From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 2 03:11: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 DAA16387 for ; Sun, 2 Dec 2001 03:11:08 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA06803; Sun, 2 Dec 2001 00:10:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA14373; Sun, 2 Dec 2001 00:07:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB285xHt025116 for ; Sun, 2 Dec 2001 00:05:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB285xcK025115 for mobile-ip-dist; Sun, 2 Dec 2001 00:05:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB285uHt025108 for ; Sun, 2 Dec 2001 00:05:56 -0800 (PST) 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 AAA24070 for ; Sun, 2 Dec 2001 00:05:56 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA16784 for ; Sun, 2 Dec 2001 00:05:55 -0800 (PST) Received: from AlperVAIO (dhcp53.docomo-usa.com [172.21.96.53]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB285r502731 for ; Sun, 2 Dec 2001 00:05:53 -0800 (PST) Message-ID: <002c01c17b07$4597fa60$356015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: Subject: Re: [mobile-ip] 0.0.0.0 src address Date: Sat, 1 Dec 2001 23:59:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 Siva, > > The foreign agent should use the link-layer address of the incoming (from > > MN) packet > > to send back the responds to the MN. So, FA can send a packet with 0.0.0.0 > > IP destination > > address and MN's link-layer address as the destination MAC address. > > > > For that, foreign agent should note the source link-layer address of the > > incoming packet. > > > > The same can also happen with simple rotuer discovery (sending router > > solicitation, and > > receiving router advertisement). Please see rfc1256. > > I agree with you regarding the usage of the link-layer address, which > is standard means to forward replies to the MN. However, from the > dicussions I have had with my "Transport" collegues regarding the > usage of 0.0.0.0 as a dest address of a IP packet, it seems that: > > The destination of 0.0.0.0 means "this machine on this network". So > by definition we CANNOT send a destination address of 0.0.0.0 onto > the network. This address is also used as a special address for DHCP > as a _source_ address. However it is not used as a destination. > > I was given RFC 1122 as a reference regarding the definition of > the destination address 0.0.0.0. Hmmm. I think I can explain how to implement this "sending to 0.0.0.0" without causing problems (using link-layer address of the incoming packet), but this still conflicts with the strict interpretation of RFC1122. I think the strict interpretation of RFC1122 considers the case "sending to 0.0.0.0", not "sending to 0.0.0.0 where you know the link-layer address of the destination". > > And for the same reason, an arp entry cannot be made at the FA to bind > the MN's link-layer address to the IP address 0.0.0.0, which is > required to forward the reply..... A similar problem occurs when we have overlaping private addresses on the same link. Two mobile nodes from two different domains can be using the same home address (10.x.y.z). Yet, by looking at the which home agent is sending the packets, the foreign agent can use the right link-layer destination address to forward them. This doesn't fit the arp table either. Also, I'm guessing we can find a spec that says no two nodes can have the same ip address on the same subnet. > > > Am I still missing something here? :-) > I think you are right these are conflicting with earlier rfcs. But, implementations can handle them. > > thanks! > > > Siva alper > > > > > > > > > > > > > > ----- Original Message ----- > > From: "Sivasundar Ramamurthy" > > To: "Mobile IP Working Group" > > Sent: Thursday, November 29, 2001 5:15 PM > > Subject: [mobile-ip] 0.0.0.0 src address > > > > > > > Hello, > > > > > > This is regarding draft rfc2002 bis-8 wrt using 0.0.0.0 as the IP > > > source of registration requests. I have only recently joined this > > > email group so please bear with me if this had been discussed earlier. > > > > > > Section 3.6.1.1 states that the Mobile Node must use 0.0.0.0 as the IP > > > source address of the registration request if it does not have a home > > > address. Section 3.7.2.3 states that the FA must use the > > > IP source of the request as IP destination address when forwarding > > > replies. > > > > > > Thus there might be cases where the FA must forward replies to the > > > address 0.0.0.0. This task appears "impossible" since rfc1122 defines > > > 0.0.0.0 as something like "this machine on this network", like > > > loopback. So a packet with destination address 0.0.0.0 might never go > > > out of the FA. > > > > > > Am I in the right here? Can someone please clarify the usage/handling > > > of 0.0.0.0 as the source address of registration requests? > > > > > > > > > Thanks in advance! > > > > > > Siva > > > > > > > > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 2 03: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 DAA16681 for ; Sun, 2 Dec 2001 03:15:36 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27457; Sun, 2 Dec 2001 01:14:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA15025; Sun, 2 Dec 2001 00:12:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB28CFHt025279 for ; Sun, 2 Dec 2001 00:12:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB28CFet025278 for mobile-ip-dist; Sun, 2 Dec 2001 00:12:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB28CBHt025271 for ; Sun, 2 Dec 2001 00:12:11 -0800 (PST) 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 AAA12330 for ; Sun, 2 Dec 2001 00:12:12 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18995 for ; Sun, 2 Dec 2001 00:12:11 -0800 (PST) Received: from AlperVAIO (dhcp53.docomo-usa.com [172.21.96.53]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB28C9502853 for ; Sun, 2 Dec 2001 00:12:10 -0800 (PST) Message-ID: <003201c17b08$25d9cc70$356015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <200112010231.SAA20942@leo.mentat.com> Subject: Re: [mobile-ip] 0.0.0.0 src address Date: Sun, 2 Dec 2001 00:05:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 Marc, > > The foreign agent should use the link-layer address of the incoming (from > > MN) packet > > to send back the responds to the MN. So, FA can send a packet with 0.0.0.0 > > IP destination > > address and MN's link-layer address as the destination MAC address. > > > > For that, foreign agent should note the source link-layer address of the > > incoming packet. > > > > The same can also happen with simple rotuer discovery (sending router > > solicitation, and > > receiving router advertisement). Please see rfc1256. > > I don't see where RFC 1256 supports the concept of *sending* to a > destination address of 0.0.0.0 so let me know if I've missed > some text. It clearly allows a router solicitation with a > *source* address of 0.0.0.0 from a host that hasn't yet determined its > own address. But the router advertisement response in such a case > doesn't go to 0.0.0.0, which would be a violation of the RFC as I read > it, but to a configured address. Here's the text excerpt from the RFC > in section 4.3 that clearly covers the source 0.0.0.0 address case in > the second sentence: > > In addition to the periodic, unsolicited advertisements, a router > sends advertisements in response to valid solicitations received on > any of its advertising interfaces. A router may choose to unicast > the response directly to the soliciting host's address (if it is not > zero), or multicast it to the interface's configured > AdvertisementAddress; in the latter case, the interface's interval > timer is reset to a new random value, as with unsolicited > advertisements. ... You are right. I missed this. I had blindly assumed advertisement must be unicasted to the solicitor. (especially because it's technically doable...) > > The rationale for a host sending with a source address of 0.0.0.0 > appears to be implied in section 5.3 as a mechanism to allow overlap of > the host's address and router discovery processes to occur in > parallel. Such a host presumably provokes an earlier multicast router > advertisement by sending the solicitation with its 0.0.0.0 source > address rather than waiting for the next periodic advertisement or > until the host has an address. This is interesting. A solicitation can cause a multicast advertisement. Not desirable for wireless systems. Bandwidth issues, and also waking up dormant nodes issue. Thanks Marc. alper > > > -- Marc -- > > From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 2 03:24: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 DAA17197 for ; Sun, 2 Dec 2001 03:24:55 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA08723; Sun, 2 Dec 2001 00:23:56 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA15882; Sun, 2 Dec 2001 00:22:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB28KpHt025435 for ; Sun, 2 Dec 2001 00:20:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB28Kpu5025434 for mobile-ip-dist; Sun, 2 Dec 2001 00:20:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB28KlHt025427 for ; Sun, 2 Dec 2001 00:20:47 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17508 for ; Sun, 2 Dec 2001 00:20:47 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29008 for ; Sun, 2 Dec 2001 01:20:29 -0700 (MST) Received: from AlperVAIO (dhcp9.docomo-usa.com [172.21.96.9]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB28Kj502992 for ; Sun, 2 Dec 2001 00:20:45 -0800 (PST) Message-ID: <00a601c17b09$592dcb20$096015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <200112010231.SAA20942@leo.mentat.com> <003201c17b08$25d9cc70$356015ac@AlperVAIO> Subject: [mobile-ip] L2 triggers draft Date: Sun, 2 Dec 2001 00:14:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 Folks, New version of L2 triggers draft is available: http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-01.txt Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems Abstract A critical factor in achieving good performance for IP mobility protocols is the design of L2 handover. Handover occurs when a Mobile Node moves from one radio Access Point to another. If the new radio Access Point is associated with a new subnet, a change in routing reachability may occur and require L3 protocol action on the part of the Mobile Node or Access Routers. If no change in subnet occurs, the Access Point may still need to take some action to inform the Access Router about a change in on-link reachability. In either case, prompt and timely information from L2 to the parties involved about the sequencing of handover can help optimize handover at the IP level. This draft discusses requirements for an L2 handover protocol or API to support optimized handover. Enjoy. alper From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 2 12:19: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 MAA24950 for ; Sun, 2 Dec 2001 12:19:14 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15995; Sun, 2 Dec 2001 10:16:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12108; Sun, 2 Dec 2001 09:16:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB2GNaHt026349 for ; Sun, 2 Dec 2001 08:23:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB2GNad3026348 for mobile-ip-dist; Sun, 2 Dec 2001 08:23:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB2GNWHt026341 for ; Sun, 2 Dec 2001 08:23:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08132 for ; Sun, 2 Dec 2001 08:23:27 -0800 (PST) Received: from out-mta3.plasa.com (out-mta3.plasa.com [202.134.0.195]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24769 for ; Sun, 2 Dec 2001 09:23:10 -0700 (MST) Received: out-mta3.plasa.com; Sun, 02 Dec 2001 23:23:00 +0700 Received: out-mta2.plasa.com; Sun, 02 Dec 2001 23:23:00 +0700 Received: from [192.168.19.56] (account ) by mail.plasa.com (CommuniGate Pro WebUser 3.4.4) with HTTP id 1517018 for ; Sun, 02 Dec 2001 23:23:00 +0700 From: "nicky muhammad ali " Subject: [mobile-ip] Low Latency MIPv4 Handover Algorithms source code for simulation To: mobile-ip@sunroof.eng.sun.com X-Mailer: CommuniGate Pro Web Mailer v.3.4.4 Date: Sun, 02 Dec 2001 23:23:00 +0700 Message-ID: In-Reply-To: <011f01c1776d$7da63630$0e02320a@T23KEMPF> 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 dear ns-users, currently i was doing my final project on handoff method analysis in mobile ip. iam having trouble mapping my algoritthm to the wireless-phy.cc code and mip-reg.cc. my work is i compare three handoffs method, original handoff method where in layer MAC handoff, the mobile host cannot send any registration request to the home agent for the new foreign agnet until mobile host really released from the old foreign agent so there occured packet loss/discard because of the handoff delay, whereas for the fast registrationmethodmobile host can send a request for the new foreign agent via the old fa to the home agent and do an ordinal handoff procedure via the new fa as well, but the request mobile host send for the new fa via old fa is without the authentication and also quickest than the ordinal procedure with this procedure the delay and packet loss can be discard.but new problem is overhead because of the doublecasting by home agent to old and new fa. where for the 3rd method, seamless hadnoff method, when mh travel in the overlap region between 2 cell and mh can receive an agent advertisement which consist of COA info, the mobile host send a registration request for the new foreign agent via old fa and then the old fa forward it to the new fa and then the new fa forward it to home agent. ha will register new fa care of address and a reply via new fa. maybe my algorithm is approximately like that. my source is from the mr ohzahata, mr shigemura journal from the ieice.or.jp site On Tue, 27 Nov 2001 10:01:08 -0800 "James Kempf" wrote: > Try http://geocities.com/kempf42/llanalysis.pdf. > > jak > ----- Original Message ----- > From: "Mike Moreton" > To: > Sent: Tuesday, November 27, 2001 12:36 AM > Subject: RE: [mobile-ip] Analysis and Comparison of Low > Latency MIPv4 > Handover Algorithms > > > > Jak, > > > > I don't think that can be the correct link... > > > > Mike > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: 26 November 2001 21:27 > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: [mobile-ip] Analysis and Comparison of Low > Latency MIPv4 > > > Handover Algorithms > > > > > > > > > Folks, > > > > > > Jon Wood and I did a study comparing PreReg, Postreg, > and > > > standard MIPv4 > > > (SMIPv4) handoff. It is at > http://www.geocities.com/llanalysis.pdf > (it > > > will shortly also appear at the DoCoMo Labs USA web > site as well). > > > Apologies for the paper format, but it is difficult > to get fine > > > depiction of experimental results in graphs using > ASCII text. > > > The study > > > describes implementation experience with the 2 low > latency > algorithms > > > (some of which Jon has already posted to the list), > and a series of > > > experiments we performed to measure the sensitivity > of all three > > > algorithms to various components of handoff latency. > Issues > > > arising from > > > the study will be discussed in a slot at the Mobile > IP Working Group > > > Meeting at IETF 52. If you have any specific issues > on the > > > study itself > > > or the paper, please post them to the list. > > > > > > jak > > > > > > > > > > > > ********************************************************************** > > This email and any files transmitted with it are > confidential and > > intended solely for the use of the individual or entity > to whom they > > are addressed. If you have received this email in error > please notify > > the system manager. > > > > This footnote also confirms that this email message has > been swept > > for the presence of computer viruses. > > > > administrator at synad.com > > ********************************************************************** > > > From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 2 17:17: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 RAA29572 for ; Sun, 2 Dec 2001 17:17:30 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10289; Sun, 2 Dec 2001 15:15:10 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07707; Sun, 2 Dec 2001 14:15:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB2MEUHt027128 for ; Sun, 2 Dec 2001 14:14:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB2METJ2027127 for mobile-ip-dist; Sun, 2 Dec 2001 14:14:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB2MEQHt027120 for ; Sun, 2 Dec 2001 14:14:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01353 for ; Sun, 2 Dec 2001 14:13:22 -0800 (PST) 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 PAA06223 for ; Sun, 2 Dec 2001 15:12:30 -0700 (MST) 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 QAA09448 for ; Sun, 2 Dec 2001 16:12:00 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id fB2MAiN04489; Sun, 2 Dec 2001 16:10:44 -0600 (CST) Message-ID: <3C0AA77F.4F307C2B@alcatel.com> Date: Sun, 02 Dec 2001 16:13:19 -0600 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com, seamoby Subject: Re: [mobile-ip] L2 triggers draft References: <200112010231.SAA20942@leo.mentat.com> <003201c17b08$25d9cc70$356015ac@AlperVAIO> <00a601c17b09$592dcb20$096015ac@AlperVAIO> 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 and WG Chairs, We have a draft which is very much related to this one at: http://search.ietf.org/internet-drafts/draft-guri-seamoby-paging-triggers-00.txt we had submitted it to SeaMoby WG because Jim's draft was discussed in London at Seamoby WG, so there is some confusion. My question is what is the next step at SLC? Will this be discussed at MIP WG, or is it in Seamoby WG domain as it was in London? Thanks in advance for any clarification. "Alper E. YEGIN" wrote: > Folks, > > New version of L2 triggers draft is available: > > http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-01.txt > > Supporting Optimized Handover for IP Mobility - > Requirements for Underlying Systems > > Abstract > > A critical factor in achieving good performance for IP mobility > protocols is the design of L2 handover. Handover occurs when a > Mobile Node moves from one radio Access Point to another. If the new > radio Access Point is associated with a new subnet, a change in > routing reachability may occur and require L3 protocol action on the > part of the Mobile Node or Access Routers. If no change in subnet > occurs, the Access Point may still need to take some action to > inform the Access Router about a change in on-link reachability. In > either case, prompt and timely information from L2 to the parties > involved about the sequencing of handover can help optimize handover > at the IP level. This draft discusses requirements for an L2 > handover protocol or API to support optimized handover. > > > Enjoy. > > alper -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 2 18:39: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 SAA00339 for ; Sun, 2 Dec 2001 18:39:02 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27313; Sun, 2 Dec 2001 16:36:50 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07374; Sun, 2 Dec 2001 15:36:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB2Na2Ht027347 for ; Sun, 2 Dec 2001 15:36:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB2Na2ns027346 for mobile-ip-dist; Sun, 2 Dec 2001 15:36:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB2NZwHt027339 for ; Sun, 2 Dec 2001 15:35:58 -0800 (PST) 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 PAA12790 for ; Sun, 2 Dec 2001 15:34:55 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11758 for ; Sun, 2 Dec 2001 15:34:55 -0800 (PST) Received: from T23KEMPF (dhcp86.docomo-usa.com [172.21.96.86]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB2NXm518031; Sun, 2 Dec 2001 15:33:48 -0800 (PST) Message-ID: <009e01c17b89$b8c4b640$566015ac@T23KEMPF> From: "James Kempf" To: , "seamoby" References: <200112010231.SAA20942@leo.mentat.com> <003201c17b08$25d9cc70$356015ac@AlperVAIO> <00a601c17b09$592dcb20$096015ac@AlperVAIO> <3C0AA77F.4F307C2B@alcatel.com> Subject: Re: [mobile-ip] L2 triggers draft Date: Sun, 2 Dec 2001 15:32:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Behcet. The Wireless Directorate has been discussing what to do about your draft and ours. We have not yet quite completed the discussion, but I am hoping that we will reach some kind of conclusion in SLC. jak ----- Original Message ----- From: "Behcet Sarikaya" To: ; "seamoby" Sent: Sunday, December 02, 2001 2:13 PM Subject: Re: [mobile-ip] L2 triggers draft > Alper and WG Chairs, > We have a draft which is very much related to this one at: > > http://search.ietf.org/internet-drafts/draft-guri-seamoby-paging-trigger s-00.txt > > we had submitted it to SeaMoby WG because Jim's draft was discussed in > London at Seamoby WG, so there is some confusion. > > My question is what is the next step at SLC? Will this be discussed at MIP > WG, or is it in Seamoby WG domain as it was in London? > > Thanks in advance for any clarification. > > "Alper E. YEGIN" wrote: > > > Folks, > > > > New version of L2 triggers draft is available: > > > > http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-01.txt > > > > Supporting Optimized Handover for IP Mobility - > > Requirements for Underlying Systems > > > > Abstract > > > > A critical factor in achieving good performance for IP mobility > > protocols is the design of L2 handover. Handover occurs when a > > Mobile Node moves from one radio Access Point to another. If the new > > radio Access Point is associated with a new subnet, a change in > > routing reachability may occur and require L3 protocol action on the > > part of the Mobile Node or Access Routers. If no change in subnet > > occurs, the Access Point may still need to take some action to > > inform the Access Router about a change in on-link reachability. In > > either case, prompt and timely information from L2 to the parties > > involved about the sequencing of handover can help optimize handover > > at the IP level. This draft discusses requirements for an L2 > > handover protocol or API to support optimized handover. > > > > > > Enjoy. > > > > alper > > -- > Behcet > > From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 2 19:00: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 TAA00555 for ; Sun, 2 Dec 2001 19:00:11 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01998; Sun, 2 Dec 2001 16:59:01 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08780; Sun, 2 Dec 2001 15:59:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB2NwFHt027520 for ; Sun, 2 Dec 2001 15:58:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB2NwE6O027518 for mobile-ip-dist; Sun, 2 Dec 2001 15:58:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB2NwBHt027510 for ; Sun, 2 Dec 2001 15:58:11 -0800 (PST) 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 PAA14309 for ; Sun, 2 Dec 2001 15:58:12 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12957 for ; Sun, 2 Dec 2001 15:58:11 -0800 (PST) Received: from T23KEMPF ([172.21.96.179]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB2NwA518472 for ; Sun, 2 Dec 2001 15:58:10 -0800 (PST) Message-ID: <000e01c17b8c$f8bf0270$b36015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Sun, 2 Dec 2001 15:56:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks, As some of you may have noticed, draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not support fast handoff for the current 802.11 MAC. While the 802.11 spec is always subject to change, it may take awhile and the IPv4 fast handoff work is supposted to be immediately deployable. We've done a short proposal for how to support fast handoff for 802.11 as it currently exists, it's at http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx t, it fits into the existing low latency framework fairly smoothly. Sorry we couldn't get this in on time, but we just figured it out in the last couple days. This proposal also has some other uses, re the low latency draft, and it is just to get the conversation started about how to fix low latency for 802.11 (that is, we don't necessary expect the WG to accept it as is, but we do want to get the problem solved). jak From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 2 19:39: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 TAA00897 for ; Sun, 2 Dec 2001 19:39:55 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA24654; Sun, 2 Dec 2001 16:37:58 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18091; Sun, 2 Dec 2001 16:37:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB30b1Ht027672 for ; Sun, 2 Dec 2001 16:37:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB30b16s027671 for mobile-ip-dist; Sun, 2 Dec 2001 16:37:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB30avHt027664 for ; Sun, 2 Dec 2001 16:36:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA18813 for ; Sun, 2 Dec 2001 16:35:56 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA00267 for ; Sun, 2 Dec 2001 17:35:55 -0700 (MST) Received: from AlperVAIO (dhcp44.docomo-usa.com [172.21.96.44]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB30Yk519165; Sun, 2 Dec 2001 16:34:47 -0800 (PST) Message-ID: <003d01c17b91$9240a8f0$2c6015ac@AlperVAIO> From: "Alper E. YEGIN" To: , "seamoby" References: <200112010231.SAA20942@leo.mentat.com> <003201c17b08$25d9cc70$356015ac@AlperVAIO> <00a601c17b09$592dcb20$096015ac@AlperVAIO> <3C0AA77F.4F307C2B@alcatel.com> <009e01c17b89$b8c4b640$566015ac@T23KEMPF> Subject: Re: [mobile-ip] L2 triggers draft Date: Sun, 2 Dec 2001 16:28:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 My opinion is, among existing working groups it best fits PILC. But, if we want to do a better job (more than L2 triggers), then I'd recommend forming a new Sub-IP working group: IP over Wireless. My 0.02 cents. Seamoby folks, please note that the new version of L2 triggers draft is at: http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-01.txt alper ----- Original Message ----- From: "James Kempf" To: ; "seamoby" Sent: Sunday, December 02, 2001 3:32 PM Subject: Re: [mobile-ip] L2 triggers draft > Behcet. > > The Wireless Directorate has been discussing what to do about your draft > and ours. We have not yet quite completed the discussion, but I am > hoping that we will reach some kind of conclusion in SLC. > > jak > > ----- Original Message ----- > From: "Behcet Sarikaya" > To: ; "seamoby" > Sent: Sunday, December 02, 2001 2:13 PM > Subject: Re: [mobile-ip] L2 triggers draft > > > > Alper and WG Chairs, > > We have a draft which is very much related to this one at: > > > > > http://search.ietf.org/internet-drafts/draft-guri-seamoby-paging-trigger > s-00.txt > > > > we had submitted it to SeaMoby WG because Jim's draft was discussed in > > London at Seamoby WG, so there is some confusion. > > > > My question is what is the next step at SLC? Will this be discussed at > MIP > > WG, or is it in Seamoby WG domain as it was in London? > > > > Thanks in advance for any clarification. > > > > "Alper E. YEGIN" wrote: > > > > > Folks, > > > > > > New version of L2 triggers draft is available: > > > > > > > http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-01.txt > > > > > > Supporting Optimized Handover for IP Mobility - > > > Requirements for Underlying Systems > > > > > > Abstract > > > > > > A critical factor in achieving good performance for IP mobility > > > protocols is the design of L2 handover. Handover occurs when a > > > Mobile Node moves from one radio Access Point to another. If the > new > > > radio Access Point is associated with a new subnet, a change in > > > routing reachability may occur and require L3 protocol action on > the > > > part of the Mobile Node or Access Routers. If no change in subnet > > > occurs, the Access Point may still need to take some action to > > > inform the Access Router about a change in on-link reachability. > In > > > either case, prompt and timely information from L2 to the parties > > > involved about the sequencing of handover can help optimize > handover > > > at the IP level. This draft discusses requirements for an L2 > > > handover protocol or API to support optimized handover. > > > > > > > > > Enjoy. > > > > > > alper > > > > -- > > Behcet > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 3 05:10:38 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25288 for ; Mon, 3 Dec 2001 05:10:37 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA18451; Mon, 3 Dec 2001 02:09:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05918; Mon, 3 Dec 2001 02:08:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3A8AHt028610 for ; Mon, 3 Dec 2001 02:08:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3A8A7K028609 for mobile-ip-dist; Mon, 3 Dec 2001 02:08:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3A86Ht028596 for ; Mon, 3 Dec 2001 02:08:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05774 for ; Mon, 3 Dec 2001 02:08:07 -0800 (PST) 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 DAA00171 for ; Mon, 3 Dec 2001 03:08:35 -0700 (MST) 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 fB3A84u02237 for ; Mon, 3 Dec 2001 11:08:04 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Dec 03 11:07:48 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Dec 2001 11:08:02 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEDF3@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Mon, 3 Dec 2001 11:06:15 +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: James, Why does draft-ietf-mobileip-lowlatency-handoffs not support 802.11? PRE-REG can be applied to 802.11 using the mobile-initiated part with a mobile trigger. The mobile trigger in this case would likely be based on signal strength measurements in the MN and the FA address could be embedded in the beacon. So I disagree that low latency needs to be fixed for 802.11. What you may have intended is that POST-REG as it is in the draft cannot be used with 802.11, but low latency has a solution which can be used for 802.11 already. /Karim > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: den 3 december 2001 00:57 > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Folks, > > As some of you may have noticed, > draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not > support fast > handoff for the current 802.11 MAC. While the 802.11 spec is always > subject to change, it may take awhile and the IPv4 fast > handoff work is > supposted to be immediately deployable. We've done a short > proposal for > how to support fast handoff for 802.11 as it currently > exists, it's at > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-han dover-00.tx t, it fits into the existing low latency framework fairly smoothly. Sorry we couldn't get this in on time, but we just figured it out in the last couple days. This proposal also has some other uses, re the low latency draft, and it is just to get the conversation started about how to fix low latency for 802.11 (that is, we don't necessary expect the WG to accept it as is, but we do want to get the problem solved). jak From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 3 10:45: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 KAA07260 for ; Mon, 3 Dec 2001 10:45:30 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12025; Mon, 3 Dec 2001 08:44:10 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14186; Mon, 3 Dec 2001 07:42:56 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3FfrHt029268 for ; Mon, 3 Dec 2001 07:41:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3FfrP9029267 for mobile-ip-dist; Mon, 3 Dec 2001 07:41:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3FfmHt029260 for ; Mon, 3 Dec 2001 07:41:48 -0800 (PST) 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 fB3Ffaq01676; Mon, 3 Dec 2001 16:41:37 +0100 (MET) Date: Mon, 3 Dec 2001 15:49:55 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] 0.0.0.0 src address To: alper@docomolabs-usa.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <002c01c17b07$4597fa60$356015ac@AlperVAIO> 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: > Hmmm. I think I can explain how to implement this "sending to 0.0.0.0" > without causing problems (using link-layer address of the incoming packet), > but this still conflicts with the strict interpretation of RFC1122. > > I think the strict interpretation of RFC1122 considers the case "sending to > 0.0.0.0", not "sending to 0.0.0.0 where you know the link-layer address > of the destination". I think you're correct. Other protocols use 0.0.0.0 as a source. For instance, DHCPv4. In that case the response it sent to 255.255.255.255 (and not 0.0.0.0) unless I'm mistaken. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 3 11:52: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 LAA13959 for ; Mon, 3 Dec 2001 11:52:04 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03524; Mon, 3 Dec 2001 09:50:45 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12888; Mon, 3 Dec 2001 08:50:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3GnmHt029491 for ; Mon, 3 Dec 2001 08:49:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3Gnm35029490 for mobile-ip-dist; Mon, 3 Dec 2001 08:49:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3GniHt029483 for ; Mon, 3 Dec 2001 08:49:44 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27614 for ; Mon, 3 Dec 2001 08:49:45 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10885 for ; Mon, 3 Dec 2001 09:49:45 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA12095 for ; Mon, 3 Dec 2001 09:49:45 -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 JAA25456 for ; Mon, 3 Dec 2001 09:49:44 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 3 Dec 2001 10:49:43 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: Singh Ajoy-ASINGH1 , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Mon, 3 Dec 2001 10:49:35 -0600 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: Here I am talking about MN trigger for pre-registration. -----Original Message----- From: Singh Ajoy-ASINGH1 Sent: Monday, December 03, 2001 10:44 AM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Hello James, I am not sure if I completely agree with this draft. I am attaching some paper from Microsoft which is not confidential. Based upon the work defined in the document, I do not sure why it is not possible to get trigger in case of 802.11. I believe we do not really need to define anything special for 802.11. I think getting L2 tigger for 802.11 looks like some implementation issues not standard issue. Any comments ? regards, ajoy -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Sunday, December 02, 2001 5:57 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 Folks, As some of you may have noticed, draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not support fast handoff for the current 802.11 MAC. While the 802.11 spec is always subject to change, it may take awhile and the IPv4 fast handoff work is supposted to be immediately deployable. We've done a short proposal for how to support fast handoff for 802.11 as it currently exists, it's at http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx t, it fits into the existing low latency framework fairly smoothly. Sorry we couldn't get this in on time, but we just figured it out in the last couple days. This proposal also has some other uses, re the low latency draft, and it is just to get the conversation started about how to fix low latency for 802.11 (that is, we don't necessary expect the WG to accept it as is, but we do want to get the problem solved). jak From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 3 11:54: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 LAA14133 for ; Mon, 3 Dec 2001 11:54:28 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16390; Mon, 3 Dec 2001 08:53:20 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13324; Mon, 3 Dec 2001 08:52:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3GpvHt029566 for ; Mon, 3 Dec 2001 08:51:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3GpveV029565 for mobile-ip-dist; Mon, 3 Dec 2001 08:51:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3GprHt029549 for ; Mon, 3 Dec 2001 08:51:53 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26050 for ; Mon, 3 Dec 2001 08:51:54 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11624 for ; Mon, 3 Dec 2001 09:51:53 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id IAA05139 for ; Mon, 3 Dec 2001 08:52:08 -0800 (PST) Received: (from marc@localhost) by leo.mentat.com (8.9.1b+Sun/8.9.1) id IAA20286 for mobile-ip@sunroof.eng.sun.com; Mon, 3 Dec 2001 08:52:08 -0800 (PST) Date: Mon, 3 Dec 2001 08:52:08 -0800 (PST) From: Marc Hasson Message-Id: <200112031652.IAA20286@leo.mentat.com> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 0.0.0.0 src address X-Sun-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, Alper > Other protocols use 0.0.0.0 as a source. For instance, DHCPv4. > In that case the response it sent to 255.255.255.255 (and not 0.0.0.0) > unless I'm mistaken. Correct. I woke up this morning with the same thought (that 0.0.0.0 source is responded to by broadcast in DHCPv4) and also remembered that in DHCPv4 its permissible/preferable to unicast the response to the newly-assigned IP destination address using the DHCP client's link-layer address. 0.0.0.0 does not appear in the IP destination field in DHCPv4 in that case, however. Its up to the DHCP'ing client to request/accept either the broadcast response or the not-yet-heard-of IP address as destination on the IP packet. The broadcast option for a DHCP server response was devised specifically for clients that would otherwise drop a DHCP response with an IP destination that they don't yet recognize as their own address-to-be. It seems to me that a Mobile Node could accept its newly-assigned non-zero unicast destination address just as well as the 0.0.0.0, it should be well-aware its in an address discovery mode analagous to DHCPv4 and process the UDP registration reply. Following the DHCP model of doing the non-zero response would take care of any RFC 1122 objection but I agree with Alper that this shouldn't be a problem for new implementations to handle in either case (if there's an objection to removing the 0.0.0.0 destination behavior thats already out there). Another way to resolve this, perhaps, would be to get a dynamic/unique IPv4 link-local address first as I believe some implementations do for non-mobility purposes. But thats more book-keeping for the MN and FA so is probably more complex than we want to do to get around a 0.0.0.0 destination address. I'm not aware of any specification, other than in this mobility draft, where 0.0.0.0 is a valid unicast IP destination in a packet so it might be nice to not have this sole exception but we can live with it if we must. Does anyone know of a non-mobility spec where this is already used? -- Marc -- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 3 12:47: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 MAA17009 for ; Mon, 3 Dec 2001 12:47:36 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18610; Mon, 3 Dec 2001 10:46:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15082; Mon, 3 Dec 2001 09:46:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3HjbHt029825 for ; Mon, 3 Dec 2001 09:45:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3HjbWc029824 for mobile-ip-dist; Mon, 3 Dec 2001 09:45:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3HjTHt029817 for ; Mon, 3 Dec 2001 09:45:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14694 for ; Mon, 3 Dec 2001 09:45:31 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10924 for ; Mon, 3 Dec 2001 10:45:27 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA22759 for ; Mon, 3 Dec 2001 10:45:26 -0700 (MST)] Received: [from il02exi01.comm.mot.com (il02exi01.comm.mot.com [145.1.204.40]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA08168 for ; Mon, 3 Dec 2001 10:45:26 -0700 (MST)] Received: by il02exi01.comm.mot.com with Internet Mail Service (5.5.2654.52) id ; Mon, 3 Dec 2001 11:45:25 -0600 Message-ID: <01FAF65DEA16D4119B95009027E78F3108A3CBB8@il02exm26.comm.mot.com> From: Lewis Adam-CAL022 To: Mobile-IP working group Subject: [mobile-ip] MN-to-MN communications in MIPv4 Date: Mon, 3 Dec 2001 11:45:14 -0600 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: I thought I read the answer to this in RFC2002, but after going back to confirm it I was unable to find it again. It is my assumption that two mobile nodes connected to the same FA should be able to by-pass normal IP routing (e.g. the need to tunnel through a HA) and route directly through the FA. I make this assumption since it would be a logical optimization since the FA has all the necessary information needed to do so (e.g. home IP address, link layer address, etc.). The only supporting text I was able to find on this in the RFC was on page 10. "Similarly, a mobile node and a prospective or current foreign agent MUST be able to exchange datagrams without relying on standard IP routing mechanisms; that is, those mechanisms which make forwarding decisions based upon the network-prefix of the destination address in the IP header. This requirement can be satisfied if the foreign agent and the visiting mobile node have an interface on the same link. In this case, the mobile node and foreign agent simply bypass their normal IP routing mechanism when sending datagrams to each other, addressing the underlying link-layer packets to their respective link-layer addresses. Other placements of the foreign agent relative to the mobile node MAY also be possible using other mechanisms to exchange datagrams between these nodes, but such placements are beyond the scope of this document." 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 Mon Dec 3 13:17: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 NAA18755 for ; Mon, 3 Dec 2001 13:17:45 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13274; Mon, 3 Dec 2001 11:16:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24540; Mon, 3 Dec 2001 10:16:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3IF1Ht029994 for ; Mon, 3 Dec 2001 10:15:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3IF120029993 for mobile-ip-dist; Mon, 3 Dec 2001 10:15:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3IEvHt029986 for ; Mon, 3 Dec 2001 10:14:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23985 for ; Mon, 3 Dec 2001 10:14:53 -0800 (PST) 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 LAA22308 for ; Mon, 3 Dec 2001 11:15:22 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fB3IEpu24358 for ; Mon, 3 Dec 2001 19:14:51 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Dec 03 19:14:51 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Dec 2001 19:14:51 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEDFD@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 Date: Mon, 3 Dec 2001 19:14:49 +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: I remember we discussed this a long time ago and it was left open as an option for the implementation. IMO it could be a useful optimisation. Not sure that the text you're referring to relates to this however and can't find it mentioned. Scenarios which were brought up where this shouldn't be done is if reverse tunneling is used or where the HA does the accounting and all the MN traffic must go through it. Rgds /Karim > -----Original Message----- > From: Lewis Adam-CAL022 [mailto:Adam.Lewis@motorola.com] > Sent: den 3 december 2001 18:45 > To: Mobile-IP working group > Subject: [mobile-ip] MN-to-MN communications in MIPv4 > > > I thought I read the answer to this in RFC2002, but after > going back to confirm it I was unable to find it again. It > is my assumption that two mobile nodes connected to the same > FA should be able to by-pass normal IP routing (e.g. the > need to tunnel through a HA) and route directly through the > FA. I make this assumption since it would be a logical > optimization since the FA has all the necessary information > needed to do so (e.g. home IP address, link layer address, > etc.). The only supporting text I was able to find on this > in the RFC was on page 10. > > "Similarly, a mobile node and a prospective or current > foreign agent MUST be able to exchange datagrams without > relying on standard IP routing mechanisms; that is, those > mechanisms which make forwarding decisions based upon the > network-prefix of the destination address in the IP header. > This requirement can be satisfied if the foreign agent and > the visiting mobile node have an interface on the same link. > In this case, the mobile node and foreign agent simply > bypass their normal IP routing mechanism when sending > datagrams to each other, addressing the underlying > link-layer packets to their respective link-layer addresses. > Other placements of the foreign agent relative to the mobile > node MAY also be possible using other mechanisms to exchange > datagrams between these nodes, but such placements are > beyond the scope of this document." > > 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 Mon Dec 3 16:18:20 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 QAA01619 for ; Mon, 3 Dec 2001 16:18:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA24009; Mon, 3 Dec 2001 13:17:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17451; Mon, 3 Dec 2001 13:17:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3LF0Ht000403 for ; Mon, 3 Dec 2001 13:15:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3LF0Z8000402 for mobile-ip-dist; Mon, 3 Dec 2001 13:15:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.85.105] (may be forged)) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3LEuHt000395 for ; Mon, 3 Dec 2001 13:14:56 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fB3LEvEu876414; Mon, 3 Dec 2001 13:14:58 -0800 (PST) Message-Id: <200112032114.fB3LEvEu876414@jurassic.eng.sun.com> Date: Mon, 3 Dec 2001 13:16:45 -0800 (PST) From: Samita Chakrabarti Subject: Re: [mobile-ip] 0.0.0.0 src address To: mobile-ip@sunroof.eng.sun.com Cc: marc@mentat.com, alper@docomolabs-usa.com, Erik.Nordmark@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: /6yuP6fi08K338YkX3pP6Q== 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: > > I woke up this morning with the same thought (that 0.0.0.0 source is > responded to by broadcast in DHCPv4) and also remembered that in DHCPv4 > its permissible/preferable to unicast the response to the > newly-assigned IP destination address using the DHCP client's > link-layer address. 0.0.0.0 does not appear in the IP destination > field in DHCPv4 in that case, however. Its up to the DHCP'ing client > to request/accept either the broadcast response or the not-yet-heard-of > IP address as destination on the IP packet. The broadcast option for a > DHCP server response was devised specifically for clients that would > otherwise drop a DHCP response with an IP destination that they don't > yet recognize as their own address-to-be. > > It seems to me that a Mobile Node could accept its newly-assigned > non-zero unicast destination address just as well as the 0.0.0.0, it > should be well-aware its in an address discovery mode analagous to > DHCPv4 and process the UDP registration reply. > Is there any mobile node implementation which accepts UDP registration reply destined to a newly assigned address and it's own link-layer address while it sends the request with src-addr=0.0.0.0 ? As it was pointed out that it is possible for an implementation to implement this behavior in MN. I think the mobile-ip base draft rfc2002-bis needs to clarify the restriction on having src-addr = 0.0.0.0 and the consequent dst-addr for the registration reply from FA to MN. Note that it is also possible that FA may find that the registration request from src-addr=0.0.0.0 and home-addr=0.0.0.0 is poorly-formatted or some other problem, how does it reply back with error then ? ( Due to the restriction in RFC1122 ) Should it drop the packet or send it to multicast addr ? I wonder, why rfc2002-bis has a MUST in 3.6.1.1, could it be MAY ? For example, what if any MN configures itself with a temporary address to send the reg-req with home-addr=0, to get it's newly-assigned homeaddr? > - If the mobile node does not have a home address, the IP source address MUST be 0.0.0.0. Also the draft needs to clarify that if the source-addr of the UDP registration request is 0.0.0.0, then what will be the IP dst addr for the regReply. -Samita From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 3 16:25: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 QAA02237 for ; Mon, 3 Dec 2001 16:25:46 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26615; Mon, 3 Dec 2001 13:22:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19494; Mon, 3 Dec 2001 13:22:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3LLfHt000543 for ; Mon, 3 Dec 2001 13:21:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3LLfpB000542 for mobile-ip-dist; Mon, 3 Dec 2001 13:21:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3LLcHt000535 for ; Mon, 3 Dec 2001 13:21:38 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18766 for ; Mon, 3 Dec 2001 13:20:36 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03499 for ; Mon, 3 Dec 2001 14:19:15 -0700 (MST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fB3LKFQ05167 for ; Mon, 3 Dec 2001 15:20:15 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Dec 2001 15:19:14 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 3 Dec 2001 15:19:14 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [mobile-ip] L2 triggers draft Date: Mon, 3 Dec 2001 15:19:14 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD1B8@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] L2 triggers draft Thread-Index: AcF7fy0LG1UT1OdtEdWBUQBQi2X+DwAwIoGg From: "Patil Basavaraj (NET/Dallas)" To: , "seamoby" Cc: X-OriginalArrivalTime: 03 Dec 2001 21:19:14.0583 (UTC) FILETIME=[28B5AA70:01C17C40] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fB3LLcHt000536 Sender: owner-mobile-ip@sunroof.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 Behcet Sarikaya wrote: > > Alper and WG Chairs, > We have a draft which is very much related to this one at: > > http://search.ietf.org/internet-drafts/draft-guri-seamoby-paging-trigger s-00.txt > > we had submitted it to SeaMoby WG because Jim's draft was discussed in > London at Seamoby WG, so there is some confusion. > > My question is what is the next step at SLC? Will this be discussed at MIP > WG, or is it in Seamoby WG domain as it was in London? L2 triggers will not be discussed in the MIP WG meeting at SLC. While we do realize the importance of L2 triggers in enabling low-latency (MIPv4) and fast handoff (MIPv6), it is still undetermined as to in what WG or area of the IETF to do work related to this. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 3 16:33: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 QAA02896 for ; Mon, 3 Dec 2001 16:33:45 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01035; Mon, 3 Dec 2001 13:32:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22490; Mon, 3 Dec 2001 13:31:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3LUaHt000704 for ; Mon, 3 Dec 2001 13:30:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3LUaud000703 for mobile-ip-dist; Mon, 3 Dec 2001 13:30:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3LUVHt000696 for ; Mon, 3 Dec 2001 13:30:32 -0800 (PST) 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 fB3LUOq02828; Mon, 3 Dec 2001 22:30:25 +0100 (MET) Date: Mon, 3 Dec 2001 21:25:34 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 To: Karim.El-Malki@era.ericsson.se Cc: "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <795A014AF92DD21182AF0008C7A404320DFBEDFD@esealnt117> 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 remember we discussed this a long time ago and it was left > open as an option for the implementation. IMO it could be a > useful optimisation. Not sure that the text you're referring to > relates to this however and can't find it mentioned. Scenarios > which were brought up where this shouldn't be done is if reverse > tunneling is used or where the HA does the accounting and all the > MN traffic must go through it. So if it is optional for FAs to implement such a short-cut, how can a HA that wants to see all packets sent to the MN (e.g. for accounting reasons) turn off such optional behavior in the FA? I would see to me that if the WG wants to allow both FA short-cuts and MNs seeing all packets that there would have to be a way to indicate the desire to enable or disable the shortcut in the registration message(s). The reverse tunneling case is more obvious - if the FA is doing reverse tunneling it shouldn't do short cuts to or from that MN. (The MN might have a private home address in which case it can't let those packets "escape" the bidirectional tunnel.) Erik > Rgds > /Karim > > > -----Original Message----- > > From: Lewis Adam-CAL022 [mailto:Adam.Lewis@motorola.com] > > Sent: den 3 december 2001 18:45 > > To: Mobile-IP working group > > Subject: [mobile-ip] MN-to-MN communications in MIPv4 > > > > > > I thought I read the answer to this in RFC2002, but after > > going back to confirm it I was unable to find it again. It > > is my assumption that two mobile nodes connected to the same > > FA should be able to by-pass normal IP routing (e.g. the > > need to tunnel through a HA) and route directly through the > > FA. I make this assumption since it would be a logical > > optimization since the FA has all the necessary information > > needed to do so (e.g. home IP address, link layer address, > > etc.). The only supporting text I was able to find on this > > in the RFC was on page 10. > > > > "Similarly, a mobile node and a prospective or current > > foreign agent MUST be able to exchange datagrams without > > relying on standard IP routing mechanisms; that is, those > > mechanisms which make forwarding decisions based upon the > > network-prefix of the destination address in the IP header. > > This requirement can be satisfied if the foreign agent and > > the visiting mobile node have an interface on the same link. > > In this case, the mobile node and foreign agent simply > > bypass their normal IP routing mechanism when sending > > datagrams to each other, addressing the underlying > > link-layer packets to their respective link-layer addresses. > > Other placements of the foreign agent relative to the mobile > > node MAY also be possible using other mechanisms to exchange > > datagrams between these nodes, but such placements are > > beyond the scope of this document." > > > > 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 Mon Dec 3 18:58: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 SAA13869 for ; Mon, 3 Dec 2001 18:58:25 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA17324; Mon, 3 Dec 2001 16:57:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22678; Mon, 3 Dec 2001 15:55:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3NscHt001152 for ; Mon, 3 Dec 2001 15:54:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB3NscYw001151 for mobile-ip-dist; Mon, 3 Dec 2001 15:54:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB3NsZHt001144 for ; Mon, 3 Dec 2001 15:54:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA20554 for ; Mon, 3 Dec 2001 15:54:36 -0800 (PST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01784 for ; Mon, 3 Dec 2001 16:54:26 -0700 (MST) Received: from research.telcordia.com (ar8-236 [192.4.8.236]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id fB3NsJkY018448; Mon, 3 Dec 2001 18:54:19 -0500 (EST) Message-ID: <3C0C1171.F86AD022@research.telcordia.com> Date: Mon, 03 Dec 2001 18:57:37 -0500 From: subir Das X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: Basavaraj.Patil@nokia.com Subject: [mobile-ip] Slides References: <200112010231.SAA20942@leo.mentat.com> <003201c17b08$25d9cc70$356015ac@AlperVAIO> <00a601c17b09$592dcb20$096015ac@AlperVAIO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alper, Pl. send your talk (for 10 mins) slides latest by Dec 10th. Thanks, Subir From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 3 19:35: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 TAA16103 for ; Mon, 3 Dec 2001 19:35:48 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA13645; Mon, 3 Dec 2001 16:34:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03692; Mon, 3 Dec 2001 16:33:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB40WLHt001415 for ; Mon, 3 Dec 2001 16:32:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB40WLnn001414 for mobile-ip-dist; Mon, 3 Dec 2001 16:32:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB40WHHt001407 for ; Mon, 3 Dec 2001 16:32:17 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28673 for ; Mon, 3 Dec 2001 16:32:19 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA13312 for ; Mon, 3 Dec 2001 17:32:19 -0700 (MST) Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.24.15]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fB40W3s00983; Mon, 3 Dec 2001 16:32:07 -0800 (PST) Received: from gdommety-w2k9.cisco.com (tmeskuna-w2k.cisco.com [171.70.57.8]) by mira-sjcm-3.cisco.com (Mirapoint) with ESMTP id ACS82397; Mon, 3 Dec 2001 16:23:40 -0800 (PST) Message-Id: <4.3.2.7.2.20011203163345.02682ae0@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 03 Dec 2001 16:36:35 -0800 To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com From: Gopal Dommety Subject: [mobile-ip] draft-ietf-mobileip-fast-mipv6-04.txt Cc: Basavaraj.Patil@nokia.com In-Reply-To: <3C0C1171.F86AD022@research.telcordia.com> References: <200112010231.SAA20942@leo.mentat.com> <003201c17b08$25d9cc70$356015ac@AlperVAIO> <00a601c17b09$592dcb20$096015ac@AlperVAIO> 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: A newer version of the Draft that addresses a lot comments sent to me can be found at: http://people.nokia.net/~patil/Internet_Drafts/draft-ietf-mobileip-fast-mipv6-04.txt Thanks Gopal From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 05:54: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 FAA23122 for ; Tue, 4 Dec 2001 05:54:43 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA10093; Tue, 4 Dec 2001 02:53:41 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08977; Tue, 4 Dec 2001 02:53:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4AqXHt002442 for ; Tue, 4 Dec 2001 02:52:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4AqXRH002441 for mobile-ip-dist; Tue, 4 Dec 2001 02:52:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4AqTHt002434 for ; Tue, 4 Dec 2001 02:52:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08875 for ; Tue, 4 Dec 2001 02:52:31 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26164 for ; Tue, 4 Dec 2001 03:52:30 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fB4AqTu03530 for ; Tue, 4 Dec 2001 11:52:29 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Dec 04 11:52:23 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 11:44:05 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEDFF@esealnt117> From: "Karim El-Malki (ERA)" To: "'Erik Nordmark'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 Date: Tue, 4 Dec 2001 10:50:42 +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: > > I remember we discussed this a long time ago and it was left > > open as an option for the implementation. IMO it could be a > > useful optimisation. Not sure that the text you're referring to > > relates to this however and can't find it mentioned. Scenarios > > which were brought up where this shouldn't be done is if reverse > > tunneling is used or where the HA does the accounting and all the > > MN traffic must go through it. > > So if it is optional for FAs to implement such a short-cut, how > can a HA that wants to see all packets sent to the MN (e.g. for > accounting reasons) turn off such optional behavior in the FA? > > I would see to me that if the WG wants to allow both FA short-cuts > and MNs seeing all packets that there would have to be a way to > indicate the desire to enable or disable the shortcut in the > registration > message(s). > > The reverse tunneling case is more obvious - if the FA is > doing reverse > tunneling it shouldn't do short cuts to or from that MN. > (The MN might have a private home address in which case it > can't let those > packets "escape" the bidirectional tunnel.) What I should have written is that it wasn't clear what scenario would require all packets to go through the HA, while reverse tunneling was more obvious. The accounting can be done in the FA. Is there any other scenario where all traffic must go through the HA? If not then this shortcut may be done by the FA if bidirectional tunneling is not used. Otherwise I agree with what you're saying. /Karim From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 06:01: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 GAA23228 for ; Tue, 4 Dec 2001 06:01:58 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA03022; Tue, 4 Dec 2001 04:00:45 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09777; Tue, 4 Dec 2001 03:00:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4B0BHt002593 for ; Tue, 4 Dec 2001 03:00:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4B0BW5002592 for mobile-ip-dist; Tue, 4 Dec 2001 03:00:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4B07Ht002585 for ; Tue, 4 Dec 2001 03:00:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28408 for ; Tue, 4 Dec 2001 03:00:07 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA13200 for ; Tue, 4 Dec 2001 04:00:35 -0700 (MST) Received: from T23KEMPF (dhcp155.docomo-usa.com [172.21.96.155]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB4Axx516308 for ; Tue, 4 Dec 2001 02:59:59 -0800 (PST) Message-ID: <004301c17cb2$980a0160$9b6015ac@T23KEMPF> From: "James Kempf" To: References: <795A014AF92DD21182AF0008C7A404320DFBEDF3@esealnt117> Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 4 Dec 2001 02:58:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Karim, The MN in 802.11 does a reassociation without any trigger to Layer 3, at least, that is how it currently works. One could make the modification you suggest below, however, it would be a change in the way the 802.11 protocol works. If you simply modify the driver to look at signal strength, then deliver a pre-Layer 2 trigger based on that, the MN may very well decide to move to another Access Point if the signal strength of that AP meets the criteria. As far as I understand, there is no way given the current 802.11 protocol to fix the new AP in advance of the Layer 2 handover. At best, given current 802.11, one could imagine delivering a pre-Layer 2 trigger as soon as the MN sent the 802.11 reassociation message (the Link Down trigger), but this would not give Prereg enough time to complete any messaging through the old AP. jak ----- Original Message ----- From: "Karim El-Malki (ERA)" To: Sent: Monday, December 03, 2001 2:06 AM Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > James, > > Why does draft-ietf-mobileip-lowlatency-handoffs not support 802.11? > PRE-REG can be applied to 802.11 using the mobile-initiated part with > a mobile trigger. The mobile trigger in this case would likely be based > on signal strength measurements in the MN and the FA address could be > embedded in the beacon. So I disagree that low latency needs to be fixed > for 802.11. What you may have intended is that POST-REG as it is in the > draft cannot be used with 802.11, but low latency has a solution which > can be used for 802.11 already. > > /Karim > > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: den 3 december 2001 00:57 > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > Folks, > > > > As some of you may have noticed, > > draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not > > support fast > > handoff for the current 802.11 MAC. While the 802.11 spec is always > > subject to change, it may take awhile and the IPv4 fast > > handoff work is > > supposted to be immediately deployable. We've done a short > > proposal for > > how to support fast handoff for 802.11 as it currently > > exists, it's at > > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-han > dover-00.tx > t, it fits into the existing > low latency framework fairly smoothly. Sorry we couldn't get this in on > time, but we just figured it out in the last couple days. This proposal > also has some other uses, re the low latency draft, and it is just to > get the conversation started about how to fix low latency for 802.11 > (that is, we don't necessary expect the WG to accept it as is, but we do > want to get the problem solved). > > jak > From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 06:19: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 GAA23412 for ; Tue, 4 Dec 2001 06:19:49 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA17566; Tue, 4 Dec 2001 03:18:51 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12426; Tue, 4 Dec 2001 03:18:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4BHlHt002789 for ; Tue, 4 Dec 2001 03:17:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4BHl5S002788 for mobile-ip-dist; Tue, 4 Dec 2001 03:17:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4BHhHt002781 for ; Tue, 4 Dec 2001 03:17:43 -0800 (PST) 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 DAA11233 for ; Tue, 4 Dec 2001 03:17:42 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15406 for ; Tue, 4 Dec 2001 03:17:42 -0800 (PST) Received: from T23KEMPF (dhcp155.docomo-usa.com [172.21.96.155]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB4BHd518374; Tue, 4 Dec 2001 03:17:39 -0800 (PST) Message-ID: <00b601c17cb5$10201f70$9b6015ac@T23KEMPF> From: "James Kempf" To: , "Singh Ajoy-ASINGH1" References: Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 4 Dec 2001 03:16:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Ajoy, Well, perhaps I am wrong then and it would supplying a pre-Layer 2 trigger is simply an implementation issue. I think the draft still has some value for Postreg, as Karim mentioned. BTW, the paper you mentioned wasn't attached. jak ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "Singh Ajoy-ASINGH1" ; Sent: Monday, December 03, 2001 8:49 AM Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > Here I am talking about MN trigger for pre-registration. > > -----Original Message----- > From: Singh Ajoy-ASINGH1 > Sent: Monday, December 03, 2001 10:44 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Hello James, > I am not sure if I completely agree with this draft. I am > attaching some paper from Microsoft which is not > confidential. Based upon the work defined in > the document, I do not sure why it is not possible to > get trigger in case of 802.11. I believe we do not > really need to define anything special for > 802.11. I think getting L2 tigger for 802.11 looks like > some implementation issues not standard issue. Any > comments ? > regards, > ajoy > > > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Sunday, December 02, 2001 5:57 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Folks, > > As some of you may have noticed, > draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not support fast > handoff for the current 802.11 MAC. While the 802.11 spec is always > subject to change, it may take awhile and the IPv4 fast handoff work is > supposted to be immediately deployable. We've done a short proposal for > how to support fast handoff for 802.11 as it currently exists, it's at > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx > t, it fits into the existing > low latency framework fairly smoothly. Sorry we couldn't get this in on > time, but we just figured it out in the last couple days. This proposal > also has some other uses, re the low latency draft, and it is just to > get the conversation started about how to fix low latency for 802.11 > (that is, we don't necessary expect the WG to accept it as is, but we do > want to get the problem solved). > > jak > From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 06:28: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 GAA23477 for ; Tue, 4 Dec 2001 06:28:01 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15695; Tue, 4 Dec 2001 04:26:50 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13283; Tue, 4 Dec 2001 03:27:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4BQNHt002970 for ; Tue, 4 Dec 2001 03:26:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4BQNXG002969 for mobile-ip-dist; Tue, 4 Dec 2001 03:26:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4BQJHt002962 for ; Tue, 4 Dec 2001 03:26:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04858 for ; Tue, 4 Dec 2001 03:26:19 -0800 (PST) From: Dan.Forsberg@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18487 for ; Tue, 4 Dec 2001 04:26:18 -0700 (MST) 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 fB4BR2A01085 for ; Tue, 4 Dec 2001 13:27:02 +0200 (EET) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Dec 2001 13:26:15 +0200 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 4 Dec 2001 13:26:15 +0200 Message-ID: To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 4 Dec 2001 13:25:45 +0200 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, One comment below. > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 04. December 2001 12:58 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Karim, > > The MN in 802.11 does a reassociation without any trigger to > Layer 3, at > least, that is how it currently works. > One could make the modification you suggest below, however, > it would be > a change in the way the 802.11 > protocol works. If you simply modify the driver to look at signal > strength, then deliver a pre-Layer 2 trigger > based on that, the MN may very well decide to move to another Access > Point if the signal strength of that > AP meets the criteria. As far as I understand, there is no > way given the > current 802.11 protocol to fix the new AP in advance of the Layer 2 > handover. This could be great help for vertical handovers also. The l3 would know the different l2 technologies and be able to compare them, choose the best according to the settings (policies). This is the approach that Dynamics - HUT Mobile IPv4 has taken. Just think for example GPRS, ethernet, wlan, bluetooth and infrared together: many possibilities, different characteristics and different costs. It would be nice to have a standard way to compare these possible connections... and use them according to the settings of the user. - Dan > At best, given current 802.11, one could imagine delivering a > pre-Layer > 2 trigger as soon > as the MN sent the 802.11 reassociation message (the Link > Down trigger), > but this would not give Prereg > enough time to complete any messaging through the old AP. > > jak > > ----- Original Message ----- > From: "Karim El-Malki (ERA)" > To: > Sent: Monday, December 03, 2001 2:06 AM > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > James, > > > > Why does draft-ietf-mobileip-lowlatency-handoffs not support 802.11? > > PRE-REG can be applied to 802.11 using the mobile-initiated > part with > > a mobile trigger. The mobile trigger in this case would likely be > based > > on signal strength measurements in the MN and the FA > address could be > > embedded in the beacon. So I disagree that low latency needs to be > fixed > > for 802.11. What you may have intended is that POST-REG as it is in > the > > draft cannot be used with 802.11, but low latency has a > solution which > > can be used for 802.11 already. > > > > /Karim > > > > > > > -----Original Message----- > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: den 3 december 2001 00:57 > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > > > Folks, > > > > > > As some of you may have noticed, > > > draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not > > > support fast > > > handoff for the current 802.11 MAC. While the 802.11 > spec is always > > > subject to change, it may take awhile and the IPv4 fast > > > handoff work is > > > supposted to be immediately deployable. We've done a short > > > proposal for > > > how to support fast handoff for 802.11 as it currently > > > exists, it's at > > > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-han > > dover-00.tx > > t, it fits into the existing > > low latency framework fairly smoothly. Sorry we couldn't get this in > on > > time, but we just figured it out in the last couple days. This > proposal > > also has some other uses, re the low latency draft, and it > is just to > > get the conversation started about how to fix low latency for 802.11 > > (that is, we don't necessary expect the WG to accept it as > is, but we > do > > want to get the problem solved). > > > > jak > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 06:41: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 GAA23611 for ; Tue, 4 Dec 2001 06:41:50 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22434; Tue, 4 Dec 2001 04:40:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14909; Tue, 4 Dec 2001 03:40:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4Be2Ht003140 for ; Tue, 4 Dec 2001 03:40:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4Be2q7003139 for mobile-ip-dist; Tue, 4 Dec 2001 03:40:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4BdwHt003132 for ; Tue, 4 Dec 2001 03:39:58 -0800 (PST) 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 DAA06365 for ; Tue, 4 Dec 2001 03:39:58 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA24237 for ; Tue, 4 Dec 2001 03:39:57 -0800 (PST) Received: from T23KEMPF (dhcp155.docomo-usa.com [172.21.96.155]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB4Bdt518939 for ; Tue, 4 Dec 2001 03:39:55 -0800 (PST) Message-ID: <01a401c17cb8$2c09c8f0$9b6015ac@T23KEMPF> From: "James Kempf" To: References: Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 4 Dec 2001 03:38:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dan, There is an issue with comparibility. How would one compare, say, signal strength measurements for 802.11 with those for GPRS (presuming one could get that information from GPRS)? Also, I don't think this is a protocol issue, it is more of an API issue. jak ----- Original Message ----- From: To: Sent: Tuesday, December 04, 2001 3:25 AM Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > Hi, > > One comment below. > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: 04. December 2001 12:58 > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > Karim, > > > > The MN in 802.11 does a reassociation without any trigger to > > Layer 3, at > > least, that is how it currently works. > > One could make the modification you suggest below, however, > > it would be > > a change in the way the 802.11 > > protocol works. If you simply modify the driver to look at signal > > strength, then deliver a pre-Layer 2 trigger > > based on that, the MN may very well decide to move to another Access > > Point if the signal strength of that > > AP meets the criteria. As far as I understand, there is no > > way given the > > current 802.11 protocol to fix the new AP in advance of the Layer 2 > > handover. > > This could be great help for vertical handovers also. The l3 would know the > different l2 technologies and be able to compare them, choose the best > according to the settings (policies). This is the approach that Dynamics - > HUT Mobile IPv4 has taken. > > Just think for example GPRS, ethernet, wlan, bluetooth and infrared > together: many possibilities, different characteristics and different costs. > It would be nice to have a standard way to compare these possible > connections... and use them according to the settings of the user. > > - Dan > > > > At best, given current 802.11, one could imagine delivering a > > pre-Layer > > 2 trigger as soon > > as the MN sent the 802.11 reassociation message (the Link > > Down trigger), > > but this would not give Prereg > > enough time to complete any messaging through the old AP. > > > > jak > > > > ----- Original Message ----- > > From: "Karim El-Malki (ERA)" > > To: > > Sent: Monday, December 03, 2001 2:06 AM > > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > James, > > > > > > Why does draft-ietf-mobileip-lowlatency-handoffs not support 802.11? > > > PRE-REG can be applied to 802.11 using the mobile-initiated > > part with > > > a mobile trigger. The mobile trigger in this case would likely be > > based > > > on signal strength measurements in the MN and the FA > > address could be > > > embedded in the beacon. So I disagree that low latency needs to be > > fixed > > > for 802.11. What you may have intended is that POST-REG as it is in > > the > > > draft cannot be used with 802.11, but low latency has a > > solution which > > > can be used for 802.11 already. > > > > > > /Karim > > > > > > > > > > -----Original Message----- > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: den 3 december 2001 00:57 > > > > To: mobile-ip@sunroof.eng.sun.com > > > > Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > > > > > > Folks, > > > > > > > > As some of you may have noticed, > > > > draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not > > > > support fast > > > > handoff for the current 802.11 MAC. While the 802.11 > > spec is always > > > > subject to change, it may take awhile and the IPv4 fast > > > > handoff work is > > > > supposted to be immediately deployable. We've done a short > > > > proposal for > > > > how to support fast handoff for 802.11 as it currently > > > > exists, it's at > > > > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-han > > > dover-00.tx > > > t, it fits into the existing > > > low latency framework fairly smoothly. Sorry we couldn't get this in > > on > > > time, but we just figured it out in the last couple days. This > > proposal > > > also has some other uses, re the low latency draft, and it > > is just to > > > get the conversation started about how to fix low latency for 802.11 > > > (that is, we don't necessary expect the WG to accept it as > > is, but we > > do > > > want to get the problem solved). > > > > > > jak > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 08:01:04 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24720 for ; Tue, 4 Dec 2001 08:01:03 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA25109; Tue, 4 Dec 2001 05:59:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20029; Tue, 4 Dec 2001 04:59:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4Cx1Ht003358 for ; Tue, 4 Dec 2001 04:59:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4Cx1R8003357 for mobile-ip-dist; Tue, 4 Dec 2001 04:59:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4CwwHt003350 for ; Tue, 4 Dec 2001 04:58:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA12358 for ; Tue, 4 Dec 2001 04:58:58 -0800 (PST) From: Dan.Forsberg@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 FAA13433 for ; Tue, 4 Dec 2001 05:58:23 -0700 (MST) 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 fB4CwZA05403 for ; Tue, 4 Dec 2001 14:58:35 +0200 (EET) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Dec 2001 14:57:44 +0200 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Tue, 4 Dec 2001 14:57:44 +0200 Message-ID: To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 4 Dec 2001 14:57:33 +0200 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, It's not plain API issue because it relates to the handoff decisions and mechanisms. Is there any WG that is working with this? - Dan > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 04. December 2001 13:38 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Dan, > > There is an issue with comparibility. How would one compare, > say, signal > strength measurements for 802.11 with > those for GPRS (presuming one could get that information from GPRS)? > > Also, I don't think this is a protocol issue, it is more of an API > issue. > > jak > > ----- Original Message ----- > From: > To: > Sent: Tuesday, December 04, 2001 3:25 AM > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > Hi, > > > > One comment below. > > > > > -----Original Message----- > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: 04. December 2001 12:58 > > > To: mobile-ip@sunroof.eng.sun.com > > > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > > > Karim, > > > > > > The MN in 802.11 does a reassociation without any trigger to > > > Layer 3, at > > > least, that is how it currently works. > > > One could make the modification you suggest below, however, > > > it would be > > > a change in the way the 802.11 > > > protocol works. If you simply modify the driver to look at signal > > > strength, then deliver a pre-Layer 2 trigger > > > based on that, the MN may very well decide to move to > another Access > > > Point if the signal strength of that > > > AP meets the criteria. As far as I understand, there is no > > > way given the > > > current 802.11 protocol to fix the new AP in advance of > the Layer 2 > > > handover. > > > > This could be great help for vertical handovers also. The l3 would > know the > > different l2 technologies and be able to compare them, > choose the best > > according to the settings (policies). This is the approach that > Dynamics - > > HUT Mobile IPv4 has taken. > > > > Just think for example GPRS, ethernet, wlan, bluetooth and infrared > > together: many possibilities, different characteristics and > different > costs. > > It would be nice to have a standard way to compare these possible > > connections... and use them according to the settings of the user. > > > > - Dan > > > > > > > At best, given current 802.11, one could imagine delivering a > > > pre-Layer > > > 2 trigger as soon > > > as the MN sent the 802.11 reassociation message (the Link > > > Down trigger), > > > but this would not give Prereg > > > enough time to complete any messaging through the old AP. > > > > > > jak > > > > > > ----- Original Message ----- > > > From: "Karim El-Malki (ERA)" > > > To: > > > Sent: Monday, December 03, 2001 2:06 AM > > > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > > > > James, > > > > > > > > Why does draft-ietf-mobileip-lowlatency-handoffs not support > 802.11? > > > > PRE-REG can be applied to 802.11 using the mobile-initiated > > > part with > > > > a mobile trigger. The mobile trigger in this case would > likely be > > > based > > > > on signal strength measurements in the MN and the FA > > > address could be > > > > embedded in the beacon. So I disagree that low latency > needs to be > > > fixed > > > > for 802.11. What you may have intended is that POST-REG as it is > in > > > the > > > > draft cannot be used with 802.11, but low latency has a > > > solution which > > > > can be used for 802.11 already. > > > > > > > > /Karim > > > > > > > > > > > > > -----Original Message----- > > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > > Sent: den 3 december 2001 00:57 > > > > > To: mobile-ip@sunroof.eng.sun.com > > > > > Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > > > > > > > > > Folks, > > > > > > > > > > As some of you may have noticed, > > > > > draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not > > > > > support fast > > > > > handoff for the current 802.11 MAC. While the 802.11 > > > spec is always > > > > > subject to change, it may take awhile and the IPv4 fast > > > > > handoff work is > > > > > supposted to be immediately deployable. We've done a short > > > > > proposal for > > > > > how to support fast handoff for 802.11 as it currently > > > > > exists, it's at > > > > > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-han > > > > dover-00.tx > > > > t, it fits into the existing > > > > low latency framework fairly smoothly. Sorry we > couldn't get this > in > > > on > > > > time, but we just figured it out in the last couple days. This > > > proposal > > > > also has some other uses, re the low latency draft, and it > > > is just to > > > > get the conversation started about how to fix low latency for > 802.11 > > > > (that is, we don't necessary expect the WG to accept it as > > > is, but we > > > do > > > > want to get the problem solved). > > > > > > > > jak > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 08:24: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 IAA25223 for ; Tue, 4 Dec 2001 08:24:46 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA24236; Tue, 4 Dec 2001 05:23:41 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23174; Tue, 4 Dec 2001 05:23:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4DMlHt003539 for ; Tue, 4 Dec 2001 05:22:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4DMlHS003538 for mobile-ip-dist; Tue, 4 Dec 2001 05:22:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4DMiHt003531 for ; Tue, 4 Dec 2001 05:22:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23530 for ; Tue, 4 Dec 2001 05:22:44 -0800 (PST) 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 GAA26854 for ; Tue, 4 Dec 2001 06:23:14 -0700 (MST) 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.11.0/WIREfire-1.3) with SMTP id fB4DMgf19449 for ; Tue, 4 Dec 2001 14:22:42 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Tue Dec 04 14:22:28 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 14:22:41 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEE01@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 4 Dec 2001 14:22:25 +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: > Well, perhaps I am wrong then and it would supplying a pre-Layer 2 > trigger is simply an implementation issue. I think the > draft still has some value for Postreg, as Karim mentioned. It is an implementation issue and the document Ajoy tried to send out explained how Windows NDIS can provide these triggers. In 802.11 the MN can scan for beacons and these could contain the corresponding FA identifiers (IP/MAC) in the SSID field. Signal strengths and error rates can also be provided. So 802.11 can supply trigger information to the MN's upper layers. The point I was trying to make is that low latency already supports 802.11 and no change needs to be made to that spec to support it. I was not saying that we should add anything. /Karim From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 08:46: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 IAA25509 for ; Tue, 4 Dec 2001 08:46:01 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA01434; Tue, 4 Dec 2001 05:45:03 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA25779; Tue, 4 Dec 2001 05:44:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4Di0Ht003710 for ; Tue, 4 Dec 2001 05:44:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4Di0j6003709 for mobile-ip-dist; Tue, 4 Dec 2001 05:44:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4DhtHt003702 for ; Tue, 4 Dec 2001 05:43:56 -0800 (PST) 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 fB4Dhoq01093; Tue, 4 Dec 2001 14:43:50 +0100 (MET) Date: Tue, 4 Dec 2001 14:42:23 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 To: "Karim El-Malki (ERA)" Cc: "'Erik Nordmark'" , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <795A014AF92DD21182AF0008C7A404320DFBEDFF@esealnt117> 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 should have written is that it wasn't clear what scenario would > require all packets to go through the HA, while reverse tunneling was > more obvious. The accounting can be done in the FA. Is there any other > scenario where all traffic must go through the HA? If not then this > shortcut may be done by the FA if bidirectional tunneling is not used. > Otherwise I agree with what you're saying. I don't know if folks have built or are building MIPv4 FAs that collect accounting information. In such a case, from reading the RFCs, they would presumably expect all packets to go through the HA. Thus having FAs implement shortcuts might be an unpleasant surprise in that case. Having the accounting be done in the FA (without the ability for the HA to verify it) is a quite different model. THus I'm not debating that a system can't be built to work that way - I'm just pointing out that allowing FA shortcuts is a change to the RFCs as I understand them. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 09:14: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 JAA26115 for ; Tue, 4 Dec 2001 09:14:31 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11075; Tue, 4 Dec 2001 06:12:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29714; Tue, 4 Dec 2001 06:12:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4EBhHt003877 for ; Tue, 4 Dec 2001 06:11:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4EBhV8003876 for mobile-ip-dist; Tue, 4 Dec 2001 06:11:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4EBeHt003869 for ; Tue, 4 Dec 2001 06:11:40 -0800 (PST) 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 GAA28913 for ; Tue, 4 Dec 2001 06:11:41 -0800 (PST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07082 for ; Tue, 4 Dec 2001 06:11:41 -0800 (PST) Received: from research.telcordia.com (ar8-236 [192.4.8.236]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id fB4EBbkY008398 for ; Tue, 4 Dec 2001 09:11:37 -0500 (EST) Message-ID: <3C0CDA58.34C1BEC1@research.telcordia.com> Date: Tue, 04 Dec 2001 09:14:48 -0500 From: subir Das X-Mailer: Mozilla 4.72 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Slides References: <200112010231.SAA20942@leo.mentat.com> <003201c17b08$25d9cc70$356015ac@AlperVAIO> <00a601c17b09$592dcb20$096015ac@AlperVAIO> <3C0C1171.F86AD022@research.telcordia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sorry about this. This is same "reply to" problem. Subir subir Das wrote: > Alper, > Pl. send your talk (for 10 mins) slides latest by Dec 10th. > > Thanks, > > Subir From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 11:13: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 LAA00087 for ; Tue, 4 Dec 2001 11:13:53 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03147; Tue, 4 Dec 2001 09:12:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24810; Tue, 4 Dec 2001 08:12:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4GBnHt004202 for ; Tue, 4 Dec 2001 08:11:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4GBn0N004201 for mobile-ip-dist; Tue, 4 Dec 2001 08:11:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4GBkHt004194 for ; Tue, 4 Dec 2001 08:11:46 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10649 for ; Tue, 4 Dec 2001 08:11:46 -0800 (PST) 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 JAA14392 for ; Tue, 4 Dec 2001 09:12:15 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id JAA05564 for ; Tue, 4 Dec 2001 09:11:45 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id JAA23980 for ; Tue, 4 Dec 2001 09:01:43 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Tue, 4 Dec 2001 10:11:44 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 4 Dec 2001 10:11:38 -0600 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: Hello James, I sent you the paper in the separate email. Due to oversize, the email with attachment did not go though the list. BTW, if any body needs to look at the attachment I can send personal copy to them. regards, ajoy -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Tuesday, December 04, 2001 5:16 AM To: mobile-ip@sunroof.eng.sun.com; Singh Ajoy-ASINGH1 Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Hi Ajoy, Well, perhaps I am wrong then and it would supplying a pre-Layer 2 trigger is simply an implementation issue. I think the draft still has some value for Postreg, as Karim mentioned. BTW, the paper you mentioned wasn't attached. jak ----- Original Message ----- From: "Singh Ajoy-ASINGH1" To: "Singh Ajoy-ASINGH1" ; Sent: Monday, December 03, 2001 8:49 AM Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > Here I am talking about MN trigger for pre-registration. > > -----Original Message----- > From: Singh Ajoy-ASINGH1 > Sent: Monday, December 03, 2001 10:44 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Hello James, > I am not sure if I completely agree with this draft. I am > attaching some paper from Microsoft which is not > confidential. Based upon the work defined in > the document, I do not sure why it is not possible to > get trigger in case of 802.11. I believe we do not > really need to define anything special for > 802.11. I think getting L2 tigger for 802.11 looks like > some implementation issues not standard issue. Any > comments ? > regards, > ajoy > > > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Sunday, December 02, 2001 5:57 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > Folks, > > As some of you may have noticed, > draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not support fast > handoff for the current 802.11 MAC. While the 802.11 spec is always > subject to change, it may take awhile and the IPv4 fast handoff work is > supposted to be immediately deployable. We've done a short proposal for > how to support fast handoff for 802.11 as it currently exists, it's at > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx > t, it fits into the existing > low latency framework fairly smoothly. Sorry we couldn't get this in on > time, but we just figured it out in the last couple days. This proposal > also has some other uses, re the low latency draft, and it is just to > get the conversation started about how to fix low latency for 802.11 > (that is, we don't necessary expect the WG to accept it as is, but we do > want to get the problem solved). > > jak > From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 12:18: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 MAA02261 for ; Tue, 4 Dec 2001 12:18:00 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28274; Tue, 4 Dec 2001 10:16:38 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02581; Tue, 4 Dec 2001 09:16:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4HFhHt004418 for ; Tue, 4 Dec 2001 09:15:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4HFgiv004417 for mobile-ip-dist; Tue, 4 Dec 2001 09:15:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4HFdHt004410 for ; Tue, 4 Dec 2001 09:15:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06014 for ; Tue, 4 Dec 2001 09:15:35 -0800 (PST) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14922 for ; Tue, 4 Dec 2001 10:16:05 -0700 (MST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 12:14:26 -0500 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 4 Dec 2001 12:14:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: 802.11 is just one of the technologies that the low latency handover protocol should support, but what about HYPERLAN, GPRS and other technologies? -Sharif. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Sunday, December 02, 2001 6:57 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 Folks, As some of you may have noticed, draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not support fast handoff for the current 802.11 MAC. While the 802.11 spec is always subject to change, it may take awhile and the IPv4 fast handoff work is supposted to be immediately deployable. We've done a short proposal for how to support fast handoff for 802.11 as it currently exists, it's at http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx t, it fits into the existing low latency framework fairly smoothly. Sorry we couldn't get this in on time, but we just figured it out in the last couple days. This proposal also has some other uses, re the low latency draft, and it is just to get the conversation started about how to fix low latency for 802.11 (that is, we don't necessary expect the WG to accept it as is, but we do want to get the problem solved). jak From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 12:56: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 MAA03922 for ; Tue, 4 Dec 2001 12:56:43 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04209; Tue, 4 Dec 2001 09:55:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13513; Tue, 4 Dec 2001 09:55:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4HsAHt004613 for ; Tue, 4 Dec 2001 09:54:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4HsAtu004612 for mobile-ip-dist; Tue, 4 Dec 2001 09:54:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4Hs6Ht004605 for ; Tue, 4 Dec 2001 09:54:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13207 for ; Tue, 4 Dec 2001 09:54:08 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06552 for ; Tue, 4 Dec 2001 10:54:36 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 12:54:04 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE460234CC@ftmail> From: Matt Impett To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] 0.0.0.0 src address Date: Tue, 4 Dec 2001 12:54: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: > For example, what if any MN configures itself with a temporary address > to send the reg-req with home-addr=0, to get it's > newly-assigned homeaddr? > > > - If the mobile node does not have a home address, the IP source > address MUST be 0.0.0.0. > I also question why this is a MUST. It is entirely possible that the MN's interface over which it is going to send the RREQ has an IP address (established via DHCP), while the mobile does not yet have a MIP home address. In this case, shouldn't it be able to send the RREQ with the interface's address as the IP source address, but with a zero home address in the RREQ?? matt From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 13:18:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05051 for ; Tue, 4 Dec 2001 13:18:52 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA15761; Tue, 4 Dec 2001 10:17:54 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12227; Tue, 4 Dec 2001 10:17:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4IGWHt004793 for ; Tue, 4 Dec 2001 10:16:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4IGWHq004792 for mobile-ip-dist; Tue, 4 Dec 2001 10:16:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4IGTHt004785 for ; Tue, 4 Dec 2001 10:16:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18853 for ; Tue, 4 Dec 2001 10:16:29 -0800 (PST) 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 LAA18044 for ; Tue, 4 Dec 2001 11:17:00 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id LAA05656 for ; Tue, 4 Dec 2001 11:16:27 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA12699 for ; Tue, 4 Dec 2001 11:16:27 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <4K0CK7F9>; Tue, 4 Dec 2001 12:16:26 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 4 Dec 2001 12:16:17 -0600 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: Sharif, Low latency handoff will work on all the technologies you have mentioned. Just they have to provide appropriate triggers. regards, ajoy -----Original Message----- From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] Sent: Tuesday, December 04, 2001 11:14 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 802.11 is just one of the technologies that the low latency handover protocol should support, but what about HYPERLAN, GPRS and other technologies? -Sharif. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Sunday, December 02, 2001 6:57 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 Folks, As some of you may have noticed, draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not support fast handoff for the current 802.11 MAC. While the 802.11 spec is always subject to change, it may take awhile and the IPv4 fast handoff work is supposted to be immediately deployable. We've done a short proposal for how to support fast handoff for 802.11 as it currently exists, it's at http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx t, it fits into the existing low latency framework fairly smoothly. Sorry we couldn't get this in on time, but we just figured it out in the last couple days. This proposal also has some other uses, re the low latency draft, and it is just to get the conversation started about how to fix low latency for 802.11 (that is, we don't necessary expect the WG to accept it as is, but we do want to get the problem solved). jak From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 13:27: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 NAA05679 for ; Tue, 4 Dec 2001 13:27:40 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26653; Tue, 4 Dec 2001 11:26:29 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15891; Tue, 4 Dec 2001 10:26:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4IPjHt004947 for ; Tue, 4 Dec 2001 10:25:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4IPjVg004946 for mobile-ip-dist; Tue, 4 Dec 2001 10:25:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4IPfHt004939 for ; Tue, 4 Dec 2001 10:25:41 -0800 (PST) Received: from onion.east.sun.com (onion [129.148.174.110]) by purol.East.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fB4IPfw19756 for ; Tue, 4 Dec 2001 13:25:41 -0500 (EST) Date: Tue, 4 Dec 2001 13:26:15 -0500 (EST) From: Steven Glass - Solaris Software Subject: [mobile-ip] Archive update. To: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: As some of you noticed, the main WG mailing-list archive at http://playground.sun.com/mobile-ip was missing November! This email is to announce that November is now right where it should be. For future reference, emails should show up in the archive as soon as they're posted [as close as 'reasonable']; there seemed to be the impression a month wasn't archived until the month was over. Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 13:38: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 NAA05961 for ; Tue, 4 Dec 2001 13:38:17 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26306; Tue, 4 Dec 2001 10:37:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18858; Tue, 4 Dec 2001 10:34:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4IXkHt005100 for ; Tue, 4 Dec 2001 10:33:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4IXkKO005099 for mobile-ip-dist; Tue, 4 Dec 2001 10:33:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4IXgHt005092 for ; Tue, 4 Dec 2001 10:33:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23749 for ; Tue, 4 Dec 2001 10:33:42 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02681 for ; Tue, 4 Dec 2001 11:33:24 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA11220 for ; Tue, 4 Dec 2001 10:33:57 -0800 (PST) Received: (from marc@localhost) by leo.mentat.com (8.9.1b+Sun/8.9.1) id KAA26513 for mobile-ip@sunroof.eng.sun.com; Tue, 4 Dec 2001 10:33:57 -0800 (PST) Date: Tue, 4 Dec 2001 10:33:57 -0800 (PST) From: Marc Hasson Message-Id: <200112041833.KAA26513@leo.mentat.com> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 0.0.0.0 src address X-Sun-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: Samita, (Sorry for the late response, @Home ate my own addressibility yesterday. :-) We'll see how my replacement cable company does today...) > > It seems to me that a Mobile Node could accept its newly-assigned > > non-zero unicast destination address just as well as the 0.0.0.0, it > > should be well-aware its in an address discovery mode analagous to > > DHCPv4 and process the UDP registration reply. > > > > Is there any mobile node implementation which accepts UDP registration > reply destined to a newly assigned address and it's own link-layer > address while it sends the request with src-addr=0.0.0.0 ? Unknown. This was just a suggestion on how to avoid the apparent 1122 commentary regarding destinations of 0.0.0.0 meaning the local machine as opposed to something on the wire. It seems to me that DHCP implementations (perhaps with kernel stack assist) already handle this but I agree that mobile node implementations would not unless we specified it. > As it was pointed out that it is possible for an implementation > to implement this behavior in MN. Agreed. I have no problem with the functionality proposed for the 0.0.0.0 address, my only commentary has been that 2002bis seems to be the first place where 0.0.0.0 appears as a destination unicast address in a packet. > I think the mobile-ip base draft rfc2002-bis needs to clarify the > restriction on having src-addr = 0.0.0.0 and the consequent dst-addr > for the registration reply from FA to MN. 100% agreed. > > Note that it is also possible that FA may find that the registration > request from src-addr=0.0.0.0 and home-addr=0.0.0.0 is poorly-formatted > or some other problem, how does it reply back with error then ? ( Due to > the restriction in RFC1122 ) > Should it drop the packet or send it to multicast addr ? OK, good point there and perhaps I wasn't fully awake to think about the error cases. DHCP presumably responds with a broadcast "nak" and lets the proper client figure it out based on the ids in the message. The same could be done with the MN but this doesn't seem as "clean" to me. If it was important to avoid the apparent 1122 restriction then thats what I would recommend but I think I'd agree that for implementation simplicity the 0.0.0.0 handling is cleaner. How are apparent conflicts with 1122 handled? Just highlighted in 2002bis since these are *mobile* host requirements, not plain hosts? > > I wonder, why rfc2002-bis has a MUST in 3.6.1.1, could it be MAY ? > > For example, what if any MN configures itself with a temporary address > to send the reg-req with home-addr=0, to get it's newly-assigned homeaddr? > > > - If the mobile node does not have a home address, the IP source > address MUST be 0.0.0.0. Yep, I found this confusing too. I *think* the first MUST "overrides" this second one when you have a co-located COA but I agree this should be clarified. > > Also the draft needs to clarify that if the source-addr of the UDP registration > request is 0.0.0.0, then what will be the IP dst addr for the regReply. Yep. -- Marc -- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 15:14: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 PAA10328 for ; Tue, 4 Dec 2001 15:13:57 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19935; Tue, 4 Dec 2001 13:12:44 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23409; Tue, 4 Dec 2001 12:12:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4KBqHt005456 for ; Tue, 4 Dec 2001 12:11:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4KBqfE005455 for mobile-ip-dist; Tue, 4 Dec 2001 12:11:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4KBnHt005448 for ; Tue, 4 Dec 2001 12:11:49 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20490 for ; Tue, 4 Dec 2001 12:11:49 -0800 (PST) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01044 for ; Tue, 4 Dec 2001 13:11:45 -0700 (MST) Received: from [192.168.1.42] (atlantis.kniveton.com [192.168.1.42]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id fB4KBgr33597; Tue, 4 Dec 2001 12:11:42 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Tue, 04 Dec 2001 12:11:41 -0800 Subject: [mobile-ip] mobile nets meeting at IETF52 From: "T.J. Kniveton" To: CC: Message-ID: 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, A few people have asked me whether we are meeting at IETF52 to discuss the Mobile Networks subject in a BOF, so I just want to answer that question for everyone else who is interested. There is no official BOF scheduled, but we are getting together for a "bar BOF" to discuss planning for the group, and possible go over some requirements and charter items to have them ready and the scope defined for a future BOF. The time we have discussed for this meeting would be on Wednesday, 12/12, after lunch (soon after the Mobile IP meeting). Hesham Soliman is in charge of the arrangements and will post them when finalized. -TJ From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 16:15: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 QAA12704 for ; Tue, 4 Dec 2001 16:15:47 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03396; Tue, 4 Dec 2001 14:14:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11341; Tue, 4 Dec 2001 13:14:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4LD1Ht005688 for ; Tue, 4 Dec 2001 13:13:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4LD17p005687 for mobile-ip-dist; Tue, 4 Dec 2001 13:13:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4LCvHt005680 for ; Tue, 4 Dec 2001 13:12:57 -0800 (PST) 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 NAA11001 for ; Tue, 4 Dec 2001 13:12:59 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10243 for ; Tue, 4 Dec 2001 13:12:59 -0800 (PST) Received: from T23KEMPF (dhcp171.docomo-usa.com [172.21.96.171]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB4LCt507946 for ; Tue, 4 Dec 2001 13:12:56 -0800 (PST) Message-ID: <001501c17d08$3894c9d0$ab6015ac@T23KEMPF> From: "James Kempf" To: References: Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 4 Dec 2001 13:11:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I guess I don't see why it being related to handoff decisions and mechanisms as being not an API issue. There is only a protocol issue if there is some need to communicate between the network elements. Deciding which of n interfaces to handoff to on the MN based on signal strength data doesn't involve communicating between network elements. Actually causing the handoff to occur might. The MIP group is workong on the handoff mechanisms. Seamoby is discussing candidate access router discovery. But the actual decision is a policy issue that is not being discussed, since it is up to the network operator to decide how they will choose the target access router. jak ----- Original Message ----- From: To: Sent: Tuesday, December 04, 2001 4:57 AM Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > Hi, > > It's not plain API issue because it relates to the handoff decisions and > mechanisms. Is there any WG that is working with this? > > - Dan > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: 04. December 2001 13:38 > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > Dan, > > > > There is an issue with comparibility. How would one compare, > > say, signal > > strength measurements for 802.11 with > > those for GPRS (presuming one could get that information from GPRS)? > > > > Also, I don't think this is a protocol issue, it is more of an API > > issue. > > > > jak > > > > ----- Original Message ----- > > From: > > To: > > Sent: Tuesday, December 04, 2001 3:25 AM > > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > Hi, > > > > > > One comment below. > > > > > > > -----Original Message----- > > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: 04. December 2001 12:58 > > > > To: mobile-ip@sunroof.eng.sun.com > > > > Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > > > > > > Karim, > > > > > > > > The MN in 802.11 does a reassociation without any trigger to > > > > Layer 3, at > > > > least, that is how it currently works. > > > > One could make the modification you suggest below, however, > > > > it would be > > > > a change in the way the 802.11 > > > > protocol works. If you simply modify the driver to look at signal > > > > strength, then deliver a pre-Layer 2 trigger > > > > based on that, the MN may very well decide to move to > > another Access > > > > Point if the signal strength of that > > > > AP meets the criteria. As far as I understand, there is no > > > > way given the > > > > current 802.11 protocol to fix the new AP in advance of > > the Layer 2 > > > > handover. > > > > > > This could be great help for vertical handovers also. The l3 would > > know the > > > different l2 technologies and be able to compare them, > > choose the best > > > according to the settings (policies). This is the approach that > > Dynamics - > > > HUT Mobile IPv4 has taken. > > > > > > Just think for example GPRS, ethernet, wlan, bluetooth and infrared > > > together: many possibilities, different characteristics and > > different > > costs. > > > It would be nice to have a standard way to compare these possible > > > connections... and use them according to the settings of the user. > > > > > > - Dan > > > > > > > > > > At best, given current 802.11, one could imagine delivering a > > > > pre-Layer > > > > 2 trigger as soon > > > > as the MN sent the 802.11 reassociation message (the Link > > > > Down trigger), > > > > but this would not give Prereg > > > > enough time to complete any messaging through the old AP. > > > > > > > > jak > > > > > > > > ----- Original Message ----- > > > > From: "Karim El-Malki (ERA)" > > > > To: > > > > Sent: Monday, December 03, 2001 2:06 AM > > > > Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > > > > > > > James, > > > > > > > > > > Why does draft-ietf-mobileip-lowlatency-handoffs not support > > 802.11? > > > > > PRE-REG can be applied to 802.11 using the mobile-initiated > > > > part with > > > > > a mobile trigger. The mobile trigger in this case would > > likely be > > > > based > > > > > on signal strength measurements in the MN and the FA > > > > address could be > > > > > embedded in the beacon. So I disagree that low latency > > needs to be > > > > fixed > > > > > for 802.11. What you may have intended is that POST-REG as it is > > in > > > > the > > > > > draft cannot be used with 802.11, but low latency has a > > > > solution which > > > > > can be used for 802.11 already. > > > > > > > > > > /Karim > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > > > > > Sent: den 3 december 2001 00:57 > > > > > > To: mobile-ip@sunroof.eng.sun.com > > > > > > Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > > > > > > > > > > > > > > > > > Folks, > > > > > > > > > > > > As some of you may have noticed, > > > > > > draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not > > > > > > support fast > > > > > > handoff for the current 802.11 MAC. While the 802.11 > > > > spec is always > > > > > > subject to change, it may take awhile and the IPv4 fast > > > > > > handoff work is > > > > > > supposted to be immediately deployable. We've done a short > > > > > > proposal for > > > > > > how to support fast handoff for 802.11 as it currently > > > > > > exists, it's at > > > > > > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-han > > > > > dover-00.tx > > > > > t, it fits into the existing > > > > > low latency framework fairly smoothly. Sorry we > > couldn't get this > > in > > > > on > > > > > time, but we just figured it out in the last couple days. This > > > > proposal > > > > > also has some other uses, re the low latency draft, and it > > > > is just to > > > > > get the conversation started about how to fix low latency for > > 802.11 > > > > > (that is, we don't necessary expect the WG to accept it as > > > > is, but we > > > > do > > > > > want to get the problem solved). > > > > > > > > > > jak > > > > > > > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 16:20: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 QAA12809 for ; Tue, 4 Dec 2001 16:20:55 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10028; Tue, 4 Dec 2001 13:19:39 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12682; Tue, 4 Dec 2001 13:19:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4LIeHt005826 for ; Tue, 4 Dec 2001 13:18:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4LIe73005825 for mobile-ip-dist; Tue, 4 Dec 2001 13:18:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4LIaHt005818 for ; Tue, 4 Dec 2001 13:18:36 -0800 (PST) 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 NAA03803 for ; Tue, 4 Dec 2001 13:18:38 -0800 (PST) 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 NAA10648 for ; Tue, 4 Dec 2001 13:18:36 -0800 (PST) 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 fB4LJbQ20068 for ; Tue, 4 Dec 2001 15:19:37 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Dec 2001 15:18:35 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Dec 2001 15:18:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: [mobile-ip] Final Agenda for IETF52 Date: Tue, 4 Dec 2001 15:18:35 -0600 MIME-Version: 1.0 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD1DB@daebe007.NOE.Nokia.com> Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: Agenda... Thread-Index: AcF9Bmf+4y9bRujyEdWxUQAAhj/HZA== From: "Patil Basavaraj (NET/Dallas)" To: "'Mobile IP'" X-OriginalArrivalTime: 04 Dec 2001 21:18:35.0818 (UTC) FILETIME=[3C0458A0:01C17D09] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fB4LIaHt005819 Sender: owner-mobile-ip@sunroof.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 INT mobileip IP Routing for Wireless/Mobile Hosts WG (Dec 12th Wed, 0900-1130) --------------------------------------------------------- 1 Agenda Bashing 10 Mins WG Chairs WG Doc Status update 2 MIPv6 Security Discussion 75 Mins a. Securing MIPv6 Binding Updates b. Home Address Option/Routing Header vs Tunnelling c. Piggybacking of binding updates Discussion lead by Gabriel Montenegro, Jari Arkko and Erik Nordmark I-Ds relevant to this discussion: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-sec-reqts- 02.txt http://www.ietf.org/internet-drafts/draft-arkko-mipv6-bu-security-01.txt http://www.ietf.org/internet-drafts/draft-montenegro-mobileip-mipv6-sece val-00.txt http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01. txt http://www.ietf.org/internet-drafts/draft-arkko-mipv6ro-secframework-00. txt Note: Only if you have read these I-Ds can you make comments at the microphone 3 RFC3012bis: Issues identified and Changes made 10 Mins Charles http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-00.tx t 4. Handoffs: Low Latency(v4) and Fast HO (v6) 30 Mins a. Discussion of issues based on implementation experience James Kempf http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-hando ffs-v4-03.txt http://geocities.com/kempf42/llanalysis.pdf b. Fast handoff - Updates/Changes/Issues raised on list Gopal Dommety http://people.nokia.net/~patil/Internet_Drafts/draft-ietf-mobileip-fast- mipv6-04.txt 5. Localized Mobility Management Requirements 10 Mins Carl Williams http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lmm-requirements -00.txt 6. MIPv6 at ETSI Bakeoff Report 10 Mins Sebastien Barbin From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 16:30: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 QAA13213 for ; Tue, 4 Dec 2001 16:30:57 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14768; Tue, 4 Dec 2001 14:29:48 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16897; Tue, 4 Dec 2001 13:29:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4LSYHt005994 for ; Tue, 4 Dec 2001 13:28:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4LSYL7005993 for mobile-ip-dist; Tue, 4 Dec 2001 13:28:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4LSUHt005986 for ; Tue, 4 Dec 2001 13:28:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06258 for ; Tue, 4 Dec 2001 13:28:32 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13752 for ; Tue, 4 Dec 2001 14:28:14 -0700 (MST) 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 fB4LTVQ20655 for ; Tue, 4 Dec 2001 15:29:31 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Tue, 4 Dec 2001 15:28:30 -0600 Received: from sdebe001.NOE.Nokia.com ([172.19.201.136]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 4 Dec 2001 15:28:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [mobile-ip] 0.0.0.0 src address Date: Tue, 4 Dec 2001 13:24:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: <3F41C3159B4C874BB244474AB53D2C1A10F493@sdebe001.NOE.Nokia.com> Thread-Topic: [mobile-ip] 0.0.0.0 src address Thread-Index: AcF88tBtYx85eOjlEdWBUQBQi2X+DwAAMD9g From: "Lalwaney Poornima (NMP/SanDiego)" To: X-OriginalArrivalTime: 04 Dec 2001 21:28:28.0621 (UTC) FILETIME=[9D5AE7D0:01C17D0A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fB4LSVHt005987 Sender: owner-mobile-ip@sunroof.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, As already discussed in this thread, the real problem is not with src= 0.0.0.0 but that if you follow RFC2002 by the word, there are cases where the destination IP agent advertisements and registration replies is copied from the src IP getting us to the scenario where destination IP=0.0.0.0. We have run into this issue with some implementations and have had interoperability concerns on this issue. I diasgree that we have to change RFC1112 interpretation by allowing 0.0.0.0 as destination IP; or implement an involved DHCP kind of state machine for dynamic address assignment. This destination IP address (0.0.0.0) is forbidden for anything except source (see RFC 1700 introduction). RFC1700 has a caveat that appears as "see note later" . I have not been able to find the note either in RFC1700 or on the updated IANA web pages. I do not believe that Mobile IPv4 (RFC2002 or 2002bis) intended to create a special case by allowing "0.0.0.0" as a valid destination address. It seems that that 0.0.0.0 was an afterthought and all the RFC2000 bis sections were not updated to reflect the effect of this case. Could we not specify the destination IP of broadcast (255.255.255.255) on replies for the cases where an agent receives a request with src IP=0.0.0.0? This is similar to what DHCP does. Uninitialized host stack implementations accept broadcast while dropping datagrams with destinaton IP of 0.0.0.0. However, I think it would be an overkill to design Mobile IPv4 clients with the DHCP behavior where the DHCPOFFER and DHCPACK have as destination IP, the address that is to be bound to the stack. Rather than allowing destination IP=0.0.0.0 as suggested in this thread, why can we not use destination IP=255.255.255.255? Now getting to link layer address on the packets with broadcast destination IP. Can we have unicast link layer address with broadcast destination IP as would be required for registartion replies? So, the following cases have to be addressed in 2002bis with regards to dynamic home address assignment: 1) If host stack has no IP address (sends requests with src IP = 0.0.0.0), what is the destination IP on registration replies? Are both destination link layer unicast and link layer broadcast permitted on the reply. 2) If the host has another address bound to the interface (either temporary or non-temporary), could that address be used for source IP with home-address=0.0.0.0? Thanks.. Poornima Lalwaney -----Original Message----- From: ext Marc Hasson [mailto:marc@mentat.com] Sent: Tuesday, December 04, 2001 10:34 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 0.0.0.0 src address Samita, (Sorry for the late response, @Home ate my own addressibility yesterday. :-) We'll see how my replacement cable company does today...) > > It seems to me that a Mobile Node could accept its newly-assigned > > non-zero unicast destination address just as well as the 0.0.0.0, it > > should be well-aware its in an address discovery mode analagous to > > DHCPv4 and process the UDP registration reply. > > > > Is there any mobile node implementation which accepts UDP registration > reply destined to a newly assigned address and it's own link-layer > address while it sends the request with src-addr=0.0.0.0 ? Unknown. This was just a suggestion on how to avoid the apparent 1122 commentary regarding destinations of 0.0.0.0 meaning the local machine as opposed to something on the wire. It seems to me that DHCP implementations (perhaps with kernel stack assist) already handle this but I agree that mobile node implementations would not unless we specified it. > As it was pointed out that it is possible for an implementation > to implement this behavior in MN. Agreed. I have no problem with the functionality proposed for the 0.0.0.0 address, my only commentary has been that 2002bis seems to be the first place where 0.0.0.0 appears as a destination unicast address in a packet. > I think the mobile-ip base draft rfc2002-bis needs to clarify the > restriction on having src-addr = 0.0.0.0 and the consequent dst-addr > for the registration reply from FA to MN. 100% agreed. > > Note that it is also possible that FA may find that the registration > request from src-addr=0.0.0.0 and home-addr=0.0.0.0 is poorly-formatted > or some other problem, how does it reply back with error then ? ( Due to > the restriction in RFC1122 ) > Should it drop the packet or send it to multicast addr ? OK, good point there and perhaps I wasn't fully awake to think about the error cases. DHCP presumably responds with a broadcast "nak" and lets the proper client figure it out based on the ids in the message. The same could be done with the MN but this doesn't seem as "clean" to me. If it was important to avoid the apparent 1122 restriction then thats what I would recommend but I think I'd agree that for implementation simplicity the 0.0.0.0 handling is cleaner. How are apparent conflicts with 1122 handled? Just highlighted in 2002bis since these are *mobile* host requirements, not plain hosts? > > I wonder, why rfc2002-bis has a MUST in 3.6.1.1, could it be MAY ? > > For example, what if any MN configures itself with a temporary address > to send the reg-req with home-addr=0, to get it's newly-assigned homeaddr? > > > - If the mobile node does not have a home address, the IP source > address MUST be 0.0.0.0. Yep, I found this confusing too. I *think* the first MUST "overrides" this second one when you have a co-located COA but I agree this should be clarified. > > Also the draft needs to clarify that if the source-addr of the UDP registration > request is 0.0.0.0, then what will be the IP dst addr for the regReply. Yep. -- Marc -- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 16:36: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 QAA13386 for ; Tue, 4 Dec 2001 16:36:15 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA17064; Tue, 4 Dec 2001 13:35:08 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17777; Tue, 4 Dec 2001 13:31:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4LUqHt006065 for ; Tue, 4 Dec 2001 13:30:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4LUqV6006064 for mobile-ip-dist; Tue, 4 Dec 2001 13:30:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4LUmHt006054 for ; Tue, 4 Dec 2001 13:30:48 -0800 (PST) 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 NAA15421 for ; Tue, 4 Dec 2001 13:30:50 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18052 for ; Tue, 4 Dec 2001 13:30:49 -0800 (PST) Received: from T23KEMPF (dhcp171.docomo-usa.com [172.21.96.171]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB4LUl508731 for ; Tue, 4 Dec 2001 13:30:48 -0800 (PST) Message-ID: <006501c17d0a$b775cc20$ab6015ac@T23KEMPF> From: "James Kempf" To: References: Subject: Re: [mobile-ip] IPv4 Fast Handover Support for 802.11 Date: Tue, 4 Dec 2001 13:29:10 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I don't know anything about Hyperlan, but the cellular technologies have or could have enough predictive information. Ajoy sent a paper about how to force handover on the MN, so it may, in fact, be a simple matter of implementation. jak ----- Original Message ----- From: "Shahrier, Sharif M." To: Sent: Tuesday, December 04, 2001 9:14 AM Subject: RE: [mobile-ip] IPv4 Fast Handover Support for 802.11 > 802.11 is just one of the technologies that the low latency handover > protocol should support, but what about HYPERLAN, GPRS > and other technologies? > > -Sharif. > > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Sunday, December 02, 2001 6:57 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] IPv4 Fast Handover Support for 802.11 > > Folks, > > As some of you may have noticed, > draft-ietf-mobileip-lowlatency-handoffs-ipv4.txt does not support fast > handoff for the current 802.11 MAC. While the 802.11 spec is always > subject to change, it may take awhile and the IPv4 fast handoff work is > supposted to be immediately deployable. We've done a short proposal for > how to support fast handoff for 802.11 as it currently exists, it's at > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx > t, it fits into the existing > low latency framework fairly smoothly. Sorry we couldn't get this in on > time, but we just figured it out in the last couple days. This proposal > also has some other uses, re the low latency draft, and it is just to > get the conversation started about how to fix low latency for 802.11 > (that is, we don't necessary expect the WG to accept it as is, but we do > want to get the problem solved). > > jak > From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 4 18: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 SAA16655 for ; Tue, 4 Dec 2001 18:04:57 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA25302; Tue, 4 Dec 2001 15:03:59 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07942; Tue, 4 Dec 2001 15:03:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4N2qHt006529 for ; Tue, 4 Dec 2001 15:02:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB4N2q0o006528 for mobile-ip-dist; Tue, 4 Dec 2001 15:02:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB4N2nHt006521 for ; Tue, 4 Dec 2001 15:02:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04107 for ; Tue, 4 Dec 2001 15:02:49 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA04867 for ; Tue, 4 Dec 2001 16:03:20 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA22250 for ; Tue, 4 Dec 2001 15:02:48 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB4N2lQ22013 for ; Tue, 4 Dec 2001 15:02:47 -0800 X-mProtect: Tue, 4 Dec 2001 15:02:47 -0800 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 smtpdE4LIUU; Tue, 04 Dec 2001 15:02:45 PST Message-ID: <3C0D5616.77E8A24B@iprg.nokia.com> Date: Tue, 04 Dec 2001 15:02:46 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Routing header Vs tunneling References: <697DAA22C5004B4596E033803A7CEF444CD1DB@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 "Patil Basavaraj (NET/Dallas)" wrote: > > INT mobileip IP Routing for Wireless/Mobile Hosts WG > (Dec 12th Wed, 0900-1130) > --------------------------------------------------------- > > 1 Agenda Bashing 10 Mins WG Chairs > WG Doc Status update > > 2 MIPv6 Security Discussion 75 Mins > > a. Securing MIPv6 Binding Updates > > b. Home Address Option/Routing Header vs Tunnelling I think we should modify 'b' to say " Home Address Option vs Tunnelling" because Pekka has suggested a solution for the routing header problem in his draft-savola-ipv6-rh-ha-security-01.txt Every host should follow these rules Routing header MUST be processed if 1. segleft is 1 2. destination address and intermediate address both belong to the same interface of the host that received the packet. Routing header MUST not be processed if 1. the address to be swapped does not belong to the same interface as the destination address on the IPv6 header. if a IPv6 host follows the above rules, is there still a security problem? if not, I suggest we drop the issue of router header Vs tunneling and use routing header with the above two rules. regards Vijay > > c. Piggybacking of binding updates > > Discussion lead by Gabriel Montenegro, Jari Arkko and Erik Nordmark > > I-Ds relevant to this discussion: > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-sec-reqts- > 02.txt > http://www.ietf.org/internet-drafts/draft-arkko-mipv6-bu-security-01.txt > http://www.ietf.org/internet-drafts/draft-montenegro-mobileip-mipv6-sece > val-00.txt > http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01. > txt > http://www.ietf.org/internet-drafts/draft-arkko-mipv6ro-secframework-00. > txt > > Note: Only if you have read these I-Ds can you make comments at the > microphone > > 3 RFC3012bis: Issues identified and Changes made 10 Mins Charles > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-00.tx > t > > 4. Handoffs: Low Latency(v4) and Fast HO (v6) 30 Mins > > a. Discussion of issues based on implementation experience > James Kempf > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-hando > ffs-v4-03.txt > http://geocities.com/kempf42/llanalysis.pdf > > b. Fast handoff - Updates/Changes/Issues raised on list > Gopal Dommety > http://people.nokia.net/~patil/Internet_Drafts/draft-ietf-mobileip-fast- > mipv6-04.txt > > 5. Localized Mobility Management Requirements 10 Mins > Carl Williams > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lmm-requirements > -00.txt > > 6. MIPv6 at ETSI Bakeoff Report 10 Mins Sebastien Barbin From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 04:06: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 EAA16994 for ; Wed, 5 Dec 2001 04:06:29 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08059; Wed, 5 Dec 2001 02:05:19 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04314; Wed, 5 Dec 2001 01:05:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB593DHt008116 for ; Wed, 5 Dec 2001 01:03:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB593DTw008115 for mobile-ip-dist; Wed, 5 Dec 2001 01:03:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5938Ht008108 for ; Wed, 5 Dec 2001 01:03:09 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA13618 for ; Wed, 5 Dec 2001 01:03:08 -0800 (PST) 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 CAA06820 for ; Wed, 5 Dec 2001 02:02:49 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fB5934I29816 for ; Wed, 5 Dec 2001 10:03:04 +0100 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 KAA01332 for ; Wed, 5 Dec 2001 10:03:04 +0100 (MET) 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 fB5934D93006 for ; Wed, 5 Dec 2001 10:03:04 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112050903.fB5934D93006@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling In-reply-to: Your message of Tue, 04 Dec 2001 15:02:46 PST. <3C0D5616.77E8A24B@iprg.nokia.com> Date: Wed, 05 Dec 2001 10:03:04 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: > b. Home Address Option/Routing Header vs Tunnelling I think we should modify 'b' to say " Home Address Option vs Tunnelling" because ... => I disagree: home address option and routing header are two basic types of tunnel address compression (cf the Deering/Zill's draft-deering-ipv6-encap-addr-deletion-00.txt), i.e. there is no essential difference. But if your purpose is to show that mobile-ip is the wrong WG I agree, and IMHO the same remark applies to 'c' (piggy-backing). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 05:43: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 FAA18046 for ; Wed, 5 Dec 2001 05:43:56 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA20040; Wed, 5 Dec 2001 02:42:54 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29462; Wed, 5 Dec 2001 02:42:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5AffHt008525 for ; Wed, 5 Dec 2001 02:41:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5AffZI008524 for mobile-ip-dist; Wed, 5 Dec 2001 02:41:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5AfbHt008517 for ; Wed, 5 Dec 2001 02:41:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA20211 for ; Wed, 5 Dec 2001 02:41:38 -0800 (PST) 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 DAA18969 for ; Wed, 5 Dec 2001 03:42:07 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fB5AfYu28367 for ; Wed, 5 Dec 2001 11:41:34 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Dec 05 11:41:32 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Dec 2001 11:41:19 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEE04@esealnt117> From: "Karim El-Malki (ERA)" To: "'Erik Nordmark'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 Date: Wed, 5 Dec 2001 11:41:18 +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: > > What I should have written is that it wasn't clear what > scenario would > > require all packets to go through the HA, while reverse > tunneling was > > more obvious. The accounting can be done in the FA. Is > there any other > > scenario where all traffic must go through the HA? If not then this > > shortcut may be done by the FA if bidirectional tunneling > is not used. > > Otherwise I agree with what you're saying. > > I don't know if folks have built or are building MIPv4 FAs > that collect > accounting information. In such a case, from reading the RFCs, they > would presumably expect all packets to go through the HA. > Thus having FAs implement shortcuts might be an unpleasant > surprise in > that case. I believe there are FAs which collect accounting data (e.g. CDMA2000 PDSNs). Would it actually be a problem for accounting? I'm not an expert in this but why should the HA want to do accounting only for one direction of MN traffic and not both? If you want to do accounting in the HA then you reverse tunnel. If there's no reverse tunneling then only the FA can collect accounting information for traffic to/from the MN. Do you think HA verification of accounting only for traffic towards the MN is something people want to do? > > Having the accounting be done in the FA (without the ability > for the HA > to verify it) is a quite different model. THus I'm not > debating that a > system can't be built to work that way - I'm just pointing > out that allowing > FA shortcuts is a change to the RFCs as I understand them. Do you mean RFC2002 or others? I'm not sure this is disallowed in 2002 but I may have misunderstood something. Also, as above, I don't think that the ability for the HA to verify the FA's accounting only for one direction of the traffic is useful. /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 05:44: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 FAA18066 for ; Wed, 5 Dec 2001 05:44:41 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA28566; Wed, 5 Dec 2001 03:43:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29610; Wed, 5 Dec 2001 02:43:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5AgfHt008544 for ; Wed, 5 Dec 2001 02:42:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5Agewo008543 for mobile-ip-dist; Wed, 5 Dec 2001 02:42:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5AgaHt008536 for ; Wed, 5 Dec 2001 02:42:37 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29453 for ; Wed, 5 Dec 2001 02:42:37 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA27845 for ; Wed, 5 Dec 2001 03:42:18 -0700 (MST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Dec 2001 11:42:17 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D82010DCEC3@lat3721.rd.francetelecom.fr> From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE To: "'mobile-ip@sunroof.eng.sun.com'" , "Karim El-Malki (ERA)" Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 Date: Wed, 5 Dec 2001 11:41:01 +0100 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, I had understood that the routing process in the FA had already changed. The FA delivers the packets with mobile node's home address as a destination address to the MN on the foreign network; otherwise it will be a loop. Or may be the FA delivers the packets to the mobile node on the foreign network only if they were encapsulated and routes them towards the HA if they weren't. Maybe some clarifications are needed in the draft. Kassi -----Message d'origine----- De : Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] Envoye : mardi 4 decembre 2001 14:42 A : Karim El-Malki (ERA) Cc : 'Erik Nordmark'; 'mobile-ip@sunroof.eng.sun.com' Objet : RE: [mobile-ip] MN-to-MN communications in MIPv4 > What I should have written is that it wasn't clear what scenario would > require all packets to go through the HA, while reverse tunneling was > more obvious. The accounting can be done in the FA. Is there any other > scenario where all traffic must go through the HA? If not then this > shortcut may be done by the FA if bidirectional tunneling is not used. > Otherwise I agree with what you're saying. I don't know if folks have built or are building MIPv4 FAs that collect accounting information. In such a case, from reading the RFCs, they would presumably expect all packets to go through the HA. Thus having FAs implement shortcuts might be an unpleasant surprise in that case. Having the accounting be done in the FA (without the ability for the HA to verify it) is a quite different model. THus I'm not debating that a system can't be built to work that way - I'm just pointing out that allowing FA shortcuts is a change to the RFCs as I understand them. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 06:05: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 GAA18229 for ; Wed, 5 Dec 2001 06:05:34 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA26097; Wed, 5 Dec 2001 03:04:16 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22530; Wed, 5 Dec 2001 03:03:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5B31Ht008843 for ; Wed, 5 Dec 2001 03:03:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5B31JM008842 for mobile-ip-dist; Wed, 5 Dec 2001 03:03:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5B2vHt008835 for ; Wed, 5 Dec 2001 03:02:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA05661 for ; Wed, 5 Dec 2001 03:02:56 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id EAA29158 for ; Wed, 5 Dec 2001 04:02:55 -0700 (MST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Dec 2001 12:02:37 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D82010DCEC4@lat3721.rd.francetelecom.fr> From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE To: "'mobile-ip@sunroof.eng.sun.com'" , "'Erik Nordmark'" Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 Date: Wed, 5 Dec 2001 12:01:21 +0100 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 fB5B2wHt008836 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit I think that the access points make the accounting and the information is delivered to the accounting centre. Kassi -----Message d'origine----- De : Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] Envoyé : mercredi 5 décembre 2001 11:41 À : 'Erik Nordmark' Cc : 'mobile-ip@sunroof.eng.sun.com' Objet : RE: [mobile-ip] MN-to-MN communications in MIPv4 I believe there are FAs which collect accounting data (e.g. CDMA2000 PDSNs). Would it actually be a problem for accounting? I'm not an expert in this but why should the HA want to do accounting only for one direction of MN traffic and not both? If you want to do accounting in the HA then you reverse tunnel. If there's no reverse tunneling then only the FA can collect accounting information for traffic to/from the MN. Do you think HA verification of accounting only for traffic towards the MN is something people want to do? > > Having the accounting be done in the FA (without the ability > for the HA > to verify it) is a quite different model. THus I'm not > debating that a > system can't be built to work that way - I'm just pointing > out that allowing > FA shortcuts is a change to the RFCs as I understand them. Do you mean RFC2002 or others? I'm not sure this is disallowed in 2002 but I may have misunderstood something. Also, as above, I don't think that the ability for the HA to verify the FA's accounting only for one direction of the traffic is useful. /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 08:52: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 IAA20765 for ; Wed, 5 Dec 2001 08:52:32 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA16936; Wed, 5 Dec 2001 05:51:21 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12159; Wed, 5 Dec 2001 05:51:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5DoGHt009223 for ; Wed, 5 Dec 2001 05:50:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5DoGwL009222 for mobile-ip-dist; Wed, 5 Dec 2001 05:50:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5DoCHt009215 for ; Wed, 5 Dec 2001 05:50:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20294 for ; Wed, 5 Dec 2001 05:50:13 -0800 (PST) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA21331 for ; Wed, 5 Dec 2001 06:50:42 -0700 (MST) Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Dec 2001 13:50:09 +0000 Message-ID: <3C0E2610.F81E9EC5@cs.ucl.ac.uk> Date: Wed, 05 Dec 2001 13:50:08 +0000 From: Theo Pagtzis Organization: UCL/Mobile Systems Group X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-fast-mipv6-03.txt References: <200111261113.GAA18889@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit A comment for whoever manages the receipt of IETF drafts.. If one looks at the date of receipt of the IESG draft announcement they would see that the draft has been submitted on the 21-Nov-01 If now one looks at the date mentioned inside the draft they would see that the draft mentions July 2001 (!!!!!) and expiry (this is the amazing one!!!) December 2001 That means to me 1) that the author seems to have supernatural powers 2) that the lifetime of a draft is one month 3) that people may feel inclined to 'forget' the date so that it looks as if it was written then..if people don't pay attention to it. I would like to complain to the IESG about that, since in this fashion I could re-discover the whole of internet by dating a draft December 1975 while I submitted it last week... This is also not fair for proposals that have been around before the latest of submission Cheers Theo UCL/Mobile Systems Group Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. > > Title : 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-03.txt > Pages : 66 > Date : 21-Nov-01 > > Mobile IPv6 describes how a mobile node can change its point of > attachment from one access router to another (this process is > referred to as Handoff). During this process, there could be a time > period during which the mobile node is unable to send or receive > IPv6 packets. This time period is referred to as handoff latency. In > certain scenarios, the handoff latency resulting due to procedures > described in Mobile IP v6 could be greater than what is acceptable to > support real-time or delay sensitive traffic. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-fast-mipv6-03.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-mobileip-fast-mipv6-03.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-mobileip-fast-mipv6-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. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <20011121140836.I-D@ietf.org> From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 10: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 KAA23060 for ; Wed, 5 Dec 2001 10:14:10 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA20467; Wed, 5 Dec 2001 07:13:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15949; Wed, 5 Dec 2001 06:24:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5ENbHt009389 for ; Wed, 5 Dec 2001 06:23:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5ENbIG009388 for mobile-ip-dist; Wed, 5 Dec 2001 06:23:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5ENYHt009381 for ; Wed, 5 Dec 2001 06:23:34 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25118 for ; Wed, 5 Dec 2001 06:23:34 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12085 for ; Wed, 5 Dec 2001 07:23:33 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB5ENWS07821 for ; Wed, 5 Dec 2001 16:23:32 +0200 Date: Wed, 5 Dec 2001 16:23:32 +0200 (EET) From: Pekka Savola To: Subject: Re: [mobile-ip] Routing header Vs tunneling In-Reply-To: <200112050903.fB5934D93006@givry.rennes.enst-bretagne.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: On Wed, 5 Dec 2001, Francis Dupont wrote: > > b. Home Address Option/Routing Header vs Tunnelling > > I think we should modify 'b' to say " Home Address Option > vs Tunnelling" because ... > > => I disagree: home address option and routing header are two > basic types of tunnel address compression (cf the Deering/Zill's > draft-deering-ipv6-encap-addr-deletion-00.txt), i.e. there is > no essential difference. > But if your purpose is to show that mobile-ip is the wrong WG > I agree, and IMHO the same remark applies to 'c' (piggy-backing). I agree with Francis. If we are to adopt tunneling, it seems to make sense to use it for both HAO and RH. If there were no problems with HAO, introducing tunneling just for RH might not be as "imperative". These issues are intertwined, as the mechanisms compared to tunneling are very similar. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 11:00: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 LAA25427 for ; Wed, 5 Dec 2001 11:00:58 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA22285; Wed, 5 Dec 2001 08:59:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08659; Wed, 5 Dec 2001 07:59:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5FwbHt009669 for ; Wed, 5 Dec 2001 07:58:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5FwajC009668 for mobile-ip-dist; Wed, 5 Dec 2001 07:58:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5FwXHt009661 for ; Wed, 5 Dec 2001 07:58:33 -0800 (PST) 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 HAA13198 for ; Wed, 5 Dec 2001 07:58:33 -0800 (PST) Received: from EXCHANGE01.domain.ecutel.com ([65.201.154.134]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29985 for ; Wed, 5 Dec 2001 07:58:32 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 Date: Wed, 5 Dec 2001 10:58:31 -0500 Message-ID: Thread-Topic: [mobile-ip] MN-to-MN communications in MIPv4 Thread-Index: AcF9efea3MU+4QfySH2NfGJHOPgtLgAKbJc+ From: "Qiang Zhang" To: , , "Karim El-Malki (ERA)" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id fB5FwXHt009662 Sender: owner-mobile-ip@sunroof.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 In addition, for those MNs that may operate at the colocated mode and use optimized routing, the problem becomes more obvious. Though per the RFC2977, a visiting network access entity needs to take the responsibility to perform AAA record collecting and DHCP server was used as a sample in this RFC... , it is still not clearly defined. Qiang -----Original Message----- From: KASSI-LAHLOU Mohammed FTRD/DMI/CAE Sent: Wed 12/5/2001 5:41 AM To: 'mobile-ip@sunroof.eng.sun.com'; Karim El-Malki (ERA) Cc: Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 Hi, I had understood that the routing process in the FA had already changed. The FA delivers the packets with mobile node's home address as a destination address to the MN on the foreign network; otherwise it will be a loop. Or may be the FA delivers the packets to the mobile node on the foreign network only if they were encapsulated and routes them towards the HA if they weren't. Maybe some clarifications are needed in the draft. Kassi -----Message d'origine----- De : Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] Envoye : mardi 4 decembre 2001 14:42 A : Karim El-Malki (ERA) Cc : 'Erik Nordmark'; 'mobile-ip@sunroof.eng.sun.com' Objet : RE: [mobile-ip] MN-to-MN communications in MIPv4 > What I should have written is that it wasn't clear what scenario would > require all packets to go through the HA, while reverse tunneling was > more obvious. The accounting can be done in the FA. Is there any other > scenario where all traffic must go through the HA? If not then this > shortcut may be done by the FA if bidirectional tunneling is not used. > Otherwise I agree with what you're saying. I don't know if folks have built or are building MIPv4 FAs that collect accounting information. In such a case, from reading the RFCs, they would presumably expect all packets to go through the HA. Thus having FAs implement shortcuts might be an unpleasant surprise in that case. Having the accounting be done in the FA (without the ability for the HA to verify it) is a quite different model. THus I'm not debating that a system can't be built to work that way - I'm just pointing out that allowing FA shortcuts is a change to the RFCs as I understand them. Erik From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 11:28: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 LAA26579 for ; Wed, 5 Dec 2001 11:28:17 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13697; Wed, 5 Dec 2001 09:27:05 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18663; Wed, 5 Dec 2001 08:27:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5GPxHt009859 for ; Wed, 5 Dec 2001 08:25:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5GPx9H009858 for mobile-ip-dist; Wed, 5 Dec 2001 08:25:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5GPuHt009851 for ; Wed, 5 Dec 2001 08:25:56 -0800 (PST) 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 IAA13213 for ; Wed, 5 Dec 2001 08:25:56 -0800 (PST) Received: from cisco.com (megha.cisco.com [192.122.173.140]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26448 for ; Wed, 5 Dec 2001 08:25:54 -0800 (PST) Received: from ROJOSEPC (odc-tekxp-51.cisco.com [192.122.174.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id VAA18125 for ; Wed, 5 Dec 2001 21:55:06 +0530 (IST) Message-ID: <0b8c01c17da9$b741eaa0$70ae7ac0@ROJOSEPC> From: "Roy Jose" To: References: <01FAF65DEA16D4119B95009027E78F3108A3CBB8@il02exm26.comm.mot.com> Subject: Re: [mobile-ip] MN-to-MN communications in MIPv4 Date: Wed, 5 Dec 2001 21:57:21 +0530 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 I think there is potential routing problem here. Suppose MN1 and MN2 are visitors on an FA (FA1). Now suppose MN2 does FA handoff and moves to FA2. FA1 will have a visiting entry for MN2 till the lifetime expiration. Now if FA1 tries to by-pass traffic to MN2 through it's visiting interface, packets won't reach MN2. This problem won't exist if HA send BU's to previous FA. But, I don't think many people would implement Route Optimizations on HA. -Roy > I thought I read the answer to this in RFC2002, but after going back to confirm it I was unable to find it again. It is my assumption that two mobile nodes connected to the same FA should be able to by-pass normal IP routing (e.g. the need to tunnel through a HA) and route directly through the FA. I make this assumption since it would be a logical optimization since the FA has all the necessary information needed to do so (e.g. home IP address, link layer address, etc.). The only supporting text I was able to find on this in the RFC was on page 10. > > "Similarly, a mobile node and a prospective or current foreign agent MUST be able to exchange datagrams without relying on standard IP routing mechanisms; that is, those mechanisms which make forwarding decisions based upon the network-prefix of the destination address in the IP header. This requirement can be satisfied if the foreign agent and the visiting mobile node have an interface on the same link. In this case, the mobile node and foreign agent simply bypass their normal IP routing mechanism when sending datagrams to each other, addressing the underlying link-layer packets to their respective link-layer addresses. Other placements of the foreign agent relative to the mobile node MAY also be possible using other mechanisms to exchange datagrams between these nodes, but such placements are beyond the scope of this document." > > 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 Dec 5 12:03: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 MAA27692 for ; Wed, 5 Dec 2001 12:03:21 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14557; Wed, 5 Dec 2001 09:02:16 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26207; Wed, 5 Dec 2001 09:01:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5H0tHt010059 for ; Wed, 5 Dec 2001 09:00:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5H0t0N010058 for mobile-ip-dist; Wed, 5 Dec 2001 09:00:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5H0qHt010051 for ; Wed, 5 Dec 2001 09:00:52 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10997 for ; Wed, 5 Dec 2001 09:00:52 -0800 (PST) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10540 for ; Wed, 5 Dec 2001 10:00:33 -0700 (MST) 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 LAA11882 for ; Wed, 5 Dec 2001 11:00:49 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch1.nortel.com; Wed, 5 Dec 2001 10:55:27 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Dec 2001 10:59:17 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0110F292@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Wed, 5 Dec 2001 10:59:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17DAE.2D5A03E0" Sender: owner-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_01C17DAE.2D5A03E0 Content-Type: text/plain; charset="iso-8859-1" Has anyone done a analysis on tunneling in general to describe possible DDoS, reflector holes in it? It seems to me that by simple induction, the same reflector threats are relavant to all forms of tunneling and that to protect against these DDoS threats state must be kept on the tunnel endpoints in order to police against DDoS reflector attack. That said - what is the use of sending the extra addresses in each packet at all since per-address authorization state must be kept on the tunnel endpoints in order to protect against the reflector attacks? > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, December 05, 2001 8:24 AM > To: mobile-ip > Subject: Re: [mobile-ip] Routing header Vs tunneling > > > On Wed, 5 Dec 2001, Francis Dupont wrote: > > > b. Home Address Option/Routing Header vs Tunnelling > > > > I think we should modify 'b' to say " Home Address Option > > vs Tunnelling" because ... > > > > => I disagree: home address option and routing header are two > > basic types of tunnel address compression (cf the Deering/Zill's > > draft-deering-ipv6-encap-addr-deletion-00.txt), i.e. there is > > no essential difference. > > But if your purpose is to show that mobile-ip is the wrong WG > > I agree, and IMHO the same remark applies to 'c' (piggy-backing). > > I agree with Francis. > > If we are to adopt tunneling, it seems to make sense to use > it for both > HAO and RH. If there were no problems with HAO, introducing tunneling > just for RH might not be as "imperative". These issues are > intertwined, > as the mechanisms compared to tunneling are very similar. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > ------_=_NextPart_001_01C17DAE.2D5A03E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

Has anyone done a analysis on tunneling in general to = describe possible DDoS, reflector holes in it? It seems to me that by = simple induction, the same reflector threats are relavant to all forms = of tunneling and that to protect against these DDoS threats state must = be kept on the tunnel endpoints in order to police against DDoS = reflector attack.

That said - what is the use of sending the extra = addresses in each packet at all since per-address authorization state = must be kept on the tunnel endpoints in order to protect against the = reflector attacks?

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Wednesday, December 05, 2001 8:24 = AM
> To: mobile-ip
> Subject: Re: [mobile-ip] Routing header Vs = tunneling
>
>
> On Wed, 5 Dec 2001, Francis Dupont = wrote:
> >    = >     b. Home Address Option/Routing Header vs = Tunnelling
> >   
> >    I think we should modify = 'b' to say " Home Address Option
> >    vs Tunnelling" = because ...
> >
> > =3D> I disagree: home address option = and routing header are two
> > basic types of tunnel address compression = (cf the Deering/Zill's
> > = draft-deering-ipv6-encap-addr-deletion-00.txt), i.e. there is
> > no essential difference.
> > But if your purpose is to show that = mobile-ip is the wrong WG
> > I agree, and IMHO the same remark applies = to 'c' (piggy-backing).
>
> I agree with Francis.
>
> If we are to adopt tunneling, it seems to make = sense to use
> it for both
> HAO and RH.  If there were no problems = with HAO, introducing tunneling
> just for RH might not be as = "imperative".  These issues are
> intertwined,
> as the mechanisms compared to tunneling are = very similar.
>
> --
> Pekka = Savola           =       "Tell me of difficulties = surmounted,
> Netcore = Oy           &nbs= p;       not those you stumble over and = fall"
> Systems. Networks. Security.  -- Robert = Jordan: A Crown of Swords
>
>

------_=_NextPart_001_01C17DAE.2D5A03E0-- From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 12:50:10 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29165 for ; Wed, 5 Dec 2001 12:50:09 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07216; Wed, 5 Dec 2001 09:48:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26830; Wed, 5 Dec 2001 09:48:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5HlRHt010296 for ; Wed, 5 Dec 2001 09:47:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5HlR0I010295 for mobile-ip-dist; Wed, 5 Dec 2001 09:47:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5HlOHt010288 for ; Wed, 5 Dec 2001 09:47:24 -0800 (PST) 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 JAA08513 for ; Wed, 5 Dec 2001 09:47:20 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18579 for ; Wed, 5 Dec 2001 09:47:19 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB5HlHS09229 for ; Wed, 5 Dec 2001 19:47:17 +0200 Date: Wed, 5 Dec 2001 19:47:16 +0200 (EET) From: Pekka Savola To: Subject: RE: [mobile-ip] Routing header Vs tunneling In-Reply-To: <933FADF5E673D411B8A30002A5608A0E0110F292@zrc2c012.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Wed, 5 Dec 2001, Glenn Morrow wrote: > Has anyone done a analysis on tunneling in general to describe possible > DDoS, reflector holes in it? It seems to me that by simple induction, the > same reflector threats are relavant to all forms of tunneling and that to > protect against these DDoS threats state must be kept on the tunnel > endpoints in order to police against DDoS reflector attack. I think one needs to create a small I-D at least on how (more or less) exactly specific tunneling would replace the current use. In this specific case -- I don't think the security considerations have been analyzed. Personally, I'd sure would be interested in trying to review a tunneling method. > That said - what is the use of sending the extra addresses in each packet at > all since per-address authorization state must be kept on the tunnel > endpoints in order to protect against the reflector attacks? Tunneling "open to all" is bad. I don't think an "open-to-all" tunneling solution would be much better than current mechanisms if it wasn't restricted in some ways (e.g. by omitting certain addresses, to make them unforgeable). However, currently tunneling (e.g. IPv4-in-IPv6 manual tunnels) are point to point, and more or less trust each end; you can create restrictions there. > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Wednesday, December 05, 2001 8:24 AM > > To: mobile-ip > > Subject: Re: [mobile-ip] Routing header Vs tunneling > > > > > > On Wed, 5 Dec 2001, Francis Dupont wrote: > > > > b. Home Address Option/Routing Header vs Tunnelling > > > > > > I think we should modify 'b' to say " Home Address Option > > > vs Tunnelling" because ... > > > > > > => I disagree: home address option and routing header are two > > > basic types of tunnel address compression (cf the Deering/Zill's > > > draft-deering-ipv6-encap-addr-deletion-00.txt), i.e. there is > > > no essential difference. > > > But if your purpose is to show that mobile-ip is the wrong WG > > > I agree, and IMHO the same remark applies to 'c' (piggy-backing). > > > > I agree with Francis. > > > > If we are to adopt tunneling, it seems to make sense to use > > it for both > > HAO and RH. If there were no problems with HAO, introducing tunneling > > just for RH might not be as "imperative". These issues are > > intertwined, > > as the mechanisms compared to tunneling are very similar. > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 14:02: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 OAA02837 for ; Wed, 5 Dec 2001 14:02:43 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA14323; Wed, 5 Dec 2001 11:01:20 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19612; Wed, 5 Dec 2001 11:00:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5Ix2Ht010915 for ; Wed, 5 Dec 2001 10:59:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5Ix2GG010914 for mobile-ip-dist; Wed, 5 Dec 2001 10:59:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5IwwHt010907 for ; Wed, 5 Dec 2001 10:58:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19255 for ; Wed, 5 Dec 2001 10:58:58 -0800 (PST) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18082 for ; Wed, 5 Dec 2001 11:58:39 -0700 (MST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with SMTP id NAA24592 for ; Wed, 5 Dec 2001 13:58:56 -0500 (EST) From: "Subrata Goswami" To: Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 Date: Wed, 5 Dec 2001 11:04:06 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <0b8c01c17da9$b741eaa0$70ae7ac0@ROJOSEPC> 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 Please bear with me a little while. If MN1 and MN2 wants to communicate and both are in the same foreign net, then the following are the options available for them to pass IP packets without involving the HA. 1. The FA is also the gateway router of the foreign subnet. 2. FA does proxy ARP (assuming Ethernet link layer) for the MN's. 3. The MN's respond to Home Address ARPs (again assuming Ethernet). Am I missing anything here ? -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Roy Jose Sent: Wednesday, December 05, 2001 8:27 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MN-to-MN communications in MIPv4 I think there is potential routing problem here. Suppose MN1 and MN2 are visitors on an FA (FA1). Now suppose MN2 does FA handoff and moves to FA2. FA1 will have a visiting entry for MN2 till the lifetime expiration. Now if FA1 tries to by-pass traffic to MN2 through it's visiting interface, packets won't reach MN2. This problem won't exist if HA send BU's to previous FA. But, I don't think many people would implement Route Optimizations on HA. -Roy > I thought I read the answer to this in RFC2002, but after going back to confirm it I was unable to find it again. It is my assumption that two mobile nodes connected to the same FA should be able to by-pass normal IP routing (e.g. the need to tunnel through a HA) and route directly through the FA. I make this assumption since it would be a logical optimization since the FA has all the necessary information needed to do so (e.g. home IP address, link layer address, etc.). The only supporting text I was able to find on this in the RFC was on page 10. > > "Similarly, a mobile node and a prospective or current foreign agent MUST be able to exchange datagrams without relying on standard IP routing mechanisms; that is, those mechanisms which make forwarding decisions based upon the network-prefix of the destination address in the IP header. This requirement can be satisfied if the foreign agent and the visiting mobile node have an interface on the same link. In this case, the mobile node and foreign agent simply bypass their normal IP routing mechanism when sending datagrams to each other, addressing the underlying link-layer packets to their respective link-layer addresses. Other placements of the foreign agent relative to the mobile node MAY also be possible using other mechanisms to exchange datagrams between these nodes, but such placements are beyond the scope of this document." > > 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 Dec 5 14:16: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 OAA04074 for ; Wed, 5 Dec 2001 14:16:10 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20896; Wed, 5 Dec 2001 11:15:04 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24888; Wed, 5 Dec 2001 11:14:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5JDrHt011113 for ; Wed, 5 Dec 2001 11:13:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5JDrhs011112 for mobile-ip-dist; Wed, 5 Dec 2001 11:13:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5JDnHt011105 for ; Wed, 5 Dec 2001 11:13:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24486 for ; Wed, 5 Dec 2001 11:13:49 -0800 (PST) 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 MAA23987 for ; Wed, 5 Dec 2001 12:14:18 -0700 (MST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA29352 for ; Wed, 5 Dec 2001 13:13:47 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id fB5JDk110758 for ; Wed, 5 Dec 2001 13:13:46 -0600 (CST) Message-ID: <3C0E728F.57776B64@alcatel.com> Date: Wed, 05 Dec 2001 13:16:31 -0600 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 0.0.0.0 src address References: <3F41C3159B4C874BB244474AB53D2C1A10F493@sdebe001.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 Lalwaley, "Lalwaney Poornima (NMP/SanDiego)" wrote: > Hi, > > As already discussed in this thread, the real problem is not with src= > 0.0.0.0 but that if you follow RFC2002 by the word, there are cases > where the destination IP agent advertisements and registration replies > is copied from the src IP getting us to the scenario where destination > IP=0.0.0.0. We have run into this issue with some implementations and > have had interoperability concerns on this issue. What kind of implementations of MIPv4 you are talking about? Hope you can share with us this info. > I diasgree that we > have to change RFC1112 interpretation by allowing 0.0.0.0 as destination > IP; or implement an involved DHCP kind of state machine for dynamic > address assignment. > > This destination IP address (0.0.0.0) is forbidden for anything except > source (see RFC 1700 introduction). RFC1700 has a caveat that appears as > "see note later" . I have not been able to find the note either in > RFC1700 or on the updated IANA web pages. > > I do not believe that Mobile IPv4 (RFC2002 or 2002bis) intended to > create a special case by allowing "0.0.0.0" as a valid destination > address. It seems that that 0.0.0.0 was an afterthought and all the > RFC2000 bis sections were not updated to reflect the effect of this > case. > > Could we not specify the destination IP of broadcast (255.255.255.255) > on replies for the cases where an agent receives a request with src > IP=0.0.0.0? This is similar to what DHCP does. Uninitialized host stack > implementations accept broadcast while dropping datagrams with > destinaton IP of 0.0.0.0. However, I think it would be an overkill to > design Mobile IPv4 clients with the DHCP behavior where the DHCPOFFER > and DHCPACK have as destination IP, the address that is to be bound to > the stack. Rather than allowing destination IP=0.0.0.0 as suggested in > this thread, why can we not use destination IP=255.255.255.255? > > Now getting to link layer address on the packets with broadcast > destination IP. Can we have unicast link layer address with broadcast > destination IP as would be required for registartion replies? > > So, the following cases have to be addressed in 2002bis with regards to > dynamic home address assignment: > > 1) If host stack has no IP address (sends requests with src IP = > 0.0.0.0), what is the destination IP on registration replies? Are both > destination link layer unicast and link layer broadcast permitted on the > reply. > > 2) If the host has another address bound to the interface (either > temporary or non-temporary), could that address be used for source IP > with home-address=0.0.0.0? > > Thanks.. > Poornima Lalwaney > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 14:20: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 OAA04270 for ; Wed, 5 Dec 2001 14:20:06 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22984; Wed, 5 Dec 2001 11:19:10 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26442; Wed, 5 Dec 2001 11:18:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5JI9Ht011285 for ; Wed, 5 Dec 2001 11:18:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5JI9Ar011284 for mobile-ip-dist; Wed, 5 Dec 2001 11:18:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5JI6Ht011277 for ; Wed, 5 Dec 2001 11:18:06 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09097 for ; Wed, 5 Dec 2001 11:18:05 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09262 for ; Wed, 5 Dec 2001 12:18:05 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA22145 for ; Wed, 5 Dec 2001 11:18:04 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB5JI4R30854 for ; Wed, 5 Dec 2001 11:18:04 -0800 X-mProtect: Wed, 5 Dec 2001 11:18:04 -0800 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 smtpd6lnEYj; Wed, 05 Dec 2001 11:18:02 PST Message-ID: <3C0E72EA.ADE2B37C@iprg.nokia.com> Date: Wed, 05 Dec 2001 11:18:02 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling References: <200112050903.fB5934D93006@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 Dupont wrote: > But if your purpose is to show that mobile-ip is the wrong WG > I agree great that you agree. this is good. lets throw these issues out of the Mobile IP WG. and lets to stick to solving the problem of key distribution between the MN and CN. this is what we should be concentrating on at this IETF IMO. regards Vijay > > Regards > > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 14:58: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 OAA07329 for ; Wed, 5 Dec 2001 14:58:51 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02616; Wed, 5 Dec 2001 12:57:41 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18827; Wed, 5 Dec 2001 11:57:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5JuGHt011543 for ; Wed, 5 Dec 2001 11:56:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5JuFL1011542 for mobile-ip-dist; Wed, 5 Dec 2001 11:56:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5JuCHt011535 for ; Wed, 5 Dec 2001 11:56:12 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18383 for ; Wed, 5 Dec 2001 11:56:12 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14838 for ; Wed, 5 Dec 2001 12:56:11 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA24623; Wed, 5 Dec 2001 11:56:10 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB5JuA321657; Wed, 5 Dec 2001 11:56:10 -0800 X-mProtect: Wed, 5 Dec 2001 11:56:10 -0800 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 smtpd5l0xnh; Wed, 05 Dec 2001 11:56:08 PST Message-ID: <3C0E7BD8.9C86FF4B@iprg.nokia.com> Date: Wed, 05 Dec 2001 11:56:08 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling 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 Pekka, I admit I am behind and have not studied the new tunneling draft yet. But I am surprised that you might suggest that we should use a new tunneling method that isn't even a working group document yet, when we already have methods that are: - Draft Standard - Implemented - Interoperable I reckon that the new tunneling method does not resolve any existing security questions. Placing a normative dependency into Mobile IPv6 to a brand new tunneling draft would only make sense if we could somehow imagine that improvement would result, and if the new tunneling draft had some magic ability to get to Proposed Standard in the near future. I will try to study the relevant drafts right away (I've been away on extended travel) to see what improvements might result, but as far as it has been explained to me I don't see them yet. Regards, Charlie P. Pekka Savola wrote: > > If we are to adopt tunneling, it seems to make sense to use it for both > HAO and RH. If there were no problems with HAO, introducing tunneling > just for RH might not be as "imperative". These issues are intertwined, > as the mechanisms compared to tunneling are very similar. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 15: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 PAA08157 for ; Wed, 5 Dec 2001 15:11:24 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15268; Wed, 5 Dec 2001 12:10:16 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21850; Wed, 5 Dec 2001 12:10:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5K92Ht011713 for ; Wed, 5 Dec 2001 12:09:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5K92iN011712 for mobile-ip-dist; Wed, 5 Dec 2001 12:09:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5K8wHt011705 for ; Wed, 5 Dec 2001 12:08:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09388 for ; Wed, 5 Dec 2001 12:08:54 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25452 for ; Wed, 5 Dec 2001 13:08:53 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA25382 for ; Wed, 5 Dec 2001 12:08:53 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB5K8qx07327 for ; Wed, 5 Dec 2001 12:08:52 -0800 X-mProtect: Wed, 5 Dec 2001 12:08:52 -0800 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 smtpdbbnrSp; Wed, 05 Dec 2001 12:08:51 PST Message-ID: <3C0E7ED3.4591F05E@iprg.nokia.com> Date: Wed, 05 Dec 2001 12:08:51 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] draft-montenegro-mipv6-seceval-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Gabriel, will there be another updated version of this draft before the IETF meeting? evaluations for atleast two protocols are missing. It will be good to fill in everything for a fair evaluation. it will great if we could conclude on something (whether a single proposal or a combination of one or more proposals) at the WG meeting next week. and the above MUST be the main focus of the meeting next week (I am getting tired repeating this). and of course, in my opinion :) regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 15:45: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 PAA10689 for ; Wed, 5 Dec 2001 15:45:12 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28525; Wed, 5 Dec 2001 12:44:22 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29333; Wed, 5 Dec 2001 12:44:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5KeNHt011923 for ; Wed, 5 Dec 2001 12:40:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5KeNUM011922 for mobile-ip-dist; Wed, 5 Dec 2001 12:40:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5KeKHt011915 for ; Wed, 5 Dec 2001 12:40:20 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16545 for ; Wed, 5 Dec 2001 12:40:20 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01062 for ; Wed, 5 Dec 2001 13:40:20 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fB5KeJE12813 for ; Wed, 5 Dec 2001 12:40:19 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAL55434; Wed, 5 Dec 2001 12:39:44 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA00351; Wed, 5 Dec 2001 12:40:18 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15374.34354.407221.647243@thomasm-u1.cisco.com> Date: Wed, 5 Dec 2001 12:40:18 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling In-Reply-To: References: <200112050903.fB5934D93006@givry.rennes.enst-bretagne.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 Pekka Savola writes: > On Wed, 5 Dec 2001, Francis Dupont wrote: > > > b. Home Address Option/Routing Header vs Tunnelling > > > > I think we should modify 'b' to say " Home Address Option > > vs Tunnelling" because ... > > > > => I disagree: home address option and routing header are two > > basic types of tunnel address compression (cf the Deering/Zill's > > draft-deering-ipv6-encap-addr-deletion-00.txt), i.e. there is > > no essential difference. > > But if your purpose is to show that mobile-ip is the wrong WG > > I agree, and IMHO the same remark applies to 'c' (piggy-backing). > > I agree with Francis. > > If we are to adopt tunneling, it seems to make sense to use it for both > HAO and RH. If there were no problems with HAO, introducing tunneling > just for RH might not be as "imperative". These issues are intertwined, > as the mechanisms compared to tunneling are very similar. Let me understand what is being proposed here. Are we saying that the tunneling between MN/CN is sufficiently general, and its security implications sufficient murky that would should remove it from MIPv6 and charter a new WG to work on the general problem rather than a MIPv6 specific problem? Mike From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 16:15: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 QAA12497 for ; Wed, 5 Dec 2001 16:15:48 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25790; Wed, 5 Dec 2001 14:14:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23533; Wed, 5 Dec 2001 13:14:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5LCwHt012110 for ; Wed, 5 Dec 2001 13:12:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5LCwli012109 for mobile-ip-dist; Wed, 5 Dec 2001 13:12:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5LCsHt012102 for ; Wed, 5 Dec 2001 13:12:55 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22876 for ; Wed, 5 Dec 2001 13:12:30 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14508 for ; Wed, 5 Dec 2001 14:12:29 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB5LCSJ10725 for ; Wed, 5 Dec 2001 23:12:28 +0200 Date: Wed, 5 Dec 2001 23:12:28 +0200 (EET) From: Pekka Savola To: Subject: Re: [mobile-ip] Routing header Vs tunneling In-Reply-To: <15374.34354.407221.647243@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: To Charlie also, On Wed, 5 Dec 2001, Michael Thomas wrote: > Pekka Savola writes: > > On Wed, 5 Dec 2001, Francis Dupont wrote: > > > > b. Home Address Option/Routing Header vs Tunnelling > > > > > > I think we should modify 'b' to say " Home Address Option > > > vs Tunnelling" because ... > > > > > > => I disagree: home address option and routing header are two > > > basic types of tunnel address compression (cf the Deering/Zill's > > > draft-deering-ipv6-encap-addr-deletion-00.txt), i.e. there is > > > no essential difference. > > > But if your purpose is to show that mobile-ip is the wrong WG > > > I agree, and IMHO the same remark applies to 'c' (piggy-backing). > > > > I agree with Francis. > > > > If we are to adopt tunneling, it seems to make sense to use it for both > > HAO and RH. If there were no problems with HAO, introducing tunneling > > just for RH might not be as "imperative". These issues are intertwined, > > as the mechanisms compared to tunneling are very similar. > > Let me understand what is being proposed here. Are > we saying that the tunneling between MN/CN is sufficiently > general, and its security implications sufficient murky > that would should remove it from MIPv6 and charter a > new WG to work on the general problem rather > than a MIPv6 specific problem? First, a clarification. I wasn't saying "we should move to tunneling". I was just trying to point out issues for consideration, _in case_ tunneling was decided to be a solution. I have not yet formed opinion on the subject. I'm not sure how you read that from what I wrote, but I think I see what you're pointing out; tunneling between some addresses is a problem that, under some circumstances, might be usable outside of MIPv6 context (one issue could be multihoming). In fact, this looks like ipng material (where, indeed, address deletion draft was originated). How we get something usable out of that.. well, I think it's still up to MIP people to see what's required if one would like to make it suit the MIP needs. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 16:20:34 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12810 for ; Wed, 5 Dec 2001 16:20:34 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29126; Wed, 5 Dec 2001 14:19:20 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25045; Wed, 5 Dec 2001 13:19:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5LIQHt012251 for ; Wed, 5 Dec 2001 13:18:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5LIQcK012250 for mobile-ip-dist; Wed, 5 Dec 2001 13:18:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5LINHt012243 for ; Wed, 5 Dec 2001 13:18:23 -0800 (PST) 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 NAA24842 for ; Wed, 5 Dec 2001 13:18:24 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17042 for ; Wed, 5 Dec 2001 13:18:23 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB5LILa10759 for ; Wed, 5 Dec 2001 23:18:21 +0200 Date: Wed, 5 Dec 2001 23:18:21 +0200 (EET) From: Pekka Savola To: Subject: Re: [mobile-ip] Routing header Vs tunneling In-Reply-To: <3C0E7BD8.9C86FF4B@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: On Wed, 5 Dec 2001, Charles E. Perkins wrote: > I admit I am behind and have not studied the new tunneling > draft yet. But I am surprised that you might suggest that > we should use a new tunneling method that isn't even a working > group document yet, when we already have methods that are: > - Draft Standard > - Implemented > - Interoperable I wasn't advocating its use; I was just discussing several issues _if_ we would, at some point (this is very probably a now or never issue), decide it's usable. Note: HAO, which is one of the used methods, is still internet-draft. The latter two apply though. > I reckon that the new tunneling method does not resolve any > existing security questions. That may or may not be; difficult to say at this point. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 16: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 QAA14635 for ; Wed, 5 Dec 2001 16:52:27 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26405; Wed, 5 Dec 2001 13:51:29 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02431; Wed, 5 Dec 2001 13:51:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5LoAHt012432 for ; Wed, 5 Dec 2001 13:50:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5LoANH012431 for mobile-ip-dist; Wed, 5 Dec 2001 13:50:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5Lo6Ht012424 for ; Wed, 5 Dec 2001 13:50:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03120 for ; Wed, 5 Dec 2001 13:50:06 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25724 for ; Wed, 5 Dec 2001 14:50:05 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA02242 for ; Wed, 5 Dec 2001 13:50:05 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB5Lo4r24043 for ; Wed, 5 Dec 2001 13:50:04 -0800 X-mProtect: Wed, 5 Dec 2001 13:50:04 -0800 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 smtpd3chuUb; Wed, 05 Dec 2001 13:50:03 PST Message-ID: <3C0E968B.D67F088B@iprg.nokia.com> Date: Wed, 05 Dec 2001 13:50:03 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling 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 Pekka Savola wrote: > Note: HAO, which is one of the used methods, is still internet-draft. The > latter two apply though. it is just a destination option which is a draft standard. and it is meant only for the destination. Vijay > > > I reckon that the new tunneling method does not resolve any > > existing security questions. > > That may or may not be; difficult to say at this point. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 17:12: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 RAA15731 for ; Wed, 5 Dec 2001 17:12:16 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA04751; Wed, 5 Dec 2001 14:11:24 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA07303; Wed, 5 Dec 2001 14:11:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5MADHt012626 for ; Wed, 5 Dec 2001 14:10:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5MADUF012625 for mobile-ip-dist; Wed, 5 Dec 2001 14:10:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5MA9Ht012618 for ; Wed, 5 Dec 2001 14:10:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08095 for ; Wed, 5 Dec 2001 14:10:09 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03200 for ; Wed, 5 Dec 2001 15:10:08 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA26303 for ; Wed, 5 Dec 2001 15:10:07 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA18144 for ; Wed, 5 Dec 2001 15:10:06 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <4K0CL6KK>; Wed, 5 Dec 2001 16:09:21 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FBF6@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] question on L2 triggers draft Date: Wed, 5 Dec 2001 16:08:02 -0600 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: Alper, Nice informative draft. I have one question on the L2 handover section (4.1) You say "When APs supporting multiple radio technologies on a single subnet, interoperability suffers if there is no L2-independent way of reporting on link movement." Would you care to elaborate? Say a WLAN AP-cellular AP case, do you mean the movement has to be reported at L3 even if the two APs belong to the same subnet? Regards, Madjid -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Sunday, December 02, 2001 2:14 AM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] L2 triggers draft Folks, New version of L2 triggers draft is available: http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-01.txt Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems Abstract A critical factor in achieving good performance for IP mobility protocols is the design of L2 handover. Handover occurs when a Mobile Node moves from one radio Access Point to another. If the new radio Access Point is associated with a new subnet, a change in routing reachability may occur and require L3 protocol action on the part of the Mobile Node or Access Routers. If no change in subnet occurs, the Access Point may still need to take some action to inform the Access Router about a change in on-link reachability. In either case, prompt and timely information from L2 to the parties involved about the sequencing of handover can help optimize handover at the IP level. This draft discusses requirements for an L2 handover protocol or API to support optimized handover. Enjoy. alper From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 18:28: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 SAA20439 for ; Wed, 5 Dec 2001 18:28:24 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28943; Wed, 5 Dec 2001 16:27:18 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24841; Wed, 5 Dec 2001 15:27:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5NQSHt012848 for ; Wed, 5 Dec 2001 15:26:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB5NQRih012847 for mobile-ip-dist; Wed, 5 Dec 2001 15:26:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB5NQOHt012840 for ; Wed, 5 Dec 2001 15:26:24 -0800 (PST) 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 PAA24614 for ; Wed, 5 Dec 2001 15:26:24 -0800 (PST) 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 PAA20222 for ; Wed, 5 Dec 2001 15:26:20 -0800 (PST) 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 fB5NRMQ22072 for ; Wed, 5 Dec 2001 17:27:22 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 5 Dec 2001 17:26:20 -0600 Received: from sdebe001.NOE.Nokia.com ([172.19.201.136]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Dec 2001 17:26:21 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [mobile-ip] 0.0.0.0 src address Date: Wed, 5 Dec 2001 15:26:19 -0800 Message-ID: <3F41C3159B4C874BB244474AB53D2C1A10F499@sdebe001.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] 0.0.0.0 src address Thread-Index: AcF9wXCiECZlWemzEdWBUgBQi2X+DwAC7vvw From: "Lalwaney Poornima (NMP/SanDiego)" To: X-OriginalArrivalTime: 05 Dec 2001 23:26:21.0189 (UTC) FILETIME=[3F58E350:01C17DE4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fB5NQOHt012841 Sender: owner-mobile-ip@sunroof.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: ext Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Wednesday, December 05, 2001 11:17 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 0.0.0.0 src address Hello Lalwaley, "Lalwaney Poornima (NMP/SanDiego)" wrote: > Hi, > > As already discussed in this thread, the real problem is not with src= > 0.0.0.0 but that if you follow RFC2002 by the word, there are cases > where the destination IP agent advertisements and registration replies > is copied from the src IP getting us to the scenario where destination > IP=0.0.0.0. We have run into this issue with some implementations and > have had interoperability concerns on this issue. What kind of implementations of MIPv4 you are talking about? Hope you can share with us this info. PL> Its Mobile IP over PPP as specified for CDMA2000, where the mobile does not have an IP address at the end of the PPP ( As I understand it, RFC2290 MIPv4 config option is not permitted for the temporary address assignment which could have been a possible solution to avoid dest IP of 0.0.0.0). However, I expect that there are other networks and hosts where the issue of destination IP = 0.0.0.0 when using dynamic home adddress assignment will need to be addressed. From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 5 20:00: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 UAA23645 for ; Wed, 5 Dec 2001 20:00:20 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA09935; Wed, 5 Dec 2001 16:59:14 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27242; Wed, 5 Dec 2001 16:58:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB60vpHt013160 for ; Wed, 5 Dec 2001 16:57:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB60vo1J013159 for mobile-ip-dist; Wed, 5 Dec 2001 16:57:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB60vlHt013152 for ; Wed, 5 Dec 2001 16:57:47 -0800 (PST) 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 QAA27021 for ; Wed, 5 Dec 2001 16:57:48 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18700 for ; Wed, 5 Dec 2001 16:57:48 -0800 (PST) Received: from AlperVAIO (dhcp9.docomo-usa.com [172.21.96.9]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB60vk527219 for ; Wed, 5 Dec 2001 16:57:46 -0800 (PST) Message-ID: <017e01c17df0$201e6350$096015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <01FAF65DEA16D4119B95009027E78F3108A3CBB8@il02exm26.comm.mot.com> <0b8c01c17da9$b741eaa0$70ae7ac0@ROJOSEPC> Subject: Re: [mobile-ip] MN-to-MN communications in MIPv4 Date: Wed, 5 Dec 2001 16:51:21 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 Roy, Having gone through this exercise twice (two implementations), yes, this is the major problem with this innocent-looking-free-optimization :) It gets home agent out of the loop. Therefore stale routing information on foreign agent can send the packets to blackhole after mobile moves off link. Also, any ingress filtering and control the home network would impose on incoming packets would be "skipped" if we let this happen. alper ----- Original Message ----- From: "Roy Jose" To: Sent: Wednesday, December 05, 2001 8:27 AM Subject: Re: [mobile-ip] MN-to-MN communications in MIPv4 > I think there is potential routing problem here. Suppose MN1 and MN2 are > visitors on an FA (FA1). Now suppose MN2 does FA handoff and moves to FA2. > FA1 will have a visiting entry for MN2 till the lifetime expiration. Now if > FA1 tries to by-pass traffic to MN2 through it's visiting interface, packets > won't reach MN2. This problem won't exist if HA send BU's to previous FA. > But, I don't think many people would implement Route Optimizations on HA. > > -Roy > > > I thought I read the answer to this in RFC2002, but after going back to > confirm it I was unable to find it again. It is my assumption that two > mobile nodes connected to the same FA should be able to by-pass normal IP > routing (e.g. the need to tunnel through a HA) and route directly through > the FA. I make this assumption since it would be a logical optimization > since the FA has all the necessary information needed to do so (e.g. home IP > address, link layer address, etc.). The only supporting text I was able to > find on this in the RFC was on page 10. > > > > "Similarly, a mobile node and a prospective or current foreign agent MUST > be able to exchange datagrams without relying on standard IP routing > mechanisms; that is, those mechanisms which make forwarding decisions based > upon the network-prefix of the destination address in the IP header. This > requirement can be satisfied if the foreign agent and the visiting mobile > node have an interface on the same link. In this case, the mobile node and > foreign agent simply bypass their normal IP routing mechanism when sending > datagrams to each other, addressing the underlying link-layer packets to > their respective link-layer addresses. Other placements of the foreign agent > relative to the mobile node MAY also be possible using other mechanisms to > exchange datagrams between these nodes, but such placements are beyond the > scope of this document." > > > > 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 Thu Dec 6 00:49: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 AAA02103 for ; Thu, 6 Dec 2001 00:49:53 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA10669; Wed, 5 Dec 2001 21:48:50 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA22815; Wed, 5 Dec 2001 21:48:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB65lpHt013612 for ; Wed, 5 Dec 2001 21:47:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB65lphS013611 for mobile-ip-dist; Wed, 5 Dec 2001 21:47:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB65lmHt013604 for ; Wed, 5 Dec 2001 21:47:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA22719 for ; Wed, 5 Dec 2001 21:47:48 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA15436 for ; Wed, 5 Dec 2001 22:48:20 -0700 (MST) Received: from AlperVAIO (dhcp149.docomo-usa.com [172.21.96.149]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB65lj505425 for ; Wed, 5 Dec 2001 21:47:45 -0800 (PST) Message-ID: <001d01c17e18$a24db100$956015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <35DBB8B7AC89D4118E98009027B1009B0464FBF6@IL27EXM10.cig.mot.com> Subject: Re: [mobile-ip] question on L2 triggers draft Date: Wed, 5 Dec 2001 21:41:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Madjid, This is James Kempf, Alper is lending me his machine. I think I wrote that. What I had in mind was the following situation. Suppose I've got a subnet with 802.11 and Bluetooth access points. Having a way that the access points could report movement to the access router would faciliatate intra-subnet movement, for example, ARP cache flushing. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: Sent: Wednesday, December 05, 2001 2:08 PM Subject: [mobile-ip] question on L2 triggers draft > Alper, > > Nice informative draft. I have one question on the L2 handover section (4.1) > You say > > "When APs supporting multiple radio technologies on a single subnet, > interoperability suffers if there is no L2-independent way of reporting > on link movement." > > Would you care to elaborate? > Say a WLAN AP-cellular AP case, do you mean the movement has to be reported > at L3 even if the two APs belong to the same subnet? > > Regards, > Madjid > > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Sunday, December 02, 2001 2:14 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] L2 triggers draft > > > Folks, > > New version of L2 triggers draft is available: > > http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-01.txt > > Supporting Optimized Handover for IP Mobility - > Requirements for Underlying Systems > > Abstract > > A critical factor in achieving good performance for IP mobility > protocols is the design of L2 handover. Handover occurs when a > Mobile Node moves from one radio Access Point to another. If the new > radio Access Point is associated with a new subnet, a change in > routing reachability may occur and require L3 protocol action on the > part of the Mobile Node or Access Routers. If no change in subnet > occurs, the Access Point may still need to take some action to > inform the Access Router about a change in on-link reachability. In > either case, prompt and timely information from L2 to the parties > involved about the sequencing of handover can help optimize handover > at the IP level. This draft discusses requirements for an L2 > handover protocol or API to support optimized handover. > > > Enjoy. > > alper > From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 01:07:36 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02487 for ; Thu, 6 Dec 2001 01:07:35 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA13684; Wed, 5 Dec 2001 22:06:38 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA24828; Wed, 5 Dec 2001 22:06:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB665eHt013743 for ; Wed, 5 Dec 2001 22:05:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB665eld013742 for mobile-ip-dist; Wed, 5 Dec 2001 22:05:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB665aHt013735 for ; Wed, 5 Dec 2001 22:05:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA23139 for ; Wed, 5 Dec 2001 22:05:37 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA20007 for ; Wed, 5 Dec 2001 23:06:08 -0700 (MST) Received: from AlperVAIO (dhcp149.docomo-usa.com [172.21.96.149]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB665Y505847 for ; Wed, 5 Dec 2001 22:05:34 -0800 (PST) Message-ID: <003a01c17e1b$1f7b5e00$956015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <8C92E23A3E87FB479988285F9E22BE460234CC@ftmail> Subject: Re: [mobile-ip] 0.0.0.0 src address Date: Wed, 5 Dec 2001 21:59:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 Matt, > > For example, what if any MN configures itself with a temporary address > > to send the reg-req with home-addr=0, to get it's > > newly-assigned homeaddr? > > > > > - If the mobile node does not have a home address, the IP source > > address MUST be 0.0.0.0. > > > > I also question why this is a MUST. It is entirely possible that the MN's > interface over which it is going to send the RREQ has an IP address > (established via DHCP), while the mobile does not yet have a MIP home > address. In this case, shouldn't it be able to send the RREQ with the > interface's address as the IP source address, but with a zero home address > in the RREQ?? You cannot make this assumption. This works only if we are using co-located care-of address. In case of FA-located care-of address, mobile node has only home address. > > matt > From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 01:14: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 BAA02905 for ; Thu, 6 Dec 2001 01:14:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA14982; Wed, 5 Dec 2001 22:13:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA25628; Wed, 5 Dec 2001 22:13:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB66CkHt013875 for ; Wed, 5 Dec 2001 22:12:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB66Ck2C013874 for mobile-ip-dist; Wed, 5 Dec 2001 22:12:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB66CgHt013867 for ; Wed, 5 Dec 2001 22:12:42 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA05438 for ; Wed, 5 Dec 2001 22:12:43 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA20743 for ; Wed, 5 Dec 2001 23:12:42 -0700 (MST) Received: from AlperVAIO ([172.21.96.179]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB66Ce506018 for ; Wed, 5 Dec 2001 22:12:40 -0800 (PST) Message-ID: <000901c17e1c$1d491f40$b36015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <3F41C3159B4C874BB244474AB53D2C1A10F493@sdebe001.NOE.Nokia.com> Subject: Re: [mobile-ip] 0.0.0.0 src address Date: Wed, 5 Dec 2001 22:06:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 Lalwaney, > So, the following cases have to be addressed in 2002bis with regards to > dynamic home address assignment: > > 1) If host stack has no IP address (sends requests with src IP = > 0.0.0.0), what is the destination IP on registration replies? Are both > destination link layer unicast and link layer broadcast permitted on the > reply. If we don't want to coflict with rfc1122, yes, we can do this. 255.255.255.255 should be fine. > > 2) If the host has another address bound to the interface (either > temporary or non-temporary), could that address be used for source IP > with home-address=0.0.0.0? If the mobile node is using colocated care-of address, yes, I think it can send a registration request using that address as the source. > > > > Thanks.. > Poornima Lalwaney > > alper > > > -----Original Message----- > From: ext Marc Hasson [mailto:marc@mentat.com] > Sent: Tuesday, December 04, 2001 10:34 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] 0.0.0.0 src address > > > Samita, > > (Sorry for the late response, @Home ate my own addressibility > yesterday. :-) We'll see how my replacement cable company does > today...) > > > > It seems to me that a Mobile Node could accept its newly-assigned > > > non-zero unicast destination address just as well as the 0.0.0.0, > it > > > should be well-aware its in an address discovery mode analagous to > > > DHCPv4 and process the UDP registration reply. > > > > > > > Is there any mobile node implementation which accepts UDP > registration > > reply destined to a newly assigned address and it's own link-layer > > address while it sends the request with src-addr=0.0.0.0 ? > > Unknown. This was just a suggestion on how to avoid the apparent 1122 > commentary regarding destinations of 0.0.0.0 meaning the local machine > as > opposed to something on the wire. > > It seems to me that DHCP implementations (perhaps with kernel stack > assist) > already handle this but I agree that mobile node implementations would > not > unless we specified it. > > > As it was pointed out that it is possible for an implementation > > to implement this behavior in MN. > > Agreed. I have no problem with the functionality proposed for the > 0.0.0.0 > address, my only commentary has been that 2002bis seems to be the first > place where 0.0.0.0 appears as a destination unicast address in a > packet. > > > I think the mobile-ip base draft rfc2002-bis needs to clarify the > > restriction on having src-addr = 0.0.0.0 and the consequent dst-addr > > for the registration reply from FA to MN. > > 100% agreed. > > > > > Note that it is also possible that FA may find that the registration > > request from src-addr=0.0.0.0 and home-addr=0.0.0.0 is > poorly-formatted > > or some other problem, how does it reply back with error then ? ( Due > to > > the restriction in RFC1122 ) > > Should it drop the packet or send it to multicast addr ? > > OK, good point there and perhaps I wasn't fully awake to think about > the error cases. DHCP presumably responds with a broadcast "nak" and > lets the proper client figure it out based on the ids in the message. > The same could be done with the MN but this doesn't seem as "clean" to > me. If it was important to avoid the apparent 1122 restriction then > thats what I would recommend but I think I'd agree that for > implementation simplicity the 0.0.0.0 handling is cleaner. > > How are apparent conflicts with 1122 handled? Just highlighted in > 2002bis > since these are *mobile* host requirements, not plain hosts? > > > > > I wonder, why rfc2002-bis has a MUST in 3.6.1.1, could it be MAY ? > > > > For example, what if any MN configures itself with a temporary > address > > to send the reg-req with home-addr=0, to get it's newly-assigned > homeaddr? > > > > > - If the mobile node does not have a home address, the IP > source > > address MUST be 0.0.0.0. > > Yep, I found this confusing too. I *think* the first MUST "overrides" > this second one when you have a co-located COA but I agree this should > be clarified. > > > > > Also the draft needs to clarify that if the source-addr of the UDP > registration > > request is 0.0.0.0, then what will be the IP dst addr for the > regReply. > > Yep. > > > -- Marc -- > From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 04: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 EAA21805 for ; Thu, 6 Dec 2001 04:02:41 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17806; Thu, 6 Dec 2001 02:01:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23026; Thu, 6 Dec 2001 01:01:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB690DHt014348 for ; Thu, 6 Dec 2001 01:00:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB690Dsq014347 for mobile-ip-dist; Thu, 6 Dec 2001 01:00:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6909Ht014340 for ; Thu, 6 Dec 2001 01:00:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22805 for ; Thu, 6 Dec 2001 01:00:10 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23040 for ; Thu, 6 Dec 2001 02:00:05 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fB6902I30939; Thu, 6 Dec 2001 10:00:02 +0100 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 KAA29280; Thu, 6 Dec 2001 10:00:02 +0100 (MET) 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 fB6901D00327; Thu, 6 Dec 2001 10:00:01 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112060900.fB6901D00327@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Pekka Savola Subject: Re: [mobile-ip] Routing header Vs tunneling In-reply-to: Your message of Wed, 05 Dec 2001 11:56:08 PST. <3C0E7BD8.9C86FF4B@iprg.nokia.com> Date: Thu, 06 Dec 2001 10:00:01 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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 admit I am behind and have not studied the new tunneling draft yet. But I am surprised that you might suggest that we should use a new tunneling method that isn't even a working group document yet, when we already have methods that are: - Draft Standard - Implemented - Interoperable => this is not the case of the home address option (we have not even an independent definition of it) and the routing header has some security issues that should be solved in a to be written document (IPv6 host requirements). So we cannot say there is no problem and it is better to deal with them in a larger and proper forum (i.e. the IPv6 WG). I reckon that the new tunneling method does not resolve any existing security questions. => not be itself but the idea is to put the burden in another WG, this should have two advantages: - more time to solve the real problem, i.e. how to secure BUs & co. - no danger to get a bad & late feedback as it happens about IPsec. Placing a normative dependency => the purpose is not to slow down Mobile IPv6 at all! If the new tunneling draft had some magic ability to get to Proposed Standard in the near future. => or the discussion about it reveals unsoluble security problems and Mobile IPv6 has a real problem, or the discussion shows how to not infringe upon security and Mobile IPv6 gets the benefit (with current or new mechanisms). I will try to study the relevant drafts right away (I've been away on extended travel) to see what improvements might result, but as far as it has been explained to me I don't see them yet. => the purpose is not improvements, it is a discussion of this kind of mechanisms in a general context. And this is *necessary* or how do you explain that the vast majority of deployed IPv6 implementations have both no home address option support and a half-backed security policy for source routing on hosts? Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 04: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 EAA21847 for ; Thu, 6 Dec 2001 04:05:03 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19234; Thu, 6 Dec 2001 02:03:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23577; Thu, 6 Dec 2001 01:04:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB692eHt014444 for ; Thu, 6 Dec 2001 01:02:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB692ddB014443 for mobile-ip-dist; Thu, 6 Dec 2001 01:02:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB692WHt014418 for ; Thu, 6 Dec 2001 01:02:33 -0800 (PST) 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 fB692Qq19367; Thu, 6 Dec 2001 10:02:26 +0100 (MET) Date: Thu, 6 Dec 2001 10:00:56 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 To: "Karim El-Malki (ERA)" Cc: "'Erik Nordmark'" , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <795A014AF92DD21182AF0008C7A404320DFBEE04@esealnt117> 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 believe there are FAs which collect accounting data (e.g. CDMA2000 PDSNs). > Would it actually be a problem for accounting? I'm not an expert in > this but why should the HA want to do accounting only for one > direction of MN traffic and not both? If you want to do accounting in the > HA then you reverse tunnel. If there's no reverse tunneling then only > the FA can collect accounting information for traffic to/from the MN. > Do you think HA verification of accounting only for traffic towards > the MN is something people want to do? My point is that we don't know - and we might not even be able to find out what assumptions folks have made for various systems. Thus being conservative not upsetting whatever assumptions folks have made would seem like a prudent approach. > Do you mean RFC2002 or others? I'm not sure this is disallowed in 2002 > but I may have misunderstood something. Also, as above, I don't think that > the ability for the HA to verify the FA's accounting only for one direction > of the traffic is useful. RFC 2002. There are lots of things (like dropping all port 443 tcp packets on the floor) that 2002 doesn't explicitly disallow - doesn't mean it is a good idea to do them. As far as I can tell (and please tell me what I missed) somebody reading RFC 2002 would assume that all packets to a MN pass through that MNs home agent. Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 04:20:24 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 EAA22002 for ; Thu, 6 Dec 2001 04:20:24 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27674; Thu, 6 Dec 2001 02:19:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25572; Thu, 6 Dec 2001 01:19:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB69I5Ht014707 for ; Thu, 6 Dec 2001 01:18:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB69I54B014706 for mobile-ip-dist; Thu, 6 Dec 2001 01:18:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB69I1Ht014699 for ; Thu, 6 Dec 2001 01:18:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA26304 for ; Thu, 6 Dec 2001 01:18:02 -0800 (PST) Received: from cisco.com (megha.cisco.com [192.122.173.140]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26858 for ; Thu, 6 Dec 2001 02:17:42 -0700 (MST) Received: from ROJOSEPC (odc-tekxp-51.cisco.com [192.122.174.112]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with SMTP id OAA09006 for ; Thu, 6 Dec 2001 14:47:12 +0530 (IST) Message-ID: <0def01c17e37$1a520b10$70ae7ac0@ROJOSEPC> From: "Roy Jose" To: References: Subject: Re: [mobile-ip] MN-to-MN communications in MIPv4 Date: Thu, 6 Dec 2001 14:49:26 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Subrata, MN or FA are not supposed to send any ARP replies. FA is the default gateway for MN's always:) Btw, I am not sure if you got my point right. What I meant was previous FA(FA1) will have stale information(ARP/route) for the MN(MN2) even after FA handoff and that will cause problems. Thanks, Roy ----- Original Message ----- From: "Subrata Goswami" To: Sent: Thursday, December 06, 2001 12:34 AM Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 > Please bear with me a little while. If MN1 and MN2 wants to communicate > and both are in the same foreign net, then the following are the options > available for them to pass IP packets without involving the HA. > > 1. The FA is also the gateway router of the foreign subnet. > 2. FA does proxy ARP (assuming Ethernet link layer) for the MN's. > 3. The MN's respond to Home Address ARPs (again assuming Ethernet). > > Am I missing anything here ? > > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Roy Jose > Sent: Wednesday, December 05, 2001 8:27 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] MN-to-MN communications in MIPv4 > > > I think there is potential routing problem here. Suppose MN1 and MN2 are > visitors on an FA (FA1). Now suppose MN2 does FA handoff and moves to FA2. > FA1 will have a visiting entry for MN2 till the lifetime expiration. Now if > FA1 tries to by-pass traffic to MN2 through it's visiting interface, packets > won't reach MN2. This problem won't exist if HA send BU's to previous FA. > But, I don't think many people would implement Route Optimizations on HA. > > -Roy > > > I thought I read the answer to this in RFC2002, but after going back to > confirm it I was unable to find it again. It is my assumption that two > mobile nodes connected to the same FA should be able to by-pass normal IP > routing (e.g. the need to tunnel through a HA) and route directly through > the FA. I make this assumption since it would be a logical optimization > since the FA has all the necessary information needed to do so (e.g. home IP > address, link layer address, etc.). The only supporting text I was able to > find on this in the RFC was on page 10. > > > > "Similarly, a mobile node and a prospective or current foreign agent MUST > be able to exchange datagrams without relying on standard IP routing > mechanisms; that is, those mechanisms which make forwarding decisions based > upon the network-prefix of the destination address in the IP header. This > requirement can be satisfied if the foreign agent and the visiting mobile > node have an interface on the same link. In this case, the mobile node and > foreign agent simply bypass their normal IP routing mechanism when sending > datagrams to each other, addressing the underlying link-layer packets to > their respective link-layer addresses. Other placements of the foreign agent > relative to the mobile node MAY also be possible using other mechanisms to > exchange datagrams between these nodes, but such placements are beyond the > scope of this document." > > > > 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 Thu Dec 6 04:28:53 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22083 for ; Thu, 6 Dec 2001 04:28:53 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01894; Thu, 6 Dec 2001 02:27:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA28680; Thu, 6 Dec 2001 01:27:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB69RHHt014863 for ; Thu, 6 Dec 2001 01:27:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB69RGB6014862 for mobile-ip-dist; Thu, 6 Dec 2001 01:27:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB69RDHt014855 for ; Thu, 6 Dec 2001 01:27:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02765 for ; Thu, 6 Dec 2001 01:27:14 -0800 (PST) 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 CAA20605 for ; Thu, 6 Dec 2001 02:27:40 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fB69R7I02655 for ; Thu, 6 Dec 2001 10:27:07 +0100 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 KAA00218 for ; Thu, 6 Dec 2001 10:27:07 +0100 (MET) 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 fB69R6D00456 for ; Thu, 6 Dec 2001 10:27:06 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112060927.fB69R6D00456@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling In-reply-to: Your message of Wed, 05 Dec 2001 12:40:18 PST. <15374.34354.407221.647243@thomasm-u1.cisco.com> Date: Thu, 06 Dec 2001 10:27:06 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: Let me understand what is being proposed here. Are we saying that the tunneling between MN/CN is sufficiently general, and its security implications sufficient murky that would should remove it from MIPv6 and charter a new WG to work on the general problem rather than a MIPv6 specific problem? => we don't need a new WG because we already have the IPv6 WG. But the purpose is really to generalize the problem and to give it to another WG... IMHO this is better than to wait the IETF last call for getting the IPv6 WG opinion, isn't it? Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 09:05: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 JAA25529 for ; Thu, 6 Dec 2001 09:05:31 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA02226; Thu, 6 Dec 2001 07:03:13 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07247; Thu, 6 Dec 2001 06:03:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6E2DHt015257 for ; Thu, 6 Dec 2001 06:02:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6E2DPb015256 for mobile-ip-dist; Thu, 6 Dec 2001 06:02:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6E2AHt015249 for ; Thu, 6 Dec 2001 06:02:10 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA12668 for ; Thu, 6 Dec 2001 06:01:08 -0800 (PST) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01010 for ; Thu, 6 Dec 2001 07:00:49 -0700 (MST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Dec 2001 09:00:04 -0500 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'seamoby@cdma-2000.org'" Subject: [mobile-ip] NSIS working group Date: Thu, 6 Dec 2001 09:00: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: I heard that the NSIS working group was supposed to have been formed some time ago, to develop protocol solutions for QoS in Mobile IP networks. I had not heard anything about it, and was wondering if its already been formed, or scheduled to be formed sometime in the future? -Sharif. From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 09:59: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 JAA26763 for ; Thu, 6 Dec 2001 09:59:19 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06966; Thu, 6 Dec 2001 07:58:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15016; Thu, 6 Dec 2001 06:58:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6Ev7Ht015486 for ; Thu, 6 Dec 2001 06:57:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6Ev7Vv015485 for mobile-ip-dist; Thu, 6 Dec 2001 06:57:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6Ev3Ht015478 for ; Thu, 6 Dec 2001 06:57:03 -0800 (PST) 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 GAA08216 for ; Thu, 6 Dec 2001 06:57:03 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA03075 for ; Thu, 6 Dec 2001 06:57:02 -0800 (PST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Dec 2001 09:56:58 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE460234D7@ftmail> From: Matt Impett To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] 0.0.0.0 src address Date: Thu, 6 Dec 2001 09:56:57 -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: Alper, > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Thursday, December 06, 2001 12:59 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] 0.0.0.0 src address > > > Matt, > > > > > For example, what if any MN configures itself with a > temporary address > > > to send the reg-req with home-addr=0, to get it's > > > newly-assigned homeaddr? > > > > > > > - If the mobile node does not have a home address, > the IP source > > > address MUST be 0.0.0.0. > > > > > > > I also question why this is a MUST. It is entirely > possible that the MN's > > interface over which it is going to send the RREQ has an IP address > > (established via DHCP), while the mobile does not yet have > a MIP home > > address. In this case, shouldn't it be able to send the > RREQ with the > > interface's address as the IP source address, but with a > zero home address > > in the RREQ?? > > You cannot make this assumption. This works only if we are using > co-located care-of address. In case of FA-located care-of > address, mobile node has only home address. I was not making the assumption that this was always the case. I was merely asking: when this is the case, shouldn't the mobile be able to set the source IP address on its RREQ equal to the interface's address over which the RREQ is going out?? Currently this is not allowed by the MIP draft, as the mobile MUST set the source address of its RREQs to 0.0.0.0 if it has no home address. Furthermore, why can't the mobile have a local interface address which is different than its home address without using co-located care-of-addresses?? matt From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 10:59:29 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28366 for ; Thu, 6 Dec 2001 10:59:28 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01193; Thu, 6 Dec 2001 07:57:08 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00501; Thu, 6 Dec 2001 07:53:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6FqDHt015717 for ; Thu, 6 Dec 2001 07:52:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6FqDeq015716 for mobile-ip-dist; Thu, 6 Dec 2001 07:52:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6FqAHt015709 for ; Thu, 6 Dec 2001 07:52:10 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23406 for ; Thu, 6 Dec 2001 07:52:10 -0800 (PST) Received: from zrc2s03g.us.nortel.com (h66s122a103n47.user.nortelnetworks.com [47.103.122.66]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26431 for ; Thu, 6 Dec 2001 08:52:09 -0700 (MST) 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 JAA02993 for ; Thu, 6 Dec 2001 09:52:06 -0600 (CST) Received: from zrchb200.us.nortel.com by smtprch2.nortel.com; Thu, 6 Dec 2001 09:44:44 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Dec 2001 09:50:14 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0110FF6B@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] NSIS working group Date: Thu, 6 Dec 2001 09:50:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C17E6D.B0A8C4B0" 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_01C17E6D.B0A8C4B0 Content-Type: text/plain; charset="iso-8859-1" Sharif, The WG was approved last week by the IESG and it is currently working on requirements. Some candidate documents are located on the NSIS page: http://www-nrc.nokia.com/sua/nsis/NSIS.htm. I think there is another draft coming down the line located at: http://www.epic.roke.co.uk/epic/draft-brunner-nsis-req-00.txt. The mail list is at: https://www1.ietf.org/mailman/listinfo/nsis Hope this helps, Glenn > -----Original Message----- > From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@InterDigital.com] > Sent: Thursday, December 06, 2001 8:00 AM > To: 'mobile-ip@sunroof.eng.sun.com' > Cc: 'seamoby@cdma-2000.org' > Subject: [mobile-ip] NSIS working group > > > I heard that the NSIS working group was supposed to have been > formed some > time ago, to develop protocol solutions for QoS in Mobile IP > networks. I had > not heard anything about it, and was wondering if its already > been formed, > or scheduled to be formed sometime in the future? > > -Sharif. > ------_=_NextPart_001_01C17E6D.B0A8C4B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] NSIS working group

Sharif,

The WG was approved last week by the IESG and it is = currently working on requirements. Some candidate documents are located = on the NSIS page:

http://www-nrc.nokia.com/sua/nsis/NSIS.htm.=

I think there is another draft coming down the line = located at:
http://www.epic.roke.co.uk/epic/draft-brunner-nsis-req= -00.txt.

The mail list is at:
https://www1.ietf.org/mailman/listinfo/nsis=

Hope this helps,

Glenn

> -----Original Message-----
> From: Shahrier, Sharif M. [mailto:Sharif.Shahrier@= InterDigital.com]
> Sent: Thursday, December 06, 2001 8:00 = AM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Cc: 'seamoby@cdma-2000.org'
> Subject: [mobile-ip] NSIS working group
>
>
> I heard that the NSIS working group was = supposed to have been
> formed some
> time ago, to develop protocol solutions for QoS = in Mobile IP
> networks. I had
> not heard anything about it, and was wondering = if its already
> been formed,
> or scheduled to be formed sometime in the = future?
>
> -Sharif.
>

------_=_NextPart_001_01C17E6D.B0A8C4B0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 12:09: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 MAA02082 for ; Thu, 6 Dec 2001 12:09:04 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15799; Thu, 6 Dec 2001 10:07:50 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08996; Thu, 6 Dec 2001 09:07:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6H73Ht016026 for ; Thu, 6 Dec 2001 09:07:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6H73EL016025 for mobile-ip-dist; Thu, 6 Dec 2001 09:07:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6H6xHt016018 for ; Thu, 6 Dec 2001 09:06:59 -0800 (PST) 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 JAA04240 for ; Thu, 6 Dec 2001 09:07:00 -0800 (PST) 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 JAA24289 for ; Thu, 6 Dec 2001 09:07:00 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA25442; Thu, 6 Dec 2001 09:06:59 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB6H6xl11384; Thu, 6 Dec 2001 09:06:59 -0800 X-mProtect: Thu, 6 Dec 2001 09:06:59 -0800 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 smtpdLdRTCD; Thu, 06 Dec 2001 09:06:58 PST Message-ID: <3C0FA5B2.AC382C96@iprg.nokia.com> Date: Thu, 06 Dec 2001 09:06:58 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Matt Impett CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 0.0.0.0 src address References: <8C92E23A3E87FB479988285F9E22BE460234D7@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Matt Impett wrote: >>> I also question why this is a MUST. It is entirely possible that >>> the MN's interface over which it is going to send the RREQ has an IP >>> address (established via DHCP), while the mobile does not yet have >>> a MIP home address. In this case, shouldn't it be able to send the >>> interface's address as the IP source address, but with a zero home >>> address in the RREQ?? I think your suggestion is reasonable. It is currently a MUST for historical reasons, and nobody ever suggested that the mandate be softened. Now that the document has already gone through IETF Last Call, changes would have to go into a Mobile IP version 3 document of some sort, and this matter doesn't seem to warrant such action. > Furthermore, why can't the mobile have a local interface address which is > different than its home address without using co-located care-of-addresses?? I don't think there is any prohibition against the mobile node getting more addresses, but that is a different question. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 12:52: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 MAA05768 for ; Thu, 6 Dec 2001 12:52:04 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA25353; Thu, 6 Dec 2001 09:48:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15513; Thu, 6 Dec 2001 09:32:56 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6HVrHt016243 for ; Thu, 6 Dec 2001 09:31:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6HVrtm016242 for mobile-ip-dist; Thu, 6 Dec 2001 09:31:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6HVoHt016235 for ; Thu, 6 Dec 2001 09:31:50 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10646 for ; Thu, 6 Dec 2001 09:31:50 -0800 (PST) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23833 for ; Thu, 6 Dec 2001 10:31:50 -0700 (MST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with SMTP id MAA17305 for ; Thu, 6 Dec 2001 12:31:48 -0500 (EST) From: "Subrata Goswami" To: Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 Date: Thu, 6 Dec 2001 09:36:45 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <0def01c17e37$1a520b10$70ae7ac0@ROJOSEPC> 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 Roy, MN and FA can do ARP, only restriction is MN can only do unicast ARP reply if it not co-located. "While the mobile node is away from home, it MUST NOT transmit any broadcast ARP Request or ARP Reply messages. Finally, while the mobile node is away from home, it MUST NOT reply to ARP Requests in which the target IP address is its own home address, unless the ARP Request is sent by a foreign agent with which the mobile node is attempting to register or a foreign agent with which the mobile node has an unexpired registration. In the latter case, the mobile node MUST use a unicast ARP Reply to respond to the foreign agent. Note that if the mobile node is using a co-located care-of address and receives an ARP Request in which the target IP address is this care-of address, then the mobile node SHOULD reply to this ARP Request. Note also that, when transmitting a Registration Request on a foreign network, a mobile node may discover the link-layer address of a foreign agent by storing the address as it is received from the Agent Advertisement from that foreign agent, but not by transmitting a broadcast ARP Request message." I have been able loacte in RFC 2002 where it says FA has to be the default router for the MN. RFC2002 says, "For datagrams sent by a mobile node, the foreign agent may serve as a default router for registered mobile nodes." Given the possibility in IPv4 that the FA may not be the default gateway for the MN, the FA may not even be able to collect any accounting data. Will address the stale-data issue in a later email. Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Roy Jose Sent: Thursday, December 06, 2001 1:19 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MN-to-MN communications in MIPv4 Hi Subrata, MN or FA are not supposed to send any ARP replies. FA is the default gateway for MN's always:) Btw, I am not sure if you got my point right. What I meant was previous FA(FA1) will have stale information(ARP/route) for the MN(MN2) even after FA handoff and that will cause problems. Thanks, Roy ----- Original Message ----- From: "Subrata Goswami" To: Sent: Thursday, December 06, 2001 12:34 AM Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 > Please bear with me a little while. If MN1 and MN2 wants to communicate > and both are in the same foreign net, then the following are the options > available for them to pass IP packets without involving the HA. > > 1. The FA is also the gateway router of the foreign subnet. > 2. FA does proxy ARP (assuming Ethernet link layer) for the MN's. > 3. The MN's respond to Home Address ARPs (again assuming Ethernet). > > Am I missing anything here ? > > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Roy Jose > Sent: Wednesday, December 05, 2001 8:27 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] MN-to-MN communications in MIPv4 > > > I think there is potential routing problem here. Suppose MN1 and MN2 are > visitors on an FA (FA1). Now suppose MN2 does FA handoff and moves to FA2. > FA1 will have a visiting entry for MN2 till the lifetime expiration. Now if > FA1 tries to by-pass traffic to MN2 through it's visiting interface, packets > won't reach MN2. This problem won't exist if HA send BU's to previous FA. > But, I don't think many people would implement Route Optimizations on HA. > > -Roy > > > I thought I read the answer to this in RFC2002, but after going back to > confirm it I was unable to find it again. It is my assumption that two > mobile nodes connected to the same FA should be able to by-pass normal IP > routing (e.g. the need to tunnel through a HA) and route directly through > the FA. I make this assumption since it would be a logical optimization > since the FA has all the necessary information needed to do so (e.g. home IP > address, link layer address, etc.). The only supporting text I was able to > find on this in the RFC was on page 10. > > > > "Similarly, a mobile node and a prospective or current foreign agent MUST > be able to exchange datagrams without relying on standard IP routing > mechanisms; that is, those mechanisms which make forwarding decisions based > upon the network-prefix of the destination address in the IP header. This > requirement can be satisfied if the foreign agent and the visiting mobile > node have an interface on the same link. In this case, the mobile node and > foreign agent simply bypass their normal IP routing mechanism when sending > datagrams to each other, addressing the underlying link-layer packets to > their respective link-layer addresses. Other placements of the foreign agent > relative to the mobile node MAY also be possible using other mechanisms to > exchange datagrams between these nodes, but such placements are beyond the > scope of this document." > > > > 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 Thu Dec 6 13:16: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 NAA06744 for ; Thu, 6 Dec 2001 13:16:44 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08924; Thu, 6 Dec 2001 11:15:38 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27467; Thu, 6 Dec 2001 10:15:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6IEUHt016475 for ; Thu, 6 Dec 2001 10:14:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6IEUKV016474 for mobile-ip-dist; Thu, 6 Dec 2001 10:14:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6IEQHt016467 for ; Thu, 6 Dec 2001 10:14:26 -0800 (PST) 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 KAA27042 for ; Thu, 6 Dec 2001 10:14:26 -0800 (PST) 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 KAA23965 for ; Thu, 6 Dec 2001 10:14:26 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA29953 for ; Thu, 6 Dec 2001 10:14:25 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB6IEPY26532 for ; Thu, 6 Dec 2001 10:14:25 -0800 X-mProtect: Thu, 6 Dec 2001 10:14:25 -0800 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 smtpd1dxPUK; Thu, 06 Dec 2001 10:14:23 PST Message-ID: <3C0FB57F.6CB061E4@iprg.nokia.com> Date: Thu, 06 Dec 2001 10:14:23 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling References: <697DAA22C5004B4596E033803A7CEF444CD1DB@daebe007.NOE.Nokia.com> <3C0D5616.77E8A24B@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 Pekka, you didnt respond to one of my questions below... Vijay Devarapalli wrote: > > Every host should follow these rules > > Routing header MUST be processed if > 1. segleft is 1 > 2. destination address and intermediate address both > belong to the same interface of the host that > received the packet. > Routing header MUST not be processed if > 1. the address to be swapped does not belong to > the same interface as the destination address > on the IPv6 header. > > if a IPv6 host follows the above rules, is there still a > security problem? if not, I suggest we drop the issue of > router header Vs tunneling and use routing header with the > above two rules. if the IPv6 host follows the above two rules while processing the routing header, do you still see any security problems with the Mobile IPv6 use of routing header? if 'no' is the answer, I suggest we drop this issue NOW! TODAY! we dont have to waste time next wednesday. regards Vijay > > regards > Vijay > > > > > c. Piggybacking of binding updates > > > > Discussion lead by Gabriel Montenegro, Jari Arkko and Erik Nordmark > > > > I-Ds relevant to this discussion: > > > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-mipv6-sec-reqts- > > 02.txt > > http://www.ietf.org/internet-drafts/draft-arkko-mipv6-bu-security-01.txt > > http://www.ietf.org/internet-drafts/draft-montenegro-mobileip-mipv6-sece > > val-00.txt > > http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01. > > txt > > http://www.ietf.org/internet-drafts/draft-arkko-mipv6ro-secframework-00. > > txt > > > > Note: Only if you have read these I-Ds can you make comments at the > > microphone > > > > 3 RFC3012bis: Issues identified and Changes made 10 Mins Charles > > > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-00.tx > > t > > > > 4. Handoffs: Low Latency(v4) and Fast HO (v6) 30 Mins > > > > a. Discussion of issues based on implementation experience > > James Kempf > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lowlatency-hando > > ffs-v4-03.txt > > http://geocities.com/kempf42/llanalysis.pdf > > > > b. Fast handoff - Updates/Changes/Issues raised on list > > Gopal Dommety > > http://people.nokia.net/~patil/Internet_Drafts/draft-ietf-mobileip-fast- > > mipv6-04.txt > > > > 5. Localized Mobility Management Requirements 10 Mins > > Carl Williams > > http://www.ietf.org/internet-drafts/draft-ietf-mobileip-lmm-requirements > > -00.txt > > > > 6. MIPv6 at ETSI Bakeoff Report 10 Mins Sebastien Barbin From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 13:29: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 NAA07206 for ; Thu, 6 Dec 2001 13:29:59 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21556; Thu, 6 Dec 2001 11:28:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02709; Thu, 6 Dec 2001 10:28:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6IRrHt016620 for ; Thu, 6 Dec 2001 10:27:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6IRqIO016619 for mobile-ip-dist; Thu, 6 Dec 2001 10:27:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6IRnHt016612 for ; Thu, 6 Dec 2001 10:27:49 -0800 (PST) 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 KAA10902 for ; Thu, 6 Dec 2001 10:27:48 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29999 for ; Thu, 6 Dec 2001 10:27:47 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fB6IRj719356 for ; Thu, 6 Dec 2001 20:27:46 +0200 Date: Thu, 6 Dec 2001 20:27:45 +0200 (EET) From: Pekka Savola To: Subject: Re: [mobile-ip] Routing header Vs tunneling In-Reply-To: <3C0FB57F.6CB061E4@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: On Thu, 6 Dec 2001, Vijay Devarapalli wrote: > Vijay Devarapalli wrote: > > > > Every host should follow these rules > > > > Routing header MUST be processed if > > 1. segleft is 1 > > 2. destination address and intermediate address both > > belong to the same interface of the host that > > received the packet. > > Routing header MUST not be processed if > > 1. the address to be swapped does not belong to > > the same interface as the destination address > > on the IPv6 header. > > > > if a IPv6 host follows the above rules, is there still a > > security problem? if not, I suggest we drop the issue of > > router header Vs tunneling and use routing header with the > > above two rules. > > if the IPv6 host follows the above two rules while processing > the routing header, do you still see any security problems > with the Mobile IPv6 use of routing header? > > if 'no' is the answer, I suggest we drop this issue NOW! TODAY! > we dont have to waste time next wednesday. You didn't mention the same zone requirement that was also in the draft; I think the omission was not on purpose. There's pretty marginal threat left assuming same zone restriction, and if the processing is implemented like this, I think the risk is probably manageable. But that doesn't mean it must be *the* way to do it. There is still the issue of HAO vs. tunneling, though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 13:30: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 NAA07229 for ; Thu, 6 Dec 2001 13:30:33 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22165; Thu, 6 Dec 2001 11:29:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03094; Thu, 6 Dec 2001 10:29:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6IRlHt016610 for ; Thu, 6 Dec 2001 10:27:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6IRkhA016609 for mobile-ip-dist; Thu, 6 Dec 2001 10:27:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6IRgHt016602 for ; Thu, 6 Dec 2001 10:27:42 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01977; Thu, 6 Dec 2001 10:27:42 -0800 (PST) Received: from sun.com (dhcp-gnb03-212-201.France.Sun.COM [129.157.212.201]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id fB6IRde12220; Thu, 6 Dec 2001 10:27:39 -0800 (PST) Message-ID: <3C0FB7EF.71EDACE9@sun.com> Date: Thu, 06 Dec 2001 19:24:47 +0100 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] draft-montenegro-mipv6-seceval-00.txt References: <3C0E7ED3.4591F05E@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 Vijay Devarapalli wrote: > will there be another updated version of this draft before > the IETF meeting? I'll try to send something out on sunday when I'm back on line. -gabriel From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 13: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 ESMTP id NAA08084 for ; Thu, 6 Dec 2001 13:59:32 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15553; Thu, 6 Dec 2001 11:58:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11395; Thu, 6 Dec 2001 10:58:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6IvJHt017000 for ; Thu, 6 Dec 2001 10:57:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6IvJu4016999 for mobile-ip-dist; Thu, 6 Dec 2001 10:57:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6IvFHt016992 for ; Thu, 6 Dec 2001 10:57:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11118 for ; Thu, 6 Dec 2001 10:57:15 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24143 for ; Thu, 6 Dec 2001 11:57:15 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA03246 for ; Thu, 6 Dec 2001 10:57:14 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB6IvEW12676 for ; Thu, 6 Dec 2001 10:57:14 -0800 X-mProtect: Thu, 6 Dec 2001 10:57:14 -0800 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 smtpdGCB4UW; Thu, 06 Dec 2001 10:57:12 PST Message-ID: <3C0FBF88.1F8E901A@iprg.nokia.com> Date: Thu, 06 Dec 2001 10:57:12 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling 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 Pekka, Pekka Savola wrote: > There's pretty marginal threat left assuming same zone restriction, and if > the processing is implemented like this, I think the risk is probably > manageable. I am very glad that you agree on this. > > But that doesn't mean it must be *the* way to do it. I can give you a very frank answer for this. routing header has been shown to work. it is a draft standard. a lot of implementors have spent a lot of time implementing this. they have also spent a lot of time going to interops and show that it works (atleast 4 interops that I know of). and I am NOT going to let anybody change it. (especially now that you agree that it is safe to use). > There is still the > issue of HAO vs. tunneling, though. I will get to that soon. regards Vijay > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 14:00: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 OAA08149 for ; Thu, 6 Dec 2001 14:00:19 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16328; Thu, 6 Dec 2001 11:59:10 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11775; Thu, 6 Dec 2001 10:59:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6Iw8Ht017025 for ; Thu, 6 Dec 2001 10:58:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6Iw8NR017024 for mobile-ip-dist; Thu, 6 Dec 2001 10:58:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6Iw4Ht017017 for ; Thu, 6 Dec 2001 10:58:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11336 for ; Thu, 6 Dec 2001 10:58:04 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15005 for ; Thu, 6 Dec 2001 11:57:45 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA03297 for ; Thu, 6 Dec 2001 10:58:03 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB6Iw2013672 for ; Thu, 6 Dec 2001 10:58:02 -0800 X-mProtect: Thu, 6 Dec 2001 10:58:02 -0800 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 smtpdnunMnt; Thu, 06 Dec 2001 10:58:01 PST Message-ID: <3C0FBFB9.B803F7EF@iprg.nokia.com> Date: Thu, 06 Dec 2001 10:58:01 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-montenegro-mipv6-seceval-00.txt References: <3C0E7ED3.4591F05E@iprg.nokia.com> <3C0FB7EF.71EDACE9@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 gabriel montenegro wrote: > > Vijay Devarapalli wrote: > > > will there be another updated version of this draft before > > the IETF meeting? > > I'll try to send something out on sunday when I'm back on line. great. I would really appreciate that. if you need some help, let me know. regards Vijay > > -gabriel From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 14:24: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 OAA09222 for ; Thu, 6 Dec 2001 14:24:32 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06713; Thu, 6 Dec 2001 12:23:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15862; Thu, 6 Dec 2001 11:23:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6JMPHt017380 for ; Thu, 6 Dec 2001 11:22:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6JMP8v017379 for mobile-ip-dist; Thu, 6 Dec 2001 11:22:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6JMMHt017372 for ; Thu, 6 Dec 2001 11:22:22 -0800 (PST) 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 LAA25490 for ; Thu, 6 Dec 2001 11:22:22 -0800 (PST) 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 LAA07330 for ; Thu, 6 Dec 2001 11:22:21 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA05191 for ; Thu, 6 Dec 2001 11:22:21 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB6JMKv12705 for ; Thu, 6 Dec 2001 11:22:20 -0800 X-mProtect: Thu, 6 Dec 2001 11:22:20 -0800 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 smtpdDdRav7; Thu, 06 Dec 2001 11:22:18 PST Message-ID: <3C0FC56B.5C137480@iprg.nokia.com> Date: Thu, 06 Dec 2001 11:22:19 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-montenegro-mipv6-seceval-00.txt References: <3C0E7ED3.4591F05E@iprg.nokia.com> <3C0FB7EF.71EDACE9@sun.com> <3C0FBFB9.B803F7EF@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 oops.. ignore the mail. I wanted to send it do Gabriel alone. Vijay Vijay Devarapalli wrote: > > gabriel montenegro wrote: > > > > Vijay Devarapalli wrote: > > > > > will there be another updated version of this draft before > > > the IETF meeting? > > > > I'll try to send something out on sunday when I'm back on line. > > great. I would really appreciate that. if you need some help, > let me know. > > regards > Vijay > > > > > -gabriel From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 14:28: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 OAA09495 for ; Thu, 6 Dec 2001 14:28:49 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10211; Thu, 6 Dec 2001 12:27:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17347; Thu, 6 Dec 2001 11:27:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6JR0Ht017517 for ; Thu, 6 Dec 2001 11:27:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6JR04S017516 for mobile-ip-dist; Thu, 6 Dec 2001 11:27:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6JQuHt017509 for ; Thu, 6 Dec 2001 11:26:56 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17158 for ; Thu, 6 Dec 2001 11:26:56 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29820 for ; Thu, 6 Dec 2001 12:26:56 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fB6JQtE29841 for ; Thu, 6 Dec 2001 11:26:55 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAL76515; Thu, 6 Dec 2001 11:26:19 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA00903; Thu, 6 Dec 2001 11:26:53 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15375.50813.186702.746029@thomasm-u1.cisco.com> Date: Thu, 6 Dec 2001 11:26:53 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling In-Reply-To: <200112060927.fB69R6D00456@givry.rennes.enst-bretagne.fr> References: <15374.34354.407221.647243@thomasm-u1.cisco.com> <200112060927.fB69R6D00456@givry.rennes.enst-bretagne.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 Francis Dupont writes: > Let me understand what is being proposed here. Are > we saying that the tunneling between MN/CN is sufficiently > general, and its security implications sufficient murky > that would should remove it from MIPv6 and charter a > new WG to work on the general problem rather > than a MIPv6 specific problem? > > => we don't need a new WG because we already have the IPv6 WG. > But the purpose is really to generalize the problem and to give it > to another WG... IMHO this is better than to wait the IETF last call > for getting the IPv6 WG opinion, isn't it? Fine, I was just trying to figure out whether moving it out of MIP was what was being discussed. I haven't made up my mind whether that makes sense. I have to admit that this is somewhat tempting, as going through this entire exercise again for ipv4 route optimization doesn't thrill me. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 14:48: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 OAA10107 for ; Thu, 6 Dec 2001 14:48:52 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22565; Thu, 6 Dec 2001 12:43:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21376; Thu, 6 Dec 2001 11:43:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6Jg8Ht017736 for ; Thu, 6 Dec 2001 11:42:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6Jg8OM017735 for mobile-ip-dist; Thu, 6 Dec 2001 11:42:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6Jg4Ht017728 for ; Thu, 6 Dec 2001 11:42:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22463 for ; Thu, 6 Dec 2001 11:42:04 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29171 for ; Thu, 6 Dec 2001 12:42:35 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA06449; Thu, 6 Dec 2001 11:42:03 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB6Jg2F06386; Thu, 6 Dec 2001 11:42:02 -0800 X-mProtect: Thu, 6 Dec 2001 11:42:02 -0800 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 smtpd4lUftA; Thu, 06 Dec 2001 11:42:00 PST Message-ID: <3C0FCA08.B0FB5C55@iprg.nokia.com> Date: Thu, 06 Dec 2001 11:42:00 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Additional comments on draft-arkko-mipv6-bu-security-00.txt References: <3BFA30E7.A02189A5@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 Hello Jari, Jari Arkko wrote: > Erik, thanks for your comments. I have some answers below: > > > Section 6.4 talks about having a configuration knob to allow > > unsecure BUs. I think this is a big mistake. Instead the WG should > > develop some BU solution that can give some security comparable to > > today's IPv4 security. > > I agree! I have recently come to the conclusion myself that > we should not allow unsecure RO at all, and as a minimum should > require one of the weak auth protocols. I was really surprised to read this. Unsecure route optimization has _never_ been allowable in the Mobile IP working group, neither for IPv4 or for IPv6. When has there been discussion otherwise? Or am I misinterpreting something? This was my biggest complaint against the original security requirements draft. There was so much analysis about what would go wrong with unsecured Binding Updates, which were never allowable or specified in any draft that I know of. The real issues were thus obscured, and the false impression was given that unsecured Binding Updates represented a security vulnerability of Mobile IPv6. The newer security requirements draft is better in that it avoids making this misrepresentation. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 15:51: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 PAA11853 for ; Thu, 6 Dec 2001 15:51:32 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05476; Thu, 6 Dec 2001 12:49:20 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29469; Thu, 6 Dec 2001 12:41:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6KeHHt018034 for ; Thu, 6 Dec 2001 12:40:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6KeHHO018033 for mobile-ip-dist; Thu, 6 Dec 2001 12:40:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6KeBHt018026 for ; Thu, 6 Dec 2001 12:40:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05898 for ; Thu, 6 Dec 2001 12:40:12 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA20496 for ; Thu, 6 Dec 2001 13:40:12 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA10289; Thu, 6 Dec 2001 12:40:11 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB6Ke7w08311; Thu, 6 Dec 2001 12:40:07 -0800 X-mProtect: Thu, 6 Dec 2001 12:40:07 -0800 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 smtpdWbVk3y; Thu, 06 Dec 2001 12:40:05 PST Message-ID: <3C0FD7A6.D1AA135D@iprg.nokia.com> Date: Thu, 06 Dec 2001 12:40:06 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Bilgic, Murat" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] more about piggybacking. References: <80DEC17E75FCD41188BD00508BF7D42D70BEA0@wanewporms04.gsm1900.org> <3BFAB7F5.A4F2B40E@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Murat, "Bilgic, Murat" wrote (actually to Cedric Westphal, but I had some answers to contribute): >> What's the assumption behind having a single link? If there are multiple links for which the constraints on bandwidth and medium access are important, I reckon that the effects would be cumulative. Considering a single link is at least easier to understand, and amounts to a conservative assumption. >> What's the delay tolerance of the BU? There isn't any established delay tolerance. The sooner the Binding Update can be delivered, the better performance. I don't think there is any huge downside other than somewhat increased end-to-end delay. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 16:00:08 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12106 for ; Thu, 6 Dec 2001 16:00:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12774; Thu, 6 Dec 2001 13:58:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10912; Thu, 6 Dec 2001 12:59:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6KvbHt018307 for ; Thu, 6 Dec 2001 12:57:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6KvaQG018306 for mobile-ip-dist; Thu, 6 Dec 2001 12:57:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6KvWHt018299 for ; Thu, 6 Dec 2001 12:57:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10699 for ; Thu, 6 Dec 2001 12:57:33 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28809 for ; Thu, 6 Dec 2001 13:57:33 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id NAA11233 for ; Thu, 6 Dec 2001 13:57:33 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id NAA03167 for ; Thu, 6 Dec 2001 13:57:32 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id <4K0CMQMX>; Thu, 6 Dec 2001 14:57:32 -0600 Message-ID: <35DBB8B7AC89D4118E98009027B1009B0464FC08@IL27EXM10.cig.mot.com> From: Nakhjiri Madjid-MNAKHJI1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] question on L2 triggers draft Date: Thu, 6 Dec 2001 14:57:24 -0600 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: Hi james (C/o Alper :) ) Ok, Understand. That sounds reasonable. Thanks, Madjid -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Wednesday, December 05, 2001 11:41 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] question on L2 triggers draft Hi Madjid, This is James Kempf, Alper is lending me his machine. I think I wrote that. What I had in mind was the following situation. Suppose I've got a subnet with 802.11 and Bluetooth access points. Having a way that the access points could report movement to the access router would faciliatate intra-subnet movement, for example, ARP cache flushing. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: Sent: Wednesday, December 05, 2001 2:08 PM Subject: [mobile-ip] question on L2 triggers draft > Alper, > > Nice informative draft. I have one question on the L2 handover section (4.1) > You say > > "When APs supporting multiple radio technologies on a single subnet, > interoperability suffers if there is no L2-independent way of reporting > on link movement." > > Would you care to elaborate? > Say a WLAN AP-cellular AP case, do you mean the movement has to be reported > at L3 even if the two APs belong to the same subnet? > > Regards, > Madjid > > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Sunday, December 02, 2001 2:14 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] L2 triggers draft > > > Folks, > > New version of L2 triggers draft is available: > > http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-01.txt > > Supporting Optimized Handover for IP Mobility - > Requirements for Underlying Systems > > Abstract > > A critical factor in achieving good performance for IP mobility > protocols is the design of L2 handover. Handover occurs when a > Mobile Node moves from one radio Access Point to another. If the new > radio Access Point is associated with a new subnet, a change in > routing reachability may occur and require L3 protocol action on the > part of the Mobile Node or Access Routers. If no change in subnet > occurs, the Access Point may still need to take some action to > inform the Access Router about a change in on-link reachability. In > either case, prompt and timely information from L2 to the parties > involved about the sequencing of handover can help optimize handover > at the IP level. This draft discusses requirements for an L2 > handover protocol or API to support optimized handover. > > > Enjoy. > > alper > From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 16:33: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 QAA13267 for ; Thu, 6 Dec 2001 16:33:30 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04656; Thu, 6 Dec 2001 14:32:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18506; Thu, 6 Dec 2001 13:32:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6LVNHt018616 for ; Thu, 6 Dec 2001 13:31:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6LVNlV018615 for mobile-ip-dist; Thu, 6 Dec 2001 13:31:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6LVIHt018608 for ; Thu, 6 Dec 2001 13:31:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18225 for ; Thu, 6 Dec 2001 13:31:19 -0800 (PST) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA13131 for ; Thu, 6 Dec 2001 14:31:52 -0700 (MST) Received: from jariws1 ([62.248.238.66]) by fep06-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011206213116.PIRN19421.fep06-app.kolumbus.fi@jariws1>; Thu, 6 Dec 2001 23:31:16 +0200 Message-ID: <035901c17e9d$61ca55e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Charles E. Perkins" Cc: References: <3BFA30E7.A02189A5@lmf.ericsson.se> <3C0FCA08.B0FB5C55@iprg.nokia.com> Subject: Re: [mobile-ip] Additional comments on draft-arkko-mipv6-bu-security-00.txt Date: Thu, 6 Dec 2001 23:31:35 +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.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 > > I agree! I have recently come to the conclusion myself that > > we should not allow unsecure RO at all, and as a minimum should > > require one of the weak auth protocols. > > I was really surprised to read this. Unsecure route optimization has > _never_ been allowable in the Mobile IP working group, neither for > IPv4 or for IPv6. When has there been discussion otherwise? There hasn't been - apparently I was the only one who was confused. In any case, now we all agree that some security must be on all the time. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 16:44: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 QAA13564 for ; Thu, 6 Dec 2001 16:44:19 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12380; Thu, 6 Dec 2001 14:43:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21427; Thu, 6 Dec 2001 13:43:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6LgRHt018800 for ; Thu, 6 Dec 2001 13:42:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6LgRY4018798 for mobile-ip-dist; Thu, 6 Dec 2001 13:42:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6LgNHt018791 for ; Thu, 6 Dec 2001 13:42:23 -0800 (PST) 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 NAA18056 for ; Thu, 6 Dec 2001 13:42:23 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18881 for ; Thu, 6 Dec 2001 13:42:13 -0800 (PST) Received: from T23KEMPF (dhcp149.docomo-usa.com [172.21.96.149]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB6LgB502627 for ; Thu, 6 Dec 2001 13:42:11 -0800 (PST) Message-ID: <00b401c17e9e$a33cd510$956015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] Forwarding from Previous CoA as an LMM Solution? Date: Thu, 6 Dec 2001 13:40:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Not trying to be provocative or anything, but I'm curious how "forwarding from previous Care of Address" which is in the Mobile IP spec, differs from HMIPv6. Anybody care to comment? One thing I can see is that forwarding from previous Care of Address limits where the LMM agent can be deployed to the Access Router, while HMIPv6 allows the MAP to be deployed anywhere. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 17:41: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 RAA15127 for ; Thu, 6 Dec 2001 17:41:48 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22920; Thu, 6 Dec 2001 15:40:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29279; Thu, 6 Dec 2001 12:40:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6KdSHt018017 for ; Thu, 6 Dec 2001 12:39:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6KdSC5018016 for mobile-ip-dist; Thu, 6 Dec 2001 12:39:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6KdOHt018009 for ; Thu, 6 Dec 2001 12:39:24 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29080 for ; Thu, 6 Dec 2001 12:39:25 -0800 (PST) Received: from rajma.kniveton.com (adsl-63-197-0-77.dsl.snfc21.pacbell.net [63.197.0.77]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29749 for ; Thu, 6 Dec 2001 13:39:06 -0700 (MST) Received: from [192.168.1.42] (atlantis.kniveton.com [192.168.1.42]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id fB6KdMr53957; Thu, 6 Dec 2001 12:39:22 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Date: Thu, 06 Dec 2001 12:39:20 -0800 Subject: FW: [mobile-ip] mobile nets meeting at IETF52 From: "T.J. Kniveton" To: , Message-ID: In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C113@Esealnt861.al.sw.ericsson.se> 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, I never saw the included on the list or in the archives so I guess it didn't make it. Anyway, we're going to meet up on Wednesday evening, at about 5:30pm - 7pm to talk about mobile networks & routers. Please e-mail hesham.soliman@era.ericsson.se to tell us how many people from your group are coming. Hesham is going to choose a good place for the meeting based on attendance and let people know. If you already received this message, sorry! Thanks, -TJ ---------- > -----Original Message----- > From: Hesham Soliman (ERA) > Sent: Wednesday, December 05, 2001 5:55 PM > To: 'mobile-ip@sunroof.eng.sun.com'; monet@crm.mot.com > Subject: RE: [mobile-ip] mobile nets meeting at IETF52 > > > Thanks TJ, > > I was meant to announce it but spent too much time > worrying about the best time for everyone ! > It has been suggested that it's too early to hit > the bar after the MIP wg meeting. > So the current suggestion is to hold the meeting > before the plenary. 17.30 - 19.00 > > It would be good to know how many people are interested > in coming, so I can find an appropriate place. > So please let me know (via private mail) if you > (or preferably more than one person per email !) > are interested in attending. > > Please note that this is not a BOF but simply a > short meeting to discuss the possibility of holding > a BOF at the next meeting. > > Cheers, > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 18:01: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 SAA15557 for ; Thu, 6 Dec 2001 18:01:23 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04464; Thu, 6 Dec 2001 15:59:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16879; Thu, 6 Dec 2001 14:59:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6MwaoH019300 for ; Thu, 6 Dec 2001 14:58:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6Mwaf8019299 for mobile-ip-dist; Thu, 6 Dec 2001 14:58:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6MwXoH019292 for ; Thu, 6 Dec 2001 14:58:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06822 for ; Thu, 6 Dec 2001 14:58:33 -0800 (PST) Received: from ns1.nttmcl.com (ns1.nttmcl.com [216.69.68.197]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03795 for ; Thu, 6 Dec 2001 15:58:14 -0700 (MST) Received: from nttmcl.com (dhcp231.nttmcl.com [216.69.69.231]) by ns1.nttmcl.com (Postfix) with ESMTP id 38CE2DE542; Thu, 6 Dec 2001 14:58:32 -0800 (PST) Message-ID: <3C0FF882.FB5ADC15@nttmcl.com> Date: Thu, 06 Dec 2001 15:00:18 -0800 From: Satomi Okazaki X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Binding Update Authentication Proposals 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 I'm reposting this, because it didn't seem to get posted the first time around. If you've already received this e-mail, please ignore this message. Regards, Satomi Okazaki > An informational document summarizing some of the proposals submitted to > the working group regarding the binding update authentication problem > (between a mobile node and a correspondent node) has been posted at the > following URL: http://www.nttmcl.com/sec/BindingUpdate.pdf . > > We have attempted to give a short summary of each of the binding update > authentication proposals listed in “MIPv6 Security: Assessment of > Proposals,” an Internet Draft by G. Montenegro. Each proposal relies on > different security association assumptions, uses different cryptographic > techniques, and hence achieves different levels of security. Our intent is > to classify these proposals into several categories and describe them in a > uniform way so that it is easy to analyze and compare their security. > > Regards, > > Satomi Okazaki > NTT Multimedia Communications Laboratories, Inc. > 250 Cambridge Avenue, Suite 300 > Palo Alto, California 94306 From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 18:57: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 SAA17169 for ; Thu, 6 Dec 2001 18:57:52 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07765; Thu, 6 Dec 2001 16:55:59 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17183; Thu, 6 Dec 2001 15:56:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6NtSoH019465 for ; Thu, 6 Dec 2001 15:55:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB6NtRKV019464 for mobile-ip-dist; Thu, 6 Dec 2001 15:55:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6NtOoH019457 for ; Thu, 6 Dec 2001 15:55:24 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA20482 for ; Thu, 6 Dec 2001 15:55:25 -0800 (PST) Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07147 for ; Thu, 6 Dec 2001 16:55:06 -0700 (MST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA12778; Thu, 6 Dec 2001 18:52:37 -0500 Received: from d03nm066.boulder.ibm.com (d03nm066.boulder.ibm.com [9.99.140.50]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB6NtNe85578; Thu, 6 Dec 2001 16:55:23 -0700 Subject: [mobile-ip] Question on performing DAD for BU's To: charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Thu, 6 Dec 2001 15:52:53 -0800 X-MIMETrack: Serialize by Router on D03NM066/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/06/2001 04:55:23 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 Charlie, I feel there is a small problem in the Draft 15 regarding the address used for performing DAD. 1. Page 67 for BU processing says that DAD should be performed on the Link Local Address. 2. Pg 94 says that : If some time elapses during which the mobile node has no binding at the home agent, it might be possible for another node to autoconfigure the mobile node's home address. A new node 'X' can configure it's address either through autoconfiguration (in which case #1 is sufficient), or by manual means. Since the address can be configured manually, I feel the specification should be changed to state that DAD should be performed on the Link Local address and all Home Addresses (if Prefix Length is > 0) based on different prefixes supported by the Home Agent. The reason is that the MN might configure a site local address as it's home address and move to a foreign network. Before HA gets the BU, another node 'X' manually configures it's address to the site local address used by the MN, and it succeeds. When HA gets the BU, it does a Neighbor Solicitation on the Link Local Address, and since X has not configured that link local address, it doesn't respond to the NS. Now packets meant for 'X' get wrongly tunneled to the MN. The node X doesn't even need to take the same site local address for this to fail, it can configure any other address based on the prefixes supported and the interface identifier. In this case, after the BU succeeds, any packets meant for this different address will still be tunnelled wrongly by the HA to the MN since Prefix Length was greater than zero. Hence I feel HA must perform DAD on all addresses (can be done parallely and probably take almost the same time as it would take for one DAD) if Prefix Length > 0. Secondly, is it a good idea for Mobility to change the value of RetransTimer to a smaller value like 0.5 seconds or smaller ? This means faster handoff for the MN. Otherwise the MN has to wait for 1.5*(RetransTimer*DupAddrDetectTransmits) = atleast 1.5 seconds before the MN gets a response, and before it is allowed to send BU's to CN's. Reducing this time ensures faster movement mechanism for the MN. Thanks, - KK From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 20:22: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 UAA20591 for ; Thu, 6 Dec 2001 20:22:40 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA14337; Thu, 6 Dec 2001 17:21:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05407; Thu, 6 Dec 2001 17:21:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB71KaoH019669 for ; Thu, 6 Dec 2001 17:20:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB71KZYg019668 for mobile-ip-dist; Thu, 6 Dec 2001 17:20:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB71KWoH019661 for ; Thu, 6 Dec 2001 17:20:32 -0800 (PST) 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 RAA16900 for ; Thu, 6 Dec 2001 17:20:32 -0800 (PST) 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 RAA09297 for ; Thu, 6 Dec 2001 17:20:31 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA29863 for ; Thu, 6 Dec 2001 17:20:29 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB71KTd13088 for ; Thu, 6 Dec 2001 17:20:29 -0800 X-mProtect: Thu, 6 Dec 2001 17:20:29 -0800 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 smtpdzxomU1; Thu, 06 Dec 2001 17:20:27 PST Message-ID: <3C10195C.F09CBE7@iprg.nokia.com> Date: Thu, 06 Dec 2001 17:20:28 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on performing DAD for BU's 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 KK, I think this comes from RFC 2462 which says if you have stateless address configuration, its enough if you do duplicate address detection on just the link local address. the other addresses are a MAY. heres the relevant text from RFC 2462, section 5.4 --------------- - Each individual unicast address SHOULD be tested for uniqueness. However, when stateless address autoconfiguration is used, address uniqueness is determined solely by the interface identifier, assuming that subnet prefixes are assigned correctly (i.e., if all of an interface's addresses are generated from the same identifier, either all addresses or none of them will be duplicates). Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link- local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier. --------------- And I guess the intention was that Mobile IPv6 did not want to specify anything in addition to what is there in RFC 2462. and regarding more than prefix on the home link there is something specified in draft 15 for that. if the 'S' bit in the BU is set, the Home Agent defends just the home address specified in the home address option. if the 'S' bit is not set, the home agent forms a home address from each prefix on the home link and defends all of them. and even in this case, by RFC 2462, its enough if you do DAD from just the link local address if stateless address configuration is being used. one more thing, in your example below node 'X' MUST configure a link local address. it cant configure a site local address alone and not configure a link local address. it is there in some RFC, I forgot which. regards Vijay Krishna Kumar wrote: > > Hi Charlie, > > I feel there is a small problem in the Draft 15 regarding the address used > for performing DAD. > > 1. Page 67 for BU processing says that DAD should be performed on the Link > Local Address. > 2. Pg 94 says that : If some time elapses during which the mobile node has > no binding at the home agent, it might be possible for another node to > autoconfigure the mobile node's home address. > > A new node 'X' can configure it's address either through autoconfiguration > (in which case #1 is sufficient), or by manual means. Since the address can > be configured manually, I feel the specification should be changed to state > that DAD should be performed on the Link Local address and all Home > Addresses (if Prefix Length is > 0) based on different prefixes supported > by the Home Agent. > > The reason is that the MN might configure a site local address as it's home > address and move to a foreign network. Before HA gets the BU, another node > 'X' manually configures it's address to the site local address used by the > MN, and it succeeds. When HA gets the BU, it does a Neighbor Solicitation > on the Link Local Address, and since X has not configured that link local > address, it doesn't respond to the NS. Now packets meant for 'X' get > wrongly tunneled to the MN. The node X doesn't even need to take the same > site local address for this to fail, it can configure any other address > based on the prefixes supported and the interface identifier. In this case, > after the BU succeeds, any packets meant for this different address will > still be tunnelled wrongly by the HA to the MN since Prefix Length was > greater than zero. Hence I feel HA must perform DAD on all addresses (can > be done parallely and probably take almost the same time as it would take > for one DAD) if Prefix Length > 0. > > Secondly, is it a good idea for Mobility to change the value of > RetransTimer to a smaller value like 0.5 seconds or smaller ? This means > faster handoff for the MN. Otherwise the MN has to wait for > 1.5*(RetransTimer*DupAddrDetectTransmits) = atleast 1.5 seconds before the > MN gets a response, and before it is allowed to send BU's to CN's. Reducing > this time ensures faster movement mechanism for the MN. > > Thanks, > > - KK From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 21:23: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 VAA21439 for ; Thu, 6 Dec 2001 21:23:32 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA29580; Thu, 6 Dec 2001 18:21:51 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19479; Thu, 6 Dec 2001 18:21:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB72KZoH019877 for ; Thu, 6 Dec 2001 18:20:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB72KZbE019876 for mobile-ip-dist; Thu, 6 Dec 2001 18:20:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB72KVoH019869 for ; Thu, 6 Dec 2001 18:20:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA16843 for ; Thu, 6 Dec 2001 18:20:31 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21181 for ; Thu, 6 Dec 2001 19:20:13 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA03327 for ; Thu, 6 Dec 2001 18:20:31 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB72KUg08582 for ; Thu, 6 Dec 2001 18:20:30 -0800 X-mProtect: Thu, 6 Dec 2001 18:20:30 -0800 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 smtpd1TUEpc; Thu, 06 Dec 2001 18:20:29 PST Message-ID: <3C10276D.ED218FC8@iprg.nokia.com> Date: Thu, 06 Dec 2001 18:20:29 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Binding Update Authentication Proposals References: <3C0FF882.FB5ADC15@nttmcl.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 Excellent work. I am sure this would help in the protocol comparison. Thanks a lot. Vijay Satomi Okazaki wrote: > > I'm reposting this, because it didn't seem to get posted the first time > around. If you've already received this e-mail, please ignore this message. > > Regards, > > Satomi Okazaki > > > An informational document summarizing some of the proposals submitted to > > the working group regarding the binding update authentication problem > > (between a mobile node and a correspondent node) has been posted at the > > following URL: http://www.nttmcl.com/sec/BindingUpdate.pdf . > > > > We have attempted to give a short summary of each of the binding update > > authentication proposals listed in ?MIPv6 Security: Assessment of > > Proposals,? an Internet Draft by G. Montenegro. Each proposal relies on > > different security association assumptions, uses different cryptographic > > techniques, and hence achieves different levels of security. Our intent is > > to classify these proposals into several categories and describe them in a > > uniform way so that it is easy to analyze and compare their security. > > > > Regards, > > > > Satomi Okazaki > > NTT Multimedia Communications Laboratories, Inc. > > 250 Cambridge Avenue, Suite 300 > > Palo Alto, California 94306 From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 6 21:46: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 VAA22720 for ; Thu, 6 Dec 2001 21:46:53 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00963; Thu, 6 Dec 2001 19:45:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19924; Thu, 6 Dec 2001 18:45:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB72iUoH019982 for ; Thu, 6 Dec 2001 18:44:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB72iUdO019981 for mobile-ip-dist; Thu, 6 Dec 2001 18:44:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB72iQoH019974 for ; Thu, 6 Dec 2001 18:44:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA01224 for ; Thu, 6 Dec 2001 18:44:27 -0800 (PST) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA09552 for ; Thu, 6 Dec 2001 19:44:58 -0700 (MST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by harumscarum.mr.itd.umich.edu (8.9.3/3.3s) with SMTP id VAA11718 for ; Thu, 6 Dec 2001 21:44:24 -0500 (EST) From: "Subrata Goswami" To: Subject: RE: [mobile-ip] question on L2 triggers draft Date: Thu, 6 Dec 2001 18:49:09 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B0464FC08@IL27EXM10.cig.mot.com> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The ref [7](802.11 IAPP ) in the draft handles all the roaming issues in a L2 connected 802.11 environment. Here roaming is transparent to IP, IAPP takes care (or would take care) of that. However , it seems that MIP is forwarded as the solution in a situation where a MN roams from a 802.11 AP to another 802.11 AP situated in another L2 network (e.g. there is no L2 connectivity between the AP's). Or the MN might roam into a 3GPPx network. In both of these situations, only the MN would be able tell that it has roamed out of this AP and roamed into that AP. Furthermore context parameters would have to be generic enough to handle very different types of networks. If the trigger is network initiated then the FA's in two potentially autonomous networks would have to exchange contexts, which might take longer than going through HA's. -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Nakhjiri Madjid-MNAKHJI1 Sent: Thursday, December 06, 2001 12:57 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] question on L2 triggers draft Hi james (C/o Alper :) ) Ok, Understand. That sounds reasonable. Thanks, Madjid -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Wednesday, December 05, 2001 11:41 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] question on L2 triggers draft Hi Madjid, This is James Kempf, Alper is lending me his machine. I think I wrote that. What I had in mind was the following situation. Suppose I've got a subnet with 802.11 and Bluetooth access points. Having a way that the access points could report movement to the access router would faciliatate intra-subnet movement, for example, ARP cache flushing. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: Sent: Wednesday, December 05, 2001 2:08 PM Subject: [mobile-ip] question on L2 triggers draft > Alper, > > Nice informative draft. I have one question on the L2 handover section (4.1) > You say > > "When APs supporting multiple radio technologies on a single subnet, > interoperability suffers if there is no L2-independent way of reporting > on link movement." > > Would you care to elaborate? > Say a WLAN AP-cellular AP case, do you mean the movement has to be reported > at L3 even if the two APs belong to the same subnet? > > Regards, > Madjid > > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Sunday, December 02, 2001 2:14 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] L2 triggers draft > > > Folks, > > New version of L2 triggers draft is available: > > http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-01.txt > > Supporting Optimized Handover for IP Mobility - > Requirements for Underlying Systems > > Abstract > > A critical factor in achieving good performance for IP mobility > protocols is the design of L2 handover. Handover occurs when a > Mobile Node moves from one radio Access Point to another. If the new > radio Access Point is associated with a new subnet, a change in > routing reachability may occur and require L3 protocol action on the > part of the Mobile Node or Access Routers. If no change in subnet > occurs, the Access Point may still need to take some action to > inform the Access Router about a change in on-link reachability. In > either case, prompt and timely information from L2 to the parties > involved about the sequencing of handover can help optimize handover > at the IP level. This draft discusses requirements for an L2 > handover protocol or API to support optimized handover. > > > Enjoy. > > alper > From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 03:20: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 DAA16193 for ; Fri, 7 Dec 2001 03:20:15 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00133; Fri, 7 Dec 2001 01:18:39 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27409; Fri, 7 Dec 2001 00:18:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB78IBoH020497 for ; Fri, 7 Dec 2001 00:18:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB78IAww020496 for mobile-ip-dist; Fri, 7 Dec 2001 00:18:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB78I7oH020489 for ; Fri, 7 Dec 2001 00:18:07 -0800 (PST) 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 AAA25798 for ; Fri, 7 Dec 2001 00:18:06 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25384 for ; Fri, 7 Dec 2001 00:18:05 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fB78Fvc13346 for ; Fri, 7 Dec 2001 10:15:57 +0200 (EET) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 7 Dec 2001 10:18:04 +0200 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Fri, 7 Dec 2001 10:18:04 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D92A4@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] NSIS working group Date: Fri, 7 Dec 2001 10:17:50 +0200 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 Glenn & Sharif, > The WG was approved last week by the IESG and it is currently > working on requirements. Some candidate documents are located > on the NSIS page: > http://www-nrc.nokia.com/sua/nsis/NSIS.htm. > > I think there is another draft coming down the line located at: > http://www.epic.roke.co.uk/epic/draft-brunner-nsis-req-00.txt. > > The mail list is at: > https://www1.ietf.org/mailman/listinfo/nsis Glenn's information is correct - currently, we do not have any working group documents - all of the documents are individual submissions. NSIS is chartered to work on signaling QoS - not the actual QoS resource reservation. The solution should work with MIP, as well as with other technologies (non-mobile). John From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 05:18: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 FAA17774 for ; Fri, 7 Dec 2001 05:18:19 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23665; Fri, 7 Dec 2001 03:16:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19471; Fri, 7 Dec 2001 02:17:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7AGPoH020709 for ; Fri, 7 Dec 2001 02:16:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7AGP3H020708 for mobile-ip-dist; Fri, 7 Dec 2001 02:16:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7AGMoH020701 for ; Fri, 7 Dec 2001 02:16:22 -0800 (PST) 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 CAA07382 for ; Fri, 7 Dec 2001 02:16:22 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12762 for ; Fri, 7 Dec 2001 02:16:20 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fB7AGII24854 for ; Fri, 7 Dec 2001 11:16:18 +0100 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 LAA27187 for ; Fri, 7 Dec 2001 11:16:18 +0100 (MET) 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 fB7AGID05521 for ; Fri, 7 Dec 2001 11:16:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112071016.fB7AGID05521@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling In-reply-to: Your message of Thu, 06 Dec 2001 11:26:53 PST. <15375.50813.186702.746029@thomasm-u1.cisco.com> Date: Fri, 07 Dec 2001 11:16:18 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: Fine, I was just trying to figure out whether moving it out of MIP was what was being discussed. I haven't made up my mind whether that makes sense. I have to admit that this is somewhat tempting, as going through this entire exercise again for ipv4 route optimization doesn't thrill me. => as there is no home address option and near every routers filter out source routed packets in IPv4 I don't understand your objection... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 05:29: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 FAA17953 for ; Fri, 7 Dec 2001 05:29:11 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA13591; Fri, 7 Dec 2001 02:27:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22838; Fri, 7 Dec 2001 02:27:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7AQuoH020815 for ; Fri, 7 Dec 2001 02:26:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7AQu4v020814 for mobile-ip-dist; Fri, 7 Dec 2001 02:26:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7AQqoH020807 for ; Fri, 7 Dec 2001 02:26:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22369 for ; Fri, 7 Dec 2001 02:26:52 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25974 for ; Fri, 7 Dec 2001 03:26:51 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fB7AQou11678 for ; Fri, 7 Dec 2001 11:26:50 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Fri Dec 07 11:22:53 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 11:22:53 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C10F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" , monet@crm.mot.com Subject: RE: [mobile-ip] mobile nets meeting at IETF52 Date: Wed, 5 Dec 2001 17:55:17 +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: Thanks TJ, I was meant to announce it but spent too much time worrying about the best time for everyone ! It has been suggested that it's too early to hit the bar after the MIP wg meeting. So the current suggestion is to hold the meeting before the plenary. 17.30 - 19.00 It would be good to know how many people are interested in coming, so I can find an appropriate place. So please let me know (via private mail) if you (or preferably more than one person per email !) are interested in attending. Please note that this is not a BOF but simply a short meeting to discuss the possibility of holding a BOF at the next meeting. Cheers, Hesham > -----Original Message----- > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > Sent: Tuesday, December 04, 2001 9:12 PM > To: monet@crm.mot.com > Cc: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] mobile nets meeting at IETF52 > > > Hi, > > A few people have asked me whether we are meeting at IETF52 > to discuss the > Mobile Networks subject in a BOF, so I just want to answer > that question for > everyone else who is interested. > > There is no official BOF scheduled, but we are getting > together for a "bar > BOF" to discuss planning for the group, and possible go over some > requirements and charter items to have them ready and the > scope defined for > a future BOF. > > The time we have discussed for this meeting would be on > Wednesday, 12/12, > after lunch (soon after the Mobile IP meeting). Hesham > Soliman is in charge > of the arrangements and will post them when finalized. > > > -TJ > > From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 05:49: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 FAA18477 for ; Fri, 7 Dec 2001 05:49:15 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA18864; Fri, 7 Dec 2001 02:48:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27888; Fri, 7 Dec 2001 02:48:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7AlJoH020914 for ; Fri, 7 Dec 2001 02:47:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7AlIMM020913 for mobile-ip-dist; Fri, 7 Dec 2001 02:47:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7AlFoH020906 for ; Fri, 7 Dec 2001 02:47:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12025 for ; Fri, 7 Dec 2001 02:47:16 -0800 (PST) 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 DAA09016 for ; Fri, 7 Dec 2001 03:47:44 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fB7Al8I29331 for ; Fri, 7 Dec 2001 11:47:08 +0100 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 LAA28028 for ; Fri, 7 Dec 2001 11:47:08 +0100 (MET) 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 fB7Al8D05699 for ; Fri, 7 Dec 2001 11:47:08 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112071047.fB7Al8D05699@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on performing DAD for BU's In-reply-to: Your message of Thu, 06 Dec 2001 15:52:53 PST. Date: Fri, 07 Dec 2001 11:47:08 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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 feel there is a small problem in the Draft 15 regarding the address used for performing DAD. 1. Page 67 for BU processing says that DAD should be performed on the Link Local Address. => this is based on the common policy where DAD is only performed on link-local addresses *and* no address uses a different interface ID. If this policy is used any node connected to the home link (the MN at home, the HA, etc) knows that so there is no problem. Perhaps this explanation is missing but draft 15 is right. Regards Francis.Dupont@enst-bretagne.fr PS: in practice either the host can be on the home link and the interface ID is built from the MAC address, either the host cannot be on the home link and one may use 1, 2, ... as the interface ID for the home address (with prefix length 0). So what you described should not happen. From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 05:51: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 FAA18541 for ; Fri, 7 Dec 2001 05:51:40 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA19682; Fri, 7 Dec 2001 02:50:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28200; Fri, 7 Dec 2001 02:50:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7AnqoH020970 for ; Fri, 7 Dec 2001 02:49:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7AnpOO020967 for mobile-ip-dist; Fri, 7 Dec 2001 02:49:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7AnmoH020959 for ; Fri, 7 Dec 2001 02:49:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10724 for ; Fri, 7 Dec 2001 02:49:48 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00433 for ; Fri, 7 Dec 2001 03:49:47 -0700 (MST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fB7Anjf24678 for ; Fri, 7 Dec 2001 11:49:46 +0100 (MET) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GNY00NEDZEG02@mbb1.ericsson.se> for mobile-ip@sunroof.eng.sun.com; Fri, 7 Dec 2001 11:49:28 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Dec 07 11:33:53 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 07 Dec 2001 11:33:53 +0100 Date: Wed, 05 Dec 2001 18:05:59 +0100 From: "Karim El-Malki (ERA)" Subject: RE: [mobile-ip] MN-to-MN communications in MIPv4 To: "'mobile-ip@sunroof.eng.sun.com'" Message-id: <795A014AF92DD21182AF0008C7A404320DFBEE0E@esealnt117> 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 there is potential routing problem here. Suppose MN1 > and MN2 are > visitors on an FA (FA1). Now suppose MN2 does FA handoff > and moves to FA2. > FA1 will have a visiting entry for MN2 till the lifetime > expiration. Now if > FA1 tries to by-pass traffic to MN2 through it's visiting > interface, packets > won't reach MN2. This problem won't exist if HA send BU's to > previous FA. > But, I don't think many people would implement Route > Optimizations on HA. The previous FA extension to the Registration message can be used where the BU is sent from new FA to old FA. Not everyone will implement this, but it should be made clear if and when this shortcut can be done. /Karim From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 06:01: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 GAA18671 for ; Fri, 7 Dec 2001 06:01:00 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11422; Fri, 7 Dec 2001 03:59:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29337; Fri, 7 Dec 2001 02:59:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7AxFoH021115 for ; Fri, 7 Dec 2001 02:59:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7AxEvY021114 for mobile-ip-dist; Fri, 7 Dec 2001 02:59:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7AxBoH021107 for ; Fri, 7 Dec 2001 02:59:11 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA15607 for ; Fri, 7 Dec 2001 02:59:12 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02521 for ; Fri, 7 Dec 2001 03:59:11 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fB7Ax9I31257 for ; Fri, 7 Dec 2001 11:59:09 +0100 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 LAA28336 for ; Fri, 7 Dec 2001 11:59:09 +0100 (MET) 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 fB7Ax9D05810 for ; Fri, 7 Dec 2001 11:59:09 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112071059.fB7Ax9D05810@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on performing DAD for BU's In-reply-to: Your message of Thu, 06 Dec 2001 17:20:28 PST. <3C10195C.F09CBE7@iprg.nokia.com> Date: Fri, 07 Dec 2001 11:59:09 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: one more thing, in your example below node 'X' MUST configure a link local address. it cant configure a site local address alone and not configure a link local address. it is there in some RFC, I forgot which. => but 'X' MAY configure a link-local address with a different interface ID (even if this is silly and confusing). To say that stateless address autoconfiguration is used is not enough because of routers (so in the quote there is an explicit assumption which applies to all nodes on the link: However, when stateless address autoconfiguration is used, address uniqueness is determined solely by the interface identifier, assuming that subnet prefixes are assigned correctly (i.e., if all of an interface's addresses are generated from the same identifier, either all addresses or none of them will be duplicates). Regards Francis.Dupont@enst-bretagne.fr PS: there was a proposal to change DAD by a duplicate Interface-ID Detection but it seems too hard to change RFC 2462 even if DIidD is strickly better. From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 06:22: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 GAA18888 for ; Fri, 7 Dec 2001 06:22:07 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA27974; Fri, 7 Dec 2001 03:20:55 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA01928; Fri, 7 Dec 2001 03:20:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7BK6oH021271 for ; Fri, 7 Dec 2001 03:20:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7BK6d4021270 for mobile-ip-dist; Fri, 7 Dec 2001 03:20:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7BK0oH021258 for ; Fri, 7 Dec 2001 03:20:01 -0800 (PST) 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 DAA01825 for ; Fri, 7 Dec 2001 03:20:00 -0800 (PST) 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 DAA14464 for ; Fri, 7 Dec 2001 03:19:59 -0800 (PST) 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.11.0/WIREfire-1.3) with SMTP id fB7BJwf01575 for ; Fri, 7 Dec 2001 12:19:58 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Dec 07 12:12:24 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 12:12:38 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C112@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'monet@crm.mot.com'" Subject: RE: [mobile-ip] mobile nets meeting at IETF52 Date: Thu, 6 Dec 2001 13:57:55 +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: Third time lucky ! > > [For some reason this one hasn't made it to the list or > back to me, sorry if you get multiple copies ] > > Thanks TJ, > > I was meant to announce it but spent too much time > worrying about the best time for everyone ! > It has been suggested that it's too early to hit > the bar after the MIP wg meeting. > So the current suggestion is to hold the meeting > before the plenary. 17.30 - 19.00 > > It would be good to know how many people are interested > in coming, so I can find an appropriate place. > So please let me know (via private mail) if you > (or preferably more than one person per email !) > are interested in attending. > > Please note that this is not a BOF but simply a > short meeting to discuss the possibility of holding > a BOF at the next meeting. > > Cheers, > Hesham > > > > > -----Original Message----- > > > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > > > Sent: Tuesday, December 04, 2001 9:12 PM > > > To: monet@crm.mot.com > > > Cc: mobile-ip@sunroof.eng.sun.com > > > Subject: [mobile-ip] mobile nets meeting at IETF52 > > > > > > > > > Hi, > > > > > > A few people have asked me whether we are meeting at IETF52 > > > to discuss the > > > Mobile Networks subject in a BOF, so I just want to answer > > > that question for > > > everyone else who is interested. > > > > > > There is no official BOF scheduled, but we are getting > > > together for a "bar > > > BOF" to discuss planning for the group, and possible go > > over some > > > requirements and charter items to have them ready and the > > > scope defined for > > > a future BOF. > > > > > > The time we have discussed for this meeting would be on > > > Wednesday, 12/12, > > > after lunch (soon after the Mobile IP meeting). Hesham > > > Soliman is in charge > > > of the arrangements and will post them when finalized. > > > > > > > > > -TJ > > > > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 06:33: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 GAA19023 for ; Fri, 7 Dec 2001 06:33:16 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA00851; Fri, 7 Dec 2001 03:32:10 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA03072; Fri, 7 Dec 2001 03:32:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7BVPoH021380 for ; Fri, 7 Dec 2001 03:31:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7BVPpW021379 for mobile-ip-dist; Fri, 7 Dec 2001 03:31:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7BVLoH021372 for ; Fri, 7 Dec 2001 03:31:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15017 for ; Fri, 7 Dec 2001 03:31:20 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08705 for ; Fri, 7 Dec 2001 04:31:19 -0700 (MST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fB7BVIu11588 for ; Fri, 7 Dec 2001 12:31:18 +0100 (MET) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with SMTP id <0GNZ009IY1B1FC@mbb1.ericsson.se> for mobile-ip@sunroof.eng.sun.com; Fri, 7 Dec 2001 12:30:37 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Dec 07 12:05:47 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 07 Dec 2001 12:05:47 +0100 Date: Thu, 06 Dec 2001 12:45:53 +0100 From: "Hesham Soliman (ERA)" Subject: RE: [mobile-ip] mobile nets meeting at IETF52 To: "'mobile-ip@sunroof.eng.sun.com'" , "'monet@crm.mot.com'" Message-id: <4DA6EA82906FD511BE2F00508BCF053801C4C110@Esealnt861.al.sw.ericsson.se> 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: [For some reason this one hasn't made it to the list or back to me, sorry if you get multiple copies ] Thanks TJ, I was meant to announce it but spent too much time worrying about the best time for everyone ! It has been suggested that it's too early to hit the bar after the MIP wg meeting. So the current suggestion is to hold the meeting before the plenary. 17.30 - 19.00 It would be good to know how many people are interested in coming, so I can find an appropriate place. So please let me know (via private mail) if you (or preferably more than one person per email !) are interested in attending. Please note that this is not a BOF but simply a short meeting to discuss the possibility of holding a BOF at the next meeting. Cheers, Hesham > > > -----Original Message----- > > From: T.J. Kniveton [mailto:TJ@Kniveton.com] > > Sent: Tuesday, December 04, 2001 9:12 PM > > To: monet@crm.mot.com > > Cc: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] mobile nets meeting at IETF52 > > > > > > Hi, > > > > A few people have asked me whether we are meeting at IETF52 > > to discuss the > > Mobile Networks subject in a BOF, so I just want to answer > > that question for > > everyone else who is interested. > > > > There is no official BOF scheduled, but we are getting > > together for a "bar > > BOF" to discuss planning for the group, and possible go > over some > > requirements and charter items to have them ready and the > > scope defined for > > a future BOF. > > > > The time we have discussed for this meeting would be on > > Wednesday, 12/12, > > after lunch (soon after the Mobile IP meeting). Hesham > > Soliman is in charge > > of the arrangements and will post them when finalized. > > > > > > -TJ > > > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 07:42:59 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19673 for ; Fri, 7 Dec 2001 07:42:58 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20601; Fri, 7 Dec 2001 05:41:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09383; Fri, 7 Dec 2001 04:41:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7Cf4oH021659 for ; Fri, 7 Dec 2001 04:41:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7Cf4WX021658 for mobile-ip-dist; Fri, 7 Dec 2001 04:41:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7Cf0oH021651 for ; Fri, 7 Dec 2001 04:41:01 -0800 (PST) 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 EAA20762 for ; Fri, 7 Dec 2001 04:41:00 -0800 (PST) Received: from neogw.osaka.iij.ad.jp (neogw.osaka.iij.ad.jp [202.232.14.130]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24541 for ; Fri, 7 Dec 2001 04:40:59 -0800 (PST) Received: by neogw.osaka.iij.ad.jp; id VAA02229; Fri, 7 Dec 2001 21:40:58 +0900 (JST) Received: from keiichi01.osaka.iij.ad.jp(192.168.65.66) by neogw.osaka.iij.ad.jp via smap (V4.2) id xma002224; Fri, 7 Dec 01 21:40:25 +0900 Received: from keiichi01.osaka.iij.ad.jp (localhost.osaka.iij.ad.jp [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.6/8.11.6) with ESMTP id fB7CeKp01019; Fri, 7 Dec 2001 21:40:20 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Fri, 07 Dec 2001 21:40:20 +0900 Message-ID: <86667ji4p7.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= To: snap-users@kame.net, mip6@kame.net, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] KAME/MIP6 implementation notes User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi folks, I have wrote a short implementation notes about current KAME/MIP6 stack. If you are interedted in our implementation, please take a look on it. Though it is still incomplete, it may be useful to understand our code. You can get it from http://www.kame.net/newsletter/20011206/kame-mip6-implementation.txt Since I will be at IETF, please ask me and other KAME/MIP6 developpers directly if you have questions/suggestions. (Of course, asking by the email is welcome too) Thanks, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 11:12: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 LAA23292 for ; Fri, 7 Dec 2001 11:12:43 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26984; Fri, 7 Dec 2001 08:10:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23502; Fri, 7 Dec 2001 08:10:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7GA3oH021991 for ; Fri, 7 Dec 2001 08:10:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7GA3X0021990 for mobile-ip-dist; Fri, 7 Dec 2001 08:10:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7G9xoH021983 for ; Fri, 7 Dec 2001 08:09:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20431 for ; Fri, 7 Dec 2001 08:09:59 -0800 (PST) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13876 for ; Fri, 7 Dec 2001 09:09:41 -0700 (MST) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 11:08:55 -0500 Message-ID: From: "Shahrier, Sharif M." To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] question on L2 triggers draft Date: Fri, 7 Dec 2001 11:08:46 -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: Is this draft available in the I-D directory? If so, what is the exact title? If its still work in progress, could you please send it to me directly? Thanks. Sharif. -----Original Message----- From: Subrata Goswami [mailto:sgoswami@umich.edu] Sent: Thursday, December 06, 2001 9:49 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] question on L2 triggers draft The ref [7](802.11 IAPP ) in the draft handles all the roaming issues in a L2 connected 802.11 environment. Here roaming is transparent to IP, IAPP takes care (or would take care) of that. However , it seems that MIP is forwarded as the solution in a situation where a MN roams from a 802.11 AP to another 802.11 AP situated in another L2 network (e.g. there is no L2 connectivity between the AP's). Or the MN might roam into a 3GPPx network. In both of these situations, only the MN would be able tell that it has roamed out of this AP and roamed into that AP. Furthermore context parameters would have to be generic enough to handle very different types of networks. If the trigger is network initiated then the FA's in two potentially autonomous networks would have to exchange contexts, which might take longer than going through HA's. -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Nakhjiri Madjid-MNAKHJI1 Sent: Thursday, December 06, 2001 12:57 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] question on L2 triggers draft Hi james (C/o Alper :) ) Ok, Understand. That sounds reasonable. Thanks, Madjid -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Wednesday, December 05, 2001 11:41 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] question on L2 triggers draft Hi Madjid, This is James Kempf, Alper is lending me his machine. I think I wrote that. What I had in mind was the following situation. Suppose I've got a subnet with 802.11 and Bluetooth access points. Having a way that the access points could report movement to the access router would faciliatate intra-subnet movement, for example, ARP cache flushing. jak ----- Original Message ----- From: "Nakhjiri Madjid-MNAKHJI1" To: Sent: Wednesday, December 05, 2001 2:08 PM Subject: [mobile-ip] question on L2 triggers draft > Alper, > > Nice informative draft. I have one question on the L2 handover section (4.1) > You say > > "When APs supporting multiple radio technologies on a single subnet, > interoperability suffers if there is no L2-independent way of reporting > on link movement." > > Would you care to elaborate? > Say a WLAN AP-cellular AP case, do you mean the movement has to be reported > at L3 even if the two APs belong to the same subnet? > > Regards, > Madjid > > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Sunday, December 02, 2001 2:14 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] L2 triggers draft > > > Folks, > > New version of L2 triggers draft is available: > > http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-01.txt > > Supporting Optimized Handover for IP Mobility - > Requirements for Underlying Systems > > Abstract > > A critical factor in achieving good performance for IP mobility > protocols is the design of L2 handover. Handover occurs when a > Mobile Node moves from one radio Access Point to another. If the new > radio Access Point is associated with a new subnet, a change in > routing reachability may occur and require L3 protocol action on the > part of the Mobile Node or Access Routers. If no change in subnet > occurs, the Access Point may still need to take some action to > inform the Access Router about a change in on-link reachability. In > either case, prompt and timely information from L2 to the parties > involved about the sequencing of handover can help optimize handover > at the IP level. This draft discusses requirements for an L2 > handover protocol or API to support optimized handover. > > > Enjoy. > > alper > From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 12:14: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 MAA24904 for ; Fri, 7 Dec 2001 12:14:32 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21125; Fri, 7 Dec 2001 09:11:25 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03128; Fri, 7 Dec 2001 09:11:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7HASoH022274 for ; Fri, 7 Dec 2001 09:10:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7HASaG022273 for mobile-ip-dist; Fri, 7 Dec 2001 09:10:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7HAPoH022266 for ; Fri, 7 Dec 2001 09:10:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03005 for ; Fri, 7 Dec 2001 09:10:25 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22976 for ; Fri, 7 Dec 2001 10:10:58 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fB7HAOV16139 for ; Fri, 7 Dec 2001 09:10:24 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAL95957; Fri, 7 Dec 2001 09:09:49 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA01444; Fri, 7 Dec 2001 09:10:23 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15376.63487.675017.585292@thomasm-u1.cisco.com> Date: Fri, 7 Dec 2001 09:10:23 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling In-Reply-To: <200112071016.fB7AGID05521@givry.rennes.enst-bretagne.fr> References: <15375.50813.186702.746029@thomasm-u1.cisco.com> <200112071016.fB7AGID05521@givry.rennes.enst-bretagne.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 Francis Dupont writes: > Fine, I was just trying to figure out whether moving > it out of MIP was what was being discussed. I haven't > made up my mind whether that makes sense. I have to > admit that this is somewhat tempting, as going through > this entire exercise again for ipv4 route optimization > doesn't thrill me. > > => as there is no home address option and near every routers filter > out source routed packets in IPv4 I don't understand your objection... I haven't read over Steve's draft, but I got the impression that it was just a tunnel with the ability to optimize redundant IP headers. I wouldn't think that is v6 specific, and that it was possibly a replacement for the RH/HAO mechanism in MIPv6 today. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 13:01: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 NAA26209 for ; Fri, 7 Dec 2001 13:01:28 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04000; Fri, 7 Dec 2001 09:57:12 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10520; Fri, 7 Dec 2001 09:41:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7HefvU000410 for ; Fri, 7 Dec 2001 09:40:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7HeeNT000409 for mobile-ip-dist; Fri, 7 Dec 2001 09:40:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7HebvU000402 for ; Fri, 7 Dec 2001 09:40:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04590 for ; Fri, 7 Dec 2001 09:40:33 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA07904 for ; Fri, 7 Dec 2001 10:41:06 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA08976; Fri, 7 Dec 2001 09:40:29 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB7HeSX31107; Fri, 7 Dec 2001 09:40:28 -0800 X-mProtect: Fri, 7 Dec 2001 09:40:28 -0800 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 smtpd7KPw5h; Fri, 07 Dec 2001 09:40:25 PST Message-ID: <3C10FF0A.61A9A018@iprg.nokia.com> Date: Fri, 07 Dec 2001 09:40:26 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling References: <200112060900.fB6901D00327@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 admit I am behind and have not studied the new tunneling > draft yet. But I am surprised that you might suggest that > we should use a new tunneling method that isn't even a working > group document yet, when we already have methods that are: > - Draft Standard > - Implemented > - Interoperable > > => this is not the case of the home address option (we have not > even an independent definition of it) and the routing header has > some security issues that should be solved in a to be written > document (IPv6 host requirements). So we cannot say there is no > problem and it is better to deal with them in a larger and proper > forum (i.e. the IPv6 WG). I think that Vijay has suggested a very simple statement about how to eliminate problems with the routing header. The new encapsulation mechanism would not solve this problem, and would require an almost identical policy to solve it (i.e., the two destinations would have to be on the same host). Furthermore, there might be other uses of the routing header, or of the new tunneling header, that would require other policies. The required policy in the case of Mobile IPv6 is particular to Mobile IPv6, and so it should be documented within the Mobile IPv6 specification. Work of a more general nature (say, in another working group) would have to take into account a great many possible uses which are not germane to Mobile IPv6. > I reckon that the new tunneling method does not resolve any > existing security questions. > > => not be itself but the idea is to put the burden in another WG, > this should have two advantages: > - more time to solve the real problem, i.e. how to secure BUs & co. > - no danger to get a bad & late feedback as it happens about IPsec. > > Placing a normative dependency > > => the purpose is not to slow down Mobile IPv6 at all! I reckon this means that we can go forward with routing header and home address option, and make future adjustments if it is indicated by the future work. I don't expect that any other working group would be as motivated to complete the necessary work as the mobile-ip group would be. > If the new tunneling draft had some magic ability to get to > Proposed Standard in the near future. > > => or the discussion about it reveals unsoluble security problems > and Mobile IPv6 has a real problem, or the discussion shows how > to not infringe upon security and Mobile IPv6 gets the benefit > (with current or new mechanisms). That's a big IF, and I am almost certain this will not be the case. I think that after some amount of thought it can be seen that the routing header and Home Address option, compared to various forms of encapsulation, have pretty much the same essential features, and neither choice offers any particular security benefits over the other. > => the purpose is not improvements, it is a discussion of this kind > of mechanisms in a general context. And this is *necessary* or how > do you explain that the vast majority of deployed IPv6 implementations > have both no home address option support and a half-backed security > policy for source routing on hosts? The solution for half-baked policies is to fix them after identifying the problems. To translate the discussion into a new problem space, or even in a new working group, is chancy at best and carries with it the real prospect of arbitrarily long delays. Source routing is one technique that can be very complicated in general. As an example, if one uses source routing to specify a routing path that is generated based on specific security policies, or based on specific QoS guarantees, then the presumption is that there is a lot of signaling which has preceded the use of the source route. This signaling would be carried out with specific purpose in mind. For Mobile IPv6, the specific purpose is very clear. Both addresses are specifically presumed to be associated with the same node - viz., the mobile node itself. One technique which is more complicated than source routing, from the point of view of understanding necessary policy restrictions, is encapsulation itself. Making the appropriate policy restrictions on a generalized encapsulation protocol will be even more difficult than making the appropriate restrictions on the use of source routing. This is especially true since the appropriate restriction for Mobile IPv6 use of source routing is very simple to identify, understand, and implement. For these reasons, I believe it is unlikely that we will gain any advantages in either timeliness or operational simplicity or performance by waiting for completion of the new tunneling headers. This is not to say that the work should not be pursued. In fact, after learning more about the new draft, I think it is interesting to compare the new tunneling work with what was standardized in RFC 2004. But to hold it out as having promise for resolving some existing security problem is, I think, wishful thinking. This is especially true since we have now had the discussion on what the security problems are, and we can go directly about getting solutions for them. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 15:24: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 PAA29375 for ; Fri, 7 Dec 2001 15:24:01 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28618; Fri, 7 Dec 2001 13:22:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24579; Fri, 7 Dec 2001 12:22:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7KLhvU001775 for ; Fri, 7 Dec 2001 12:21:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7KLhxm001774 for mobile-ip-dist; Fri, 7 Dec 2001 12:21:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7KLdvU001767 for ; Fri, 7 Dec 2001 12:21:40 -0800 (PST) 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 MAA16153 for ; Fri, 7 Dec 2001 12:21:41 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04137 for ; Fri, 7 Dec 2001 12:21:40 -0800 (PST) Received: from AlperVAIO (dhcp153.docomo-usa.com [172.21.96.153]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB7KLX518150 for ; Fri, 7 Dec 2001 12:21:33 -0800 (PST) Message-ID: <001101c17f5b$de47e650$996015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <8C92E23A3E87FB479988285F9E22BE460234D7@ftmail> Subject: Re: [mobile-ip] 0.0.0.0 src address Date: Fri, 7 Dec 2001 12:15:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 Matt, > > > > For example, what if any MN configures itself with a > > temporary address > > > > to send the reg-req with home-addr=0, to get it's > > > > newly-assigned homeaddr? > > > > > > > > > - If the mobile node does not have a home address, > > the IP source > > > > address MUST be 0.0.0.0. > > > > > > > > > > I also question why this is a MUST. It is entirely > > possible that the MN's > > > interface over which it is going to send the RREQ has an IP address > > > (established via DHCP), while the mobile does not yet have > > a MIP home > > > address. In this case, shouldn't it be able to send the > > RREQ with the > > > interface's address as the IP source address, but with a > > zero home address > > > in the RREQ?? > > > > You cannot make this assumption. This works only if we are using > > co-located care-of address. In case of FA-located care-of > > address, mobile node has only home address. > > I was not making the assumption that this was always the case. I was merely > asking: when this is the case, shouldn't the mobile be able to set the oh, ok. I thought you were suggesting this as a solution. > source IP address on its RREQ equal to the interface's address over which > the RREQ is going out?? that should be ok. > Currently this is not allowed by the MIP draft, as > the mobile MUST set the source address of its RREQs to 0.0.0.0 if it has no > home address. I don't know why it has to be like that. I cannot think of any reason. I think the mobile node should be able to send the registration request with the care-of address as the source address. After all, the reg. req. can carry home address in a separate field. In the case of co-located care-of address and dynamic home address allocation, how can the mobile node send the registration request with an unspecified source address (and receive a response)? I think this is an important problem. > > Furthermore, why can't the mobile have a local interface address which is > different than its home address without using co-located care-of-addresses?? > I guess you can do that. It is just that one of the reasons of not having a co-located care-of address is that mobile might be unable to get a topological address (no dhcp, no ppp, or not enough IPv4 address). And resort to FA-located care-of address. If it can get an address, it can use co-located care-of address. But, then again it doesn't have to. I agree. > matt > alper From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 15:53: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 PAA29780 for ; Fri, 7 Dec 2001 15:53:13 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16512; Fri, 7 Dec 2001 13:51:47 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02329; Fri, 7 Dec 2001 12:51:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7KofvU001915 for ; Fri, 7 Dec 2001 12:50:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7KofJB001914 for mobile-ip-dist; Fri, 7 Dec 2001 12:50:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7KocvU001907 for ; Fri, 7 Dec 2001 12:50:38 -0800 (PST) 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 MAA21686 for ; Fri, 7 Dec 2001 12:50:36 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15056 for ; Fri, 7 Dec 2001 12:50:35 -0800 (PST) Received: from AlperVAIO (dhcp153.docomo-usa.com [172.21.96.153]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB7KoX519320 for ; Fri, 7 Dec 2001 12:50:33 -0800 (PST) Message-ID: <00ea01c17f5f$eb7e05d0$996015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <200112060900.fB6901D00327@givry.rennes.enst-bretagne.fr> Subject: [mobile-ip] privacy? Date: Fri, 7 Dec 2001 12:44:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 Folks, I remember seeing a presentation in the area of location privacy. Something other than Claude and Francis's draft draft-castelluccia-mobileip-privacy-00.txt. Could the author or whoever remembers it, send me an e-mail? I'd like to get a copy of the draft. Thanks! alper From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 16:20: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 QAA00422 for ; Fri, 7 Dec 2001 16:20:31 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02221; Fri, 7 Dec 2001 14:19:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04989; Fri, 7 Dec 2001 13:19:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7LIFvU002020 for ; Fri, 7 Dec 2001 13:18:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7LIF6V002019 for mobile-ip-dist; Fri, 7 Dec 2001 13:18:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7LICvU002012 for ; Fri, 7 Dec 2001 13:18:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04840 for ; Fri, 7 Dec 2001 13:18:12 -0800 (PST) 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 OAA01445 for ; Fri, 7 Dec 2001 14:17:53 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fB7LI2I27838; Fri, 7 Dec 2001 22:18:02 +0100 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 WAA11840; Fri, 7 Dec 2001 22:18:02 +0100 (MET) 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 fB7LI2D08123; Fri, 7 Dec 2001 22:18:02 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112072118.fB7LI2D08123@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E. Perkins" cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling In-reply-to: Your message of Fri, 07 Dec 2001 09:40:26 PST. <3C10FF0A.61A9A018@iprg.nokia.com> Date: Fri, 07 Dec 2001 22:18:02 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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 think that Vijay has suggested a very simple statement about how to eliminate problems with the routing header. => I know but the problem remains until its solution is in a standard document (and applied). My concern is this document is in the scope of the IPv6 WG, not of the mobile-ip WG, so we are only losing our time because of the wrong mailing list/working group. Furthermore, there might be other uses of the routing header, or of the new tunneling header, that would require other policies. The required policy in the case of Mobile IPv6 is particular to Mobile IPv6, and so it should be documented within the Mobile IPv6 specification. Work of a more general nature (say, in another working group) would have to take into account a great many possible uses which are not germane to Mobile IPv6. => I disagree: a Mobile IPv6 node is first an IPv6 node. The security problem (and its solution) is bound to the routing header and not to mobility, i.e. mobile IPv6 has shown there is a hole in IPv6 specs (the need of a policy about routing headers). I reckon this means that we can go forward with routing header and home address option, and make future adjustments if it is indicated by the future work. => this is the idea: give the burden to someone else. I don't expect that any other working group would be as motivated to complete the necessary work as the mobile-ip group would be. => the necessary work is in the IPv6 WG charter and there is no closed door between the two groups. I think that after some amount of thought it can be seen that the routing header and Home Address option, compared to various forms of encapsulation, have pretty much the same essential features, and neither choice offers any particular security benefits over the other. => I was not clear enough: I agree the features are the same, my idea is the result for one should apply to the other. > => the purpose is not improvements, it is a discussion of this kind > of mechanisms in a general context. And this is *necessary* or how > do you explain that the vast majority of deployed IPv6 implementations > have both no home address option support and a half-backed security > policy for source routing on hosts? The solution for half-baked policies is to fix them after identifying the problems. To translate the discussion into a new problem space, or even in a new working group, is chancy at best and carries with it the real prospect of arbitrarily long delays. => it seems we disagree about a fundamental point: in order to get mobile IPv6 nodes we first need to get IPv6 nodes. The routing header problem is an IPv6 one so it has to be solved by the IPv6 WG ASAP. I don't want to have some FUD about routing header just because the problem wasn't been dealt with in time as it happened for IPv4. For these reasons, I believe it is unlikely that we will gain any advantages in either timeliness or operational simplicity or performance by waiting for completion of the new tunneling headers. This is not to say that the work should not be pursued. In fact, after learning more about the new draft, I think it is interesting to compare the new tunneling work with what was standardized in RFC 2004. But to hold it out as having promise for resolving some existing security problem is, I think, wishful thinking. This is especially true since we have now had the discussion on what the security problems are, and we can go directly about getting solutions for them. => is it an example of wishful thinking (:-)? BTW I'd like to know how we can get the mandatory support of the Home Address Option in specs and its support in the real world without the help of the IPv6 WG... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 16:52: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 QAA00910 for ; Fri, 7 Dec 2001 16:52:45 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21301; Fri, 7 Dec 2001 14:51:18 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12784; Fri, 7 Dec 2001 13:51:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7LoWvU002131 for ; Fri, 7 Dec 2001 13:50:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7LoWnW002130 for mobile-ip-dist; Fri, 7 Dec 2001 13:50:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7LoTvU002123 for ; Fri, 7 Dec 2001 13:50:29 -0800 (PST) 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 NAA07999 for ; Fri, 7 Dec 2001 13:50:29 -0800 (PST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05460 for ; Fri, 7 Dec 2001 13:50:28 -0800 (PST) Received: from hpindsra.cup.hp.com (hpindsra.cup.hp.com [15.13.104.190]) by palrel12.hp.com (Postfix) with ESMTP id E74F01F969 for ; Fri, 7 Dec 2001 13:50:27 -0800 (PST) Received: from hpindsra (hpindsra [15.13.104.190]) by hpindsra.cup.hp.com with ESMTP (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id NAA02553 for ; Fri, 7 Dec 2001 13:57:28 -0800 (PST) Date: Fri, 7 Dec 2001 13:57:26 -0800 (PST) From: Sivasundar Ramamurthy X-Sender: sramam@hpindsra To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 0.0.0.0 src address In-Reply-To: <001101c17f5b$de47e650$996015ac@AlperVAIO> 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, > I think the mobile node should be able to send the registration request > with the care-of address as the source address. After all, the reg. req. can > carry home address in a separate field. > > In the case of co-located care-of address and dynamic home address > allocation, how can the mobile node send the registration request with > an unspecified source address (and receive a response)? > section 3.6.1.1 defines the rules for what address the MN should use when sending out requests. My interpreation of this section is that the first rule that applies to the situation must be used. That is, if the MN has a co-located COA, it must use that as the src of a registration request, EVEN if it does not have a home address. The reason I interpret it so is due the issue brought up by Alper, and these specific words in rule #3: "In all other cirsumstance....." It is clear that rule #3 applies only if rules #1 and #2 do not. But the question is, does rule #2 apply only if rule #1 does not? I interepret it so; the MN can use the co-location COA as the src of its request even when it has no home address.... Following this interpretation, rule #2 is used only if rule #1 does not apply, thus not involving the "0.0.0.0 src address" issue in the case of MN with co-located COA! Is my interpretation too imaginative? :-) If it is, then the problem described by Alper is serious. If the MN sends a request (co-located COA and address allocation) to the HA with 0.0.0.0 as src address, the chances of getting the reply back to the MN seem bleak. (could it be null??) Anyway, even if my interpreation holds, the "0.0.0.0 src address" issue still lives as in the case when the MN does not use a co-located COA and does not have a home address....(rule #2). thanks! Siva From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 17:01: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 RAA01107 for ; Fri, 7 Dec 2001 17:01:39 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16797; Fri, 7 Dec 2001 14:00:25 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA15319; Fri, 7 Dec 2001 14:00:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7LxYvU002233 for ; Fri, 7 Dec 2001 13:59:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7LxYa0002232 for mobile-ip-dist; Fri, 7 Dec 2001 13:59:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7LxVvU002225 for ; Fri, 7 Dec 2001 13:59:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17818 for ; Fri, 7 Dec 2001 13:59:31 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA10510 for ; Fri, 7 Dec 2001 15:00:04 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA25758; Fri, 7 Dec 2001 13:59:29 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB7LxSX11247; Fri, 7 Dec 2001 13:59:28 -0800 X-mProtect: Fri, 7 Dec 2001 13:59:28 -0800 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 smtpdWyseVs; Fri, 07 Dec 2001 13:59:27 PST Message-ID: <3C113BC0.E20D1C3B@iprg.nokia.com> Date: Fri, 07 Dec 2001 13:59:28 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling References: <200112072118.fB7LI2D08123@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 Francis Dupont wrote: > > In your previous mail you wrote: > > I think that Vijay has suggested a very simple statement about how > to eliminate problems with the routing header. > > => I know but the problem remains until its solution is in a standard > document (and applied). My concern is this document is in the scope > of the IPv6 WG, not of the mobile-ip WG, so we are only losing our > time because of the wrong mailing list/working group. My point in the text following this statement was as follows. The _reason_ for establishing the intermediate points to be used in a routing header varies according to the "application". Thus, the way in which the recipient has to check for validity varies according to the "application". While Mobile IPv6 is not an application in the usual sense of the word, it is a protocol which makes use of a routing header for a specific purpose. This is not a general purpose signaling for general purpose use of the routing header. It is specific to Mobile IPv6, and therefore the rules by which the routing header processing has to be checked have to be specific within the Mobile IPv6 document. > Furthermore, there might be other uses of the routing header, or of > the new tunneling header, that would require other policies. The > required policy in the case of Mobile IPv6 is particular to Mobile IPv6, > and so it should be documented within the Mobile IPv6 specification. > Work of a more general nature (say, in another working group) would > have to take into account a great many possible uses which are not > germane to Mobile IPv6. > > => I disagree: a Mobile IPv6 node is first an IPv6 node. Yes, but this statement is not relevant to the purpose at hand. > The security > problem (and its solution) is bound to the routing header and not to > mobility, i.e. mobile IPv6 has shown there is a hole in IPv6 specs > (the need of a policy about routing headers). Use of the terminology "security problem" is not very good here. The problem is that we have to be sure that a node which is supposed to accept a routing header for the purposes of mobility doesn't accept routing headers that have deleterious effects unrelated to Mobile IPv6. So, yes it's a "security problem", but more specifically it shows the need to refuse to carry out unauthorized routing operations. > => it seems we disagree about a fundamental point: in order to get mobile > IPv6 nodes we first need to get IPv6 nodes. The routing header problem > is an IPv6 one so it has to be solved by the IPv6 WG ASAP. I don't want > to have some FUD about routing header just because the problem wasn't > been dealt with in time as it happened for IPv4. I think that I have explained the reason for my disagrement on this point in a way that might be clearer this time. To try another restatement: Use of routing header probably has to be enabled for specific purposes. I think it is extremely unlikely that the IPng working group can establish a comprehensive list of all future purposes for which the routing header may be applicable. I think that each new purpose might require different rules for preventing unwarranted intrusions for unauthorized routing. Thus, it's appropriate for the Mobile IPv6 group to establish the rules. Furthermore, these statements would have to be even more strongly if applied to the otherwise functionally identical scenarios appropriate for generalized encapsulation techniques. > For these reasons, I believe it is unlikely that we will gain any > advantages in either timeliness or operational simplicity or performance > by waiting for completion of the new tunneling headers. This is not to > say that the work should not be pursued. In fact, after learning more > about the new draft, I think it is interesting to compare the new tunneling > work with what was standardized in RFC 2004. But to hold it out as having > promise for resolving some existing security problem is, I think, wishful > thinking. This is especially true since we have now had the discussion > on what the security problems are, and we can go directly about getting > solutions for them. > > => is it an example of wishful thinking (:-)? Am I allowed to distinguish between wishful thinking, and my bit of optimism which comes from reading oh-so-many e-mails and drafts on the subject over the last few months? > BTW I'd like to know how we can get the mandatory support of the Home Address > Option in specs and its support in the real world without the help of the > IPv6 WG... If we resolve the remaining questions surrounding the Home Address Option, and if the document passes IETF Last Call, then I think that by process we will get support in the real world. But that is a big subject, and appropriate to another e-mail in the near future. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 17:07:59 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 RAA01219 for ; Fri, 7 Dec 2001 17:07:58 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA19196; Fri, 7 Dec 2001 14:06:56 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17037; Fri, 7 Dec 2001 14:06:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7M60vU002347 for ; Fri, 7 Dec 2001 14:06:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7M60Xi002346 for mobile-ip-dist; Fri, 7 Dec 2001 14:06:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7M5vvU002339 for ; Fri, 7 Dec 2001 14:05:57 -0800 (PST) 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 OAA16849 for ; Fri, 7 Dec 2001 14:05:57 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08522 for ; Fri, 7 Dec 2001 14:05:56 -0800 (PST) Received: from strtio1.cup.hp.com (strtio1.cup.hp.com [15.13.129.245]) by palrel10.hp.com (Postfix) with ESMTP id 5EF2E1F5E6 for ; Fri, 7 Dec 2001 14:05:55 -0800 (PST) Received: (from jlau@localhost) by strtio1.cup.hp.com (8.9.3 (PHNE_18979)/8.9.3 SMKit7.02) id OAA27040 for mobile-ip@sunroof.eng.sun.com; Fri, 7 Dec 2001 14:07:14 -0800 (PST) Date: Fri, 7 Dec 2001 14:07:14 -0800 (PST) From: Joe Lau Message-Id: <200112072207.OAA27040@strtio1.cup.hp.com> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 0.0.0.0 src address In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=X-roman8 Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > ..... If the MN > sends a request (co-located COA and address allocation) to the HA with > 0.0.0.0 as src address, the chances of getting the reply back to the > MN seem bleak. (could it be null??) Right. A co-located COA MN _must_ not send a registration request with a 0.0.0.0 source address. There is no way to get a reply back even if the registration request itself made it to the HA. Joe From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 17:15:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01337 for ; Fri, 7 Dec 2001 17:15:52 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA22018; Fri, 7 Dec 2001 14:14:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18631; Fri, 7 Dec 2001 14:14:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7MEAvU002477 for ; Fri, 7 Dec 2001 14:14:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7ME9e9002476 for mobile-ip-dist; Fri, 7 Dec 2001 14:14:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7ME6vU002469 for ; Fri, 7 Dec 2001 14:14:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA13309 for ; Fri, 7 Dec 2001 14:14:06 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11273 for ; Fri, 7 Dec 2001 15:14:05 -0700 (MST) Received: from T23KEMPF (dhcp155.docomo-usa.com [172.21.96.155]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB7MDw523305 for ; Fri, 7 Dec 2001 14:13:59 -0800 (PST) Message-ID: <003901c17f6c$3e2d3470$9b6015ac@T23KEMPF> From: "James Kempf" To: References: Subject: Re: [mobile-ip] question on L2 triggers draft Date: Fri, 7 Dec 2001 14:12:20 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > However , it seems that MIP is forwarded as the solution in a situation > where a MN roams from a 802.11 AP to another 802.11 AP situated in another > L2 network (e.g. there is no L2 connectivity between the AP's). IAPP works cross subnet, if that is what you meant by "no L2 connectivity between AP's". >Or the MN > might roam into a 3GPPx network. In both of these situations, only the MN > would be able tell that it has roamed out of this AP and roamed into that > AP. I don't quite understand your point here. If the MN is capable of handling 802.11 and 3GPP traffic, then it will have two interfaces. The interfaces will have their own respective L2 triggers as will the access points in the network. > Furthermore context parameters would have to be generic enough to handle > very > different types of networks. If the trigger is network initiated then the > FA's > in two potentially autonomous networks would have to exchange contexts, > which > might take longer than going through HA's. > I don't believe the intent is to propose L2 triggers for intertechnology handover. The triggers are proposed for handover between access points of the same technology. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 17:20:23 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01406 for ; Fri, 7 Dec 2001 17:20:23 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23781; Fri, 7 Dec 2001 14:19:08 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19540; Fri, 7 Dec 2001 14:19:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7MICvU002557 for ; Fri, 7 Dec 2001 14:18:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7MICQ4002556 for mobile-ip-dist; Fri, 7 Dec 2001 14:18:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7MI9vU002549 for ; Fri, 7 Dec 2001 14:18:09 -0800 (PST) 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 OAA22161 for ; Fri, 7 Dec 2001 14:18:09 -0800 (PST) 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 OAA12896 for ; Fri, 7 Dec 2001 14:18:05 -0800 (PST) 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 fB7MJAQ04324 for ; Fri, 7 Dec 2001 16:19:10 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 7 Dec 2001 16:18:05 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Dec 2001 16:18:06 -0600 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Fri, 7 Dec 2001 16:18:06 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD21A@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Routing header Vs tunneling Thread-Index: AcF9F/bWalgXr+kDEdWrzAAIx6S5QwCVK35Q X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 From: "Patil Basavaraj (NET/Dallas)" To: Cc: X-OriginalArrivalTime: 07 Dec 2001 22:18:06.0389 (UTC) FILETIME=[0B7B7E50:01C17F6D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fB7MI9vU002550 Sender: owner-mobile-ip@sunroof.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 > > 2 MIPv6 Security Discussion 75 Mins > > > > a. Securing MIPv6 Binding Updates > > > > b. Home Address Option/Routing Header vs Tunnelling > > I think we should modify 'b' to say " Home Address Option > vs Tunnelling" because Pekka has suggested a solution for > the routing header problem in his > draft-savola-ipv6-rh-ha-security-01.txt Actually the updated agenda that I submitted to the IETF before the deadline read this item as : ...... b. Security requirements for Home Address Option and Routing Header ...... Did not really intend to compare tunnelling schemes. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 17:21: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 RAA01424 for ; Fri, 7 Dec 2001 17:21:07 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09884; Fri, 7 Dec 2001 15:19:39 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19861; Fri, 7 Dec 2001 14:19:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7MJCvU002577 for ; Fri, 7 Dec 2001 14:19:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7MJCtg002576 for mobile-ip-dist; Fri, 7 Dec 2001 14:19:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7MJ8vU002566 for ; Fri, 7 Dec 2001 14:19:08 -0800 (PST) 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 OAA19584 for ; Fri, 7 Dec 2001 14:19:08 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16157 for ; Fri, 7 Dec 2001 14:19:07 -0800 (PST) Received: from T23KEMPF (dhcp155.docomo-usa.com [172.21.96.155]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB7MJ5523559 for ; Fri, 7 Dec 2001 14:19:05 -0800 (PST) Message-ID: <006501c17f6c$f4b2ab30$9b6015ac@T23KEMPF> From: "James Kempf" To: References: Subject: Re: [mobile-ip] question on L2 triggers draft Date: Fri, 7 Dec 2001 14:17:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit It is draft-manyfolks-l2-mobilereq-04.txt. Should be there. jak ----- Original Message ----- From: "Shahrier, Sharif M." To: Sent: Friday, December 07, 2001 8:08 AM Subject: RE: [mobile-ip] question on L2 triggers draft > Is this draft available in the I-D directory? If so, what is the exact > title? > If its still work in progress, could you please send it to me directly? > Thanks. > > Sharif. > > -----Original Message----- > From: Subrata Goswami [mailto:sgoswami@umich.edu] > Sent: Thursday, December 06, 2001 9:49 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] question on L2 triggers draft > > The ref [7](802.11 IAPP ) in the draft handles all the roaming > issues in a L2 connected 802.11 environment. Here roaming is transparent > to IP, IAPP takes care (or would take care) of that. > > However , it seems that MIP is forwarded as the solution in a situation > where a MN roams from a 802.11 AP to another 802.11 AP situated in another > L2 network (e.g. there is no L2 connectivity between the AP's). Or the MN > might roam into a 3GPPx network. In both of these situations, only the MN > would be able tell that it has roamed out of this AP and roamed into that > AP. > Furthermore context parameters would have to be generic enough to handle > very > different types of networks. If the trigger is network initiated then the > FA's > in two potentially autonomous networks would have to exchange contexts, > which > might take longer than going through HA's. > > > > > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Nakhjiri > Madjid-MNAKHJI1 > Sent: Thursday, December 06, 2001 12:57 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] question on L2 triggers draft > > > Hi james (C/o Alper :) ) > > Ok, Understand. That sounds reasonable. > > Thanks, > Madjid > > -----Original Message----- > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > Sent: Wednesday, December 05, 2001 11:41 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] question on L2 triggers draft > > > Hi Madjid, > > > This is James Kempf, Alper is lending me his machine. > > I think I wrote that. What I had in mind was the following situation. > Suppose I've got a subnet with 802.11 and Bluetooth access points. Having a > way that the access points could report movement to the access router would > faciliatate intra-subnet movement, for example, ARP cache flushing. > > jak > > ----- Original Message ----- > From: "Nakhjiri Madjid-MNAKHJI1" > To: > Sent: Wednesday, December 05, 2001 2:08 PM > Subject: [mobile-ip] question on L2 triggers draft > > > > Alper, > > > > Nice informative draft. I have one question on the L2 handover section > (4.1) > > You say > > > > "When APs supporting multiple radio technologies on a single subnet, > > interoperability suffers if there is no L2-independent way of reporting > > on link movement." > > > > Would you care to elaborate? > > Say a WLAN AP-cellular AP case, do you mean the movement has to be > reported > > at L3 even if the two APs belong to the same subnet? > > > > Regards, > > Madjid > > > > > > -----Original Message----- > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > Sent: Sunday, December 02, 2001 2:14 AM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] L2 triggers draft > > > > > > Folks, > > > > New version of L2 triggers draft is available: > > > > http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-01.txt > > > > Supporting Optimized Handover for IP Mobility - > > Requirements for Underlying Systems > > > > Abstract > > > > A critical factor in achieving good performance for IP mobility > > protocols is the design of L2 handover. Handover occurs when a > > Mobile Node moves from one radio Access Point to another. If the new > > radio Access Point is associated with a new subnet, a change in > > routing reachability may occur and require L3 protocol action on the > > part of the Mobile Node or Access Routers. If no change in subnet > > occurs, the Access Point may still need to take some action to > > inform the Access Router about a change in on-link reachability. In > > either case, prompt and timely information from L2 to the parties > > involved about the sequencing of handover can help optimize handover > > at the IP level. This draft discusses requirements for an L2 > > handover protocol or API to support optimized handover. > > > > > > Enjoy. > > > > alper > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 17:21:59 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 RAA01471 for ; Fri, 7 Dec 2001 17:21:58 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA24719; Fri, 7 Dec 2001 14:20:54 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20104; Fri, 7 Dec 2001 14:20:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7MKDvU002639 for ; Fri, 7 Dec 2001 14:20:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7MKCZK002638 for mobile-ip-dist; Fri, 7 Dec 2001 14:20:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7MK9vU002628 for ; Fri, 7 Dec 2001 14:20:09 -0800 (PST) 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 OAA09756 for ; Fri, 7 Dec 2001 14:20:09 -0800 (PST) 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 OAA13688 for ; Fri, 7 Dec 2001 14:20:09 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fB7MKEQ10833 for ; Fri, 7 Dec 2001 16:20:14 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Fri, 7 Dec 2001 16:20:07 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 7 Dec 2001 16:20:08 -0600 content-class: urn:content-classes:message Subject: RE: [mobile-ip] draft-montenegro-mipv6-seceval-00.txt Date: Fri, 7 Dec 2001 16:20:08 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F811555372@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] draft-montenegro-mipv6-seceval-00.txt X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcF+iE/p/8rM6up5EdWJVgAIx6TWpQA5KfdQ From: "Le Franck (NRC/Dallas)" To: X-OriginalArrivalTime: 07 Dec 2001 22:20:08.0890 (UTC) FILETIME=[547FA9A0:01C17F6D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fB7MK9vU002629 Sender: owner-mobile-ip@sunroof.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, We made some suggestions to improve the mechanism described in the initial "Dynamic Diffie Hellman based Key Distribution for Mobile IPv6" Internet-draft some days ago, and here is a more detailed description of the proposed enhancements. Unfortunately we could not meet the IETF cut off deadline but here is a link to the document: http://people.nokia.net/~patil/Internet_Drafts/draft-le-mobileip-dh-01.t xt Thank you very much, Franck From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 17:32: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 RAA01640 for ; Fri, 7 Dec 2001 17:32:14 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17145; Fri, 7 Dec 2001 15:30:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22438; Fri, 7 Dec 2001 14:31:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7MULvU002855 for ; Fri, 7 Dec 2001 14:30:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB7MUK9h002854 for mobile-ip-dist; Fri, 7 Dec 2001 14:30:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7MUHvU002847 for ; Fri, 7 Dec 2001 14:30:17 -0800 (PST) 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 OAA24842; Fri, 7 Dec 2001 14:30:18 -0800 (PST) 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 OAA20228; Fri, 7 Dec 2001 14:30:17 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA28015; Fri, 7 Dec 2001 14:30:17 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB7MUFo18204; Fri, 7 Dec 2001 14:30:15 -0800 X-mProtect: Fri, 7 Dec 2001 14:30:15 -0800 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 smtpdTv5rgA; Fri, 07 Dec 2001 14:30:13 PST Message-ID: <3C1142F6.1EEA3CFA@iprg.nokia.com> Date: Fri, 07 Dec 2001 14:30:14 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Mobile IP Working Group Subject: [mobile-ip] Binding Update <--> bu3way 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, As I understand it, one of Jeff Schiller's main objections to the Mobile IPv6 specification for handling Binding Updates could be expressed as follows: Even if the specification _mandates_ that Binding Updates must be authenticated, some vendors or operators will configure systems that ignore mandated protocol behavior unless we devise some method that makes it easy to do the right thing. I think that some people (e.g., me) interpreted this to mean that a lightweight key distribution protocol was required before Mobile IPv6 could become Proposed Standard. However, I now understand that this wasn't the intent. Maybe we can satisfy the requirement by using your recently proposed BU3WAY draft to enable processing for Binding Updates whenever a suitable security association is not available. This would work as follows: - If the mobile node has a security assocation with the correspondent node, it sends an authenticated Binding Update - Otherwise, if a key establishment protocol exists, the mobile node initiates key establishment - Otherwise, the mobile node carries out the BU3WAY operations When we get a good key distribution protocol, and I reckon we have several viable candidates, then BU3WAY would likely be required less often, as mobile endpoints have better tools for establishing the required security associations for authenticated Binding Updates. If this seems like a reasonable plan, then I would like to also suggest that the BU3WAY message formats be changed so that the authorization cookie information be located into suboptions so that the format can remain compatible with existing Binding Updates. It would be possible for the Binding Update format to remain the same even if the authorization happened one way or the other depending on suboptions. The downside is that now the correspondent node would have to implement more protocol. I hope it's not too much additional stuff. Regards, Charlie P. PS. I hope this hasn't all been said before in previous messages. I am still in the process of catching up with things. From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 19: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 TAA03707 for ; Fri, 7 Dec 2001 19:47:08 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA09619; Fri, 7 Dec 2001 16:40:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15743; Fri, 7 Dec 2001 16:40:37 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB80dgvU003246 for ; Fri, 7 Dec 2001 16:39:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB80dgKM003245 for mobile-ip-dist; Fri, 7 Dec 2001 16:39:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.81.36] (may be forged)) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB80ddvU003238 for ; Fri, 7 Dec 2001 16:39:39 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with SMTP id fB80debG468482; Fri, 7 Dec 2001 16:39:41 -0800 (PST) Message-Id: <200112080039.fB80debG468482@jurassic.eng.sun.com> Date: Fri, 7 Dec 2001 16:41:28 -0800 (PST) From: Samita Chakrabarti Subject: Re: [mobile-ip] 0.0.0.0 src address To: mobile-ip@sunroof.eng.sun.com, marc@mentat.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: L1nOJ04bX0bdwBStmufGjw== 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 Marc, > > > > > Note that it is also possible that FA may find that the registration > > request from src-addr=0.0.0.0 and home-addr=0.0.0.0 is poorly-formatted > > or some other problem, how does it reply back with error then ? ( Due to > > the restriction in RFC1122 ) > > Should it drop the packet or send it to multicast addr ? > > OK, good point there and perhaps I wasn't fully awake to think about > the error cases. DHCP presumably responds with a broadcast "nak" and > lets the proper client figure it out based on the ids in the message. > The same could be done with the MN but this doesn't seem as "clean" to > me. If it was important to avoid the apparent 1122 restriction then > thats what I would recommend but I think I'd agree that for > implementation simplicity the 0.0.0.0 handling is cleaner. IMHO, we need to stick to rfc1122 restriction--as it should not change for mobileip draft. Sending the reply to multicast or broadcast (when src-addr is zero ) is reasonable. > > How are apparent conflicts with 1122 handled? Just highlighted in 2002bis > since these are *mobile* host requirements, not plain hosts? > This restriction in rfc1122 should be vaild in any kind of internet network. > > > > I wonder, why rfc2002-bis has a MUST in 3.6.1.1, could it be MAY ? > > > > For example, what if any MN configures itself with a temporary address > > to send the reg-req with home-addr=0, to get it's newly-assigned homeaddr? > > > > > - If the mobile node does not have a home address, the IP source > > address MUST be 0.0.0.0. > > Yep, I found this confusing too. I *think* the first MUST "overrides" > this second one when you have a co-located COA but I agree this should > be clarified. > > From the discussion in the working group alias, it seems that folks agree that MUST can be changed and the MN can use it's temporary ip-addr as the source addr of the regReq while it requests for dynamic home-addr assignment. Now we have to reach a consensus on sending replies to dst addr (broadcast or multicast) when in fact the ip src-addr of the request is zero. Thanks for your reply. -Samita From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 20:23: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 UAA04126 for ; Fri, 7 Dec 2001 20:23:40 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07109; Fri, 7 Dec 2001 18:17:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29625; Fri, 7 Dec 2001 17:17:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB81GDvU003500 for ; Fri, 7 Dec 2001 17:16:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB81GC1d003499 for mobile-ip-dist; Fri, 7 Dec 2001 17:16:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB81G9vU003492 for ; Fri, 7 Dec 2001 17:16:10 -0800 (PST) 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 RAA21507 for ; Fri, 7 Dec 2001 17:16:04 -0800 (PST) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10005 for ; Fri, 7 Dec 2001 17:16:04 -0800 (PST) Received: from ieee.org ([12.248.77.70]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20011208011604.ISQJ24045.rwcrmhc53.attbi.com@ieee.org> for ; Sat, 8 Dec 2001 01:16:04 +0000 Message-ID: <3C1169D3.AB7DD394@ieee.org> Date: Fri, 07 Dec 2001 19:16:03 -0600 From: Peter Lei X-Mailer: Mozilla 4.79 [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] 0.0.0.0 src address 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 trying again... seems my first one went to /dev/null... "Alper E. YEGIN" wrote: > > Matt, > > > > > > For example, what if any MN configures itself with a > > > temporary address > > > > > to send the reg-req with home-addr=0, to get it's > > > > > newly-assigned homeaddr? > > > > > > > > > > > - If the mobile node does not have a home address, > > > the IP source > > > > > address MUST be 0.0.0.0. > > > > > > > > > > > > > I also question why this is a MUST. It is entirely > > > possible that the MN's > > > > interface over which it is going to send the RREQ has an IP address > > > > (established via DHCP), while the mobile does not yet have > > > a MIP home > > > > address. In this case, shouldn't it be able to send the > > > RREQ with the > > > > interface's address as the IP source address, but with a > > > zero home address > > > > in the RREQ?? > > > > > > You cannot make this assumption. This works only if we are using > > > co-located care-of address. In case of FA-located care-of > > > address, mobile node has only home address. > > > > I was not making the assumption that this was always the case. I was > merely > > asking: when this is the case, shouldn't the mobile be able to set the > > oh, ok. I thought you were suggesting this as a solution. > > > source IP address on its RREQ equal to the interface's address over which > > the RREQ is going out?? > > that should be ok. > > > Currently this is not allowed by the MIP draft, as > > the mobile MUST set the source address of its RREQs to 0.0.0.0 if it has > no > > home address. > > I don't know why it has to be like that. I cannot think of any reason. > > I think the mobile node should be able to send the registration request > with the care-of address as the source address. After all, the reg. req. can > carry home address in a separate field. > > In the case of co-located care-of address and dynamic home address > allocation, how can the mobile node send the registration request with > an unspecified source address (and receive a response)? > > I think this is an important problem. So, wouldn't this solve this issue in 3.6.1.1 in 2002bis-08 (Note, this merely "moves" the added requirement in -08): - When registering on a foreign network with a co-located care-of address, the IP source address MUST be the care-of address. - In all other circumstances, the IP source address MUST be the mobile node's home address. If the mobile node does not have a home address, the IP source address MUST be 0.0.0.0. Was this not the original intent of adding the 0.0.0.0 "homeless" text in the first place; i.e. clarifying behavior for the homeless MN registering through a FA, yet still allowing the homeless MN using a colocated COA. --peter [rest snipped] From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 21:13: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 VAA04690 for ; Fri, 7 Dec 2001 21:13:54 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA28095; Fri, 7 Dec 2001 18:07:32 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA28042; Fri, 7 Dec 2001 18:07:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB826evU003631 for ; Fri, 7 Dec 2001 18:06:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB826eu1003630 for mobile-ip-dist; Fri, 7 Dec 2001 18:06:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB826cvU003623 for ; Fri, 7 Dec 2001 18:06:39 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28596 for ; Fri, 7 Dec 2001 21:06:38 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id VAA06075 for mobile-ip@sunroof.eng.sun.com; Fri, 7 Dec 2001 21:07:13 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB6NQ0oH019438 for ; Thu, 6 Dec 2001 15:26:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23319 for ; Thu, 6 Dec 2001 15:26:00 -0800 (PST) Received: from dcs-server2.cs.uiuc.edu (dcs-server2.cs.uiuc.edu [128.174.252.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02249 for ; Thu, 6 Dec 2001 16:26:33 -0700 (MST) Received: from BROOKLYN (brooklyn.cs.uiuc.edu [128.174.244.80]) (authenticated bits=0) by dcs-server2.cs.uiuc.edu (8.12.1/8.12.1) with ESMTP id fB6NPw7Y013319 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 6 Dec 2001 17:25:59 -0600 (CST) Message-ID: <0c0501c17ead$5c919010$50f4ae80@cs.uiuc.edu> From: "MC2R" To: "mobileip" Subject: [mobile-ip] Call for Papers: Mobile Computing and Communications Review (MC2R) Date: Thu, 6 Dec 2001 17:25:58 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Call for Papers Content-Transfer-Encoding: 7bit Mobile Computing and Communications Review (MC2R) The official publication of ACM SIGMOBILE PUBLICATION PURPOSE -------------------- The explosive growth of wide-area cellular systems and local-area wireless networks and the emergence of home area radio networks and personal area body networks are just the beginning of "the wireless revolution". The ultimate goal - uncompromised connectivity and performance for mobile computing devices - requires that we meet the challenge of creating fully integrated, seamless, fault-tolerant and heterogeneous networks composed of fully distributed, energy efficient, and ubiquitous mobile computing platforms. Making truly tetherless computing possible demands that we carefully evaluate, enhance and perhaps re-design our networks, systems, algorithms, and applications. This publication serves to enhance the ability of ACM SIGMOBILE members to keep up-to-date in this rapidly moving field, as well as serve as a major focal point for the discussion of new directions of portable computation and mobile networks for both the research and market-driven communities. PAPERS ------ Technical papers describing previously unpublished, original, completed research, and not currently under review by another conference or journal are solicited on topics related to mobile or wireless research, systems, or practice. Topics of interest include, but are not limited to: * Applications and computing services supporting the mobile user * Network architectures, protocols or service algorithms * Performance characterization of mobile/wireless networks * Network management for mobile and wireless networks * Data management and databases for mobile environments * Service integration and interworking of wired and wireless networks * Interaction between different layers of mobile or wireless systems. * Security, scalability and reliability issues * Nomadic computing * Wearable computing and networking * Satellite communications * Quality of Service and Integrated Services in Mobile or Wireless Networks * Mobile Internetworking * Intelligent network signaling * Mobile VoIP * Mobile ad hoc and sensor networks * Power management and control algorithms * User interfaces and systems design * Theory/algorithms How to submit ------------- Paper submission will be handled electronically. After following the detailed submission instructions from the MC2R web page (http://www.acm.org/sigmobile/MC2R), authors should email a PDF or PostScript version of their full paper to: editors_sigmobile@acm.org. Information on SIGMOBILE, including how to join, is available from: http://www.acm.org/sigmobile IMPORTANT DATES ---- Authors are free to submit manuscripts at any time for inclusion in the next review cycle. EDITOR IN CHIEF ---- Jason Redi, BBN Technologies, U.S.A. (redi@bbn.com) ASSOCIATE EDITORS ---- Anthony Joseph, University of California, Berkeley, U.S.A. (adj@cs.berkeley.edu) Robin Kravets, University of Illinois, Urbana-Champaign, U.S.A. (rhk@cs.uiuc.edu) FOR MORE INFORMATION ---- Please visit the MC2R web site at http://www.acm.org/sigmobile/MC2R. For specific questions, feel free to contact the editors of MC2R at editors_sigmobile@acm.org From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 21:14: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 VAA04703 for ; Fri, 7 Dec 2001 21:14:30 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA28242; Fri, 7 Dec 2001 18:08:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA28141; Fri, 7 Dec 2001 18:08:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB827LvU003648 for ; Fri, 7 Dec 2001 18:07:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB827K50003647 for mobile-ip-dist; Fri, 7 Dec 2001 18:07:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB827IvU003640 for ; Fri, 7 Dec 2001 18:07:19 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03698 for ; Fri, 7 Dec 2001 21:07:18 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id VAA06087 for mobile-ip@sunroof.eng.sun.com; Fri, 7 Dec 2001 21:07:53 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB7KscvU001979 for ; Fri, 7 Dec 2001 12:54:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27801 for ; Fri, 7 Dec 2001 12:54:39 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21720 for ; Fri, 7 Dec 2001 13:54:39 -0700 (MST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id fB7Ksb921417 for ; Fri, 7 Dec 2001 12:54:38 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id fB7Ksa014585 for ; Fri, 7 Dec 2001 12:54:36 -0800 (PST) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id MAA15163 for ; Fri, 7 Dec 2001 12:54:35 -0800 (PST) Message-ID: <3C112C8B.3B4E1102@cisco.com> Date: Fri, 07 Dec 2001 14:54:35 -0600 From: Peter Lei X-Mailer: Mozilla 4.79 [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] 0.0.0.0 src address References: <8C92E23A3E87FB479988285F9E22BE460234D7@ftmail> <001101c17f5b$de47e650$996015ac@AlperVAIO> 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 E. YEGIN" wrote: > > Matt, > > > > > > For example, what if any MN configures itself with a > > > temporary address > > > > > to send the reg-req with home-addr=0, to get it's > > > > > newly-assigned homeaddr? > > > > > > > > > > > - If the mobile node does not have a home address, > > > the IP source > > > > > address MUST be 0.0.0.0. > > > > > > > > > > > > > I also question why this is a MUST. It is entirely > > > possible that the MN's > > > > interface over which it is going to send the RREQ has an IP address > > > > (established via DHCP), while the mobile does not yet have > > > a MIP home > > > > address. In this case, shouldn't it be able to send the > > > RREQ with the > > > > interface's address as the IP source address, but with a > > > zero home address > > > > in the RREQ?? > > > > > > You cannot make this assumption. This works only if we are using > > > co-located care-of address. In case of FA-located care-of > > > address, mobile node has only home address. > > > > I was not making the assumption that this was always the case. I was > merely > > asking: when this is the case, shouldn't the mobile be able to set the > > oh, ok. I thought you were suggesting this as a solution. > > > source IP address on its RREQ equal to the interface's address over which > > the RREQ is going out?? > > that should be ok. > > > Currently this is not allowed by the MIP draft, as > > the mobile MUST set the source address of its RREQs to 0.0.0.0 if it has > no > > home address. > > I don't know why it has to be like that. I cannot think of any reason. > > I think the mobile node should be able to send the registration request > with the care-of address as the source address. After all, the reg. req. can > carry home address in a separate field. > > In the case of co-located care-of address and dynamic home address > allocation, how can the mobile node send the registration request with > an unspecified source address (and receive a response)? > > I think this is an important problem. So, wouldn't this solve this issue in 3.6.1.1 in 2002bis-08 (Note, this merely "moves" the added requirement in -08): - When registering on a foreign network with a co-located care-of address, the IP source address MUST be the care-of address. - In all other circumstances, the IP source address MUST be the mobile node's home address. If the mobile node does not have a home address, the IP source address MUST be 0.0.0.0. Was this not the original intent of adding the 0.0.0.0 "homeless" text in the first place; i.e. clarifying behavior for the homeless MN registering through a FA, yet still allowing the homeless MN using a colocated COA. --peter [rest snipped] From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 7 21:44: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 VAA06010 for ; Fri, 7 Dec 2001 21:44:42 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01852; Fri, 7 Dec 2001 19:40:50 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25837; Fri, 7 Dec 2001 18:41:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB82c0vU003927 for ; Fri, 7 Dec 2001 18:38:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB82c0Va003926 for mobile-ip-dist; Fri, 7 Dec 2001 18:38:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB82btvU003918; Fri, 7 Dec 2001 18:37:56 -0800 (PST) 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 SAA03179; Fri, 7 Dec 2001 18:37:56 -0800 (PST) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04831; Fri, 7 Dec 2001 18:37:55 -0800 (PST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA34490; Fri, 7 Dec 2001 20:35:07 -0600 Received: from d03nm066.boulder.ibm.com (d03nm066.boulder.ibm.com [9.99.140.50]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB82acU134602; Fri, 7 Dec 2001 19:36:38 -0700 Subject: Re: [mobile-ip] Question on performing DAD for BU's To: vijayd@iprg.nokia.com, Francis.Dupont@enst-bretagne.fr Cc: 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: Fri, 7 Dec 2001 18:33:07 -0800 X-MIMETrack: Serialize by Router on D03NM066/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/07/2001 07:36:38 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 Vijay & Francis, I didn't state the complete problem (though Francis did correctly guess what I meant), so let me add a few lines to describe that. When the MN goes to a FN, another node (which already had it's address autoconfigured, thereby having it's own link local address) configured the MN's home address manually, unintentionally or maliciously. When the HA does DAD on the link local address, the new node does not respond to the NS, since it has a different link local address. Now there will be a conflict for packets destined to either the MN or the new node. Isn't it needed to do DAD in this case for every address ? My problem is only with manual configuration , I agree that autoconfiguration doesn't create this problem at all. Also, the 'S' bit doesn't solve the problem, it is not defending all the addresses, the 'S' bit is used for tunnelling packets with any of the many home addresses values based on the prefixes supported, instead of just the home address. > this is based on the common policy where DAD is only performed on link-local addresses *and* no address uses a different interface ID. If this restriction is enforced, this problem does not exist. But that is exactly what I am trying to find out. If a node can configure an address with a different interface identifier, then DAD should be done on all addresses values. Please let me know if this is wrong in any way. Thanks, - KK Vijay Devarapalli To: mobile-ip@sunroof.eng.sun.com Sent by: cc: owner-mobile-ip@sunroof.e Subject: Re: [mobile-ip] Question on performing DAD for BU's ng.sun.com 12/06/2001 05:20 PM Please respond to mobile-ip Hi KK, I think this comes from RFC 2462 which says if you have stateless address configuration, its enough if you do duplicate address detection on just the link local address. the other addresses are a MAY. heres the relevant text from RFC 2462, section 5.4 --------------- - Each individual unicast address SHOULD be tested for uniqueness. However, when stateless address autoconfiguration is used, address uniqueness is determined solely by the interface identifier, assuming that subnet prefixes are assigned correctly (i.e., if all of an interface's addresses are generated from the same identifier, either all addresses or none of them will be duplicates). Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link- local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier. --------------- And I guess the intention was that Mobile IPv6 did not want to specify anything in addition to what is there in RFC 2462. and regarding more than prefix on the home link there is something specified in draft 15 for that. if the 'S' bit in the BU is set, the Home Agent defends just the home address specified in the home address option. if the 'S' bit is not set, the home agent forms a home address from each prefix on the home link and defends all of them. and even in this case, by RFC 2462, its enough if you do DAD from just the link local address if stateless address configuration is being used. one more thing, in your example below node 'X' MUST configure a link local address. it cant configure a site local address alone and not configure a link local address. it is there in some RFC, I forgot which. regards Vijay Krishna Kumar wrote: > > Hi Charlie, > > I feel there is a small problem in the Draft 15 regarding the address used > for performing DAD. > > 1. Page 67 for BU processing says that DAD should be performed on the Link > Local Address. > 2. Pg 94 says that : If some time elapses during which the mobile node has > no binding at the home agent, it might be possible for another node to > autoconfigure the mobile node's home address. > > A new node 'X' can configure it's address either through autoconfiguration > (in which case #1 is sufficient), or by manual means. Since the address can > be configured manually, I feel the specification should be changed to state > that DAD should be performed on the Link Local address and all Home > Addresses (if Prefix Length is > 0) based on different prefixes supported > by the Home Agent. > > The reason is that the MN might configure a site local address as it's home > address and move to a foreign network. Before HA gets the BU, another node > 'X' manually configures it's address to the site local address used by the > MN, and it succeeds. When HA gets the BU, it does a Neighbor Solicitation > on the Link Local Address, and since X has not configured that link local > address, it doesn't respond to the NS. Now packets meant for 'X' get > wrongly tunneled to the MN. The node X doesn't even need to take the same > site local address for this to fail, it can configure any other address > based on the prefixes supported and the interface identifier. In this case, > after the BU succeeds, any packets meant for this different address will > still be tunnelled wrongly by the HA to the MN since Prefix Length was > greater than zero. Hence I feel HA must perform DAD on all addresses (can > be done parallely and probably take almost the same time as it would take > for one DAD) if Prefix Length > 0. > > Secondly, is it a good idea for Mobility to change the value of > RetransTimer to a smaller value like 0.5 seconds or smaller ? This means > faster handoff for the MN. Otherwise the MN has to wait for > 1.5*(RetransTimer*DupAddrDetectTransmits) = atleast 1.5 seconds before the > MN gets a response, and before it is allowed to send BU's to CN's. Reducing > this time ensures faster movement mechanism for the MN. > > Thanks, > > - KK From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 8 03:13: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 DAA27421 for ; Sat, 8 Dec 2001 03:13:00 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA06969; Sat, 8 Dec 2001 00:06:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA25218; Sat, 8 Dec 2001 00:06:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB885jvU004334 for ; Sat, 8 Dec 2001 00:05:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB885joA004333 for mobile-ip-dist; Sat, 8 Dec 2001 00:05:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB885gvU004326 for ; Sat, 8 Dec 2001 00:05:42 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20375 for ; Sat, 8 Dec 2001 00:05:43 -0800 (PST) Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17547 for ; Sat, 8 Dec 2001 01:05:41 -0700 (MST) Received: from ryuji.sfc.wide.ad.jp.sfc.wide.ad.jp (3536156928r4.freeserve.ne.jp [210.197.121.4]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 097895D03E; Sat, 8 Dec 2001 17:05:33 +0900 (JST) Date: Sat, 08 Dec 2001 17:11:03 +0900 Message-ID: <87n10u1694.wl@ryuji.sfc.wide.ad.jp.sfc.wide.ad.jp> From: Ryuji Wakikawa To: mobile-ip@sunroof.eng.sun.com Cc: mip6@sfc.wide.ad.jp Subject: Re: [mobile-ip] Interoperability for the Auth Suboption In-Reply-To: <3C05ABBB.51F282E1@iprg.nokia.com> References: <3C05ABBB.51F282E1@iprg.nokia.com> User-Agent: Wanderlust/2.7.6 (Too Funky) REMI/1.14.3 (Matsudai) LIMIT/1.14.7 (Fujiidera) APEL/10.3 Emacs/20.7 (i386-unknown-netbsd1.5.2) MULE/4.1 (AOI) MIME-Version: 1.0 (generated by REMI 1.14.3 - "Matsudai") Content-Type: text/plain; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Folks We will give small notes for our implementations. It might not be so valuable because the implementation is getting older. We are now catching up the newer draft-15 (Not finished yet), but it seems not to be so hard to implement the Authentication Sub Option as Vijay said in his former mail about "Interoperability for the Auth Suboption". Our current implementation is based on draft-ietf-mobileip-ipv6-13.txt and has MN, CN and HA on FreeBSD KAME stack. Our implementation is different from KAME-MIP6 implementation, we still keep working for our original MIP6 implementation with original extensions at InternetCAR project (http://www.sfc.wide.ad.jp/InternetCAR). We tested MIP6 interoperability with many other implementations at connectathon 2001. Our BASE MIP6 features. - Support multiple network interfaces for single home address, simultaneously. - Switching network interfaces (i.e. CoAs) depending on network environments and user's priority. - IPsec (AH) Support - SA selectors As I posted mails to MIP6 ML before, SA selector was extended to handle the MIP6 SA for BU and BA. AHs insertion never becomes bottleneck when MIP6 piggy-back BU, because SFC-MIP6 put AH only for the data with piggybacked BU and never put AH for the rest of data (without BU). Current implementation uses static SA (not running IKE). Since we are implementing our original features into MIP6 and testing the updated MIP6 now, we will announce and release newer MIP6 before long. We are planning to participate in next connectathon2002 for newer MIP6 implementation (draft-15 base). Please check the our MIP6 HP at http://neo.sfc.wide.ad.jp/~mip6/index.html Unfortunately we can not go the next IETF, please contact us by mail (mip6@sfc.wide.ad.jp). regards, ryuji At Wed, 28 Nov 2001 19:30:03 -0800, Vijay Devarapalli wrote: > > Hello, > > At the ETSI IPv6 plugtest at Cannes last week, we managed to > achieve interoperability for the Authentication Sub Option. > There were two independent implentations (one from HUT) and > one from us (Nokia Research, Mt. View). There were also > conformance tests from Ericsson Research, Hungary to test > the Authentication Sub Option. The tests were successful. > We used static security associations for the tests. > > IMHO, It is very easy to implement. Compared to this AH > checksum calculation is a mess. > > The auth checksum was calculated over the following fields > (as specifed in draft 15). > > For the Binding Update > > - The IPv6 address of the destination of the packet, as seen by the > recipient > - Care-of Address, in the Source IP Address of the IPv6 header > - The Home Address of the mobile node, from the Home Address > destination option > - Option Type of the Binding Update destination option > - Option Length of the Binding Update destination option > - All flags of the Binding Update destination option > - Reserved Field of the Binding Update destination option > - Sequence Number Field of the Binding Update > - Lifetime of the Binding Update destination option > - The entire data from all Binding Update Sub-Options (except the > Authentication Data suboption), if any others exist > - The Type (i.e., the 8-bit value 0x04) and the Length of the > Authentication Data Sub-Option > - Security Parameters Index (SPI) of the Authentication Data > Sub-Option > > > For the Binding Acknowledgement > > - The IPv6 address of the destination of the packet, as seen by the > recipient > - The Home Address of the sender > - Option Type of the Binding Acknowledgement destination option > - Option Length of the Binding Acknowledgement > - Status of the Binding Acknowledgement > - Sequence Number field of the Binding Acknowledgement > - Lifetime field of the Binding Acknowledgement destination option > - Refresh field of the Binding Acknowledgement destination option > - The entire data from all Binding Acknowledgement Sub-Options > (except the Authentication Data suboption), if any others exist > - The Type (i.e., the 8-bit value 0x04) and the Length of the > Authentication Data Sub-Option > - Security Parameters Index (SPI) of the Authentication Data > Sub-Option > > > regards > Vijay From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 8 18:50:24 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 SAA05594 for ; Sat, 8 Dec 2001 18:50:23 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10696; Sat, 8 Dec 2001 16:48:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29264; Sat, 8 Dec 2001 15:48:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB8NmAvU005575 for ; Sat, 8 Dec 2001 15:48:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB8NmANo005574 for mobile-ip-dist; Sat, 8 Dec 2001 15:48:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB8Nm5vU005567 for ; Sat, 8 Dec 2001 15:48:06 -0800 (PST) Received: from lillen (hobo078.Eng.Sun.COM [129.146.31.78]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fB8Nlkq11271; Sun, 9 Dec 2001 00:47:47 +0100 (MET) Date: Sun, 9 Dec 2001 00:46:10 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] Routing header Vs tunneling To: Glenn Morrow Cc: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Glenn, > That said - what is the use of sending the extra addresses in each packet at > all since per-address authorization state must be kept on the tunnel > endpoints in order to protect against the reflector attacks? Are you suggesting sending packets with just two IP addresses and having the endpoint replace the source IP and destination IP based on what it has in the binding cache entry? I think such an approach has some robustness problems. - What happens if the MN moves away and other MN appears and acquires the same CoA? If there is a stale binding cache entry for the CoA->old HoA in some CN there will be TCP checksum failures should the new MN/HoA try to communicate with it since it will use the old CoA->HoA mapping. - What if a MN wants to have one session (e.g. TCP or VoIP) with a CN using route optimization and another session (e.g. DNS udp lookup) not using route optimization. That CN would not be able to tell whether to apply the address replacement - the source address would be the CoA in both cases. And I can't even imagine what the security issues would be in such a case. So I think having all packets contain all the necessary IP addresses makes sense. Erik From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 8 18: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 SAA05612 for ; Sat, 8 Dec 2001 18:50:38 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11017; Sat, 8 Dec 2001 16:49:27 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29467; Sat, 8 Dec 2001 15:49:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB8Nn5vU005622 for ; Sat, 8 Dec 2001 15:49:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB8Nn5J2005621 for mobile-ip-dist; Sat, 8 Dec 2001 15:49:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB8Nn0vU005605 for ; Sat, 8 Dec 2001 15:49:01 -0800 (PST) Received: from lillen (hobo078.Eng.Sun.COM [129.146.31.78]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fB8NmPq11290; Sun, 9 Dec 2001 00:48:26 +0100 (MET) Date: Sun, 9 Dec 2001 00:46:49 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Additional comments on draft-arkko-mipv6-bu-security-00.txt To: "Charles E. Perkins" Cc: Jari Arkko , mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Hello Jari, > > Jari Arkko wrote: > > > Erik, thanks for your comments. I have some answers below: > > > > > Section 6.4 talks about having a configuration knob to allow > > > unsecure BUs. I think this is a big mistake. Instead the WG should > > > develop some BU solution that can give some security comparable to > > > today's IPv4 security. > > > > I agree! I have recently come to the conclusion myself that > > we should not allow unsecure RO at all, and as a minimum should > > require one of the weak auth protocols. > > I was really surprised to read this. Unsecure route optimization has > _never_ been allowable in the Mobile IP working group, neither for > IPv4 or for IPv6. When has there been discussion otherwise? > > Or am I misinterpreting something? Charlie, you apparently didn't read the subject line of the message. This discuss thread is about the text in draft-arkko-mipv6-bu-security-00.txt. Erik From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 8 18:51: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 SAA05631 for ; Sat, 8 Dec 2001 18:51:25 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27398; Sat, 8 Dec 2001 15:50:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29551; Sat, 8 Dec 2001 15:50:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB8NnVvU005687 for ; Sat, 8 Dec 2001 15:49:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB8NnVRp005686 for mobile-ip-dist; Sat, 8 Dec 2001 15:49:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB8NnQvU005663 for ; Sat, 8 Dec 2001 15:49:27 -0800 (PST) Received: from lillen (hobo078.Eng.Sun.COM [129.146.31.78]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fB8NnMq11335; Sun, 9 Dec 2001 00:49:22 +0100 (MET) Date: Sun, 9 Dec 2001 00:47:45 +0100 (CET) From: Erik Nordmark Subject: [mobile-ip] Risks of not verifying the care-of address To: mroe@microsoft.com Cc: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Section 7.3 of says The BAKE/2 and CAM-DH protocols described in this memo verify that that packets sent to a mobile node's claimed care-of address reach an entity that is willing to participate in the protocol. If this check was not performed, a malicious mobile node could perform a denial of service attack by asking a correspondent node to send it a high volume stream of data, and then sending the correspondent a binding update that redirects the stream of data to the victim of the denial of service attack. But there seems to be a tradeoffs between this type of protection and "3rd party reflection". By this term I mean X sending a packet to A (with X as the source address) which tells A to send packets to B. ("Normal reflection" is based on spoofing the source address to cause reply packets to go back to the wrong place.) BTW: bu3way has problem as well - the BUR sent from the CoA causes a BUC to be sent to the Home Address. If sending a packet from a CoA (or HoA) to the CN causes packets to be sent to the address that was not in the source field, then this is "3rd party reflection". Such protocol mechanisms can be used to cause DoS attacks against low bandwidth nodes as well. For instance, assume X and A have 100 Mbps bandwidth between then and B only has 100 kbps bandwidth. Then X can send 100 Mbps of BU related packets (the first packet in an exchange) to A. For DoS reasons A can't create state associated with that first packet. If A sends the "response" packet to an IP address other than the source address of the "request" then B might see on the order of 100 MBps of packets coming towards it. And ingress filtering can't prevent this, ITRACE can't trace it back from B, etc. So I think the conservative thing to do if there is a need to check with the CoA as well as the HoA during BUs is to send more packets. For instance, the MN could send packet1 both with CoA as the source (causing a "response" to be sent to the CoA) and with HoA as the source (reverse-tunneled through the HA). Then when the has the information from both "responses" it can do the actual BU. But it still isn't obvious to me that preventing packet flooding attacks against a unwilling CoA is a requirement. Seems like there are other means to flood a low-bandwidth node. Erik From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 8 18:53: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 SAA05708 for ; Sat, 8 Dec 2001 18:53:47 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11941; Sat, 8 Dec 2001 16:52:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29950; Sat, 8 Dec 2001 15:52:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB8Nq9vU005881 for ; Sat, 8 Dec 2001 15:52:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB8Nq98g005880 for mobile-ip-dist; Sat, 8 Dec 2001 15:52:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB8Nq5vU005870 for ; Sat, 8 Dec 2001 15:52:05 -0800 (PST) Received: from lillen (hobo078.Eng.Sun.COM [129.146.31.78]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fB8Nq3q11402; Sun, 9 Dec 2001 00:52:03 +0100 (MET) Date: Sun, 9 Dec 2001 00:50:26 +0100 (CET) From: Erik Nordmark Subject: [mobile-ip] Avoiding negotiate down hazards for BU To: mobile-ip@sunroof.eng.sun.com Cc: 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: Section 6.2 of draft-aura-mipv6-bu-attacks-00.txt talks about the difficulty of allowing multiple methods for securing BUs with different strength - that an attacker could always force the use of the weakest method unless the negotiation of method is done at the highest security. This is true in general. However, if it turns out that the WG would like to pursue both a method relying on just return routability and another method (like CAM/SUCV) relying on a hash of a public key in the Interface ID part of the address, then I think we can do better if there is a need. The idea is to carve out half of the local INterface ID space (currently used by RFC 3041 and other addresses) to mean "only accept BUs for this address using the stronger method", with the weaker method (unless overridden by local policy on the CN) is acceptable for all other Interface IDs. If course, this would mean revising at least RFC 3041. But it might be an option if there is WG interest to pursue both classes of methods. Erik From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 8 18:54:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05734 for ; Sat, 8 Dec 2001 18:54:21 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA26597; Sat, 8 Dec 2001 15:48:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29168; Sat, 8 Dec 2001 15:48:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB8NlOvU005551 for ; Sat, 8 Dec 2001 15:47:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB8NlOND005550 for mobile-ip-dist; Sat, 8 Dec 2001 15:47:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB8NlJvU005543 for ; Sat, 8 Dec 2001 15:47:20 -0800 (PST) Received: from lillen (hobo078.Eng.Sun.COM [129.146.31.78]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fB8NlGq11241; Sun, 9 Dec 2001 00:47:16 +0100 (MET) Date: Sun, 9 Dec 2001 00:45:39 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routing header Vs tunneling To: Vijay Devarapalli Cc: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > b. Home Address Option/Routing Header vs Tunnelling > > I think we should modify 'b' to say " Home Address Option > vs Tunnelling" because Pekka has suggested a solution for > the routing header problem in his > draft-savola-ipv6-rh-ha-security-01.txt The intent of the presenters was actually to use Pekka Savola's draft to talk about the security requirements for HAOpt and routing headers, and not go into a discussion about whether the tunneling packet formats are better or worse than the HAOpt and RH packet formats. If the WG can come to closure on the requirements then we have one less thing to worry about. > Every host should follow these rules > > Routing header MUST be processed if > 1. segleft is 1 > 2. destination address and intermediate address both > belong to the same interface of the host that > received the packet. > Routing header MUST not be processed if > 1. the address to be swapped does not belong to > the same interface as the destination address > on the IPv6 header. > > if a IPv6 host follows the above rules, is there still a > security problem? if not, I suggest we drop the issue of > router header Vs tunneling and use routing header with the > above two rules. As I just sent to the ipv6 list, I think the overloading of routing headers make it harder for firewalls to differentiate between MIPv6 use of routing headers as opposed to other routing headers (those where the different hops are for different nodes). This was pointed out in Pekka's draft if I remember correctly. I don't know how important this concern is. What does the WG think about that concern? Erik From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 8 19:42: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 TAA06349 for ; Sat, 8 Dec 2001 19:42:42 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02005; Sat, 8 Dec 2001 16:41:38 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00456; Sat, 8 Dec 2001 16:41:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB90esvU006033 for ; Sat, 8 Dec 2001 16:40:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB90esSH006032 for mobile-ip-dist; Sat, 8 Dec 2001 16:40:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB90eovU006025 for ; Sat, 8 Dec 2001 16:40:50 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00419 for ; Sat, 8 Dec 2001 16:40:52 -0800 (PST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20235 for ; Sat, 8 Dec 2001 17:40:33 -0700 (MST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id BAA28878 for ; Sun, 9 Dec 2001 01:40:00 +0100 From: "Henrik Levkowetz" To: Subject: [mobile-ip] RFC 3012 - what about challenges from HA Date: Sun, 9 Dec 2001 01:40:49 +0100 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 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.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 going over RFC 3012 and the 3012bis draft, I'm getting puzzled by this: There is provisions for challenges to the MN from the FA, trough the MIP Agent Advertisment Challenge Extension(section 2), and there is provisions for challenges from all entities except the HA and FA trough the Generalized Mobile IP Authentication Extension (section 5). But this leaves the HA hanging in the middle - there's no specific challenge extension for a HA to use, and the Generalized Mobile IP Authentication Extension is not defined for an HA to use. How Come? Henrik ------------------------------------------------------------------------ Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com ------------------------------------------------------------------------ From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 8 20:15: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 UAA06925 for ; Sat, 8 Dec 2001 20:15:37 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA04771; Sat, 8 Dec 2001 17:14:25 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24961; Sat, 8 Dec 2001 17:14:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB91DZvU006141 for ; Sat, 8 Dec 2001 17:13:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB91DZhS006140 for mobile-ip-dist; Sat, 8 Dec 2001 17:13:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB91DWvU006133 for ; Sat, 8 Dec 2001 17:13:32 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05732 for ; Sat, 8 Dec 2001 17:13:34 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA11097 for ; Sat, 8 Dec 2001 18:13:33 -0700 (MST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 4E13A6A904; Sun, 9 Dec 2001 03:13:10 +0200 (EET) Message-ID: <3C12BA10.5030304@piuha.net> Date: Sun, 09 Dec 2001 03:10:40 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com, mroe@microsoft.com, tuomaura@microsoft.com Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: 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 Erik Nordmark wrote: > By this term I mean X sending a packet to A (with X as the source address) > which tells A to send packets to B. > ("Normal reflection" is based on spoofing the source address to cause > reply packets to go back to the wrong place.) > > BTW: bu3way has problem as well - the BUR sent from the CoA causes a BUC > to be sent to the Home Address. > > If sending a packet from a CoA (or HoA) to the CN causes packets to be > sent to the address that was not in the source field, then this is > "3rd party reflection". Ah, I see. So the problem in BAKE/2 and CAM-DH is more the message to the Home Address, than the CoA routability test. Interestingly, the problem you describe is exactly the same one as we have been discussing around the HAO and regular traffic! Obviously, when sending the first packet of BAKE/2 we do not have a BCE ready yet - so to use the HAO at this time would be illegal according to rules laid out before. I believe also Classic Bake, Busec, and SUCV have a similar issue. > For instance, the MN could send packet1 both with CoA as the source > (causing a "response" to be sent to the CoA) and with HoA as the source > (reverse-tunneled through the HA). > Then when the has the information from both "responses" it can do the > actual BU. This is an interesting approach. We have to think about it some more. A few issues come to mind: - Using a similar technique as we are using now, the additional message does not have to add more delay, if both messages can be sent simultaneously - In order to keep the CN stateless, the processing of the two legs must be kept independent and two response messages generated also. Have to look at the math to make sure this is doable... > But it still isn't obvious to me that preventing packet flooding > attacks against a unwilling CoA is a requirement. Seems like there are other > means to flood a low-bandwidth node. I believe what we do with the CoA test can, if omitted, cause really serious damage. It's not just the low bandwidth nodes, the attack outlined in draft-aura (open tcp to yourself, take a look at the sequence numbers, then move the stream towards victim, possibly send a few TCP ACKs now and then to keep the stream going) appears to be able to easily flood larger nodes or whole networks due to the high amplification factor. It appears more serious than HOA reflection, where there's no amplification. However, the success of the attack depends on (a) ingress filtering being off in the attacker's network (irrelevant if it is on in the victim network). And, (b) you have to be on the path HA-CN in order to fool the CN's weak authentication procedure*. Ok, so you could say that it is an unlikely place to be in. However, in this case the attacker has complete freedom to choose both HA and CN nodes in a way that places him between them. This is because he is not attacking HA and CN, he is attacking someone at another location, the CoA. I can't immediately see how you could do with current stationary IPv4. Since we assumed there's no ingress filtering, the attacker could indeed try to open a session towards a spoofed source address. Attacks like that exist, and typically depend on the knowledge the attacker has on how the OS allocates TCP sequence numbers etc. But there's an important additional advantage that MIPv6 gives for the attacker: he can temporarily direct the flow to himself to learn TCP sequence numbers or any basic DoS protection built to the particular protocol. Jari *) Trivial for BAKE/2 and relatives. For CAM-DH and relatives, you could invent your own public key and address. From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 8 22:48:24 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10428 for ; Sat, 8 Dec 2001 22:48:24 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA24240; Sat, 8 Dec 2001 20:47:01 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA10732; Sat, 8 Dec 2001 19:47:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB93kXvU006363 for ; Sat, 8 Dec 2001 19:46:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB93kXf0006362 for mobile-ip-dist; Sat, 8 Dec 2001 19:46:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB93kTvU006355 for ; Sat, 8 Dec 2001 19:46:30 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04282 for ; Sat, 8 Dec 2001 19:46:31 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA24064 for ; Sat, 8 Dec 2001 20:46:12 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA21550 for ; Sat, 8 Dec 2001 19:46:30 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB93kTV15352 for ; Sat, 8 Dec 2001 19:46:29 -0800 X-mProtect: Sat, 8 Dec 2001 19:46:29 -0800 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 smtpdFww1Oo; Sat, 08 Dec 2001 19:46:27 PST Message-ID: <3C12DDA1.28768737@iprg.nokia.com> Date: Sat, 08 Dec 2001 19:42:25 -0800 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] RFC 3012 - what about challenges from HA 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, Since the home agent has a security association with the mobile node, and since the registration request has replay protection and authentication extension, there isn't any need for the challenge. The whole registration message data can properly be considered to be a challenge, because of the anti-replay data in the Identificatoin field. Regards, Charlie P. Henrik Levkowetz wrote: > On going over RFC 3012 and the 3012bis draft, I'm getting puzzled by > this: > > There is provisions for challenges to the MN from the FA, trough the > MIP Agent Advertisment Challenge Extension(section 2), and there is > provisions for challenges from all entities except the HA and FA > trough the Generalized Mobile IP Authentication Extension (section 5). > > But this leaves the HA hanging in the middle - there's no specific > challenge extension for a HA to use, and the Generalized Mobile IP > Authentication Extension is not defined for an HA to use. > > How Come? > > Henrik > > ------------------------------------------------------------------------ > Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com > ------------------------------------------------------------------------ From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 8 23:34: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 XAA11202 for ; Sat, 8 Dec 2001 23:34:31 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03287; Sat, 8 Dec 2001 21:33:06 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA16002; Sat, 8 Dec 2001 20:33:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB94WIvU006492 for ; Sat, 8 Dec 2001 20:32:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB94WIwt006491 for mobile-ip-dist; Sat, 8 Dec 2001 20:32:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB94WFvU006484 for ; Sat, 8 Dec 2001 20:32:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA13045 for ; Sat, 8 Dec 2001 20:32:17 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03045 for ; Sat, 8 Dec 2001 21:31:58 -0700 (MST) Received: from AlperVAIO (dhcp130.docomo-usa.com [172.21.96.130]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB94WFJ28908 for ; Sat, 8 Dec 2001 20:32:15 -0800 (PST) Message-ID: <00b301c18069$94796670$826015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <3C1169D3.AB7DD394@ieee.org> Subject: Re: [mobile-ip] 0.0.0.0 src address Date: Sat, 8 Dec 2001 20:25:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 Peter, > So, wouldn't this solve this issue in 3.6.1.1 in 2002bis-08 (Note, this > merely "moves" the added requirement in -08): > > - When registering on a foreign network with a co-located care-of > address, the IP source address MUST be the care-of address. > > - In all other circumstances, the IP source address MUST be the > mobile node's home address. If the mobile node does not have a > home address, the IP source address MUST be 0.0.0.0. Yes, this should solve the problem. > > Was this not the original intent of adding the 0.0.0.0 "homeless" text > in the first place; i.e. clarifying behavior for the homeless MN > registering through a FA, yet still allowing the homeless MN using > a colocated COA. Maybe. Like Siva's interpretation. Probably (?) after a careful reading and little bit of thinking, implementor would do the right thing. But I still think the draft could benefit a clearer text, like yours. alper > > --peter > > [rest snipped] > From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 9 01:19: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 BAA13199 for ; Sun, 9 Dec 2001 01:19:27 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA21978; Sat, 8 Dec 2001 23:17:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA11483; Sat, 8 Dec 2001 22:17:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB96GGvU006680 for ; Sat, 8 Dec 2001 22:16:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB96GGh9006679 for mobile-ip-dist; Sat, 8 Dec 2001 22:16:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB96GDvU006672 for ; Sat, 8 Dec 2001 22:16:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA11357 for ; Sat, 8 Dec 2001 22:15:13 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA21439 for ; Sat, 8 Dec 2001 23:13:39 -0700 (MST) 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 fB96EfA11921 for ; Sun, 9 Dec 2001 08:14:41 +0200 (EET) Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Sun, 9 Dec 2001 08:13:55 +0200 Received: by esebh24nok with Internet Mail Service (5.5.2652.78) id ; Sun, 9 Dec 2001 08:13:54 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF6E5E06@esebe004.NOE.Nokia.com> To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org Subject: RE: [mobile-ip] L2 triggers draft Date: Sun, 9 Dec 2001 08:13:49 +0200 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 all, > My opinion is, among existing working groups it best fits PILC. > > But, if we want to do a better job (more than L2 triggers), then I'd > recommend forming a new Sub-IP working group: IP over Wireless. Its too late for Salt Lake City & maybe too early for Minneapolis, but I think a bof on this general area would be useful. In NSIS, there is some discussion on if/how you could tie air interface (layer 2) QoS properties into layer 3. I think a BOF with some general discussion on the problem area(s), at least to give some scope to the problem would be very interesting. We want to make sure we don't go 'ocean-boiling' .... best regards, John From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 9 05:25: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 FAA29784 for ; Sun, 9 Dec 2001 05:25:53 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA26179; Sun, 9 Dec 2001 02:24:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22237; Sun, 9 Dec 2001 02:24:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9ANrvU007111 for ; Sun, 9 Dec 2001 02:23:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB9ANrsR007110 for mobile-ip-dist; Sun, 9 Dec 2001 02:23:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9ANnvU007103 for ; Sun, 9 Dec 2001 02:23:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02138 for ; Sun, 9 Dec 2001 02:23:51 -0800 (PST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA19063 for ; Sun, 9 Dec 2001 03:24:24 -0700 (MST) Received: from chardonnay (sparcis.ipunplugged.com [10.0.1.163]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id LAA02059 for ; Sun, 9 Dec 2001 11:22:58 +0100 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] RFC 3012 - what about challenges from HA Date: Sun, 9 Dec 2001 11:23:48 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C12DDA1.28768737@iprg.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.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, Ah, I see, then I can appreciate the reasoning. However, what if one would like to use a pre-existing authentication infrastructure which was designed to use challenges, instead of creating a new set of shared secrets, public/private keys or whatever for use with mobile ip? Might there not be a place also for challenges from a HA in that case? Regards, Henrik > > Hello Henrik, > > Since the home agent has a security association with the > mobile node, and since the registration request has > replay protection and authentication extension, there > isn't any need for the challenge. The whole registration > message data can properly be considered to be a > challenge, because of the anti-replay data in the > Identificatoin field. > > Regards, > Charlie P. > > > Henrik Levkowetz wrote: > > > On going over RFC 3012 and the 3012bis draft, I'm getting puzzled by > > this: > > > > There is provisions for challenges to the MN from the FA, trough the > > MIP Agent Advertisment Challenge Extension(section 2), and there is > > provisions for challenges from all entities except the HA and FA > > trough the Generalized Mobile IP Authentication Extension (section 5). > > > > But this leaves the HA hanging in the middle - there's no specific > > challenge extension for a HA to use, and the Generalized Mobile IP > > Authentication Extension is not defined for an HA to use. > > > > How Come? > > > > Henrik > > > > ------------------------------------------------------------------------ > > Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com > > ------------------------------------------------------------------------ From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 9 15:36: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 PAA04263 for ; Sun, 9 Dec 2001 15:36:12 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27811; Sun, 9 Dec 2001 12:34:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27154; Sun, 9 Dec 2001 12:34:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9KXpvU007976 for ; Sun, 9 Dec 2001 12:33:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB9KXpHE007975 for mobile-ip-dist; Sun, 9 Dec 2001 12:33:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9KXkvU007968 for ; Sun, 9 Dec 2001 12:33:47 -0800 (PST) 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 fB9KXeq04269; Sun, 9 Dec 2001 21:33:40 +0100 (MET) Date: Sun, 9 Dec 2001 21:32:01 +0100 (CET) From: Erik Nordmark Subject: [mobile-ip] Re: Binding Update <--> bu3way To: "Charles E. Perkins" Cc: Erik Nordmark , Mobile IP Working Group In-Reply-To: "Your message with ID" <3C1142F6.1EEA3CFA@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: > I think that some people (e.g., me) interpreted this to mean that a > lightweight key distribution protocol was required before Mobile IPv6 > could become Proposed Standard. However, I now understand that this > wasn't the intent. Maybe we can satisfy the requirement by using > your recently proposed BU3WAY draft to enable processing for Binding > Updates whenever a suitable security association is not available. Do you think the basic 3-way for every update would perform well enough? Or do you think there would be a need to establish a binding security association? > This would work as follows: > > - If the mobile node has a security assocation with the > correspondent node, it sends an authenticated Binding Update By this do you mean IPsec SA or something more vague? > - Otherwise, if a key establishment protocol exists, the mobile > node initiates key establishment > - Otherwise, the mobile node carries out the BU3WAY operations I think this runs into "negotiate down" security threats. (I think it is draft-draft-aura-mipv6-bu-attacks-00.txt that talks about this.) For example, if a CN wants to use a high security as possible how can it prevent an attacker from forcing the use of the weak BU3WAY? Erik From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 9 16:05: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 QAA04439 for ; Sun, 9 Dec 2001 16:05:57 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01206; Sun, 9 Dec 2001 13:04:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28850; Sun, 9 Dec 2001 13:04:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9L3ovU008078 for ; Sun, 9 Dec 2001 13:03:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB9L3oQ0008077 for mobile-ip-dist; Sun, 9 Dec 2001 13:03:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9L3kvU008070 for ; Sun, 9 Dec 2001 13:03:47 -0800 (PST) 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 fB9L3cq05067; Sun, 9 Dec 2001 22:03:39 +0100 (MET) Date: Sun, 9 Dec 2001 22:02:00 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Risks of not verifying the care-of address To: jari.arkko@piuha.net Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, mroe@microsoft.com, tuomaura@microsoft.com In-Reply-To: "Your message with ID" <3C12BA10.5030304@piuha.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Ah, I see. So the problem in BAKE/2 and CAM-DH is more the message to the > Home Address, than the CoA routability test. OK - you mean I swapped things around. The first packet is sourced from the CoA and this causes a packet to be sent to the HoA. > This is an interesting approach. We have to think about it some more. > A few issues come to mind: > > - Using a similar technique as we are using now, the additional message does > not have to add more delay, if both messages can be sent simultaneously agreed. > - In order to keep the CN stateless, the processing of the two legs must > be kept independent and two response messages generated also. Have to > look at the math to make sure this is doable... I the context bu3way you could get a separate cookie on each path and be required to present both cookies in the actual BU message. In this case the CN would be stateless. > I believe what we do with the CoA test can, if omitted, cause really serious > damage. It's not just the low bandwidth nodes, the attack outlined in > draft-aura (open tcp to yourself, take a look at the sequence numbers, then > move the stream towards victim, possibly send a few TCP ACKs now and then to > keep the stream going) appears to be able to easily flood larger nodes or > whole networks due to the high amplification factor. It appears more serious > than HOA reflection, where there's no amplification. However, the success of > the attack depends on (a) ingress filtering being off in the attacker's > network (irrelevant if it is on in the victim network). Why does ingress filtering need to be off? The attacker has the home address for the connection. Thus it can send ACK packets from its home address while the data packet are route optimized to go directly to the CoA (victim). Of course, in this case the victim sees the HoA in the packets which points at the attacker. Spoofing allows the attacker to hide. Erik > And, (b) you have to > be on the path HA-CN in order to fool the CN's weak authentication > procedure*. Ok, so you could say that it is an unlikely place to be in. > However, in this case the attacker has complete freedom to choose both HA > and CN nodes in a way that places him between them. This is because he is > not attacking HA and CN, he is attacking someone at another location, the > CoA. > > I can't immediately see how you could do with current stationary > IPv4. Since we assumed there's no ingress filtering, the attacker could > indeed try to open a session towards a spoofed source address. Attacks like > that exist, and typically depend on the knowledge the attacker has on how > the OS allocates TCP sequence numbers etc. But there's an important > additional advantage that MIPv6 gives for the attacker: he can > temporarily direct the flow to himself to learn TCP sequence numbers > or any basic DoS protection built to the particular protocol. > > Jari > > *) Trivial for BAKE/2 and relatives. For CAM-DH and relatives, you could > invent your own public key and address. > > From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 9 16:18:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04556 for ; Sun, 9 Dec 2001 16:18:46 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26298; Sun, 9 Dec 2001 14:16:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17498; Sun, 9 Dec 2001 13:16:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9LFlvU008203 for ; Sun, 9 Dec 2001 13:15:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB9LFl7p008202 for mobile-ip-dist; Sun, 9 Dec 2001 13:15:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9LFivU008195 for ; Sun, 9 Dec 2001 13:15:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02469 for ; Sun, 9 Dec 2001 13:14:43 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA25859 for ; Sun, 9 Dec 2001 14:14:24 -0700 (MST) Received: from AlperVAIO (dhcp27.docomo-usa.com [172.21.96.27]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fB9LDYJ16779; Sun, 9 Dec 2001 13:13:34 -0800 (PST) Message-ID: <004e01c180f5$9e293c90$1b6015ac@AlperVAIO> From: "Alper E. YEGIN" To: , References: <0C1353ABB1DEB74DB067ADFF749C4EEF6E5E06@esebe004.NOE.Nokia.com> Subject: Re: [mobile-ip] L2 triggers draft Date: Sun, 9 Dec 2001 13:07:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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, > > My opinion is, among existing working groups it best fits PILC. > > > > But, if we want to do a better job (more than L2 triggers), then I'd > > recommend forming a new Sub-IP working group: IP over Wireless. > > Its too late for Salt Lake City & maybe too early for Minneapolis, > but I think a bof on this general area would be useful. In I agree. > NSIS, there is some discussion on if/how you could tie air > interface (layer 2) QoS properties into layer 3. I think > a BOF with some general discussion on the problem area(s), at > least to give some scope to the problem would be very interesting. I think we need a home for L2-L3 interaction for mobile and wireless networks. As you say, QoS is an example. L2 triggers requirement is another. Later we'll also "implement" this L2 triggers requirements, in the form of "L2 triggers protocol", which needs a home as well. And then there's future PANA protocol, which is likely to do key distribution. These keys, which are received at L3 can be passed down to L2 to do encryption (depends on L2 capabilities). Learning L2 capabilites can help making intelligent decisions on mobility. So, I think we have candidates to at least have a bof. > We want to make sure we don't go 'ocean-boiling' .... Sure. > > best regards, > John Thanks. alper > From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 9 17: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 RAA05325 for ; Sun, 9 Dec 2001 17:52:21 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14621; Sun, 9 Dec 2001 15:50:54 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05371; Sun, 9 Dec 2001 14:51:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9MnxvU008512 for ; Sun, 9 Dec 2001 14:49:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB9MnxNZ008511 for mobile-ip-dist; Sun, 9 Dec 2001 14:49:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB9MnuvU008504; Sun, 9 Dec 2001 14:49:56 -0800 (PST) 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 OAA07914; Sun, 9 Dec 2001 14:49:58 -0800 (PST) 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 OAA10662; Sun, 9 Dec 2001 14:49:57 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA17836; Sun, 9 Dec 2001 14:49:47 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fB9MnkX25107; Sun, 9 Dec 2001 14:49:46 -0800 X-mProtect: Sun, 9 Dec 2001 14:49:46 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdilMl7v; Sun, 09 Dec 2001 14:49:45 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id OAA31604; Sun, 9 Dec 2001 14:49:45 -0800 (PST) Message-ID: <3C13EA89.CAF04E3@iprg.nokia.com> Date: Sun, 09 Dec 2001 14:49:45 -0800 From: "Jari T. Malinen" Organization: Nokia X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: Jari Arkko , ipng@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.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 Pekka, The HAO issue you mention can arguably be considered an implementation issue, taken care by the note in the MIPv6 draft. However, it should be mandatory. I'll discuss this below. I'll also cross-post this note to the mobile-ip since you asked it there without anybody answering. Pekka Savola wrote: > > On Fri, 7 Dec 2001, Jari T. Malinen wrote: > > Jari Arkko wrote: > > > > > > > To conclude, dst.hdr is in RFC, > > > > the new proposal an individual draft so I'd say it could be > > > > something to consider for a second generation of Mobile IPv6, > > > > perhaps. > > > > > > Just a clarifying question to make sure I have correctly understood > > > the current situation with the HAO: the DO header is in the basic > > > IPv6 RFCs. However, the format of a specific DO that can be > > > used to carry the Home Address, HAO, is defined in the MIPv6 > > > I-D. I'm asking this because we'd very much like to publish the > > > cellular host draft as an RFC soon, and in order to require the > > > use of the HAO we need not just a resolution to the security > > > worries, but also a reference to some RFC that defines the HAO. > > > Unless I'm mistaken, we currently don't have such an RFC anywhere. > > > Or? > > > > True, though Mobile IPv6 seems to have a process and timetable to > > achieve the same goal and also be in last stages of the process. > > > > HAO was presented to ipng as a mandatory feature before IPv6 was > > finalized and it was designed to fill a missing piece of IPv6 > > functionality to support mobility. At that time it was endorsed > > by the ipng wg and it ended up in the MIPv6 draft. It has been > > pretty stable ever since. The only reason it is not yet in RFC is > > due to non-HAO-format related issues. > > Btw, > > One interesting detail of HAO is that its processing isn't defined > anywhere. > > If you look at MIPv6 draft, the only thing it says about this (AFAICS) is > a note in security considerations that it could be implemented like > swapping the addresses. This issue of HAO processing was supposed to be covered by the note you refer to. On my opinion it is a very important note and should have had more emphasis, but according to some other implementors, discussed (also) in the ETSI Bakeoff 1 year back, there was some issue of read-only buffers in somebody's implementation which kept the formulation as it is now. Or maybe I remember it incorrectly, I did not quite understand motivation for the concern then. There is a subtle transparency issue involved in this note. MIPv6 provides transparency by letting applications see the packet as if coming from the home address. In implementation this is at least considered to mean that when an application reads the IP source address from the socket, it is the home address. This implementation detail is not verbosely explained since it should be obvious to implementors what application transparency (from changes of the CoA) means in this respect. The processing order both sending and receiving need to be such that the transparency is obtained, e.g. for an SCTP INIT packet to have an IPv6 option which can be the home address with exactly the same machinery used with non-HAO packets. Any other protocol when using HAddr for communication need to experience the same degree of transparency. But, when processing other headers beyond HAO in an implementation, transparency should also mean they see the home address in IP source just like in a non-MIPv6 data packet. For example, when constructing an AH, and the note is followed, we observe the swapping happens at HAO processing in the receiving end before AH processing. If the expressed transparency principle would be followed in IPsec integration to the fullest, this would mean the receiving AH processing sees HAddr in IP source. When following in AH ICV computation the rule of having the authenticated data as seen by the receiver after processing, it should take into account this swap (swap the addresses in the ICV computation copy of a to-be sent packet to reflect the same swap at the receiving end's HAO processing). Hence, on my opinion, the note should be elevated to be something mandatory. This would fully implement the transparency principle. It requires no message format or interface changes to IPsec, only for it to follow its existing principle of making authenticated packet look like one seen by the receiver (to reflect the swap of CoA and HAddr in case of HOA option in a to-be sent packet when doing the ICV generation). Some called this note just an implementation detail, to me there is more to it, it gives a processing rule needed for clean implementation of transparency. Now there may be implementations with tricks to avoid this processing when assuming IPsec implementation is untouchable to the latest bit (the swap can't be done until all IPsec implementations agree, since otherwise we'll get wrong MAC value from the other end not doing the swap when this end follows the rule).. Hence, this is more of an issue of harmonizing protocol engineering implementation rules for inter-protocol interworking than an actual security issue. > I have brought this up in mobile-ip@ but there wasn't any response... Hope this gives one answer. I also hope implementors seeing this otherwise would express their concerns now. I'd say it also points there is a siginficant body of experimentation done with current components of MIPv6, HAO included. Changing its format now would mean a long re-rehearsal to get to the same state of experience. Possible, but this should be taken into account when deciding so. > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 9 20:59: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 UAA07127 for ; Sun, 9 Dec 2001 20:59:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA10475; Sun, 9 Dec 2001 17:58:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27742; Sun, 9 Dec 2001 17:58:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA1w3vU009030 for ; Sun, 9 Dec 2001 17:58:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBA1w3Zc009029 for mobile-ip-dist; Sun, 9 Dec 2001 17:58:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA1w0vU009022 for ; Sun, 9 Dec 2001 17:58:00 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27687 for ; Sun, 9 Dec 2001 17:58:02 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03368 for ; Sun, 9 Dec 2001 18:58:01 -0700 (MST) Received: from T23KEMPF (dhcp171.docomo-usa.com [172.21.96.171]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBA1vtJ21284; Sun, 9 Dec 2001 17:57:55 -0800 (PST) Message-ID: <001f01c1811d$dbf955f0$ab6015ac@T23KEMPF> From: "James Kempf" To: , "Charles E. Perkins" Cc: "Erik Nordmark" , "Mobile IP Working Group" References: Subject: Re: [mobile-ip] Re: Binding Update <--> bu3way Date: Sun, 9 Dec 2001 17:56:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, > Do you think the basic 3-way for every update would perform well enough? If the 3 way update needs to be done for every handover, then off the top of my head, I think the answer is no. It would, however, be useful to go through some calculations to check this intuition. > Or do you think there would be a need to establish a binding security > association? > I think this would be preferable for a longer lasting traffic pattern. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 00:49: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 AAA11432 for ; Mon, 10 Dec 2001 00:49:49 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA19349; Sun, 9 Dec 2001 21:48:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA23365; Sun, 9 Dec 2001 21:48:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA5lYvU009483 for ; Sun, 9 Dec 2001 21:47:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBA5lYWg009482 for mobile-ip-dist; Sun, 9 Dec 2001 21:47:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA5lVvU009475; Sun, 9 Dec 2001 21:47:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA02249; Sun, 9 Dec 2001 21:47:34 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA11940; Sun, 9 Dec 2001 22:47:32 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBA5lSa26295; Mon, 10 Dec 2001 07:47:28 +0200 Date: Mon, 10 Dec 2001 07:47:28 +0200 (EET) From: Pekka Savola To: "Jari T. Malinen" cc: Jari Arkko , , Subject: [mobile-ip] Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt In-Reply-To: <3C13EA89.CAF04E3@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: On Sun, 9 Dec 2001, Jari T. Malinen wrote: > Pekka, > > The HAO issue you mention can arguably be considered an implementation > issue, taken care by the note in the MIPv6 draft. However, it should be > mandatory. I'll discuss this below. I'll also cross-post this note to > the mobile-ip since you asked it there without anybody answering. My gripe here is the location: IMO, it must be noted in the *main sections* of the draft how home addresses are supposed to be used (e.g. it substitutes the source address in some implementation-dependent way for example X.x, maintaining connections even though the source address would change). This is taken as granted, like everybody would already know what Home Address is supposed to achieve. Security Considerations seems like a completely wrong place to specify the behaviour. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 03:59: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 DAA29609 for ; Mon, 10 Dec 2001 03:59:03 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26964; Mon, 10 Dec 2001 01:57:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27377; Mon, 10 Dec 2001 00:57:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA8v9vU009712 for ; Mon, 10 Dec 2001 00:57:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBA8v84F009711 for mobile-ip-dist; Mon, 10 Dec 2001 00:57:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBA8v4vU009704 for ; Mon, 10 Dec 2001 00:57:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27314 for ; Mon, 10 Dec 2001 00:56:59 -0800 (PST) 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 BAA22474 for ; Mon, 10 Dec 2001 01:57:34 -0700 (MST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id fBA8tPP27248; Mon, 10 Dec 2001 09:55:25 +0100 (MET) Message-ID: <3C14787C.C5C79043@inrialpes.fr> Date: Mon, 10 Dec 2001 09:55:24 +0100 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: Erik Nordmark , mroe@microsoft.com, tuomaura@microsoft.com Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: <3C12BA10.5030304@piuha.net> Content-Type: multipart/alternative; boundary="------------3138C0D37EA2D6D29D258AD9" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------3138C0D37EA2D6D29D258AD9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Erik Nordmark wrote: > > > By this term I mean X sending a packet to A (with X as the source address) > > which tells A to send packets to B. > > ("Normal reflection" is based on spoofing the source address to cause > > reply packets to go back to the wrong place.) > > > > BTW: bu3way has problem as well - the BUR sent from the CoA causes a BUC > > to be sent to the Home Address. > > > > If sending a packet from a CoA (or HoA) to the CN causes packets to be > > sent to the address that was not in the source field, then this is > > "3rd party reflection". > > Ah, I see. So the problem in BAKE/2 and CAM-DH is more the message to the > Home Address, than the CoA routability test. > > Interestingly, the problem you describe is exactly the same one as we > have been discussing around the HAO and regular traffic! Obviously, > when sending the first packet of BAKE/2 we do not have a BCE ready yet - > so to use the HAO at this time would be illegal according to rules > laid out before. > > I believe also Classic Bake, Busec, and SUCV have a similar issue. Hello, no, SUCV does not have a similar issue.. With SUCV, the packets are exchanged directly between the MN and the CN. This was motivated by 2 things: -we wanted to avoid the problem mentioned above -we wanted to support homeless MN. regards, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------3138C0D37EA2D6D29D258AD9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jari Arkko wrote:
Erik Nordmark wrote:

> By this term I mean X sending a packet to A (with X as the source address)
> which tells A to send packets to B.
> ("Normal reflection" is based on spoofing the source address to cause
> reply packets to go back to the wrong place.)
>
> BTW: bu3way has problem as well - the BUR sent from the CoA causes a BUC
> to be sent to the Home Address.
>
> If sending a packet from a CoA (or HoA) to the CN causes packets to be
> sent to the address that was not in the source field, then this is
> "3rd party reflection".

Ah, I see. So the problem in BAKE/2 and CAM-DH is more the message to the
Home Address, than the CoA routability test.

Interestingly, the problem you describe is exactly the same one as we
have been discussing around the HAO and regular traffic! Obviously,
when sending the first packet of BAKE/2 we do not have a BCE ready yet -
so to use the HAO at this time would be illegal according to rules
laid out before.

I believe also Classic Bake, Busec, and SUCV have a similar issue.

Hello,

no, SUCV does not have a similar issue..
With SUCV, the packets are exchanged directly between the MN and the CN.
This was motivated by 2 things:
-we wanted to avoid the problem mentioned above
-we wanted to support homeless MN.

regards,
Claude. 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------3138C0D37EA2D6D29D258AD9-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 06:44: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 GAA00767 for ; Mon, 10 Dec 2001 06:44:27 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19761; Mon, 10 Dec 2001 04:43:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06824; Mon, 10 Dec 2001 03:43:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBABgQvU010109 for ; Mon, 10 Dec 2001 03:42:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBABgPLc010108 for mobile-ip-dist; Mon, 10 Dec 2001 03:42:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBABgMvU010101 for ; Mon, 10 Dec 2001 03:42:22 -0800 (PST) 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 DAA14216 for ; Mon, 10 Dec 2001 03:42:23 -0800 (PST) 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 DAA15986 for ; Mon, 10 Dec 2001 03:42:22 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 3D4DA6A904; Mon, 10 Dec 2001 13:42:05 +0200 (EET) Message-ID: <3C149F8F.1030203@piuha.net> Date: Mon, 10 Dec 2001 13:42:07 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Claude Castelluccia Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark , mroe@microsoft.com, tuomaura@microsoft.com Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: <3C12BA10.5030304@piuha.net> <3C14787C.C5C79043@inrialpes.fr> 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 Claude Castelluccia wrote: > no, SUCV does not have a similar issue.. > With SUCV, the packets are exchanged directly between the MN and the CN. > This was motivated by 2 things: > -we wanted to avoid the problem mentioned above > -we wanted to support homeless MN. I guess I have to believe what you say, though the -01 version of your draft seems to say under SUCVp2 that "this message is sent to the MN's Home Address and forwarded by the Home Agent to the Mobile current CoA". (Perhaps this has changed in -02 which I hear is around somewhere, can you btw send a link, I didn't seem to get it from the I-D directories.) But let's not argue what the protocols do and don't do. I think we can make a few observations based on the discussion: - If we believe the HOA reflection is an issue, we should avoid HOA reflection even in the weak authentication protocol. This is apparently doable in the way that we discussed with Erik previously, or with the way that you indicate above. - The only way to support homeless MN is to employ the public key hash techniques, HoA return routability isn't applicable. (Or?) - In order to prevent trivial DoS attacks against the public key hash techniques, CAM-DH uses return routability at the bottom and SUCV uses puzzles. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 07:03: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 HAA00930 for ; Mon, 10 Dec 2001 07:03:52 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA06568; Mon, 10 Dec 2001 04:02:46 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09874; Mon, 10 Dec 2001 04:02:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAC1wvU010205 for ; Mon, 10 Dec 2001 04:01:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAC1w0Y010204 for mobile-ip-dist; Mon, 10 Dec 2001 04:01:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAC1tvU010197 for ; Mon, 10 Dec 2001 04:01:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA02319; Mon, 10 Dec 2001 04:01:55 -0800 (PST) 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 FAA11334; Mon, 10 Dec 2001 05:02:30 -0700 (MST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id fBAC0JP03391; Mon, 10 Dec 2001 13:00:19 +0100 (MET) Message-ID: <3C14A3D5.A9E2034E@inrialpes.fr> Date: Mon, 10 Dec 2001 13:00:21 +0100 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: Erik Nordmark , mroe@microsoft.com, tuomaura@microsoft.com, jari.arkko@piuha.net Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: <3C12BA10.5030304@piuha.net> <3C14787C.C5C79043@inrialpes.fr> <3C149F8F.1030203@piuha.net> Content-Type: multipart/alternative; boundary="------------1985D82ADF91331DE8FFA83D" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------1985D82ADF91331DE8FFA83D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, Jari Arkko wrote: > Claude Castelluccia wrote: > > > no, SUCV does not have a similar issue.. > > With SUCV, the packets are exchanged directly between the MN and the CN. > > This was motivated by 2 things: > > -we wanted to avoid the problem mentioned above > > -we wanted to support homeless MN. > > I guess I have to believe what you say, though the -01 version of your > draft seems to say under SUCVp2 that "this message is sent to the MN's > Home Address and forwarded by the Home Agent to the Mobile current > CoA". (Perhaps this has changed in -02 which I hear is around somewhere, > can you btw send a link, I didn't seem to get it from the I-D directories.) > yes, we have missed the ID submission deadline that why the -02 version is not on the i-D directories. The 02 version can be retrieved on my Web page at: http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-02.txt > > But let's not argue what the protocols do and don't do. I think we > can make a few observations based on the discussion: > > - If we believe the HOA reflection is an issue, we should avoid > HOA reflection even in the weak authentication protocol. This > is apparently doable in the way that we discussed with Erik previously, > or with the way that you indicate above. > > - The only way to support homeless MN is to employ the public key > hash techniques, HoA return routability isn't applicable. (Or?) > > - In order to prevent trivial DoS attacks against the public > key hash techniques, CAM-DH uses return routability at the > bottom and SUCV uses puzzles. Privacy might also be a reason why you don't want to use return routability. There is a section in the SUCV draft v2 that tries to tackle this issue... regards, Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------1985D82ADF91331DE8FFA83D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hello,

Jari Arkko wrote:

Claude Castelluccia wrote:

> no, SUCV does not have a similar issue..
> With SUCV, the packets are exchanged directly between the MN and the CN.
> This was motivated by 2 things:
> -we wanted to avoid the problem mentioned above
> -we wanted to support homeless MN.

I guess I have to believe what you say, though the -01 version of your
draft seems to say under SUCVp2 that "this message is sent to the MN's
Home Address and forwarded by the Home Agent to the Mobile current
CoA". (Perhaps this has changed in -02 which I hear is around somewhere,
can you btw send a link, I didn't seem to get it from the I-D directories.)
 

yes, we have missed the ID submission deadline that why the -02 version is not
on the i-D directories. The 02 version can be retrieved on my Web page at:
http://www.inrialpes.fr/planete/people/ccastel/draft-montenegro-sucv-02.txt
 
 
But let's not argue what the protocols do and don't do. I think we
can make a few observations based on the discussion:

- If we believe the HOA reflection is an issue, we should avoid
   HOA reflection even in the weak authentication protocol. This
   is apparently doable in the way that we discussed with Erik previously,
   or with the way that you indicate above.

- The only way to support homeless MN is to employ the public key
   hash techniques, HoA return routability isn't applicable. (Or?)

- In order to prevent trivial DoS attacks against the public
   key hash techniques, CAM-DH uses return routability at the
   bottom and SUCV uses puzzles.

Privacy might also be a reason why you don't want to use return routability. There
is a section in the SUCV draft v2 that tries to tackle this issue...

regards,
Claude. 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------1985D82ADF91331DE8FFA83D-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 07:49:44 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01353 for ; Mon, 10 Dec 2001 07:49:44 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA18003; Mon, 10 Dec 2001 04:48:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA08777; Mon, 10 Dec 2001 04:48:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAClbvU010406 for ; Mon, 10 Dec 2001 04:47:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAClb3h010405 for mobile-ip-dist; Mon, 10 Dec 2001 04:47:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAClXvU010398 for ; Mon, 10 Dec 2001 04:47:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA08720 for ; Mon, 10 Dec 2001 04:47:35 -0800 (PST) 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 FAA09805 for ; Mon, 10 Dec 2001 05:48:10 -0700 (MST) Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id OAA12774 for ; Mon, 10 Dec 2001 14:47:32 +0200 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma012770; Mon, 10 Dec 01 14:47:17 +0200 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 fBAClGf07328 for ; Mon, 10 Dec 2001 14:47:16 +0200 (EET) Received: from localhost (lpetande@localhost) by morphine.tml.hut.fi (8.9.3+Sun/8.9.3) with ESMTP id OAA02784 for ; Mon, 10 Dec 2001 14:47:16 +0200 (EET) X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs Date: Mon, 10 Dec 2001 14:47:16 +0200 (EET) From: Henrik Petander To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Implementation experiences of the authentication suboption 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, At ETSI IPv6 plugtest we successfully tested the authentication data suboption as specified in draft 15. We used HMAC MD5 with 12 bytes of authentication data. The test was run between HUT's MIPL MN and Nokia's HA. We implemented the authentication data suboption in a few working days, and about 180 lines of code, when using existing code (from IPSec AH) for HMAC-MD5. Since the adding and processing of the suboption is done as a part of the MIPv6 implementation it is easy to work with home address options, routing headers etc.. The implementation supports hmac-md5-96 and hmac-sha-1 and it is available from www.mipl.mediapoli.com with source code. If an authentication algorithm and its mode will be specified in the mipv6 draft then the authentication data suboption will IMO be ready for use. Provided that no new weaknesses in HMAC MD5 have been found, RFC 2403, or otherwise RFC 2404 could be applied directly to the authentication data suboption. Finishing this part of the mipv6 spec would IMHO provide an easy way to get working authentication into the implementations, without sacrificing anything. The authentication suboption should also coexist with IPSec processing without any problems, since it is just payload to any IPSec headers. 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 Mon Dec 10 10: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 KAA02902 for ; Mon, 10 Dec 2001 10:07:57 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14334; Mon, 10 Dec 2001 08:06:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28484; Mon, 10 Dec 2001 07:06:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAF5ZvU010684 for ; Mon, 10 Dec 2001 07:05:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAF5ZbK010683 for mobile-ip-dist; Mon, 10 Dec 2001 07:05:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAF5IvU010667 for ; Mon, 10 Dec 2001 07:05:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27069 for ; Mon, 10 Dec 2001 07:05:08 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28756 for ; Mon, 10 Dec 2001 08:05:41 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBAF51B22116 for ; Mon, 10 Dec 2001 09:05:02 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 09:03:50 -0600 Message-ID: From: "Mohamed Khalil" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular -host-02.txt Date: Mon, 10 Dec 2001 09:03:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1818B.E330D4B0" Sender: owner-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_01C1818B.E330D4B0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Jari T. Malinen [mailto:jmalinen@iprg.nokia.com] Sent: Sunday, December 09, 2001 4:50 PM To: Pekka Savola Cc: Jari Arkko; ipng@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt Pekka, The HAO issue you mention can arguably be considered an implementation issue, taken care by the note in the MIPv6 draft. However, it should be mandatory. I'll discuss this below. I'll also cross-post this note to the mobile-ip since you asked it there without anybody answering. Pekka Savola wrote: > > On Fri, 7 Dec 2001, Jari T. Malinen wrote: > > Jari Arkko wrote: > > > > > > > To conclude, dst.hdr is in RFC, > > > > the new proposal an individual draft so I'd say it could be > > > > something to consider for a second generation of Mobile IPv6, > > > > perhaps. > > > > > > Just a clarifying question to make sure I have correctly understood > > > the current situation with the HAO: the DO header is in the basic > > > IPv6 RFCs. However, the format of a specific DO that can be > > > used to carry the Home Address, HAO, is defined in the MIPv6 > > > I-D. I'm asking this because we'd very much like to publish the > > > cellular host draft as an RFC soon, and in order to require the > > > use of the HAO we need not just a resolution to the security > > > worries, but also a reference to some RFC that defines the HAO. > > > Unless I'm mistaken, we currently don't have such an RFC anywhere. > > > Or? > > > > True, though Mobile IPv6 seems to have a process and timetable to > > achieve the same goal and also be in last stages of the process. > > > > HAO was presented to ipng as a mandatory feature before IPv6 was > > finalized and it was designed to fill a missing piece of IPv6 > > functionality to support mobility. At that time it was endorsed > > by the ipng wg and it ended up in the MIPv6 draft. It has been > > pretty stable ever since. The only reason it is not yet in RFC is > > due to non-HAO-format related issues. > > Btw, > > One interesting detail of HAO is that its processing isn't defined > anywhere. > > If you look at MIPv6 draft, the only thing it says about this (AFAICS) is > a note in security considerations that it could be implemented like > swapping the addresses. This issue of HAO processing was supposed to be covered by the note you refer to. On my opinion it is a very important note and should have had more emphasis, but according to some other implementors, discussed (also) in the ETSI Bakeoff 1 year back, there was some issue of read-only buffers in somebody's implementation which kept the formulation as it is now. Or maybe I remember it incorrectly, I did not quite understand motivation for the concern then. There is a subtle transparency issue involved in this note. MIPv6 provides transparency by letting applications see the packet as if coming from the home address. In implementation this is at least considered to mean that when an application reads the IP source address from the socket, it is the home address. This implementation detail is not verbosely explained since it should be obvious to implementors what application transparency (from changes of the CoA) means in this respect. The processing order both sending and receiving need to be such that the transparency is obtained, e.g. for an SCTP INIT packet to have an IPv6 option which can be the home address with exactly the same machinery used with non-HAO packets. Any other protocol when using HAddr for communication need to experience the same degree of transparency. But, when processing other headers beyond HAO in an implementation, transparency should also mean they see the home address in IP source just like in a non-MIPv6 data packet. For example, when constructing an AH, and the note is followed, we observe the swapping happens at HAO processing in the receiving end before AH processing. If the expressed transparency principle would be followed in IPsec integration to the fullest, this would mean the receiving AH processing sees HAddr in IP source. When following in AH ICV computation the rule of having the authenticated data as seen by the receiver after processing, it should take into account this swap (swap the addresses in the ICV computation copy of a to-be sent packet to reflect the same swap at the receiving end's HAO processing). Hence, on my opinion, the note should be elevated to be something mandatory. This would fully implement the transparency principle. It requires no message format or interface changes to IPsec, only for it to follow its existing principle of making authenticated packet look like one seen by the receiver (to reflect the swap of CoA and HAddr in case of HOA option in a to-be sent packet when doing the ICV generation). Some called this note just an implementation detail, to me there is more to it, it gives a processing rule needed for clean implementation of transparency. Now there may be implementations with tricks to avoid this processing when assuming IPsec implementation is untouchable to the latest bit (the swap can't be done until all IPsec implementations agree, since otherwise we'll get wrong MAC value from the other end not doing the swap when this end follows the rule).. Hence, this is more of an issue of harmonizing protocol engineering implementation rules for inter-protocol interworking than an actual security issue. > I have brought this up in mobile-ip@ but there wasn't any response... Hope this gives one answer. I also hope implementors seeing this otherwise would express their concerns now. I'd say it also points there is a siginficant body of experimentation done with current components of MIPv6, HAO included. Changing its format now would mean a long re-rehearsal to get to the same state of experience. Possible, but this should be taken into account when deciding so. > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords BR, -Jari ------_=_NextPart_001_01C1818B.E330D4B0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt

-----Original Message-----
From: Jari T. Malinen [mailto:jmalinen@iprg.nokia.com]
Sent: Sunday, December 09, 2001 4:50 PM
To: Pekka Savola
Cc: Jari Arkko; ipng@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Re: FW: I-D
ACTION:draft-manyfolks-ipv6-cellular-host-02.txt


Pekka,

The HAO issue you mention can arguably be considered an implementation
issue, taken care by the note in the MIPv6 draft. However, it should be
mandatory. I'll discuss this below. I'll also cross-post this note to
the mobile-ip since you asked it there without anybody answering.

Pekka Savola wrote:
>
> On Fri, 7 Dec 2001, Jari T. Malinen wrote:
> > Jari Arkko wrote:
> > >
> > > > To conclude, dst.hdr is in RFC,
> > > > the new proposal an individual draft so I'd say it could be
> > > > something to consider for a second generation of Mobile IPv6,
> > > > perhaps.
> > >
> > > Just a clarifying question to make sure I have correctly understood
> > > the current situation with the HAO: the DO header is in the basic
> > > IPv6 RFCs. However, the format of a specific DO that can be
> > > used to carry the Home Address, HAO, is defined in the MIPv6
> > > I-D. I'm asking this because we'd very much like to publish the
> > > cellular host draft as an RFC soon, and in order to require the
> > > use of the HAO we need not just a resolution to the security
> > > worries, but also a reference to some RFC that defines the HAO.
> > > Unless I'm mistaken, we currently don't have such an RFC anywhere.
> > > Or?
> >
> > True, though Mobile IPv6 seems to have a process and timetable to
> > achieve the same goal and also be in last stages of the process.
> >
> > HAO was presented to ipng as a mandatory feature before IPv6 was
> > finalized and it was designed to fill a missing piece of IPv6
> > functionality to support mobility. At that time it was endorsed
> > by the ipng wg and it ended up in the MIPv6 draft. It has been
> > pretty stable ever since. The only reason it is not yet in RFC is
> > due to non-HAO-format related issues.
>
> Btw,
>
> One interesting detail of HAO is that its processing isn't defined
> anywhere.
>
> If you look at MIPv6 draft, the only thing it says about this (AFAICS) is
> a note in security considerations that it could be implemented like
> swapping the addresses.

This issue of HAO processing was supposed to be covered by the note you
refer to. On my opinion it is a very important note and should have had
more emphasis, but according to some other implementors, discussed (also)
in the ETSI Bakeoff 1 year back, there was some issue of read-only buffers
in somebody's implementation which kept the formulation as it is now. Or
maybe I remember it incorrectly, I did not quite understand motivation for
the concern then.

There is a subtle transparency issue involved in this note. MIPv6 provides
transparency by letting applications see the packet as if coming from the
home address. In implementation this is at least considered to mean that
when an application reads the IP source address from the socket, it is
the home address. This implementation detail is not verbosely explained
since it should be obvious to implementors what application transparency
(from changes of the CoA) means in this respect.

The processing order both sending and receiving need to be such that the
transparency is obtained, e.g. for an SCTP INIT packet to have an IPv6
option which can be the home address with exactly the same machinery
used with non-HAO packets. Any other protocol when using HAddr for
communication need to experience the same degree of transparency.

But, when processing other headers beyond HAO in an implementation,
transparency should also mean they see the home address in IP source just
like in a non-MIPv6 data packet. For example, when constructing an AH,
and the note is followed, we observe the swapping happens at HAO processing
in the receiving end before AH processing. If the expressed transparency
principle would be followed in IPsec integration to the fullest, this would
mean the receiving AH processing sees HAddr in IP source. When following in
AH ICV computation the rule of having the authenticated data as seen by the
receiver after processing, it should take into account this swap (swap the
addresses in the ICV computation copy of a to-be sent packet to reflect the
same swap at the receiving end's HAO processing).

Hence, on my opinion, the note should be elevated to be something mandatory.
This would fully implement the transparency principle. It requires no message
format or interface changes to IPsec, only for it to follow its existing principle
of making authenticated packet look like one seen by the receiver (to reflect the
swap of CoA and HAddr in case of HOA option in a to-be sent packet when doing the
ICV generation).

Some called this note just an implementation detail, to me there is more to it,
it gives a processing rule needed for clean implementation of transparency.
Now there may be implementations with tricks to avoid this processing when
assuming IPsec implementation is untouchable to the latest bit (the swap can't
be done until all IPsec implementations agree, since otherwise we'll get wrong
MAC value from the other end not doing the swap when this end follows the rule)..
Hence, this is more of an issue of harmonizing protocol engineering implementation
rules for inter-protocol interworking than an actual security issue.

> I have brought this up in mobile-ip@ but there wasn't any response...

Hope this gives one answer. I also hope implementors seeing this otherwise would
express their concerns now. I'd say it also points there is a siginficant body
of experimentation done with current components of MIPv6, HAO included. Changing its
format now would mean a long re-rehearsal to get to the same state of experience.
Possible, but this should be taken into account when deciding so.

> --
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

BR,

-Jari

------_=_NextPart_001_01C1818B.E330D4B0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 10:08: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 KAA02919 for ; Mon, 10 Dec 2001 10:08:03 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05520; Mon, 10 Dec 2001 07:06:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28493; Mon, 10 Dec 2001 07:06:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAF5NvU010681 for ; Mon, 10 Dec 2001 07:05:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAF5NZO010680 for mobile-ip-dist; Mon, 10 Dec 2001 07:05:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAF5HvU010666 for ; Mon, 10 Dec 2001 07:05:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27063 for ; Mon, 10 Dec 2001 07:05:07 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28757 for ; Mon, 10 Dec 2001 08:05:41 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBAF51B22118 for ; Mon, 10 Dec 2001 09:05:02 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 09:03:50 -0600 Message-ID: From: "Mohamed Khalil" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular -host-02.txt Date: Mon, 10 Dec 2001 09:03:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1818B.E42FF530" Sender: owner-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_01C1818B.E42FF530 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Jari T. Malinen [mailto:jmalinen@iprg.nokia.com] Sent: Sunday, December 09, 2001 4:50 PM To: Pekka Savola Cc: Jari Arkko; ipng@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt Pekka, The HAO issue you mention can arguably be considered an implementation issue, taken care by the note in the MIPv6 draft. However, it should be mandatory. I'll discuss this below. I'll also cross-post this note to the mobile-ip since you asked it there without anybody answering. Pekka Savola wrote: > > On Fri, 7 Dec 2001, Jari T. Malinen wrote: > > Jari Arkko wrote: > > > > > > > To conclude, dst.hdr is in RFC, > > > > the new proposal an individual draft so I'd say it could be > > > > something to consider for a second generation of Mobile IPv6, > > > > perhaps. > > > > > > Just a clarifying question to make sure I have correctly understood > > > the current situation with the HAO: the DO header is in the basic > > > IPv6 RFCs. However, the format of a specific DO that can be > > > used to carry the Home Address, HAO, is defined in the MIPv6 > > > I-D. I'm asking this because we'd very much like to publish the > > > cellular host draft as an RFC soon, and in order to require the > > > use of the HAO we need not just a resolution to the security > > > worries, but also a reference to some RFC that defines the HAO. > > > Unless I'm mistaken, we currently don't have such an RFC anywhere. > > > Or? > > > > True, though Mobile IPv6 seems to have a process and timetable to > > achieve the same goal and also be in last stages of the process. > > > > HAO was presented to ipng as a mandatory feature before IPv6 was > > finalized and it was designed to fill a missing piece of IPv6 > > functionality to support mobility. At that time it was endorsed > > by the ipng wg and it ended up in the MIPv6 draft. It has been > > pretty stable ever since. The only reason it is not yet in RFC is > > due to non-HAO-format related issues. > > Btw, > > One interesting detail of HAO is that its processing isn't defined > anywhere. > > If you look at MIPv6 draft, the only thing it says about this (AFAICS) is > a note in security considerations that it could be implemented like > swapping the addresses. This issue of HAO processing was supposed to be covered by the note you refer to. On my opinion it is a very important note and should have had more emphasis, but according to some other implementors, discussed (also) in the ETSI Bakeoff 1 year back, there was some issue of read-only buffers in somebody's implementation which kept the formulation as it is now. Or maybe I remember it incorrectly, I did not quite understand motivation for the concern then. There is a subtle transparency issue involved in this note. MIPv6 provides transparency by letting applications see the packet as if coming from the home address. In implementation this is at least considered to mean that when an application reads the IP source address from the socket, it is the home address. This implementation detail is not verbosely explained since it should be obvious to implementors what application transparency (from changes of the CoA) means in this respect. The processing order both sending and receiving need to be such that the transparency is obtained, e.g. for an SCTP INIT packet to have an IPv6 option which can be the home address with exactly the same machinery used with non-HAO packets. Any other protocol when using HAddr for communication need to experience the same degree of transparency. But, when processing other headers beyond HAO in an implementation, transparency should also mean they see the home address in IP source just like in a non-MIPv6 data packet. For example, when constructing an AH, and the note is followed, we observe the swapping happens at HAO processing in the receiving end before AH processing. If the expressed transparency principle would be followed in IPsec integration to the fullest, this would mean the receiving AH processing sees HAddr in IP source. When following in AH ICV computation the rule of having the authenticated data as seen by the receiver after processing, it should take into account this swap (swap the addresses in the ICV computation copy of a to-be sent packet to reflect the same swap at the receiving end's HAO processing). Hence, on my opinion, the note should be elevated to be something mandatory. This would fully implement the transparency principle. It requires no message format or interface changes to IPsec, only for it to follow its existing principle of making authenticated packet look like one seen by the receiver (to reflect the swap of CoA and HAddr in case of HOA option in a to-be sent packet when doing the ICV generation). Some called this note just an implementation detail, to me there is more to it, it gives a processing rule needed for clean implementation of transparency. Now there may be implementations with tricks to avoid this processing when assuming IPsec implementation is untouchable to the latest bit (the swap can't be done until all IPsec implementations agree, since otherwise we'll get wrong MAC value from the other end not doing the swap when this end follows the rule).. Hence, this is more of an issue of harmonizing protocol engineering implementation rules for inter-protocol interworking than an actual security issue. > I have brought this up in mobile-ip@ but there wasn't any response... Hope this gives one answer. I also hope implementors seeing this otherwise would express their concerns now. I'd say it also points there is a siginficant body of experimentation done with current components of MIPv6, HAO included. Changing its format now would mean a long re-rehearsal to get to the same state of experience. Possible, but this should be taken into account when deciding so. > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords BR, -Jari ------_=_NextPart_001_01C1818B.E42FF530 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Re: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt

-----Original Message-----
From: Jari T. Malinen [mailto:jmalinen@iprg.nokia.com]
Sent: Sunday, December 09, 2001 4:50 PM
To: Pekka Savola
Cc: Jari Arkko; ipng@sunroof.eng.sun.com; mobile-ip@sunroof.eng.sun.com
Subject: [mobile-ip] Re: FW: I-D
ACTION:draft-manyfolks-ipv6-cellular-host-02.txt


Pekka,

The HAO issue you mention can arguably be considered an implementation
issue, taken care by the note in the MIPv6 draft. However, it should be
mandatory. I'll discuss this below. I'll also cross-post this note to
the mobile-ip since you asked it there without anybody answering.

Pekka Savola wrote:
>
> On Fri, 7 Dec 2001, Jari T. Malinen wrote:
> > Jari Arkko wrote:
> > >
> > > > To conclude, dst.hdr is in RFC,
> > > > the new proposal an individual draft so I'd say it could be
> > > > something to consider for a second generation of Mobile IPv6,
> > > > perhaps.
> > >
> > > Just a clarifying question to make sure I have correctly understood
> > > the current situation with the HAO: the DO header is in the basic
> > > IPv6 RFCs. However, the format of a specific DO that can be
> > > used to carry the Home Address, HAO, is defined in the MIPv6
> > > I-D. I'm asking this because we'd very much like to publish the
> > > cellular host draft as an RFC soon, and in order to require the
> > > use of the HAO we need not just a resolution to the security
> > > worries, but also a reference to some RFC that defines the HAO.
> > > Unless I'm mistaken, we currently don't have such an RFC anywhere.
> > > Or?
> >
> > True, though Mobile IPv6 seems to have a process and timetable to
> > achieve the same goal and also be in last stages of the process.
> >
> > HAO was presented to ipng as a mandatory feature before IPv6 was
> > finalized and it was designed to fill a missing piece of IPv6
> > functionality to support mobility. At that time it was endorsed
> > by the ipng wg and it ended up in the MIPv6 draft. It has been
> > pretty stable ever since. The only reason it is not yet in RFC is
> > due to non-HAO-format related issues.
>
> Btw,
>
> One interesting detail of HAO is that its processing isn't defined
> anywhere.
>
> If you look at MIPv6 draft, the only thing it says about this (AFAICS) is
> a note in security considerations that it could be implemented like
> swapping the addresses.

This issue of HAO processing was supposed to be covered by the note you
refer to. On my opinion it is a very important note and should have had
more emphasis, but according to some other implementors, discussed (also)
in the ETSI Bakeoff 1 year back, there was some issue of read-only buffers
in somebody's implementation which kept the formulation as it is now. Or
maybe I remember it incorrectly, I did not quite understand motivation for
the concern then.

There is a subtle transparency issue involved in this note. MIPv6 provides
transparency by letting applications see the packet as if coming from the
home address. In implementation this is at least considered to mean that
when an application reads the IP source address from the socket, it is
the home address. This implementation detail is not verbosely explained
since it should be obvious to implementors what application transparency
(from changes of the CoA) means in this respect.

The processing order both sending and receiving need to be such that the
transparency is obtained, e.g. for an SCTP INIT packet to have an IPv6
option which can be the home address with exactly the same machinery
used with non-HAO packets. Any other protocol when using HAddr for
communication need to experience the same degree of transparency.

But, when processing other headers beyond HAO in an implementation,
transparency should also mean they see the home address in IP source just
like in a non-MIPv6 data packet. For example, when constructing an AH,
and the note is followed, we observe the swapping happens at HAO processing
in the receiving end before AH processing. If the expressed transparency
principle would be followed in IPsec integration to the fullest, this would
mean the receiving AH processing sees HAddr in IP source. When following in
AH ICV computation the rule of having the authenticated data as seen by the
receiver after processing, it should take into account this swap (swap the
addresses in the ICV computation copy of a to-be sent packet to reflect the
same swap at the receiving end's HAO processing).

Hence, on my opinion, the note should be elevated to be something mandatory.
This would fully implement the transparency principle. It requires no message
format or interface changes to IPsec, only for it to follow its existing principle
of making authenticated packet look like one seen by the receiver (to reflect the
swap of CoA and HAddr in case of HOA option in a to-be sent packet when doing the
ICV generation).

Some called this note just an implementation detail, to me there is more to it,
it gives a processing rule needed for clean implementation of transparency.
Now there may be implementations with tricks to avoid this processing when
assuming IPsec implementation is untouchable to the latest bit (the swap can't
be done until all IPsec implementations agree, since otherwise we'll get wrong
MAC value from the other end not doing the swap when this end follows the rule)..
Hence, this is more of an issue of harmonizing protocol engineering implementation
rules for inter-protocol interworking than an actual security issue.

> I have brought this up in mobile-ip@ but there wasn't any response...

Hope this gives one answer. I also hope implementors seeing this otherwise would
express their concerns now. I'd say it also points there is a siginficant body
of experimentation done with current components of MIPv6, HAO included. Changing its
format now would mean a long re-rehearsal to get to the same state of experience.
Possible, but this should be taken into account when deciding so.

> --
> Pekka Savola                 "Tell me of difficulties surmounted,
> Netcore Oy                   not those you stumble over and fall"
> Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

BR,

-Jari

------_=_NextPart_001_01C1818B.E42FF530-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 10:19: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 KAA03131 for ; Mon, 10 Dec 2001 10:19:11 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA10650; Mon, 10 Dec 2001 07:18:02 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00487; Mon, 10 Dec 2001 07:17:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAFH6vU010898 for ; Mon, 10 Dec 2001 07:17:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAFH6lu010897 for mobile-ip-dist; Mon, 10 Dec 2001 07:17:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAFH2vU010890 for ; Mon, 10 Dec 2001 07:17:03 -0800 (PST) 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 fBAFGwq07721; Mon, 10 Dec 2001 16:16:58 +0100 (MET) Date: Mon, 10 Dec 2001 16:15:18 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Risks of not verifying the care-of address To: Claude Castelluccia Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark , mroe@microsoft.com, tuomaura@microsoft.com In-Reply-To: "Your message with ID" <3C14787C.C5C79043@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: > -we wanted to support homeless MN. Just a note that as far as I know "homeless MN" isn't a requirement the IETF work, at least I've never seen a discussion whether or not it should be a requirement. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 11:40:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05000 for ; Mon, 10 Dec 2001 11:40:17 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01572; Mon, 10 Dec 2001 09:38:59 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21320; Mon, 10 Dec 2001 08:39:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAGcavU011075 for ; Mon, 10 Dec 2001 08:38:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAGcZEm011074 for mobile-ip-dist; Mon, 10 Dec 2001 08:38:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAGcWvU011067 for ; Mon, 10 Dec 2001 08:38:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21207 for ; Mon, 10 Dec 2001 08:38:33 -0800 (PST) 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 JAA25025 for ; Mon, 10 Dec 2001 09:39:10 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA00293 for ; Mon, 10 Dec 2001 09:38:32 -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 JAA26978 for ; Mon, 10 Dec 2001 09:38:31 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Mon, 10 Dec 2001 09:38:29 -0700 Received: from zorglub.crm.mot.com (zantafio.crm.mot.com [140.101.173.9]) by thorgal.crm.mot.com (Postfix) with ESMTP id 77F7E2EC83; Mon, 10 Dec 2001 17:37:35 +0100 (CET) Received: from test9.crm.mot.com.crm.mot.com ([163.14.20.33]) by zorglub.crm.mot.com (8.8.8/8.8.8) with ESMTP id RAA28379; Mon, 10 Dec 2001 17:38:23 +0100 (MET) To: Erik.Nordmark@eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: From: Alexandru Petrescu Date: 10 Dec 2001 14:15:38 +0100 In-Reply-To: Message-Id: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 20 Sender: owner-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: > So I think the conservative thing to do if there is a need to check > with the CoA as well as the HoA during BUs is to send more packets. > For instance, the MN could send packet1 both with CoA as the source > (causing a "response" to be sent to the CoA) and with HoA as the > source (reverse-tunneled through the HA). Then when the has the > information from both "responses" it can do the actual BU. Something like the two simultaneous messages below? MN --------> CN --------> HA | <------------------------| MN CN <-------- HA | |--------------------------> Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 11:40: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 LAA05029 for ; Mon, 10 Dec 2001 11:40:40 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA20748; Mon, 10 Dec 2001 08:38:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21218; Mon, 10 Dec 2001 08:38:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAGbtvU011058 for ; Mon, 10 Dec 2001 08:37:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAGbtp4011057 for mobile-ip-dist; Mon, 10 Dec 2001 08:37:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAGbqvU011050 for ; Mon, 10 Dec 2001 08:37:52 -0800 (PST) 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 IAA08253 for ; Mon, 10 Dec 2001 08:37:53 -0800 (PST) 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 IAA19103 for ; Mon, 10 Dec 2001 08:37:52 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id JAA11607 for ; Mon, 10 Dec 2001 09:37:51 -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 JAA24822 for ; Mon, 10 Dec 2001 09:37:50 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Mon, 10 Dec 2001 10:37:44 -0600 Received: from zorglub.crm.mot.com (zantafio.crm.mot.com [140.101.173.9]) by thorgal.crm.mot.com (Postfix) with ESMTP id E8C9E2EC83; Mon, 10 Dec 2001 17:36:53 +0100 (CET) Received: from test9.crm.mot.com.crm.mot.com ([163.14.20.33]) by zorglub.crm.mot.com (8.8.8/8.8.8) with ESMTP id RAA27259; Mon, 10 Dec 2001 17:37:29 +0100 (MET) To: greg.daley@eng.monash.edu.au Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-ietf-mobileip-hmipv6-05.txt References: <200111291105.GAA20298@ietf.org> <3C06B125.42154E36@eng.monash.edu.au> From: Alexandru Petrescu Date: 09 Dec 2001 00:24:40 +0100 In-Reply-To: <3C06B125.42154E36@eng.monash.edu.au> Message-Id: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Lines: 75 Sender: owner-mobile-ip@sunroof.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 Greg, I'm catching up with old mails. Greg Daley writes: > I'm not sure if this is what we want to do > (replicate router function), but it is an > easy thing to do, and the trust relationships > between adjacent nodes on a link is likely > to be easy to manage (since there is a good > chance that SA exist between Routers on the > same link). > > Router Renumbering sounds OK, but who do > you allow to send the MAP propagations? Auth/authorization is something to be considered in HMIPv6, but I was not referring to this. In my oppinion, the section 5.2.1 of HMIPv6 draft is insufficient. It shows how to match a prefix and update with a MAP option. This deviates from "genuine" RR where you match a prefix and update with another prefix. From this, other things become difficult to do, deleting MAP options for example. I suppose that RR is normally used like this: you administer a site and decide to replace all 3ffe:ffff::/64 with 3ffe:fffe::/64 on your entire site. I comes down to put 3ffe:ffff::/64 in your match prefixes and 3ffe::fffe::/64 in use prefixes of all CHANGE messages. In HMIPv6 as I understand it, you would need to specify all the /128 addresses of all advertising interfaces of all AR's as use-prefixes and add the MAP option. It's so un-natural. > * MAPS? >  > If so, then dependent on the number of MAPs, > the key distribution mechanisms are more > complex (since it is unlikely that every AR will > have an SA for every MAP).  > > * an Central NMS? > > If you allow just a small set of trusted servers, > to send the RR Map options, then you have a > situation where the NMS will have to collect > information about the MAPs before distributing it > on the to AR's. Among the existing protocols that could be used for this I would rather think of DHCPv6. In DHCPv6 a Relay could be located with the AR and the DHCPv6 Server would pass the address of the MAP (as it passes the address of a DNS server.) > Maybe it is appropriate to develop separate > guidance for dynamic map option propagation > and management? I guess it's too early to discuss MAP (or LMM agent for that matter) discovery. It's not even known for sure what is wanted from a local mobility management scheme. MAP discovery is already in the solution space. > > Also, I still think HMIPv6 should specify a way to delete MAP-options > > from an advertising interface.(RR means to do that is to put 0 in > > use-prefix of a CHANGE). > > It is easy to delete map options by setting the > Preference value to 255 (do not use). Any means to delete the MAP option should go hand in hand with how genuine RR deletes prefixes from the interfaces. I think this is not the case now. This is why I raised this issue. When you delete you need to first match it with something. And that something can not be a MAP option but should be a prefix. Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 12:17: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 MAA05930 for ; Mon, 10 Dec 2001 12:17:32 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04731; Mon, 10 Dec 2001 10:16:09 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29725; Mon, 10 Dec 2001 09:16:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAHFXvU011409 for ; Mon, 10 Dec 2001 09:15:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAHFWUs011408 for mobile-ip-dist; Mon, 10 Dec 2001 09:15:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAHFSvU011401 for ; Mon, 10 Dec 2001 09:15:29 -0800 (PST) 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 fBAHFNq20365; Mon, 10 Dec 2001 18:15:23 +0100 (MET) Date: Mon, 10 Dec 2001 18:13:41 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Risks of not verifying the care-of address To: Alexandru Petrescu Cc: Erik.Nordmark@eng.sun.com, 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: > Erik Nordmark writes: > > So I think the conservative thing to do if there is a need to check > > with the CoA as well as the HoA during BUs is to send more packets. > > For instance, the MN could send packet1 both with CoA as the source > > (causing a "response" to be sent to the CoA) and with HoA as the > > source (reverse-tunneled through the HA). Then when the has the > > information from both "responses" it can do the actual BU. > > Something like the two simultaneous messages below? > > MN --------> CN --------> HA > | > <------------------------| > > > MN CN <-------- HA > | > |--------------------------> No - the symmetry is different. One exchange would be MN(CoA) -> CN MN(CoA) <- CN and the other would be MN(HoA) -> HA -> CN (reverse-tunneled through HA) MN(HoA) <- HA <- CN Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 12:38: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 MAA06430 for ; Mon, 10 Dec 2001 12:38:15 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22948; Mon, 10 Dec 2001 10:36:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04923; Mon, 10 Dec 2001 09:37:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAHaFvU011564 for ; Mon, 10 Dec 2001 09:36:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAHaFJR011563 for mobile-ip-dist; Mon, 10 Dec 2001 09:36:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAHaCvU011556 for ; Mon, 10 Dec 2001 09:36:12 -0800 (PST) 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 JAA04599 for ; Mon, 10 Dec 2001 09:36:09 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06235 for ; Mon, 10 Dec 2001 09:36:08 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBAHa5B19257; Mon, 10 Dec 2001 11:36:05 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 11:34:53 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011B8505@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 11:35:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C181A1.004CDE80" Sender: owner-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_01C181A1.004CDE80 Content-Type: text/plain; charset="iso-8859-1" GM] Comments in-line below. > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Saturday, December 08, 2001 5:46 PM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > Glenn, > > > That said - what is the use of sending the extra addresses > in each packet at > > all since per-address authorization state must be kept on the tunnel > > endpoints in order to protect against the reflector attacks? > > Are you suggesting sending packets with just two IP addresses > and having the > endpoint replace the source IP and destination IP based on > what it has in > the binding cache entry? GM] Yes > > I think such an approach has some robustness problems. GM] I think it is no less robust than what would have to occur even if we did send the extra address - but I am certainly open to an attempt to find some sort of stateless argument for why the extra address needs to be there. I just don't see it if the reflector attack is mandated to be prevented. > - What happens if the MN moves away and other MN appears and > acquires the same > CoA? GM]The new mobile would have a new home address which could be used to distinguish the two. The home address would have had to be conveyed via some signaling i.e. something like a binding update and the cache maintained. This signaling needs to be authorized and authenticated in order to protect against a mobile binding another mobile's home address to a particular COA. If there is a stale binding cache entry for the CoA->old HoA > in some CN there will be TCP checksum failures should the > new MN/HoA try to > communicate with it since it will use the old CoA->HoA mapping. GM]If there is no cache entry that is valid the packets should be dropped and perhaps an ICMP error message sent to notify the sender (MN's COA) that they need to refresh. > - What if a MN wants to have one session (e.g. TCP or VoIP) > with a CN using route optimization and another session > (e.g. DNS udp > lookup) > not using route optimization. That CN would not be able to > tell whether > to apply the address replacement - the source address > would be the CoA > in both cases. GM] Why would the mobile not want to use route optimization? I don't see why a mobile would not want to use route optimization with every node if it were available (ubiquitous). > > And I can't even imagine what the security issues would be in > such a case. GM] As far as I can tell, the security issues are exactly the same irrespective of whether the extra address is sent. The statement doesn't detail any specific issue - by all means, please do. > So I think having all packets contain all the necessary IP > addresses makes > sense. GM] I have to say I am not that optimistic of such a thing gaining wide acceptance any time soon; however, the protections necessary against reflector attack with route optimized MIP makes sending the extra address, useless. If you protect against the reflector, then you have conveyed the addresses to each side with credentials for authentication and authorization and the CN is already having to check against DDoS based upon some table. This information has to be stored in a table unless you want to have to authenticate and authorize on each bearer packet. GM] I think we have already seen some discussion on the IPv6 WG list about the cache etc.. It does seem that people are beginning to see the point - but I must say this would be a serious leep of faith. Just keep asking yourself what will have to be done with the packet when there is no cache entry - i.e. even if the home address is conveyed in the packet. GM] Earlier I tried to make the point that if MIP is required to deal with the reflector attack, then you might as well require that the CN's do route optimization because the same state will have to be kept on the CN - might as well go for the gusto. The people making micro cameras and toasters with IP stacks started freaking out on this though. They want the small cheap footprint. GM] This frustrated me to no end and so now I think we might need to start looking at having the routers close to the CN's do some of these functions but gee - I can only imagine the reaction I'll get from that suggestion from the end to enders. This isn't exactly a new idea, though. Even the first renditions of MIPv6 had such thoughts in it. We also have GES, TUBA, 8+8, LAR, MBG, etc.. that explored this concept, although many of these solutions had the tunneling overhead as well. Putting the cache on the CN was easier from a signaling semantics point of view because it basically results in a point to point problem set as apposed to a subnet to subnet problem set. This is why I think the placement of the route optimization functions on the routers close to the CN's was discounted in favor of the easier problem set. GM] Route optimized MIPv6 is turning into a bunch of catch-22's (footprint vs security). I think route optimization should be ubiquitous irrespective of the choice of where to put the cache entries. Moore's law should eventually handle the footprint and economics of microcameras and toasters etc.. Each time the requirements of nodes for route optimization is relaxed the specification is complicated and the code size on the mobile goes up because it has to deal with backoff procedures. GM]I hum for a MUST on the CN binding update requirement or start having the WG look at mandating the cache on the routers close to the CNs. I don't think the footprint and cost people can start complaining about having a MUST for routers. Whatever the choice I have a strong belief that route optimization should be ubiquitous, deployable and backed up by MUSTs in the specs. GM]One thing is for sure, though. The layer-5 signaling-based node mobility solutions gain in credibility each day the MIP spec is debated over and incomplete. It is hard to tell who on the receiver list is FUDing and who is not. I certainly don't believe you (Erik) are one of the FUD people. GM]I mentioned a little timer earlier on the list related to competition from these layer-5 solutions. The timer has expired for some operators. BTW, last time I checked on these layer-5 signaled solutions, they don't need tunnel overhead either. But see - they are layer-5 signaling and it's O.K. to make a "pseudo-connection" i.e. install and maintain some state. It is the same thing - these solutions use IP stack mobility shims and swap the addresses at the endpoints. Regards, Glenn ------_=_NextPart_001_01C181A1.004CDE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

GM] Comments in-line below.

> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.c= om]
> Sent: Saturday, December 08, 2001 5:46 = PM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Routing header Vs = tunneling
>
>
> Glenn,
>
> > That said - what is the use of sending the = extra addresses
> in each packet at
> > all since per-address authorization state = must be kept on the tunnel
> > endpoints in order to protect against the = reflector attacks?
>
> Are you suggesting sending packets with just = two IP addresses
> and having the
> endpoint replace the source IP and destination = IP based on
> what it has in
> the binding cache entry?

GM] Yes

>
> I think such an approach has some robustness = problems.

GM] I think it is no less robust than what would have = to occur even if we did send the extra address - but I am certainly = open to an attempt to find some sort of stateless argument for why the = extra address needs to be there. I just don't see it if the reflector = attack is mandated to be prevented.

>  - What happens if the MN moves away and = other MN appears and
> acquires the same
>    CoA?

GM]The new mobile would have a new home address which = could be used to distinguish the two. The home address would have had = to be conveyed via some signaling i.e. something like a binding update = and the cache maintained. This signaling needs to be authorized and = authenticated in order to protect against a mobile binding another = mobile's home address to a particular COA.

 If there is a stale binding cache entry  = for the CoA->old HoA
>    in some CN there will be TCP = checksum failures should the
> new MN/HoA try to
>    communicate with it since it = will use the old CoA->HoA mapping.

GM]If there is no cache entry that is valid the = packets should be dropped and perhaps an ICMP error message sent to = notify the sender (MN's COA) that they need to refresh.

>  - What if a MN wants to have one session = (e.g. TCP or VoIP)
>    with a CN using route = optimization and another session 
> (e.g. DNS udp
> lookup)
>    not using route optimization. = That CN would not be able to
> tell whether
>    to apply the address = replacement - the source address
> would be the CoA
>    in both cases.

GM] Why would the mobile not want to use route = optimization? I don't see why a mobile would not want to use route = optimization with every node if it were available (ubiquitous). =

>
> And I can't even imagine what the security = issues would be in
> such a case.

GM] As far as I can tell, the security issues are = exactly the same irrespective of whether the extra address is sent. The = statement doesn't detail any specific issue - by all means, please = do.

> So I think having all packets contain all the = necessary IP
> addresses makes
> sense.

GM] I have to say I am not that optimistic of such a = thing gaining wide acceptance any time soon; however, the protections = necessary against reflector attack with route optimized MIP makes = sending the extra address, useless. If you protect against the = reflector, then you have conveyed the addresses to each side with = credentials for authentication and authorization and the CN is already = having to check against DDoS based upon some table. This information = has to be stored in a table unless you want to have to authenticate and = authorize on each bearer packet.

GM] I think we have already seen some discussion on = the IPv6 WG list about the cache etc.. It does seem that people are = beginning to see the point - but I must say this would be a serious = leep of faith. Just keep asking yourself what will have to be done with = the packet when there is no cache entry - i.e. even if the home address = is conveyed in the packet.

GM] Earlier I tried to make the point that if MIP is = required to deal with the reflector attack, then you might as well = require that the CN's do route optimization because the same state will = have to be kept on the CN - might as well go for the gusto. The people = making micro cameras and toasters with IP stacks started freaking out = on this though. They want the small cheap footprint.

GM] This frustrated me to no end and so now I think = we might need to start looking at having the routers close to the CN's = do some of these functions but gee - I can only imagine the reaction = I'll get from that suggestion from the end to enders. This isn't = exactly a new idea, though. Even the first renditions of MIPv6 had such = thoughts in it. We also have GES, TUBA, 8+8, LAR, MBG, etc.. that = explored this concept, although many of these solutions had the = tunneling overhead as well. Putting the cache on the CN was easier from = a signaling semantics point of view because it basically results in a = point to point problem set as apposed to a subnet to subnet problem = set. This is why I think the placement of the route optimization = functions on the routers close to the CN's was discounted in favor of = the easier problem set.

GM] Route optimized MIPv6 is turning into a bunch of = catch-22's (footprint vs security). I think route optimization should = be ubiquitous irrespective of the choice of where to put the cache = entries. Moore's law should eventually handle the footprint and = economics of microcameras and toasters etc.. Each time the requirements = of nodes for route optimization is relaxed the specification is = complicated and the code size on the mobile goes up because it has to = deal with backoff procedures.

GM]I hum for a MUST on the CN binding update = requirement or start having the WG look at mandating the cache on the = routers close to the CNs. I don't think the footprint and cost people = can start complaining about having a MUST for routers. Whatever the = choice I have a strong belief that route optimization should be = ubiquitous, deployable and backed up by MUSTs in the specs.

GM]One thing is for sure, though. The layer-5 = signaling-based node mobility solutions gain in credibility each day = the MIP spec is debated over and incomplete. It is hard to tell who on = the receiver list is FUDing and who is not. I certainly don't believe = you (Erik) are one of the FUD people.

GM]I mentioned a little timer earlier on the list = related to competition from these layer-5 solutions. The timer has = expired for some operators. BTW, last time I checked on these layer-5 = signaled solutions, they don't need tunnel overhead either. But see - = they are layer-5 signaling and it's O.K. to make a = "pseudo-connection" i.e. install and maintain some state. It = is the same thing -  these solutions use IP stack mobility shims = and swap the addresses at the endpoints.

Regards,

Glenn



------_=_NextPart_001_01C181A1.004CDE80-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 13:09: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 NAA07204 for ; Mon, 10 Dec 2001 13:08:59 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19515; Mon, 10 Dec 2001 11:07:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03888; Mon, 10 Dec 2001 10:07:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAI6cvU011792 for ; Mon, 10 Dec 2001 10:06:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAI6cau011791 for mobile-ip-dist; Mon, 10 Dec 2001 10:06:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAI6ZvU011781 for ; Mon, 10 Dec 2001 10:06:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02824 for ; Mon, 10 Dec 2001 10:06:37 -0800 (PST) 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 LAA11050 for ; Mon, 10 Dec 2001 11:07:14 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id KAA21351 for ; Mon, 10 Dec 2001 10:57:01 -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 LAA14423 for ; Mon, 10 Dec 2001 11:06:35 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r3.mot.com with ESMTP; Mon, 10 Dec 2001 12:05:37 -0600 Received: from zorglub.crm.mot.com (zantafio.crm.mot.com [140.101.173.9]) by thorgal.crm.mot.com (Postfix) with ESMTP id E5A312EC83; Mon, 10 Dec 2001 19:01:17 +0100 (CET) Received: from test9.crm.mot.com.crm.mot.com ([163.14.20.36]) by zorglub.crm.mot.com (8.8.8/8.8.8) with ESMTP id TAA28528; Mon, 10 Dec 2001 19:02:03 +0100 (MET) To: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: From: Alexandru Petrescu Date: 10 Dec 2001 17:58:03 +0100 In-Reply-To: Message-Id: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 20 Sender: owner-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 exchange would be > MN(CoA) -> CN > MN(CoA) <- CN > and the other would be > > MN(HoA) -> HA -> CN (reverse-tunneled through HA) > MN(HoA) <- HA <- CN What would stop a malicious HA to flood CN with MN(HoA)->HA->CN messages having the HoA of an attacked HA? I would prefer simpler schemes with a lesser number of messages, this being presumably easier to secure. I liked a lot HACOOKIES where the exchange was only: MN -> CN -> HA CN <- HA Alex From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 13:10: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 NAA07261 for ; Mon, 10 Dec 2001 13:10:43 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21632; Mon, 10 Dec 2001 11:09:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04571; Mon, 10 Dec 2001 10:09:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAI8uvU011848 for ; Mon, 10 Dec 2001 10:08:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAI8uMV011847 for mobile-ip-dist; Mon, 10 Dec 2001 10:08:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAI8qvU011840 for ; Mon, 10 Dec 2001 10:08:53 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04385 for ; Mon, 10 Dec 2001 10:08:50 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20710 for ; Mon, 10 Dec 2001 11:08:31 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA23808; Mon, 10 Dec 2001 10:08:48 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBAI8mv07023; Mon, 10 Dec 2001 10:08:48 -0800 X-mProtect: Mon, 10 Dec 2001 10:08:48 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin16.iprg.nokia.com (205.226.20.246, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdpzizPD; Mon, 10 Dec 2001 10:08:44 PST Message-ID: <3C14F9C1.2FD6A55E@iprg.nokia.com> Date: Mon, 10 Dec 2001 10:06:57 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Morrow CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling References: <933FADF5E673D411B8A30002A5608A0E011B8505@zrc2c012.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 Glenn Morrow wrote: > > > That said - what is the use of sending the extra addresses > > in each packet at > > > all since per-address authorization state must be kept on the > tunnel > > > endpoints in order to protect against the reflector attacks? I didn't think that this conclusion had been drawn. The reflector attack under discussion doesn't seem to be a horrible problem to me, and it's no worse than what can be done today wthout any Home Address destination option. However, I still can agree that keeping extra state as you mention will enable protection against the problem anyway. I just didn't think that it had been agreed as a mandated part of a solution. > > Are you suggesting sending packets with just two IP addresses > > and having the > > endpoint replace the source IP and destination IP based on > > what it has in > > the binding cache entry? > > GM] Yes I don't think this is a good idea, unless there is some extra information in the two-address header that says it is O.K. to do the replacement. Currently, it is possible for a mobile node to use both its home address and its care-of address for communications with correspondent nodes. This might well be useful for two different data applications between the same two nodes. I think we should try to maintain the usefulness of the care-of address as a legitimate IPv6 address for applications that, for whatever reason, do not need mobility support. Maybe SMS would be like that, if every "session" only lasted for a single packet. But presumably "more" applications would use the home address in preference to the care-of address as the IP(v6) address identifying the application endpoint. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 13:17: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 NAA07498 for ; Mon, 10 Dec 2001 13:17:20 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27754; Mon, 10 Dec 2001 11:15:55 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06500; Mon, 10 Dec 2001 10:16:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIFAvU012021 for ; Mon, 10 Dec 2001 10:15:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAIFA46012020 for mobile-ip-dist; Mon, 10 Dec 2001 10:15:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIF7vU012008 for ; Mon, 10 Dec 2001 10:15:07 -0800 (PST) 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 KAA04897 for ; Mon, 10 Dec 2001 10:15:09 -0800 (PST) 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 KAA13445 for ; Mon, 10 Dec 2001 10:15:09 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA24494; Mon, 10 Dec 2001 10:15:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBAIF8i14485; Mon, 10 Dec 2001 10:15:08 -0800 X-mProtect: Mon, 10 Dec 2001 10:15:08 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin16.iprg.nokia.com (205.226.20.246, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdN4ai9n; Mon, 10 Dec 2001 10:15:06 PST Message-ID: <3C14FB32.493436E1@iprg.nokia.com> Date: Mon, 10 Dec 2001 10:13:06 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: Binding Update <--> bu3way 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: > Do you think the basic 3-way for every update would perform well enough? > Or do you think there would be a need to establish a binding security > association? I think that in many situations it would be better to have a binding security association established. > > This would work as follows: > > > > - If the mobile node has a security assocation with the > > correspondent node, it sends an authenticated Binding Update > > By this do you mean IPsec SA or something more vague? I meant "binding security association", analogous to "mobility security association" in IPv4. > > - Otherwise, if a key establishment protocol exists, the mobile > > node initiates key establishment > > - Otherwise, the mobile node carries out the BU3WAY operations > > I think this runs into "negotiate down" security threats. (I think it > is draft-draft-aura-mipv6-bu-attacks-00.txt that talks about this.) > For example, if a CN wants to use a high security as possible > how can it prevent an attacker from forcing the use of the weak BU3WAY? If the correspondent node wants higher security, it doesn't have to respond to bu3way protocol efforts, right? If you meant something else, then maybe I have to look at the draft you cite. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 13:20: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 NAA07669 for ; Mon, 10 Dec 2001 13:20:12 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14120; Mon, 10 Dec 2001 10:18:51 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07086; Mon, 10 Dec 2001 10:18:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIHkvU012080 for ; Mon, 10 Dec 2001 10:17:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAIHkp7012079 for mobile-ip-dist; Mon, 10 Dec 2001 10:17:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIHhvU012072 for ; Mon, 10 Dec 2001 10:17:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02600 for ; Mon, 10 Dec 2001 10:17:46 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04827 for ; Mon, 10 Dec 2001 11:17:44 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBAIHhV11440; Mon, 10 Dec 2001 10:17:43 -0800 (PST) Received: from [10.21.58.157] (sj-dial-6-9.cisco.com [10.21.58.10]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACC03814; Mon, 10 Dec 2001 10:17:30 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <933FADF5E673D411B8A30002A5608A0E011B8505@zrc2c012.us.nortel.com> References: <933FADF5E673D411B8A30002A5608A0E011B8505@zrc2c012.us.nortel.com> Date: Mon, 10 Dec 2001 10:18:12 -0800 To: mobile-ip@sunroof.eng.sun.com From: Steve Deering Subject: RE: [mobile-ip] Routing header Vs tunneling Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com 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: At 11:35 AM -0600 12/10/01, Glenn Morrow wrote: >GM] Why would the mobile not want to use route optimization? For privacy reasons, the owner of the mobile device may not wish to reveal it's current location in the network to its correspondent(s). Steve From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 13:28: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 NAA07936 for ; Mon, 10 Dec 2001 13:28:51 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19194; Mon, 10 Dec 2001 10:27:21 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09403; Mon, 10 Dec 2001 10:27:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIQevU012308 for ; Mon, 10 Dec 2001 10:26:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAIQeFf012307 for mobile-ip-dist; Mon, 10 Dec 2001 10:26:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIQbvU012300 for ; Mon, 10 Dec 2001 10:26:37 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07425; Mon, 10 Dec 2001 10:26:39 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09979; Mon, 10 Dec 2001 11:26:39 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA25234; Mon, 10 Dec 2001 10:26:38 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBAIQch30581; Mon, 10 Dec 2001 10:26:38 -0800 X-mProtect: Mon, 10 Dec 2001 10:26:38 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin16.iprg.nokia.com (205.226.20.246, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdHB3Pmu; Mon, 10 Dec 2001 10:26:36 PST Message-ID: <3C14FDCA.4D3CC043@iprg.nokia.com> Date: Mon, 10 Dec 2001 10:24:11 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Additional comments on draft-arkko-mipv6-bu-security-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, Erik Nordmark wrote: > > Hello Jari, > > > > Jari Arkko wrote: > ...... > > > I agree! I have recently come to the conclusion myself that > > > we should not allow unsecure RO at all, and as a minimum should > > > require one of the weak auth protocols. > > > > I was really surprised to read this. Unsecure route optimization has > > _never_ been allowable in the Mobile IP working group, neither for > > IPv4 or for IPv6. When has there been discussion otherwise? > > > > Or am I misinterpreting something? > > Charlie, you apparently didn't read the subject line of the message. > This discuss thread is about the text in draft-arkko-mipv6-bu-security-00.txt. I got that part all right, but I still am very curious about why there might have been discussion about allowing unsecured Binding Updates. They are known to be bad, and they are not and have not been part of the Mobile IP protocol for reasons which have been well known for many years. Thus, when I read that people have now drawn the conclusion that unsecured Binding Updates are bad, I begin to wonder how the discussion was intended to be related to Mobile IPv6. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 13:48: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 NAA08499 for ; Mon, 10 Dec 2001 13:48:25 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29937; Mon, 10 Dec 2001 10:47:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14675; Mon, 10 Dec 2001 10:47:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIk9vU012520 for ; Mon, 10 Dec 2001 10:46:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAIk9iE012519 for mobile-ip-dist; Mon, 10 Dec 2001 10:46:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAIk6vU012512 for ; Mon, 10 Dec 2001 10:46:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25481 for ; Mon, 10 Dec 2001 10:46:08 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19843 for ; Mon, 10 Dec 2001 11:46:07 -0700 (MST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 8B5866A905; Mon, 10 Dec 2001 20:45:51 +0200 (EET) Message-ID: <3C14F65C.6020901@piuha.net> Date: Mon, 10 Dec 2001 19:52:28 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Claude Castelluccia Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark , mroe@microsoft.com, tuomaura@microsoft.com Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: <3C12BA10.5030304@piuha.net> <3C14787C.C5C79043@inrialpes.fr> <3C149F8F.1030203@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Claude, We discussed earlier about why there's return routability or not at the bottom of these public key hash techniques. Then I said the following: > - In order to prevent trivial DoS attacks against the public > key hash techniques, CAM-DH uses return routability at the > bottom and SUCV uses puzzles. It seems that I missed an important point though. What CAM and SUCV are able to do is to conclusively prove that the sending node really came up with the particular IPv6 address in question. However, it is still possible for attackers to pick a network X, generate their own key and address, and claim to be mobile nodes from X. This could potentially be used for something bad, such as initiating a session from a CoA and then deleting the BCE and bombing X with traffic that continues to flow from the CN to the MN. The prevention of this attack is another reason why CAM-DH runs BAKE/2 at the bottom: the return routability tests ensure that the attackers can't claim to be from X if they really aren't from there (or on the path to it). Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 13:50: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 NAA08561 for ; Mon, 10 Dec 2001 13:50:19 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26273; Mon, 10 Dec 2001 11:49:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15446; Mon, 10 Dec 2001 10:49:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAImUvU012610 for ; Mon, 10 Dec 2001 10:48:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAImUb2012609 for mobile-ip-dist; Mon, 10 Dec 2001 10:48:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAImPvU012602 for ; Mon, 10 Dec 2001 10:48:25 -0800 (PST) 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 KAA15176 for ; Mon, 10 Dec 2001 10:48:28 -0800 (PST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05611 for ; Mon, 10 Dec 2001 10:48:26 -0800 (PST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fBAImPS23112 for ; Mon, 10 Dec 2001 13:48:25 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 10 Dec 2001 18:48:24 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C0CE58237@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Erik Nordmark , "'deering@cisco.com'" Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 18:48:22 -0000 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: *At 11:35 AM -0600 12/10/01, Glenn Morrow wrote: *>GM] Why would the mobile not want to use route optimization? * *For privacy reasons, the owner of the mobile device may not *wish to reveal *it's current location in the network to its correspondent(s). * *Steve Location privacy is not obtained simply by disabling route optimization: the visited net addr (Care-of address) is revealed to the CN by sending to it IPv6 packets (with source address set to the CoA)... Not using the CoA as source address comes with some ingress filtering problems... Alessio From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 14: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 OAA09346 for ; Mon, 10 Dec 2001 14:17:51 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15075; Mon, 10 Dec 2001 11:16:36 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22527; Mon, 10 Dec 2001 11:16:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJFlvU012807 for ; Mon, 10 Dec 2001 11:15:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAJFlIl012806 for mobile-ip-dist; Mon, 10 Dec 2001 11:15:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJFhvU012799 for ; Mon, 10 Dec 2001 11:15:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16436; Mon, 10 Dec 2001 11:15:28 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04962; Mon, 10 Dec 2001 12:15:27 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBAJFPB06107; Mon, 10 Dec 2001 13:15:26 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 13:14:14 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011B86C0@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Cc: Erik Nordmark , "'deering@cisco.com'" Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 13:14:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C181AE.E1C56FF0" Sender: owner-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_01C181AE.E1C56FF0 Content-Type: text/plain; charset="iso-8859-1" Alessio, You are correct and this is why I came to the conclusion that the simultaneous operation of location privacy and route optimization is the only true functional excuse in my opinion that could be used to put the binding functions on the routers close to the CN. Now some people think that "location privacy" means that you have to hide the location from "others" i.e. snoopers i.e. not the people engaged in communications. I thought that "location privacy" that you didn't even want the nodes involved in end to end communications to be able to find out where the parties were unless they were authorized to do so i.e. in addition to the snoopers. So the first paragraph is true based upon this definition of "location privacy". I guess no one has really done an information id on "what is location privacy vs anonymity? If you use anonymity have you achieved location privacy etc..". Thanks for bringing this up. BTW if the definition of location privacy is just the snoopers then your previous SUCV/anonymity work could handle that. Anyway thanks again for bringing up this point. Glenn > -----Original Message----- > From: Casati, Alessio (Alessio) [mailto:acasati@lucent.com] > Sent: Monday, December 10, 2001 12:48 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Cc: Erik Nordmark; 'deering@cisco.com' > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > > > *At 11:35 AM -0600 12/10/01, Glenn Morrow wrote: > *>GM] Why would the mobile not want to use route optimization? > * > *For privacy reasons, the owner of the mobile device may not > *wish to reveal > *it's current location in the network to its correspondent(s). > * > *Steve > > Location privacy is not obtained simply by disabling > route optimization: the visited net addr (Care-of address) > is revealed to the CN by sending to it IPv6 packets > (with source address set to the CoA)... Not using the CoA as > source address comes with some ingress filtering problems... > > > > Alessio > ------_=_NextPart_001_01C181AE.E1C56FF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

Alessio,

You are correct and this is why I came to the = conclusion that the simultaneous operation of location privacy and = route optimization is the only true functional excuse in my opinion = that could be used to put the binding functions on the routers close to = the CN.

Now some people think that "location = privacy" means that you have to hide the location from = "others" i.e. snoopers i.e. not the people engaged in = communications. I thought that "location privacy" that you = didn't even want the nodes involved in end to end communications to be = able to find out where the parties were unless they were authorized to = do so i.e. in addition to the snoopers. So the first paragraph is true = based upon this definition of "location privacy". I guess no = one has really done an information id on "what is location privacy = vs anonymity? If you use anonymity have you achieved location privacy = etc..".

Thanks for bringing this up. BTW if the definition of = location privacy is just the snoopers then your previous SUCV/anonymity = work could handle that.

Anyway thanks again for bringing up this = point.

Glenn

> -----Original Message-----
> From: Casati, Alessio (Alessio) [mailto:acasati@lucent.com]=
> Sent: Monday, December 10, 2001 12:48 PM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Cc: Erik Nordmark; 'deering@cisco.com'
> Subject: RE: [mobile-ip] Routing header Vs = tunneling
>
>
>
>
> *At 11:35 AM -0600 12/10/01, Glenn Morrow = wrote:
> *>GM] Why would the mobile not want to use = route optimization?
> *
> *For privacy reasons, the owner of the mobile = device may not
> *wish to reveal
> *it's current location in the network to its = correspondent(s).
> *
> *Steve
>
> Location privacy is not obtained simply by = disabling
> route optimization: the visited net addr = (Care-of address)
> is revealed to the CN by sending to it IPv6 = packets
> (with source address set to the CoA)... Not = using the CoA as
> source address comes with some ingress = filtering problems...
>
>
>
> Alessio
>

------_=_NextPart_001_01C181AE.E1C56FF0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 14:20:20 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09400 for ; Mon, 10 Dec 2001 14:20:19 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA16390; Mon, 10 Dec 2001 11:19:00 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23405; Mon, 10 Dec 2001 11:18:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJI7vU012848 for ; Mon, 10 Dec 2001 11:18:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAJI7Mf012847 for mobile-ip-dist; Mon, 10 Dec 2001 11:18:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJI4vU012840 for ; Mon, 10 Dec 2001 11:18:04 -0800 (PST) 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 LAA21909 for ; Mon, 10 Dec 2001 11:18:05 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08397 for ; Mon, 10 Dec 2001 11:18:05 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBAJI2B06532 for ; Mon, 10 Dec 2001 13:18:03 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 13:16:51 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011B86CA@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 13:16:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C181AF.391C4B20" Sender: owner-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_01C181AF.391C4B20 Content-Type: text/plain; charset="iso-8859-1" Yes, you are right. Please see response to Claude. > -----Original Message----- > From: Steve Deering [mailto:deering@cisco.com] > Sent: Monday, December 10, 2001 12:18 PM > To: mobile-ip@sunroof.eng.sun.com > Cc: Erik Nordmark; mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > At 11:35 AM -0600 12/10/01, Glenn Morrow wrote: > >GM] Why would the mobile not want to use route optimization? > > For privacy reasons, the owner of the mobile device may not > wish to reveal > it's current location in the network to its correspondent(s). > > Steve > > ------_=_NextPart_001_01C181AF.391C4B20 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Routing header Vs tunneling

Yes, you are right. Please see response to Claude.

> -----Original Message-----
> From: Steve Deering [mailto:deering@cisco.com]
> Sent: Monday, December 10, 2001 12:18 PM
> To: mobile-ip@sunroof.eng.sun.com
> Cc: Erik Nordmark; mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Routing header Vs tunneling
>
>
> At 11:35 AM -0600 12/10/01, Glenn Morrow wrote:
> >GM] Why would the mobile not want to use route optimization?
>
> For privacy reasons, the owner of the mobile device may not
> wish to reveal
> it's current location in the network to its correspondent(s).
>
> Steve
>
>

------_=_NextPart_001_01C181AF.391C4B20-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 14: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 OAA09486 for ; Mon, 10 Dec 2001 14:23:07 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA18082; Mon, 10 Dec 2001 11:21:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24348; Mon, 10 Dec 2001 11:21:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJLBvU012958 for ; Mon, 10 Dec 2001 11:21:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAJLB18012957 for mobile-ip-dist; Mon, 10 Dec 2001 11:21:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJL7vU012944 for ; Mon, 10 Dec 2001 11:21:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17766 for ; Mon, 10 Dec 2001 11:21:08 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22357 for ; Mon, 10 Dec 2001 12:20:49 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBAJL5B07086; Mon, 10 Dec 2001 13:21:06 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 13:19:54 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011B86D6@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: "Glenn Morrow" , mobile-ip@sunroof.eng.sun.com Cc: Erik Nordmark , "'deering@cisco.com'" Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 13:20:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C181AF.AA6F10F0" Sender: owner-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_01C181AF.AA6F10F0 Content-Type: text/plain; charset="iso-8859-1" Whoops, I meant Claude Castellucio's work on SUCV/anonymity. > -----Original Message----- > From: Morrow, Glenn [RICH2:C330:EXCH] > Sent: Monday, December 10, 2001 1:15 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Cc: Erik Nordmark; 'deering@cisco.com' > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > Alessio, > > You are correct and this is why I came to the conclusion that > the simultaneous operation of location privacy and route > optimization is the only true functional excuse in my opinion > that could be used to put the binding functions on the > routers close to the CN. > > Now some people think that "location privacy" means that you > have to hide the location from "others" i.e. snoopers i.e. > not the people engaged in communications. I thought that > "location privacy" that you didn't even want the nodes > involved in end to end communications to be able to find out > where the parties were unless they were authorized to do so > i.e. in addition to the snoopers. So the first paragraph is > true based upon this definition of "location privacy". I > guess no one has really done an information id on "what is > location privacy vs anonymity? If you use anonymity have you > achieved location privacy etc..". > > Thanks for bringing this up. BTW if the definition of > location privacy is just the snoopers then your previous > SUCV/anonymity work could handle that. > > Anyway thanks again for bringing up this point. > > Glenn > > > -----Original Message----- > > From: Casati, Alessio (Alessio) [mailto:acasati@lucent.com] > > Sent: Monday, December 10, 2001 12:48 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Cc: Erik Nordmark; 'deering@cisco.com' > > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > > > > > > > > *At 11:35 AM -0600 12/10/01, Glenn Morrow wrote: > > *>GM] Why would the mobile not want to use route optimization? > > * > > *For privacy reasons, the owner of the mobile device may not > > *wish to reveal > > *it's current location in the network to its correspondent(s). > > * > > *Steve > > > > Location privacy is not obtained simply by disabling > > route optimization: the visited net addr (Care-of address) > > is revealed to the CN by sending to it IPv6 packets > > (with source address set to the CoA)... Not using the CoA as > > source address comes with some ingress filtering problems... > > > > > > > > Alessio > > > ------_=_NextPart_001_01C181AF.AA6F10F0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Routing header Vs tunneling

Whoops,

I meant Claude Castellucio's work on SUCV/anonymity.

> -----Original Message-----
> From: Morrow, Glenn [RICH2:C330:EXCH]
> Sent: Monday, December 10, 2001 1:15 PM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Cc: Erik Nordmark; 'deering@cisco.com'
> Subject: RE: [mobile-ip] Routing header Vs tunneling
>
>
> Alessio,
>
> You are correct and this is why I came to the conclusion that
> the simultaneous operation of location privacy and route
> optimization is the only true functional excuse in my opinion
> that could be used to put the binding functions on the
> routers close to the CN.
>
> Now some people think that "location privacy" means that you
> have to hide the location from "others" i.e. snoopers i.e.
> not the people engaged in communications. I thought that
> "location privacy" that you didn't even want the nodes
> involved in end to end communications to be able to find out
> where the parties were unless they were authorized to do so
> i.e. in addition to the snoopers. So the first paragraph is
> true based upon this definition of "location privacy". I
> guess no one has really done an information id on "what is
> location privacy vs anonymity? If you use anonymity have you
> achieved location privacy etc..".
>
> Thanks for bringing this up. BTW if the definition of
> location privacy is just the snoopers then your previous
> SUCV/anonymity work could handle that.
>
> Anyway thanks again for bringing up this point.
>
> Glenn
>
> > -----Original Message-----
> > From: Casati, Alessio (Alessio) [mailto:acasati@lucent.com]
> > Sent: Monday, December 10, 2001 12:48 PM
> > To: 'mobile-ip@sunroof.eng.sun.com'
> > Cc: Erik Nordmark; 'deering@cisco.com'
> > Subject: RE: [mobile-ip] Routing header Vs tunneling
> >
> >
> >
> >
> > *At 11:35 AM -0600 12/10/01, Glenn Morrow wrote:
> > *>GM] Why would the mobile not want to use route optimization?
> > *
> > *For privacy reasons, the owner of the mobile device may not
> > *wish to reveal
> > *it's current location in the network to its correspondent(s).
> > *
> > *Steve
> >
> > Location privacy is not obtained simply by disabling
> > route optimization: the visited net addr (Care-of address)
> > is revealed to the CN by sending to it IPv6 packets
> > (with source address set to the CoA)... Not using the CoA as
> > source address comes with some ingress filtering problems...
> >
> >
> >
> > Alessio
> >
>

------_=_NextPart_001_01C181AF.AA6F10F0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 14:23: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 OAA09555 for ; Mon, 10 Dec 2001 14:23:51 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23640; Mon, 10 Dec 2001 12:22:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24611; Mon, 10 Dec 2001 11:22:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJLkvU012990 for ; Mon, 10 Dec 2001 11:21:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAJLkBo012989 for mobile-ip-dist; Mon, 10 Dec 2001 11:21:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJLgvU012977 for ; Mon, 10 Dec 2001 11:21:42 -0800 (PST) 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 LAA24267 for ; Mon, 10 Dec 2001 11:21:43 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26872 for ; Mon, 10 Dec 2001 11:21:38 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBAJLaB07165 for ; Mon, 10 Dec 2001 13:21:37 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 13:20:25 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011B86DA@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: "Glenn Morrow" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 13:20:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C181AF.BF2EF4B0" Sender: owner-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_01C181AF.BF2EF4B0 Content-Type: text/plain; charset="iso-8859-1" Whoops, I meant Allesio. > -----Original Message----- > From: Morrow, Glenn [RICH2:C330:EXCH] > Sent: Monday, December 10, 2001 1:18 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > Yes, you are right. Please see response to Claude. > > > -----Original Message----- > > From: Steve Deering [mailto:deering@cisco.com] > > Sent: Monday, December 10, 2001 12:18 PM > > To: mobile-ip@sunroof.eng.sun.com > > Cc: Erik Nordmark; mobile-ip@sunroof.eng.sun.com > > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > > > > At 11:35 AM -0600 12/10/01, Glenn Morrow wrote: > > >GM] Why would the mobile not want to use route optimization? > > > > For privacy reasons, the owner of the mobile device may not > > wish to reveal > > it's current location in the network to its correspondent(s). > > > > Steve > > > > > ------_=_NextPart_001_01C181AF.BF2EF4B0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Routing header Vs tunneling

Whoops,

I meant Allesio.

> -----Original Message-----
> From: Morrow, Glenn [RICH2:C330:EXCH]
> Sent: Monday, December 10, 2001 1:18 PM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [mobile-ip] Routing header Vs tunneling
>
>
> Yes, you are right. Please see response to Claude.
>
> > -----Original Message-----
> > From: Steve Deering [mailto:deering@cisco.com]
> > Sent: Monday, December 10, 2001 12:18 PM
> > To: mobile-ip@sunroof.eng.sun.com
> > Cc: Erik Nordmark; mobile-ip@sunroof.eng.sun.com
> > Subject: RE: [mobile-ip] Routing header Vs tunneling
> >
> >
> > At 11:35 AM -0600 12/10/01, Glenn Morrow wrote:
> > >GM] Why would the mobile not want to use route optimization?
> >
> > For privacy reasons, the owner of the mobile device may not
> > wish to reveal
> > it's current location in the network to its correspondent(s).
> >
> > Steve
> >
> >
>

------_=_NextPart_001_01C181AF.BF2EF4B0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 14:33: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 OAA09737 for ; Mon, 10 Dec 2001 14:33:26 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00868; Mon, 10 Dec 2001 12:32:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26253; Mon, 10 Dec 2001 11:32:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJVWvU013169 for ; Mon, 10 Dec 2001 11:31:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAJVVFw013168 for mobile-ip-dist; Mon, 10 Dec 2001 11:31:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJVSvU013161 for ; Mon, 10 Dec 2001 11:31:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27262 for ; Mon, 10 Dec 2001 11:31:29 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21959 for ; Mon, 10 Dec 2001 12:32:03 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBAJVNB08957 for ; Mon, 10 Dec 2001 13:31:23 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 13:30:12 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011B86FE@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 13:30:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C181B1.1CD944C0" Sender: owner-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_01C181B1.1CD944C0 Content-Type: text/plain; charset="iso-8859-1" I undertand this point of view as well. We'd have to turn off half of the applications and protocols in use today on the Internet with the same problems. Not the mention to be "fair", 60% of the existing RFCs should be demoted back to drafts if put under the same scrutiny. This is somewhat of a brave new world with new threats. Two wrongs don't make a right but believe me, I hear you on the getting picked on front. regards, Glenn > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: Monday, December 10, 2001 12:07 PM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Routing header Vs tunneling > > > > Glenn Morrow wrote: > > > > > That said - what is the use of sending the extra addresses > > > in each packet at > > > > all since per-address authorization state must be kept on the > > tunnel > > > > endpoints in order to protect against the reflector attacks? > > I didn't think that this conclusion had been drawn. > The reflector attack under discussion doesn't seem > to be a horrible problem to me, and it's no worse than > what can be done today wthout any Home Address > destination option. > > However, I still can agree that keeping extra state as > you mention will enable protection against the problem > anyway. I just didn't think that it had been agreed as > a mandated part of a solution. > > > > Are you suggesting sending packets with just two IP addresses > > > and having the > > > endpoint replace the source IP and destination IP based on > > > what it has in > > > the binding cache entry? > > > > GM] Yes > > I don't think this is a good idea, unless there is some extra > information in the two-address header that says it is O.K. to > do the replacement. > > Currently, it is possible for a mobile node to use both its > home address and its care-of address for communications > with correspondent nodes. This might well be useful for > two different data applications between the same two nodes. > I think we should try to maintain the usefulness of the care-of > address as a legitimate IPv6 address for applications that, > for whatever reason, do not need mobility support. Maybe > SMS would be like that, if every "session" only lasted for > a single packet. But presumably "more" applications would > use the home address in preference to the care-of address > as the IP(v6) address identifying the application endpoint. > > Regards, > Charlie P. > > ------_=_NextPart_001_01C181B1.1CD944C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

I undertand this point of view as well. We'd have to = turn off half of the applications and protocols in use today on the = Internet with the same problems. Not the mention to be = "fair", 60% of the existing RFCs should be demoted back to = drafts if put under the same scrutiny. 

This is somewhat of a brave new world with new = threats. Two wrongs don't make a right but believe me, I hear you on = the getting picked on front.

regards,

Glenn

> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: Monday, December 10, 2001 12:07 PM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Routing header Vs = tunneling
>
>
>
> Glenn Morrow wrote:
>
> > > > That said - what is the use of = sending the extra addresses
> > > in each packet at
> > > > all since per-address = authorization state must be kept on the
> > tunnel
> > > > endpoints in order to protect = against the reflector attacks?
>
> I didn't think that this conclusion had been = drawn.
> The reflector attack under discussion doesn't = seem
> to be a horrible problem to me, and it's no = worse than
> what can be done today wthout any Home = Address
> destination option.
>
> However, I still can agree that keeping extra = state as
> you mention will enable protection against the = problem
> anyway.  I just didn't think that it had = been agreed as
> a mandated part of a solution.
>
> > > Are you suggesting sending packets = with just two IP addresses
> > > and having the
> > > endpoint replace the source IP and = destination IP based on
> > > what it has in
> > > the binding cache entry?
> >
> > GM] Yes
>
> I don't think this is a good idea, unless there = is some extra
> information in the two-address header that says = it is O.K. to
> do the replacement.
>
> Currently, it is possible for a mobile node to = use both its
> home address and its care-of address for = communications
> with correspondent nodes.  This might well = be useful for
> two different data applications between the = same two nodes.
> I think we should try to maintain the = usefulness of the care-of
> address as a legitimate IPv6 address for = applications that,
> for whatever reason, do not need mobility = support.  Maybe
> SMS would be like that, if every = "session" only lasted for
> a single packet.  But presumably = "more" applications would
> use the home address in preference to the = care-of address
> as the IP(v6) address identifying the = application endpoint.
>
> Regards,
> Charlie P.
>
>

------_=_NextPart_001_01C181B1.1CD944C0-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 14:34: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 OAA09776 for ; Mon, 10 Dec 2001 14:34:43 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24243; Mon, 10 Dec 2001 11:33:31 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26550; Mon, 10 Dec 2001 11:33:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJWkvU013190 for ; Mon, 10 Dec 2001 11:32:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAJWjR8013189 for mobile-ip-dist; Mon, 10 Dec 2001 11:32:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJWfvU013181; Mon, 10 Dec 2001 11:32:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07646; Mon, 10 Dec 2001 11:32:42 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12379; Mon, 10 Dec 2001 12:32:41 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA00274; Mon, 10 Dec 2001 11:32:40 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBAJWdj09497; Mon, 10 Dec 2001 11:32:39 -0800 X-mProtect: Mon, 10 Dec 2001 11:32:39 -0800 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 smtpdxiIDQa; Mon, 10 Dec 2001 11:32:37 PST Message-ID: <3C150DD6.C295C679@iprg.nokia.com> Date: Mon, 10 Dec 2001 11:32:38 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Krishna Kumar CC: Francis.Dupont@enst-bretagne.fr, mobile-ip@sunroof.eng.sun.com, owner-mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question on performing DAD for BU's 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 KK, Krishna Kumar wrote: > > Hi Vijay & Francis, > > I didn't state the complete problem (though Francis did correctly guess > what I meant), so let me add a few lines to describe that. When the MN goes > to a FN, another node (which already had it's address autoconfigured, > thereby having it's own link local address) configured the MN's home > address manually, unintentionally or maliciously. When the HA does DAD on lets assume unintentionally. if you have a malicious node on your home link, lot more things (worse?) could happen. > the link local address, the new node does not respond to the NS, since it > has a different link local address. Now there will be a conflict for > packets destined to either the MN or the new node. Isn't it needed to do > DAD in this case for every address ? > > My problem is only with manual configuration , I agree that > autoconfiguration doesn't create this problem at all. you are right. but it comes from somebody making mistake while manually configuring the address on the MN. > > Also, the 'S' bit doesn't solve the problem, it is not defending all the > addresses, the 'S' bit is used for tunnelling packets with any of the many > home addresses values based on the prefixes supported, instead of just the > home address. acutally section 9.1 talks about creating a binding cache entry for each address that can be derived from other prefixes on the home link. and when you talk about creating a binding cache entry, it also means that the home agent is defending that particular address. it answers to neighbor solicitations for that address. otherwise the packets would never reach the home agent and would never be tunneled to the mobile node. so we can assume the if the 'S' bit is not set in the BU, the home agent defends and creats a binding cache entry for each address that can be derived from other prefixes on the home link. if the wording is not clear maybe we can add some text. > > > this is based on the common policy where DAD is only performed on > link-local addresses *and* no address uses a different interface ID. > > If this restriction is enforced, this problem does not exist. But that is > exactly what I am trying to find out. If a node can configure an address > with a different interface identifier, then DAD should be done on all > addresses values. I am not sure about the answer to this question. maybe others can comment on this. Vijay > > Please let me know if this is wrong in any way. > > Thanks, > > - KK > > > Vijay Devarapalli > To: mobile-ip@sunroof.eng.sun.com > Sent by: cc: > owner-mobile-ip@sunroof.e Subject: Re: [mobile-ip] Question on performing DAD for BU's > ng.sun.com > > > 12/06/2001 05:20 PM > Please respond to > mobile-ip > > > > Hi KK, > > I think this comes from RFC 2462 which says if you have stateless > address configuration, its enough if you do duplicate address > detection on just the link local address. the other addresses are > a MAY. > > heres the relevant text from RFC 2462, section 5.4 > > --------------- > > - Each individual unicast address SHOULD be tested for uniqueness. > However, when stateless address autoconfiguration is used, > address uniqueness is determined solely by the interface > identifier, assuming that subnet prefixes are assigned correctly > (i.e., if all of an interface's addresses are generated from the > same identifier, either all addresses or none of them will be > duplicates). Thus, for a set of addresses formed from the same > interface identifier, it is sufficient to check that the link- > local address generated from the identifier is unique on the > link. In such cases, the link-local address MUST be tested for > uniqueness, and if no duplicate address is detected, an > implementation MAY choose to skip Duplicate Address Detection > for additional addresses derived from the same interface > identifier. > > --------------- > > And I guess the intention was that Mobile IPv6 did not want to > specify anything in addition to what is there in RFC 2462. > > and regarding more than prefix on the home link there is > something specified in draft 15 for that. if the 'S' bit in the > BU is set, the Home Agent defends just the home address > specified in the home address option. if the 'S' bit is not set, > the home agent forms a home address from each prefix on the home > link and defends all of them. and even in this case, by RFC 2462, > its enough if you do DAD from just the link local address if > stateless address configuration is being used. > > one more thing, in your example below node 'X' MUST configure a > link local address. it cant configure a site local address alone > and not configure a link local address. it is there in some RFC, > I forgot which. > > regards > Vijay > > Krishna Kumar wrote: > > > > Hi Charlie, > > > > I feel there is a small problem in the Draft 15 regarding the address > used > > for performing DAD. > > > > 1. Page 67 for BU processing says that DAD should be performed on the > Link > > Local Address. > > 2. Pg 94 says that : If some time elapses during which the mobile node > has > > no binding at the home agent, it might be possible for another node to > > autoconfigure the mobile node's home address. > > > > A new node 'X' can configure it's address either through > autoconfiguration > > (in which case #1 is sufficient), or by manual means. Since the address > can > > be configured manually, I feel the specification should be changed to > state > > that DAD should be performed on the Link Local address and all Home > > Addresses (if Prefix Length is > 0) based on different prefixes supported > > by the Home Agent. > > > > The reason is that the MN might configure a site local address as it's > home > > address and move to a foreign network. Before HA gets the BU, another > node > > 'X' manually configures it's address to the site local address used by > the > > MN, and it succeeds. When HA gets the BU, it does a Neighbor Solicitation > > on the Link Local Address, and since X has not configured that link local > > address, it doesn't respond to the NS. Now packets meant for 'X' get > > wrongly tunneled to the MN. The node X doesn't even need to take the same > > site local address for this to fail, it can configure any other address > > based on the prefixes supported and the interface identifier. In this > case, > > after the BU succeeds, any packets meant for this different address will > > still be tunnelled wrongly by the HA to the MN since Prefix Length was > > greater than zero. Hence I feel HA must perform DAD on all addresses (can > > be done parallely and probably take almost the same time as it would take > > for one DAD) if Prefix Length > 0. > > > > Secondly, is it a good idea for Mobility to change the value of > > RetransTimer to a smaller value like 0.5 seconds or smaller ? This means > > faster handoff for the MN. Otherwise the MN has to wait for > > 1.5*(RetransTimer*DupAddrDetectTransmits) = atleast 1.5 seconds before > the > > MN gets a response, and before it is allowed to send BU's to CN's. > Reducing > > this time ensures faster movement mechanism for the MN. > > > > Thanks, > > > > - KK From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 14:39: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 OAA09846 for ; Mon, 10 Dec 2001 14:39:32 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26677; Mon, 10 Dec 2001 11:38:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28224; Mon, 10 Dec 2001 11:38:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJbdvU013333 for ; Mon, 10 Dec 2001 11:37:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAJbdw5013332 for mobile-ip-dist; Mon, 10 Dec 2001 11:37:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAJbavU013325 for ; Mon, 10 Dec 2001 11:37:36 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28098 for ; Mon, 10 Dec 2001 11:37:37 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA25154 for ; Mon, 10 Dec 2001 12:38:14 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBAJbYB10167 for ; Mon, 10 Dec 2001 13:37:35 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 13:36:23 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011B8722@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 13:36:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C181B1.F90CE190" Sender: owner-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_01C181B1.F90CE190 Content-Type: text/plain; charset="iso-8859-1" True - We have the same definition of what location privacy is. > -----Original Message----- > From: Casati, Alessio (Alessio) [mailto:acasati@lucent.com] > Sent: Monday, December 10, 2001 12:48 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Cc: Erik Nordmark; 'deering@cisco.com' > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > > > *At 11:35 AM -0600 12/10/01, Glenn Morrow wrote: > *>GM] Why would the mobile not want to use route optimization? > * > *For privacy reasons, the owner of the mobile device may not > *wish to reveal > *it's current location in the network to its correspondent(s). > * > *Steve > > Location privacy is not obtained simply by disabling > route optimization: the visited net addr (Care-of address) > is revealed to the CN by sending to it IPv6 packets > (with source address set to the CoA)... Not using the CoA as > source address comes with some ingress filtering problems... > > > > Alessio > ------_=_NextPart_001_01C181B1.F90CE190 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Routing header Vs tunneling

True - We have the same definition of what location privacy is.

> -----Original Message-----
> From: Casati, Alessio (Alessio) [mailto:acasati@lucent.com]
> Sent: Monday, December 10, 2001 12:48 PM
> To: 'mobile-ip@sunroof.eng.sun.com'
> Cc: Erik Nordmark; 'deering@cisco.com'
> Subject: RE: [mobile-ip] Routing header Vs tunneling
>
>
>
>
> *At 11:35 AM -0600 12/10/01, Glenn Morrow wrote:
> *>GM] Why would the mobile not want to use route optimization?
> *
> *For privacy reasons, the owner of the mobile device may not
> *wish to reveal
> *it's current location in the network to its correspondent(s).
> *
> *Steve
>
> Location privacy is not obtained simply by disabling
> route optimization: the visited net addr (Care-of address)
> is revealed to the CN by sending to it IPv6 packets
> (with source address set to the CoA)... Not using the CoA as
> source address comes with some ingress filtering problems...
>
>
>
> Alessio
>

------_=_NextPart_001_01C181B1.F90CE190-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 15:11: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 PAA10276 for ; Mon, 10 Dec 2001 15:11:30 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00654; Mon, 10 Dec 2001 13:10:06 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06422; Mon, 10 Dec 2001 12:10:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAK9TvU013539 for ; Mon, 10 Dec 2001 12:09:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAK9SCE013538 for mobile-ip-dist; Mon, 10 Dec 2001 12:09:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAK9PvU013531 for ; Mon, 10 Dec 2001 12:09:26 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06294 for ; Mon, 10 Dec 2001 12:09:27 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13621 for ; Mon, 10 Dec 2001 13:09:26 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBAK9OB16413 for ; Mon, 10 Dec 2001 14:09:25 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 14:08:13 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E011B87B4@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 14:08:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C181B6.68CA1670" Sender: owner-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_01C181B6.68CA1670 Content-Type: text/plain; charset="iso-8859-1" Resending? > -----Original Message----- > From: Morrow, Glenn [RICH2:C330:EXCH] > Sent: Monday, December 10, 2001 11:36 AM > To: 'Erik Nordmark' > Cc: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > GM] Comments in-line below. > > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > > Sent: Saturday, December 08, 2001 5:46 PM > > To: Morrow, Glenn [RICH2:C330:EXCH] > > Cc: mobile-ip@sunroof.eng.sun.com > > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > > > > Glenn, > > > > > That said - what is the use of sending the extra addresses > > in each packet at > > > all since per-address authorization state must be kept on > the tunnel > > > endpoints in order to protect against the reflector attacks? > > > > Are you suggesting sending packets with just two IP addresses > > and having the > > endpoint replace the source IP and destination IP based on > > what it has in > > the binding cache entry? > > GM] Yes > > > > > I think such an approach has some robustness problems. > > GM] I think it is no less robust than what would have to > occur even if we did send the extra address - but I am > certainly open to an attempt to find some sort of stateless > argument for why the extra address needs to be there. I just > don't see it if the reflector attack is mandated to be prevented. > > > - What happens if the MN moves away and other MN appears and > > acquires the same > > CoA? > > GM]The new mobile would have a new home address which could > be used to distinguish the two. The home address would have > had to be conveyed via some signaling i.e. something like a > binding update and the cache maintained. This signaling needs > to be authorized and authenticated in order to protect > against a mobile binding another mobile's home address to a > particular COA. > > If there is a stale binding cache entry for the CoA->old HoA > > in some CN there will be TCP checksum failures should the > > new MN/HoA try to > > communicate with it since it will use the old CoA->HoA mapping. > > GM]If there is no cache entry that is valid the packets > should be dropped and perhaps an ICMP error message sent to > notify the sender (MN's COA) that they need to refresh. > > > - What if a MN wants to have one session (e.g. TCP or VoIP) > > with a CN using route optimization and another session > > (e.g. DNS udp > > lookup) > > not using route optimization. That CN would not be able to > > tell whether > > to apply the address replacement - the source address > > would be the CoA > > in both cases. > > GM] Why would the mobile not want to use route optimization? > I don't see why a mobile would not want to use route > optimization with every node if it were available (ubiquitous). > > > > > And I can't even imagine what the security issues would be in > > such a case. > > GM] As far as I can tell, the security issues are exactly the > same irrespective of whether the extra address is sent. The > statement doesn't detail any specific issue - by all means, please do. > > > So I think having all packets contain all the necessary IP > > addresses makes > > sense. > > GM] I have to say I am not that optimistic of such a thing > gaining wide acceptance any time soon; however, the > protections necessary against reflector attack with route > optimized MIP makes sending the extra address, useless. If > you protect against the reflector, then you have conveyed the > addresses to each side with credentials for authentication > and authorization and the CN is already having to check > against DDoS based upon some table. This information has to > be stored in a table unless you want to have to authenticate > and authorize on each bearer packet. > > GM] I think we have already seen some discussion on the IPv6 > WG list about the cache etc.. It does seem that people are > beginning to see the point - but I must say this would be a > serious leep of faith. Just keep asking yourself what will > have to be done with the packet when there is no cache entry > - i.e. even if the home address is conveyed in the packet. > > GM] Earlier I tried to make the point that if MIP is required > to deal with the reflector attack, then you might as well > require that the CN's do route optimization because the same > state will have to be kept on the CN - might as well go for > the gusto. The people making micro cameras and toasters with > IP stacks started freaking out on this though. They want the > small cheap footprint. > > GM] This frustrated me to no end and so now I think we might > need to start looking at having the routers close to the CN's > do some of these functions but gee - I can only imagine the > reaction I'll get from that suggestion from the end to > enders. This isn't exactly a new idea, though. Even the first > renditions of MIPv6 had such thoughts in it. We also have > GES, TUBA, 8+8, LAR, MBG, etc.. that explored this concept, > although many of these solutions had the tunneling overhead > as well. Putting the cache on the CN was easier from a > signaling semantics point of view because it basically > results in a point to point problem set as apposed to a > subnet to subnet problem set. This is why I think the > placement of the route optimization functions on the routers > close to the CN's was discounted in favor of the easier problem set. > > GM] Route optimized MIPv6 is turning into a bunch of > catch-22's (footprint vs security). I think route > optimization should be ubiquitous irrespective of the choice > of where to put the cache entries. Moore's law should > eventually handle the footprint and economics of microcameras > and toasters etc.. Each time the requirements of nodes for > route optimization is relaxed the specification is > complicated and the code size on the mobile goes up because > it has to deal with backoff procedures. > > GM]I hum for a MUST on the CN binding update requirement or > start having the WG look at mandating the cache on the > routers close to the CNs. I don't think the footprint and > cost people can start complaining about having a MUST for > routers. Whatever the choice I have a strong belief that > route optimization should be ubiquitous, deployable and > backed up by MUSTs in the specs. > > GM]One thing is for sure, though. The layer-5 signaling-based > node mobility solutions gain in credibility each day the MIP > spec is debated over and incomplete. It is hard to tell who > on the receiver list is FUDing and who is not. I certainly > don't believe you (Erik) are one of the FUD people. > > GM]I mentioned a little timer earlier on the list related to > competition from these layer-5 solutions. The timer has > expired for some operators. BTW, last time I checked on these > layer-5 signaled solutions, they don't need tunnel overhead > either. But see - they are layer-5 signaling and it's O.K. to > make a "pseudo-connection" i.e. install and maintain some > state. It is the same thing - these solutions use IP stack > mobility shims and swap the addresses at the endpoints. > > Regards, > > Glenn > > > > ------_=_NextPart_001_01C181B6.68CA1670 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Routing header Vs tunneling

Resending?

> -----Original Message-----
> From: Morrow, Glenn [RICH2:C330:EXCH]
> Sent: Monday, December 10, 2001 11:36 AM
> To: 'Erik Nordmark'
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Routing header Vs tunneling
>
>
> GM] Comments in-line below.
>
> > -----Original Message-----
> > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com]
> > Sent: Saturday, December 08, 2001 5:46 PM
> > To: Morrow, Glenn [RICH2:C330:EXCH]
> > Cc: mobile-ip@sunroof.eng.sun.com
> > Subject: RE: [mobile-ip] Routing header Vs tunneling
> >
> >
> > Glenn,
> >
> > > That said - what is the use of sending the extra addresses
> > in each packet at
> > > all since per-address authorization state must be kept on
> the tunnel
> > > endpoints in order to protect against the reflector attacks?
> >
> > Are you suggesting sending packets with just two IP addresses
> > and having the
> > endpoint replace the source IP and destination IP based on
> > what it has in
> > the binding cache entry?
>
> GM] Yes
>
> >
> > I think such an approach has some robustness problems.
>
> GM] I think it is no less robust than what would have to
> occur even if we did send the extra address - but I am
> certainly open to an attempt to find some sort of stateless
> argument for why the extra address needs to be there. I just
> don't see it if the reflector attack is mandated to be prevented.
>
> >  - What happens if the MN moves away and other MN appears and
> > acquires the same
> >    CoA?
>
> GM]The new mobile would have a new home address which could
> be used to distinguish the two. The home address would have
> had to be conveyed via some signaling i.e. something like a
> binding update and the cache maintained. This signaling needs
> to be authorized and authenticated in order to protect
> against a mobile binding another mobile's home address to a
> particular COA.
>
>  If there is a stale binding cache entry  for the CoA->old HoA
> >    in some CN there will be TCP checksum failures should the
> > new MN/HoA try to
> >    communicate with it since it will use the old CoA->HoA mapping.
>
> GM]If there is no cache entry that is valid the packets
> should be dropped and perhaps an ICMP error message sent to
> notify the sender (MN's COA) that they need to refresh.
>
> >  - What if a MN wants to have one session (e.g. TCP or VoIP)
> >    with a CN using route optimization and another session 
> > (e.g. DNS udp
> > lookup)
> >    not using route optimization. That CN would not be able to
> > tell whether
> >    to apply the address replacement - the source address
> > would be the CoA
> >    in both cases.
>
> GM] Why would the mobile not want to use route optimization?
> I don't see why a mobile would not want to use route
> optimization with every node if it were available (ubiquitous).
>
> >
> > And I can't even imagine what the security issues would be in
> > such a case.
>
> GM] As far as I can tell, the security issues are exactly the
> same irrespective of whether the extra address is sent. The
> statement doesn't detail any specific issue - by all means, please do.
>
> > So I think having all packets contain all the necessary IP
> > addresses makes
> > sense.
>
> GM] I have to say I am not that optimistic of such a thing
> gaining wide acceptance any time soon; however, the
> protections necessary against reflector attack with route
> optimized MIP makes sending the extra address, useless. If
> you protect against the reflector, then you have conveyed the
> addresses to each side with credentials for authentication
> and authorization and the CN is already having to check
> against DDoS based upon some table. This information has to
> be stored in a table unless you want to have to authenticate
> and authorize on each bearer packet.
>
> GM] I think we have already seen some discussion on the IPv6
> WG list about the cache etc.. It does seem that people are
> beginning to see the point - but I must say this would be a
> serious leep of faith. Just keep asking yourself what will
> have to be done with the packet when there is no cache entry
> - i.e. even if the home address is conveyed in the packet.
>
> GM] Earlier I tried to make the point that if MIP is required
> to deal with the reflector attack, then you might as well
> require that the CN's do route optimization because the same
> state will have to be kept on the CN - might as well go for
> the gusto. The people making micro cameras and toasters with
> IP stacks started freaking out on this though. They want the
> small cheap footprint.
>
> GM] This frustrated me to no end and so now I think we might
> need to start looking at having the routers close to the CN's
> do some of these functions but gee - I can only imagine the
> reaction I'll get from that suggestion from the end to
> enders. This isn't exactly a new idea, though. Even the first
> renditions of MIPv6 had such thoughts in it. We also have
> GES, TUBA, 8+8, LAR, MBG, etc.. that explored this concept,
> although many of these solutions had the tunneling overhead
> as well. Putting the cache on the CN was easier from a
> signaling semantics point of view because it basically
> results in a point to point problem set as apposed to a
> subnet to subnet problem set. This is why I think the
> placement of the route optimization functions on the routers
> close to the CN's was discounted in favor of the easier problem set.
>
> GM] Route optimized MIPv6 is turning into a bunch of
> catch-22's (footprint vs security). I think route
> optimization should be ubiquitous irrespective of the choice
> of where to put the cache entries. Moore's law should
> eventually handle the footprint and economics of microcameras
> and toasters etc.. Each time the requirements of nodes for
> route optimization is relaxed the specification is
> complicated and the code size on the mobile goes up because
> it has to deal with backoff procedures.
>
> GM]I hum for a MUST on the CN binding update requirement or
> start having the WG look at mandating the cache on the
> routers close to the CNs. I don't think the footprint and
> cost people can start complaining about having a MUST for
> routers. Whatever the choice I have a strong belief that
> route optimization should be ubiquitous, deployable and
> backed up by MUSTs in the specs.
>
> GM]One thing is for sure, though. The layer-5 signaling-based
> node mobility solutions gain in credibility each day the MIP
> spec is debated over and incomplete. It is hard to tell who
> on the receiver list is FUDing and who is not. I certainly
> don't believe you (Erik) are one of the FUD people.
>
> GM]I mentioned a little timer earlier on the list related to
> competition from these layer-5 solutions. The timer has
> expired for some operators. BTW, last time I checked on these
> layer-5 signaled solutions, they don't need tunnel overhead
> either. But see - they are layer-5 signaling and it's O.K. to
> make a "pseudo-connection" i.e. install and maintain some
> state. It is the same thing -  these solutions use IP stack
> mobility shims and swap the addresses at the endpoints.
>
> Regards,
>
> Glenn
>
>
>
>

------_=_NextPart_001_01C181B6.68CA1670-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 15:20:08 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10419 for ; Mon, 10 Dec 2001 15:20:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06837; Mon, 10 Dec 2001 13:18:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08095; Mon, 10 Dec 2001 12:19:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAKHqvU013630 for ; Mon, 10 Dec 2001 12:17:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAKHqZF013629 for mobile-ip-dist; Mon, 10 Dec 2001 12:17:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAKHmvU013622 for ; Mon, 10 Dec 2001 12:17:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00212; Mon, 10 Dec 2001 12:17:26 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16443; Mon, 10 Dec 2001 13:17:25 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBAKHPV27359; Mon, 10 Dec 2001 12:17:25 -0800 (PST) Received: from [10.21.58.157] (sj-dial-4-61.cisco.com [171.68.181.190]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACC07831; Mon, 10 Dec 2001 12:17:12 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <976F7C55E3B2D111A0720008C728549C0CE58237@en0060exch001u.uk.lucent.com> References: <976F7C55E3B2D111A0720008C728549C0CE58237@en0060exch001u.uk.lucent.com> Date: Mon, 10 Dec 2001 12:17:54 -0800 To: "Casati, Alessio (Alessio)" From: Steve Deering Subject: RE: [mobile-ip] Routing header Vs tunneling Cc: "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark 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: At 6:48 PM +0000 12/10/01, Casati, Alessio (Alessio) wrote: >Location privacy is not obtained simply by disabling >route optimization: the visited net addr (Care-of address) >is revealed to the CN by sending to it IPv6 packets >(with source address set to the CoA)... Not using the CoA as >source address comes with some ingress filtering problems... You do bidirectional tunneling through the home agent when you want to keep your location hidden from your corrrespondents (i.e., you disable route optimization on both directions). The outer source address in the tunneled packets from MH to HA is the care-of address, so it gets through the ingress filters fine, and then gets removed by the HA as a natural side-effect of decapsulation, before the packet goes to the correspondent. Steve From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 15:40: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 PAA10874 for ; Mon, 10 Dec 2001 15:40:19 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA24617; Mon, 10 Dec 2001 12:39:10 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12167; Mon, 10 Dec 2001 12:39:03 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAKcGvU013795 for ; Mon, 10 Dec 2001 12:38:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAKcFVm013794 for mobile-ip-dist; Mon, 10 Dec 2001 12:38:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAKcCvU013787 for ; Mon, 10 Dec 2001 12:38:12 -0800 (PST) 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 MAA22924 for ; Mon, 10 Dec 2001 12:38:14 -0800 (PST) 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 MAA11589 for ; Mon, 10 Dec 2001 12:38:13 -0800 (PST) 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 fBAKcDV18209; Mon, 10 Dec 2001 12:38:13 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAM30889; Mon, 10 Dec 2001 12:37:37 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA02598; Mon, 10 Dec 2001 12:38:11 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15381.7475.640960.400363@thomasm-u1.cisco.com> Date: Mon, 10 Dec 2001 12:38:11 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: "Casati, Alessio (Alessio)" , Erik Nordmark Subject: RE: [mobile-ip] Routing header Vs tunneling In-Reply-To: References: <976F7C55E3B2D111A0720008C728549C0CE58237@en0060exch001u.uk.lucent.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 Steve Deering writes: > At 6:48 PM +0000 12/10/01, Casati, Alessio (Alessio) wrote: > >Location privacy is not obtained simply by disabling > >route optimization: the visited net addr (Care-of address) > >is revealed to the CN by sending to it IPv6 packets > >(with source address set to the CoA)... Not using the CoA as > >source address comes with some ingress filtering problems... > > You do bidirectional tunneling through the home agent when you want to > keep your location hidden from your corrrespondents (i.e., you disable > route optimization on both directions). The outer source address in > the tunneled packets from MH to HA is the care-of address, so it > gets through the ingress filters fine, and then gets removed by the > HA as a natural side-effect of decapsulation, before the packet goes > to the correspondent. Right, and I think that given the hazard for the CN with spooofed HAO, there needs to be a failsafe way for the MN to communicate with the CN if, for whatever reason, the CN will not accept the binding updated. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 15:53: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 PAA11191 for ; Mon, 10 Dec 2001 15:53:13 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29589; Mon, 10 Dec 2001 13:51:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14701; Mon, 10 Dec 2001 12:52:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAKp0vU013909 for ; Mon, 10 Dec 2001 12:51:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAKp03V013908 for mobile-ip-dist; Mon, 10 Dec 2001 12:51:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAKovvU013901 for ; Mon, 10 Dec 2001 12:50:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25884 for ; Mon, 10 Dec 2001 12:50:59 -0800 (PST) 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 NAA02394 for ; Mon, 10 Dec 2001 13:51:35 -0700 (MST) 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 fBAKou911743; Mon, 10 Dec 2001 12:50:56 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAM31223; Mon, 10 Dec 2001 12:50:21 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA02603; Mon, 10 Dec 2001 12:50:55 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15381.8239.214214.388020@thomasm-u1.cisco.com> Date: Mon, 10 Dec 2001 12:50:55 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: "Charles E. Perkins" , "Erik Nordmark" Subject: Re: [mobile-ip] Re: Binding Update <--> bu3way In-Reply-To: <001f01c1811d$dbf955f0$ab6015ac@T23KEMPF> References: <001f01c1811d$dbf955f0$ab6015ac@T23KEMPF> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf writes: > Erik, > > > Do you think the basic 3-way for every update would perform well > enough? > > If the 3 way update needs to be done for every handover, then off the > top of my head, I think the > answer is no. It would, however, be useful to go through some > calculations to check this > intuition. Something that needs to be kept in mind here is that MN/CN updates are probably a long-haul operation. That is, if you are in any way dependent to their timeliness, to support the needed performance characteristics, you're probably already in trouble because they may need to go half way around the world. In this light, it may be that in combination with local convergence techniques -- FMIP, etc -- you can take the MN/CN binding update out of the critical handoff path in which case the performance of _any_ of these proposals is moot (handoffwise, that is). Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 16: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 QAA11707 for ; Mon, 10 Dec 2001 16:17:51 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11256; Mon, 10 Dec 2001 13:16:32 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20703; Mon, 10 Dec 2001 13:16:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALDpvU014083 for ; Mon, 10 Dec 2001 13:13:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALDpBF014082 for mobile-ip-dist; Mon, 10 Dec 2001 13:13:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALDmvU014073 for ; Mon, 10 Dec 2001 13:13:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01109 for ; Mon, 10 Dec 2001 13:13:19 -0800 (PST) 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 OAA12962 for ; Mon, 10 Dec 2001 14:13:53 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBALDCI00968 for ; Mon, 10 Dec 2001 22:13:12 +0100 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 WAA20311 for ; Mon, 10 Dec 2001 22:13:12 +0100 (MET) 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 fBALDCD18537 for ; Mon, 10 Dec 2001 22:13:12 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112102113.fBALDCD18537@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling In-reply-to: Your message of Sun, 09 Dec 2001 00:45:39 +0100. Date: Mon, 10 Dec 2001 22:13:12 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: As I just sent to the ipv6 list, I think the overloading of routing headers make it harder for firewalls to differentiate between MIPv6 use of routing headers as opposed to other routing headers (those where the different hops are for different nodes). This was pointed out in Pekka's draft if I remember correctly. I don't know how important this concern is. => I believe the concern will be for other/new usages of routing headers if firewall implementors support only the MIPv6 special case... Another reason to move this thread to the proper WG! Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 16:22: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 QAA11837 for ; Mon, 10 Dec 2001 16:22:44 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19943; Mon, 10 Dec 2001 14:20:47 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21769; Mon, 10 Dec 2001 13:21:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALJrvU014205 for ; Mon, 10 Dec 2001 13:19:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALJrr7014204 for mobile-ip-dist; Mon, 10 Dec 2001 13:19:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALJnvU014197 for ; Mon, 10 Dec 2001 13:19:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02939 for ; Mon, 10 Dec 2001 13:19:51 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06717 for ; Mon, 10 Dec 2001 14:19:50 -0700 (MST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 853C66A905; Mon, 10 Dec 2001 23:19:18 +0200 (EET) Message-ID: <3C1522D3.90605@piuha.net> Date: Mon, 10 Dec 2001 23:02:11 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Alexandru Petrescu Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: 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 Alexandru Petrescu wrote: > What would stop a malicious HA to flood CN with MN(HoA)->HA->CN > messages having the HoA of an attacked HA? I'm not sure I understand your attack, I think we pretty much have to trust the HA. And of course, anyone can spoof messages towards the CN so the CN must be prepared to deal with that in any case. Several proposals do that, in various ways. > I would prefer simpler schemes with a lesser number of messages, this > being presumably easier to secure. I liked a lot HACOOKIES where the > exchange was only: > > MN -> CN -> HA > CN <- HA Simpler is better of course. However, we do need to fulfil reasonable security requirements, and not introduce new attacks. Right now, there's a couple of attacks where we haven't decided yet if they are serious enough to require protection. These are: * HOA reflection attack from draft-savola * As a special case of the above, Erik discovered that you can do the reflection attack with some of the current weak authentication protocols. This is an example of a security scheme bringing along with itself new security problems. * 3rd party bombing attack from draft-aura For the first and third attacks we have some proposals that can prevent them. The protection of the second attack is being discussed in this thread. As far as I can see, HACOOKIES could potentially be vulnerable to the second attack. It seems to be vulnerable to the third attack as well, but only for attackers on the HA-CN path because the attacker would have to know the ha-mn cookie, at least if the CN public key is attached to the BUQR. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 16: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 QAA11848 for ; Mon, 10 Dec 2001 16:22:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20395; Mon, 10 Dec 2001 14:21:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21863; Mon, 10 Dec 2001 13:21:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALKWvU014221 for ; Mon, 10 Dec 2001 13:20:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALKVQV014220 for mobile-ip-dist; Mon, 10 Dec 2001 13:20:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALKPvU014213 for ; Mon, 10 Dec 2001 13:20:25 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03102 for ; Mon, 10 Dec 2001 13:20:27 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06876 for ; Mon, 10 Dec 2001 14:20:23 -0700 (MST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id D5E9A6A904; Mon, 10 Dec 2001 23:19:55 +0200 (EET) Message-ID: <3C1523F7.1070508@piuha.net> Date: Mon, 10 Dec 2001 23:07:03 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com, mroe@microsoft.com, tuomaura@microsoft.com Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: 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 >>I believe what we do with the CoA test can, if omitted, cause really serious >>damage. It's not just the low bandwidth nodes, the attack outlined in >>draft-aura (open tcp to yourself, take a look at the sequence numbers, then >>move the stream towards victim, possibly send a few TCP ACKs now and then to >>keep the stream going) appears to be able to easily flood larger nodes or >>whole networks due to the high amplification factor. It appears more serious >>than HOA reflection, where there's no amplification. However, the success of >>the attack depends on (a) ingress filtering being off in the attacker's >>network (irrelevant if it is on in the victim network). >> > > Why does ingress filtering need to be off? > > The attacker has the home address for the connection. > Thus it can send ACK packets from its home address while the > data packet are route optimized to go directly to the CoA (victim). > > Of course, in this case the victim sees the HoA in the packets which points > at the attacker. Spoofing allows the attacker to hide. Spoofing is necessary for the attacker to send the Weak Auth / Binding Update messages. These must appear as if they came from the CoA, otherwise the CN should immediately throw the messages away. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 16:33: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 QAA12030 for ; Mon, 10 Dec 2001 16:33:18 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27925; Mon, 10 Dec 2001 14:31:55 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24770; Mon, 10 Dec 2001 13:32:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALVMvU014456 for ; Mon, 10 Dec 2001 13:31:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALVMiJ014455 for mobile-ip-dist; Mon, 10 Dec 2001 13:31:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALVJvU014448 for ; Mon, 10 Dec 2001 13:31:19 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24516 for ; Mon, 10 Dec 2001 13:31:21 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21163 for ; Mon, 10 Dec 2001 14:31:56 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA08613 for ; Mon, 10 Dec 2001 13:31:19 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBALVJb30716 for ; Mon, 10 Dec 2001 13:31:19 -0800 X-mProtect: Mon, 10 Dec 2001 13:31:19 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpd9E8SwT; Mon, 10 Dec 2001 13:31:17 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id NAA33195 for ; Mon, 10 Dec 2001 13:31:17 -0800 (PST) Message-ID: <3C1529A5.C707875F@iprg.nokia.com> Date: Mon, 10 Dec 2001 13:31:17 -0800 From: "Jari T. Malinen" Organization: Nokia 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] Routing header Vs tunneling References: <976F7C55E3B2D111A0720008C728549C0CE58237@en0060exch001u.uk.lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Steve, > At 6:48 PM +0000 12/10/01, Casati, Alessio (Alessio) wrote: > >Location privacy is not obtained simply by disabling > >route optimization: the visited net addr (Care-of address) > >is revealed to the CN by sending to it IPv6 packets > >(with source address set to the CoA)... Not using the CoA as > >source address comes with some ingress filtering problems... > > You do bidirectional tunneling through the home agent when you want to > keep your location hidden from your corrrespondents (i.e., you disable > route optimization on both directions). The outer source address in > the tunneled packets from MH to HA is the care-of address, so it > gets through the ingress filters fine, and then gets removed by the > HA as a natural side-effect of decapsulation, before the packet goes > to the correspondent. Good idea. However, nodes not requiring this don't need to abandon route optimization and due to routing scalability reasons and single point of failure issue of the HA constantly on path, also route optimization is a desired feature. I see your suggestion as a possible new mode of operation for a new requirement. When adding new tasks and requirements for mobility beyond those in the charter, reverse tunneling to HA is very useful. We also suggested that in a draft, discussed in the monet (Mobile Networks) mailing list, cf http://search.ietf.org/internet-drafts/draft-kniveton-mobrtr-00.txt And, as you say, HAO need not be there, reverse tunneling works just with IP addresses in inner and outer packets. But, mobile routers were considered out of scope here.. > Steve BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 16:43: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 QAA12368 for ; Mon, 10 Dec 2001 16:43:44 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05326; Mon, 10 Dec 2001 14:41:44 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27228; Mon, 10 Dec 2001 13:41:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALfLvU014724 for ; Mon, 10 Dec 2001 13:41:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALfLM2014723 for mobile-ip-dist; Mon, 10 Dec 2001 13:41:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALfHvU014716 for ; Mon, 10 Dec 2001 13:41:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26368 for ; Mon, 10 Dec 2001 13:41:20 -0800 (PST) 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 OAA26314 for ; Mon, 10 Dec 2001 14:41:55 -0700 (MST) 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 fBALfE900931; Mon, 10 Dec 2001 13:41:18 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAM32628; Mon, 10 Dec 2001 13:40:39 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA02613; Mon, 10 Dec 2001 13:41:13 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15381.11257.296381.216881@thomasm-u1.cisco.com> Date: Mon, 10 Dec 2001 13:41:13 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: Alexandru Petrescu , Erik Nordmark Subject: Re: [mobile-ip] Risks of not verifying the care-of address In-Reply-To: <3C1522D3.90605@piuha.net> References: <3C1522D3.90605@piuha.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko writes: > Alexandru Petrescu wrote: > > > > What would stop a malicious HA to flood CN with MN(HoA)->HA->CN > > messages having the HoA of an attacked HA? > > > I'm not sure I understand your attack, I think we pretty much > have to trust the HA. And of course, anyone can spoof messages > towards the CN so the CN must be prepared to deal with that > in any case. Several proposals do that, in various ways. Ignore if this is noise. What happens if the HA and MN are in collusion? > > I would prefer simpler schemes with a lesser number of messages, this > > being presumably easier to secure. I liked a lot HACOOKIES where the > > exchange was only: > > > > MN -> CN -> HA > > CN <- HA Note that in COOKIES, the HA intervention was an optimization. Because of collusion, the security properties were really those of the MN and CN (ie, you can't make any assumptions about the trustworthiness of the HA). Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 16:44: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 QAA12404 for ; Mon, 10 Dec 2001 16:44:43 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA24241; Mon, 10 Dec 2001 13:43:39 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28118; Mon, 10 Dec 2001 13:43:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALgivU014768 for ; Mon, 10 Dec 2001 13:42:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALgi16014766 for mobile-ip-dist; Mon, 10 Dec 2001 13:42:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALgdvU014756 for ; Mon, 10 Dec 2001 13:42:40 -0800 (PST) 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 fBALgWq08336; Mon, 10 Dec 2001 22:42:33 +0100 (MET) Date: Mon, 10 Dec 2001 22:40:46 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Risks of not verifying the care-of address 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: > What would stop a malicious HA to flood CN with MN(HoA)->HA->CN > messages having the HoA of an attacked HA? Nothing, just like there isn't anything preventing the HA to send TCP SYN packets with HA as the source. In both cases the reply packet goes back to/through the HA. But I seem to have failed to communicate the problem here. A sending a packet to B which causes B to reply to A is not different than most protocols - TCP SYN, ICMP echo, DNS lookups, etc. A sending a packet to B which causes B to send a packet to C is quite different. That is my concern. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 16:47: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 QAA12447 for ; Mon, 10 Dec 2001 16:47:05 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20930; Mon, 10 Dec 2001 13:37:08 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25997; Mon, 10 Dec 2001 13:37:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALaQvU014560 for ; Mon, 10 Dec 2001 13:36:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALaQBv014559 for mobile-ip-dist; Mon, 10 Dec 2001 13:36:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALaLvU014549 for ; Mon, 10 Dec 2001 13:36:22 -0800 (PST) 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 fBALaCq07999; Mon, 10 Dec 2001 22:36:12 +0100 (MET) Date: Mon, 10 Dec 2001 22:34:29 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] Routing header Vs tunneling To: Glenn Morrow Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > - What happens if the MN moves away and other MN appears and > > acquires the same > > CoA? > > GM]The new mobile would have a new home address which could be used to > distinguish the two. Yes, but that home address would not be contained in the packet. So when the CN receives a packet from a CoA how can it tell that the CoA->HoA mapping has changed? > The home address would have had to be conveyed via some > signaling i.e. something like a binding update and the cache maintained. > This signaling needs to be authorized and authenticated in order to protect > against a mobile binding another mobile's home address to a particular COA. Yes, but who would do this binding update when? The old "owner" of the CoA might have just walked out of radio range. The new "owner" of the CoA doesn't know which CNs might have a binding cache entry. BTW: I think it would be useful for you to work out the details perhaps as a short I-D. > GM] Why would the mobile not want to use route optimization? I don't see why > a mobile would not want to use route optimization with every node if it were > available (ubiquitous). Limited resources - e.g. limited memory for the binding update list or wanting to limit the total amount of bandwidth or CPU spent on the binding update protocol. > > > > And I can't even imagine what the security issues would be in > > such a case. > > GM] As far as I can tell, the security issues are exactly the same > irrespective of whether the extra address is sent. The statement doesn't > detail any specific issue - by all means, please do. I'll do that once there is a complete proposal I can read. > GM]One thing is for sure, though. The layer-5 signaling-based node mobility > solutions gain in credibility each day the MIP spec is debated over and > incomplete. It is hard to tell who on the receiver list is FUDing and who is > not. I certainly don't believe you (Erik) are one of the FUD people. Thanks for the confidence. I'm am seriously concerned that we need the right security requirements for MIPv6 to avoid creating a new tool for DDoS attacks but I do realize that I am on a bit of thin ice since, even without MIPv6, there isn't a chosen path or paths for tracing back DoS attacks. So there isn't a very well known idea of what it means to not make it harder to deal with DDoS. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 16:47: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 QAA12506 for ; Mon, 10 Dec 2001 16:47:54 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA25994; Mon, 10 Dec 2001 13:46:57 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29787; Mon, 10 Dec 2001 13:46:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALkDvU014903 for ; Mon, 10 Dec 2001 13:46:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBALkDnt014902 for mobile-ip-dist; Mon, 10 Dec 2001 13:46:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALk9vU014890 for ; Mon, 10 Dec 2001 13:46:09 -0800 (PST) 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 NAA08814 for ; Mon, 10 Dec 2001 13:46:12 -0800 (PST) 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 NAA22808 for ; Mon, 10 Dec 2001 13:46:11 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA09577 for ; Mon, 10 Dec 2001 13:46:10 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBALkAM22712 for ; Mon, 10 Dec 2001 13:46:10 -0800 X-mProtect: Mon, 10 Dec 2001 13:46:10 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com(P1.5 smtpdiOgQxh; Mon, 10 Dec 2001 13:46:08 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id NAA33209 for ; Mon, 10 Dec 2001 13:46:08 -0800 (PST) Message-ID: <3C152D1F.F50C3679@iprg.nokia.com> Date: Mon, 10 Dec 2001 13:46:07 -0800 From: "Jari T. Malinen" Organization: Nokia 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] Routing header Vs tunneling References: <976F7C55E3B2D111A0720008C728549C0CE58237@en0060exch001u.uk.lucent.com> <15381.7475.640960.400363@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: > > Steve Deering writes: > > At 6:48 PM +0000 12/10/01, Casati, Alessio (Alessio) wrote: > > >Location privacy is not obtained simply by disabling > > >route optimization: the visited net addr (Care-of address) > > >is revealed to the CN by sending to it IPv6 packets > > >(with source address set to the CoA)... Not using the CoA as > > >source address comes with some ingress filtering problems... > > > > You do bidirectional tunneling through the home agent when you want to > > keep your location hidden from your corrrespondents (i.e., you disable > > route optimization on both directions). The outer source address in > > the tunneled packets from MH to HA is the care-of address, so it > > gets through the ingress filters fine, and then gets removed by the > > HA as a natural side-effect of decapsulation, before the packet goes > > to the correspondent. > > Right, and I think that given the hazard for the > CN with spooofed HAO, there needs to be a failsafe > way for the MN to communicate with the CN if, for > whatever reason, the CN will not accept the binding > updated. However, and this also applies to the early work we've done in mobile routers, if the scalability requirement of extending beyond infrastructures in authentication are taken seriously, also the leg from HA to CN is equally M to N tunneling: weak authentication (or something) would logically be needed even with the reverse tunneling via HA. > Mike BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 17:04: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 RAA12892 for ; Mon, 10 Dec 2001 17:04:48 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA22381; Mon, 10 Dec 2001 15:03:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03474; Mon, 10 Dec 2001 14:03:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAM2tvU015081 for ; Mon, 10 Dec 2001 14:02:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAM2tg8015080 for mobile-ip-dist; Mon, 10 Dec 2001 14:02:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAM2qvU015073 for ; Mon, 10 Dec 2001 14:02:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01090 for ; Mon, 10 Dec 2001 14:02:55 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21375 for ; Mon, 10 Dec 2001 15:02:54 -0700 (MST) 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 fBAM1H920996; Mon, 10 Dec 2001 14:01:18 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAM33004; Mon, 10 Dec 2001 13:54:27 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA02616; Mon, 10 Dec 2001 13:55:01 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15381.12085.355210.508271@thomasm-u1.cisco.com> Date: Mon, 10 Dec 2001 13:55:01 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: Alexandru Petrescu , Erik Nordmark Subject: Re: [mobile-ip] Risks of not verifying the care-of address 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: > > What would stop a malicious HA to flood CN with MN(HoA)->HA->CN > > messages having the HoA of an attacked HA? > > Nothing, just like there isn't anything preventing the HA to > send TCP SYN packets with HA as the source. In both cases the > reply packet goes back to/through the HA. > > But I seem to have failed to communicate the problem here. > > A sending a packet to B which causes B to reply to A is > not different than most protocols - TCP SYN, ICMP echo, DNS lookups, etc. > > A sending a packet to B which causes B to send a packet to C > is quite different. That is my concern. Indeed, however, is this possibly solvable by requiring CN to rate limit verifications? That is, when a CN sees a new HAO for which it doesn't have a cache entry, the only traffic it will send via tha HA is something that will verify that the MN is, in fact, reachable that way, and that that traffic is rate limited? I haven't managed to grok the amplification attack so I have no idea whether this would be generally helpful. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 17:22: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 RAA13259 for ; Mon, 10 Dec 2001 17:22:49 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04973; Mon, 10 Dec 2001 15:21:13 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16453; Mon, 10 Dec 2001 14:21:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAMKevU015211 for ; Mon, 10 Dec 2001 14:20:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAMKeIo015210 for mobile-ip-dist; Mon, 10 Dec 2001 14:20:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAMKbvU015203 for ; Mon, 10 Dec 2001 14:20:37 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA05109 for ; Mon, 10 Dec 2001 14:20:39 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23101 for ; Mon, 10 Dec 2001 15:20:39 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA11945; Mon, 10 Dec 2001 14:20:38 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBAMKcP00586; Mon, 10 Dec 2001 14:20:38 -0800 X-mProtect: Mon, 10 Dec 2001 14:20:38 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin24.iprg.nokia.com (205.226.20.218, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdKSvQ3s; Mon, 10 Dec 2001 14:20:36 PST Message-ID: <3C153511.2036B45C@iprg.nokia.com> Date: Mon, 10 Dec 2001 14:20:01 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tuomas Aura , Jari Arkko CC: mobile-ip@sunroof.eng.sun.com Subject: Assumption not made! Re: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-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 folks, While reading the abovementioned document, I came across the following passage: The assumption in Mobile IPv6, as in many other systems, seems to have been that generic security mechanism such as IPSec, IKE, and a public-key infrastructure (PKI) will eventually solve all authentication issues. But as co-author of the specification, I can assure you that no such assumption was ever made. In fact, the best way to express it, is that _no_ assumption about security infrastructure was made. I think this is quite appropriate, and is still a viable perspective. For one thing, since we didn't know what security infrastructure to use, it makes a lot of sense to me to avoid making assumptions about it. Any assumptions that we might have made would directly have had the effect of excluding some possible solutions. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 17:28: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 RAA13359 for ; Mon, 10 Dec 2001 17:28:19 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08904; Mon, 10 Dec 2001 15:26:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17995; Mon, 10 Dec 2001 14:27:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAMQWvU015325 for ; Mon, 10 Dec 2001 14:26:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAMQWjq015324 for mobile-ip-dist; Mon, 10 Dec 2001 14:26:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAMQTvU015317 for ; Mon, 10 Dec 2001 14:26:29 -0800 (PST) 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 OAA08487 for ; Mon, 10 Dec 2001 14:26:32 -0800 (PST) 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 OAA11721 for ; Mon, 10 Dec 2001 14:26:31 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA12277; Mon, 10 Dec 2001 14:26:31 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBAMQVj09373; Mon, 10 Dec 2001 14:26:31 -0800 X-mProtect: Mon, 10 Dec 2001 14:26:31 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin24.iprg.nokia.com (205.226.20.218, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd8T9yXf; Mon, 10 Dec 2001 14:26:28 PST Message-ID: <3C153670.6708B42D@iprg.nokia.com> Date: Mon, 10 Dec 2001 14:25:53 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Tuomas Aura , Jari Arkko CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-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 again folks, Isn't it true that much of this document deals with reasons why it's bad to accept unauthenticated Binding Updates? I don't see exactly why we have to keep solving that same problem, since as I have noted quite a few times we have already solved it by mandating authentication in every single revision of Mobile IPv6. I'm reminded that one can prove any theorem if one starts with a false assumption. But the goal should not be to refute every such theorem -- it's better to avoid making false assumptions in the first place... I'll try to take a closer look at the threats that do not involve failure to authenticate Binding Updates. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 17: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 ESMTP id RAA13657 for ; Mon, 10 Dec 2001 17:39:55 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17659; Mon, 10 Dec 2001 15:38:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21233; Mon, 10 Dec 2001 14:38:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAMc2vU015454 for ; Mon, 10 Dec 2001 14:38:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAMc2Lb015453 for mobile-ip-dist; Mon, 10 Dec 2001 14:38:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAMbwvU015446 for ; Mon, 10 Dec 2001 14:37:58 -0800 (PST) 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 fBAMbiq10574; Mon, 10 Dec 2001 23:37:49 +0100 (MET) Date: Mon, 10 Dec 2001 23:36:01 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Re: Binding Update <--> bu3way To: Charlie Perkins Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C14FB32.493436E1@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: > I think that in many situations it would be better to have a binding > security association established. OK. Good to know. > > I think this runs into "negotiate down" security threats. (I think it > > is draft-draft-aura-mipv6-bu-attacks-00.txt that talks about this.) > > For example, if a CN wants to use a high security as possible > > how can it prevent an attacker from forcing the use of the weak BU3WAY? > > If the correspondent node wants higher security, it doesn't have to > respond to bu3way protocol efforts, right? If you meant something > else, then maybe I have to look at the draft you cite. Yes, but it seems like the MN should be able to influence which security is required to accept its BU instead of only making it up to the CN. For instance imagine a MN that only wants to use the more secure method talking to a CN that supports both methods (it supports the weaker method for interoperability with MNs that use the weaker one). Then the MN can use the stronger method with that CN, but an attacker can attack using the weaker method. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 17:46: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 RAA13815 for ; Mon, 10 Dec 2001 17:46:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23884; Mon, 10 Dec 2001 14:45:14 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22638; Mon, 10 Dec 2001 14:45:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAMiWvU015568 for ; Mon, 10 Dec 2001 14:44:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAMiWTI015567 for mobile-ip-dist; Mon, 10 Dec 2001 14:44:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAMiPvU015551 for ; Mon, 10 Dec 2001 14:44:26 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24506 for ; Mon, 10 Dec 2001 17:44:28 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA06184 for mobile-ip@sunroof.eng.sun.com; Mon, 10 Dec 2001 17:45:04 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBALoHvU015017 for ; Mon, 10 Dec 2001 13:50:17 -0800 (PST) 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 NAA09823 for ; Mon, 10 Dec 2001 13:50:20 -0800 (PST) Received: from yahoo.com (bdsl.66.12.26.59.gte.net [66.12.26.59]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA25553 for ; Mon, 10 Dec 2001 13:50:19 -0800 (PST) Date: Mon, 10 Dec 2001 13:46:21 -0800 From: "Digital Coast Roundtable" Message-ID: To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Wednesday - 3rd Annual Digital Coast Holiday Reception X-Mailer: eMerge 1.65 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 Dear Member of the Digital Coast: You are invited to attend the 3rd Annual Digital Coast Holiday Reception on Wednesday, December 12 from 6:30 to 10:30 p.m. at the Wadsworth Theatre. This special networking event is presented by several technology and entertainment professional networking groups and will bring the Digital Coast community together for the biggest industry event of the year. There will be several speakers who will share useful information regarding economic growth, technology forecasts, employment opportunities, and the City's safety and security plans. The program will close with a live performance by the Los Angeles band Kneegirl. For more information: http://www.digitalcoast.org/events.html To RSVP: https://www.tieronenetwork.org/Holiday/RSVP.asp The 3rd Annual Digital Coast Holiday Reception Wednesday, December 12, 2001 6:30 - 10:30 p.m. Wadsworth Theatre Building 226 Eisenhower Avenue in the VA complex off the 405 http://www.gla.med.va.gov/maps/WadsworthTheatre.htm Brought to you by our sponsors: Pepperdine Center for Entrepreneurship and Technology Law http://law.pepperdine.edu/cetl/index.shtml Supporting Digital Coast Showcase Sponsors: Fontera Corporation http://www.fronteracorp.com iAgency http://www.iagency.com Stuart F. Cooper Co. http://www.sfcooper.com Tickets are $15 in advance or $20 at the door. To purchase tickets for this event, please visit https://www.tieronenetwork.org/Holiday/RSVP.asp Participating Organizations: Academy of Interactive Arts and Sciences Academy of Television Arts & Sciences Association of Internet Professionals - LA & OC FWE Southern California Internet Society - LA Chapter larta - the technology alliance for southern California Producers Guild of America PROMAX San Diego Regional Technology Alliance Society for Internet Advancement Software Council of Southern California Tier One UC Santa Barbara Digital Media Innovation Project - DiMI Women In Film Women in New Technologies Women in Technology International LA Women in Technology International OC Writers Guild of America, west Event to benefit Habitat for Humanity http://www.habitatla.org -- dcr29246-01%mobile-ip@sunroof.eng.sun.com From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 17:53: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 RAA13940 for ; Mon, 10 Dec 2001 17:53:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA26931; Mon, 10 Dec 2001 14:51:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24131; Mon, 10 Dec 2001 14:51:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAMolvU015667 for ; Mon, 10 Dec 2001 14:50:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBAMolji015666 for mobile-ip-dist; Mon, 10 Dec 2001 14:50:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBAMohvU015659 for ; Mon, 10 Dec 2001 14:50:43 -0800 (PST) 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 OAA03862 for ; Mon, 10 Dec 2001 14:50:46 -0800 (PST) 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 OAA22126 for ; Mon, 10 Dec 2001 14:50:42 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA13844; Mon, 10 Dec 2001 14:50:42 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBAMof816428; Mon, 10 Dec 2001 14:50:41 -0800 X-mProtect: Mon, 10 Dec 2001 14:50:41 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin31.iprg.nokia.com (205.226.20.225, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd0wtObz; Mon, 10 Dec 2001 14:50:39 PST Message-ID: <3C153C13.12D739CA@iprg.nokia.com> Date: Mon, 10 Dec 2001 14:49:55 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: Binding Update <--> bu3way 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, > Yes, but it seems like the MN should be able to influence which security > is required to accept its BU instead of only making it up to the CN. > > For instance imagine a MN that only wants to use the more secure method > talking to a CN that supports both methods (it supports the weaker method > for interoperability with MNs that use the weaker one). > Then the MN can use the stronger method with that CN, but an > attacker can attack using the weaker method. Maybe it would be a good idea to require that Binding Updates be authenticated with pre-established security associations whenever possible. If a malicious node attempts bu3way when the correspondent node already has a better security association established, then that might be deemed an error by the correspondent node. I know this isn't a complete solution, but at least it's a start. The details would depend on the final form of any key establishment protocol, probably. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 18:15: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 SAA14328 for ; Mon, 10 Dec 2001 18:15:42 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA07378; Mon, 10 Dec 2001 15:14:31 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19276; Mon, 10 Dec 2001 15:14:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANDTvU015912 for ; Mon, 10 Dec 2001 15:13:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBANDTXK015911 for mobile-ip-dist; Mon, 10 Dec 2001 15:13:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANDPvU015904 for ; Mon, 10 Dec 2001 15:13:25 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16896; Mon, 10 Dec 2001 15:13:26 -0800 (PST) Received: from sun.com (vpn-129-156-96-34.EMEA.Sun.COM [129.156.96.34]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id fBANDMe12595; Mon, 10 Dec 2001 15:13:22 -0800 (PST) Message-ID: <3C154120.27D8C9BF@sun.com> Date: Tue, 11 Dec 2001 00:11:28 +0100 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] Routing header Vs tunneling References: <200112102113.fBALDCD18537@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 Francis Dupont wrote: > As I just sent to the ipv6 list, I think the overloading of routing headers > make it harder for firewalls to differentiate between MIPv6 use of > routing headers as opposed to other routing headers (those where the different > hops are for different nodes). This was pointed out in Pekka's draft if > I remember correctly. > > I don't know how important this concern is. > > => I believe the concern will be for other/new usages of routing headers > if firewall implementors support only the MIPv6 special case... > Another reason to move this thread to the proper WG! Agree. This might put me on Glenn Morrow's FUD list, but here's an extreme position: I think this is where the IESG must step in. Yes, the MIP wg can go continue using RH/HAO, but I think it has been successfully demonstrated that tunneling with the zill/deering extensions can accomplish the same thing. It is the IESG's job to avoid proliferation of duplicate mechanisms. Better one well-known mechanism than a slew of them. Definitely true for security and firewalls point of view, so it can be couched in those terms. Notice that this nearly happened in IPv4 with Dave Johnson's minimal encapsulation (rfc2004) but it didn't gain much ground cuz only the MIP wg was pushing it. This new zill/deering option is now outside the MIP wg, where it should be. MIP wg should just adopt it, help spec it, push to put it on the fast-track and get it done. And yes, we should deprecate RH/HAO. Anything to make mobility less 'weird' and more in line with non-mobile wg's (IPv6) will save us problems down the road. asbestos shields on, -gabriel From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 18:21: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 SAA14418 for ; Mon, 10 Dec 2001 18:21:24 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18051; Mon, 10 Dec 2001 16:20:05 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA20875; Mon, 10 Dec 2001 15:20:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANJgvU015992 for ; Mon, 10 Dec 2001 15:19:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBANJgWM015991 for mobile-ip-dist; Mon, 10 Dec 2001 15:19:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANJbvU015984 for ; Mon, 10 Dec 2001 15:19:38 -0800 (PST) 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 fBANJTq13134; Tue, 11 Dec 2001 00:19:30 +0100 (MET) Date: Tue, 11 Dec 2001 00:17:38 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Risks of not verifying the care-of address To: Michael Thomas Cc: mobile-ip@sunroof.eng.sun.com, Alexandru Petrescu , Erik Nordmark In-Reply-To: "Your message with ID" <15381.12085.355210.508271@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: > > A sending a packet to B which causes B to send a packet to C > > is quite different. That is my concern. > > Indeed, however, is this possibly solvable > by requiring CN to rate limit verifications? > That is, when a CN sees a new HAO for which > it doesn't have a cache entry, the only traffic > it will send via tha HA is something that will > verify that the MN is, in fact, reachable that > way, and that that traffic is rate limited? In theory yes, but I have no idea what is a reasonable rate to plug into an implementation that runs on everything from my laptop to a 64+ processor server. Defense against TCP SYN attacks can detect when something unusual is going on (connections in SYN-RCVD timing out) and apply limits in that case. But since we don't want to create state (to avoid DoS) on the first packet I don't see how an implementation can determine when something unusual is going on. This leaves picking a magic "number of new BUs per second" rate out of a hat. > I haven't managed to grok the amplification > attack so I have no idea whether this would be > generally helpful. It isn't an amplification - one packet results in one packet. But the issue is that the victim sees a packet from B and has no way (other that getting B to collect packet traces) to find out that the packets are in fact generated because of A sending things to B. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 18:24: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 SAA14481 for ; Mon, 10 Dec 2001 18:24:56 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA11770; Mon, 10 Dec 2001 15:23:35 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21778; Mon, 10 Dec 2001 15:23:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANMpvU016058 for ; Mon, 10 Dec 2001 15:22:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBANMpd6016057 for mobile-ip-dist; Mon, 10 Dec 2001 15:22:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANMkvU016047 for ; Mon, 10 Dec 2001 15:22:47 -0800 (PST) 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 fBANMbq13249; Tue, 11 Dec 2001 00:22:37 +0100 (MET) Date: Tue, 11 Dec 2001 00:20:47 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Re: Binding Update <--> bu3way To: Charlie Perkins Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C153C13.12D739CA@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: > Maybe it would be a good idea to require that Binding Updates be > authenticated with pre-established security associations whenever > possible. If a malicious node attempts bu3way when the correspondent > node already has a better security association established, then that might > be deemed an error by the correspondent node. > > I know this isn't a complete solution, but at least it's a start. The > details would depend on the final form of any key establishment > protocol, probably. I don't think that is needed - picking a single method for securing BUs is probably the best (assuming the chairs can get concensus around that). BTW: You seem to have gone full circle back to requiring a PKI - or how would the pre-established SA be created? Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 18:33: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 SAA14710 for ; Mon, 10 Dec 2001 18:33:15 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27531; Mon, 10 Dec 2001 16:31:50 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23596; Mon, 10 Dec 2001 15:32:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANVHvU016217 for ; Mon, 10 Dec 2001 15:31:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBANVHWA016212 for mobile-ip-dist; Mon, 10 Dec 2001 15:31:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANVDvU016202 for ; Mon, 10 Dec 2001 15:31:13 -0800 (PST) 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 PAA13219; Mon, 10 Dec 2001 15:31:14 -0800 (PST) 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 PAA09457; Mon, 10 Dec 2001 15:31:14 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA16352; Mon, 10 Dec 2001 15:31:14 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBANVDR01821; Mon, 10 Dec 2001 15:31:13 -0800 X-mProtect: Mon, 10 Dec 2001 15:31:13 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin0.iprg.nokia.com (205.226.20.230, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdMOXgWA; Mon, 10 Dec 2001 15:31:11 PST Message-ID: <3C154583.AEA0E4E2@iprg.nokia.com> Date: Mon, 10 Dec 2001 15:30:11 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Mobile IP Working Group Subject: Re: [mobile-ip] Re: Binding Update <--> bu3way 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 don't think that is needed - picking a single method for securing BUs > is probably the best (assuming the chairs can get concensus around that). > > BTW: You seem to have gone full circle back to requiring a PKI - or how would > the pre-established SA be created? I didn't say anything about how the security association was to be created. If I don't know this, does it mean I require PKI? I myself like the idea of solving one piece of the puzzle at a time, instead of having to do everything all at once. So, I would much prefer it if we could figure out how to do security associations later. There's already good ways known about how to authenticate Binding Updates, once the security association is in place, which could potentially be done in any of several ways. I think it would be a mistake to require a one-size fits all method for establishing the necessary security associations at the mobile node. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 18:48: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 SAA14981 for ; Mon, 10 Dec 2001 18:48:28 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA21762; Mon, 10 Dec 2001 15:47:20 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27023; Mon, 10 Dec 2001 15:47:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANkRvU016421 for ; Mon, 10 Dec 2001 15:46:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBANkRxa016420 for mobile-ip-dist; Mon, 10 Dec 2001 15:46:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBANkOvU016413 for ; Mon, 10 Dec 2001 15:46:24 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06318; Mon, 10 Dec 2001 15:46:21 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23402; Mon, 10 Dec 2001 16:46:20 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA16867; Mon, 10 Dec 2001 15:46:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBANkJo15511; Mon, 10 Dec 2001 15:46:19 -0800 X-mProtect: Mon, 10 Dec 2001 15:46:19 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin0.iprg.nokia.com (205.226.20.230, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpd6uFoXJ; Mon, 10 Dec 2001 15:46:16 PST Message-ID: <3C154903.F3EDAF7F@iprg.nokia.com> Date: Mon, 10 Dec 2001 15:45:07 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Gabriel Montenegro CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling References: <200112102113.fBALDCD18537@givry.rennes.enst-bretagne.fr> <3C154120.27D8C9BF@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 Gabriel, gabriel montenegro wrote: > Francis Dupont wrote: > > > I don't know how important this concern is. > > > > => I believe the concern will be for other/new usages of routing headers > > if firewall implementors support only the MIPv6 special case... > > Another reason to move this thread to the proper WG! As I mentioned before, this particular use of the routing header is specific to Mobile IPv6, and thus should be handled in the mobile-ip working group. Moreover, I think that whatever uses the routing header will have, will each be specific for a particular purpose. Thus, I do not think that it makes sense to create anything more than very general guidelines within some over-arching working group effort. > I think this is where the IESG must step in. Yes, the MIP wg can go continue > using RH/HAO, but I think it has been successfully demonstrated that > tunneling with the zill/deering extensions can accomplish the same thing. It was already successfully demonstrated long before the Zill/Deering draft. I don't think that anyone has ever tried to argue that encapsulation was incapable of these operations. In fact, Mobile IPv4 had several LSR-based attempts, and we certainly know that encapsulation can do the same task in the context of IPv4. > It is the IESG's job to avoid proliferation of duplicate mechanisms. Better > one well-known mechanism than a slew of them. Definitely true for > security and firewalls point of view, so it can be couched in those terms. The mechanism you refer to is not on any standards track as far as I know. It might take quite a while to get it done. Furthermore, the encapsulation mechanisms do nothing to solve any security problems, and probably make the problems ever-so-slightly worse just because of their greater generality. > Notice that this nearly happened in IPv4 with Dave Johnson's minimal > encapsulation (rfc2004) but it didn't gain much ground cuz only the MIP wg was pushing > it. This new zill/deering option is now outside the MIP wg, where it should be. > MIP wg should just adopt it, help spec it, push to put it on the fast-track and get it done. It is a different case, not least because in IPv6 the encapsulation endpoint would be at the mobile node. This means more bytes over the air. > And yes, we should deprecate RH/HAO. Anything to make mobility less 'weird' and > more in line with non-mobile wg's (IPv6) will save us problems down the road. If we make everything sufficiently in-line with non-mobile protocols, we are likely to get non-mobility. But I know you didn't mean that. On the other hand, I would have thought that using Draft Standard IPv6 mechanisms was "O.K." according to almost any reasonable engineering criterion. Plus, they are in fact known to work after years of interoperability testing. > asbestos shields on, I'm not sure whether it's braver to go for complete upheaval and catharsis, and join in the fray, or to try to take the shortest most direct route towards completion. I'm going to stick with the latter. I don't have any shields, though, and it feels pretty crispy around here. I do know that catharsis "feels good" for a while, and might be satisfying, until the devil which had been residing in the details begins to re-establish its dominance over results once again. Given a bit of shared purpose, I think we have the tools at hand to satisfy the demands which were placed on us last year about this time, and I think we ought to go down that road as expediently as possible. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 20:15: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 UAA16133 for ; Mon, 10 Dec 2001 20:15:43 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA25984; Mon, 10 Dec 2001 17:14:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05815; Mon, 10 Dec 2001 17:14:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB1DHvU017012 for ; Mon, 10 Dec 2001 17:13:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB1DHDO017011 for mobile-ip-dist; Mon, 10 Dec 2001 17:13:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB1DEvU017004 for ; Mon, 10 Dec 2001 17:13:14 -0800 (PST) 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 RAA12593; Mon, 10 Dec 2001 17:13:15 -0800 (PST) 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 RAA19844; Mon, 10 Dec 2001 17:13:14 -0800 (PST) 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 fBB1Bd902666; Mon, 10 Dec 2001 17:13:12 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAM38094; Mon, 10 Dec 2001 17:10:41 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA02716; Mon, 10 Dec 2001 17:11:15 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15381.23859.593678.93683@thomasm-u1.cisco.com> Date: Mon, 10 Dec 2001 17:11:15 -0800 (PST) To: Erik Nordmark Cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com, Alexandru Petrescu Subject: Re: [mobile-ip] Risks of not verifying the care-of address In-Reply-To: References: <15381.12085.355210.508271@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: > > > > A sending a packet to B which causes B to send a packet to C > > > is quite different. That is my concern. > > > > Indeed, however, is this possibly solvable > > by requiring CN to rate limit verifications? > > That is, when a CN sees a new HAO for which > > it doesn't have a cache entry, the only traffic > > it will send via tha HA is something that will > > verify that the MN is, in fact, reachable that > > way, and that that traffic is rate limited? > > In theory yes, but I have no idea what is a reasonable rate to > plug into an implementation that runs on everything from my laptop > to a 64+ processor server. > > Defense against TCP SYN attacks can detect when something unusual > is going on (connections in SYN-RCVD timing out) and apply limits > in that case. > But since we don't want to create state (to avoid DoS) on the first > packet I don't see how an implementation can determine when something > unusual is going on. > This leaves picking a magic "number of new BUs per second" rate out > of a hat. Hmm. It seems to me that the only that is necessary is to make the input effort (BU's) from the attacker be greater than the output effort (verifies). That is, if the attacker doesn't get leverage through his reflectors, the attacker would either find some other leverage mechanism (oh say, IIS zombies), or just direct a spoofed flooding attack directly. I would think that rate limiting would make that true. Yes, you may end up with a state DoS attack on the refelector, but couldn't its effects be mitigated by separate accounting? This is, after all, supposed to be a cache. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 21:52: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 VAA17826 for ; Mon, 10 Dec 2001 21:52:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA26436; Mon, 10 Dec 2001 18:50:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA27656; Mon, 10 Dec 2001 18:50:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB2nLvU017325 for ; Mon, 10 Dec 2001 18:49:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB2nLO8017324 for mobile-ip-dist; Mon, 10 Dec 2001 18:49:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB2nIvU017317 for ; Mon, 10 Dec 2001 18:49:18 -0800 (PST) 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 SAA02340 for ; Mon, 10 Dec 2001 18:49:19 -0800 (PST) Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com [192.11.222.161]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24977 for ; Mon, 10 Dec 2001 18:49:19 -0800 (PST) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by ihemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fBB2nHW26964 for ; Mon, 10 Dec 2001 21:49:17 -0500 (EST) Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id VAA18528; Mon, 10 Dec 2001 21:49:13 -0500 (EST) Cc: mroe@microsoft.com, erik.nordmark@eng.sun.com Received: from lucent.com by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id VAA18524; Mon, 10 Dec 2001 21:49:12 -0500 (EST) Message-ID: <3C15742A.90307696@lucent.com> Date: Mon, 10 Dec 2001 21:49:14 -0500 From: Erik Anderlind X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Original-CC: mroe@microsoft.com, erik.nordmark@eng.sun.com Subject: Re: [mobile-ip] Risks of not verifying the care-of address 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, It seems another way a mobile node could deal with this reflection DoS is to change its COA through use of its favorite IPv6 address assignment method. Unless the attacker is explicitly notified about the change in mobile address, it seems it could not know what the new address is, and thus the duration of the attack is bounded. The proposal has the nice property of making it desireable to implement mechanisms for the mobile to generate "privacy" addresses (with random suffix), as otherwise it might be possible for attacker to guess the new address. Routers will eventually return "ICMP Unreachable" to CN and the later will redirect the stream back via the HA to the attacker!!! If the CN sees this happens many times, it could possibly blacklist the HA collaborating with the malicious node. ...Erik (a different Erik) Erik Nordmark wrote: > > Section 7.3 of says > The BAKE/2 and CAM-DH protocols described in this memo verify that > that packets sent to a mobile node's claimed care-of address reach an > entity that is willing to participate in the protocol. If this check > was not performed, a malicious mobile node could perform a denial of > service attack by asking a correspondent node to send it a high > volume stream of data, and then sending the correspondent a binding > update that redirects the stream of data to the victim of the denial > of service attack. > > But there seems to be a tradeoffs between this type of protection and > "3rd party reflection". > By this term I mean X sending a packet to A (with X as the source address) > which tells A to send packets to B. > ("Normal reflection" is based on spoofing the source address to cause > reply packets to go back to the wrong place.) > > BTW: bu3way has problem as well - the BUR sent from the CoA causes a BUC > to be sent to the Home Address. > > If sending a packet from a CoA (or HoA) to the CN causes packets to be > sent to the address that was not in the source field, then this is > "3rd party reflection". > > Such protocol mechanisms can be used to cause DoS attacks against low bandwidth > nodes as well. > > For instance, assume X and A have 100 Mbps bandwidth between then and B > only has 100 kbps bandwidth. > > Then X can send 100 Mbps of BU related packets (the first packet in > an exchange) to A. For DoS reasons A can't create state associated with > that first packet. If A sends the "response" packet to an IP address > other than the source address of the "request" then B might see on the order > of 100 MBps of packets coming towards it. > > And ingress filtering can't prevent this, ITRACE can't trace it back from B, > etc. > > So I think the conservative thing to do if there is a need to check with the > CoA as well as the HoA during BUs is to send more packets. > For instance, the MN could send packet1 both with CoA as the source > (causing a "response" to be sent to the CoA) and with HoA as the source > (reverse-tunneled through the HA). > Then when the has the information from both "responses" it can do the > actual BU. > > But it still isn't obvious to me that preventing packet flooding > attacks against a unwilling CoA is a requirement. Seems like there are other > means to flood a low-bandwidth node. > > Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 22:05:46 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18008 for ; Mon, 10 Dec 2001 22:05:46 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA00987; Mon, 10 Dec 2001 20:04:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA29501; Mon, 10 Dec 2001 19:04:33 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB33bvU017461 for ; Mon, 10 Dec 2001 19:03:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB33bQ4017460 for mobile-ip-dist; Mon, 10 Dec 2001 19:03:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB33XvU017453 for ; Mon, 10 Dec 2001 19:03:33 -0800 (PST) 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 fBB33Rq21284; Tue, 11 Dec 2001 04:03:27 +0100 (MET) Date: Tue, 11 Dec 2001 04:01:46 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Risks of not verifying the care-of address To: Michael Thomas Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com, Alexandru Petrescu In-Reply-To: "Your message with ID" <15381.23859.593678.93683@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: > Hmm. It seems to me that the only that is > necessary is to make the input effort (BU's) > from the attacker be greater than the output > effort (verifies). That is, if the attacker doesn't > get leverage through his reflectors, the attacker > would either find some other leverage mechanism > (oh say, IIS zombies), or just direct a spoofed > flooding attack directly. The way reflectors is used during DDoS attacks (Vern Paxon has paper on this) doesn't assume any packet amplication. The reflectors are just used to hide the IP addresses of the slaves. > I would think that rate limiting would make that > true. Yes, you may end up with a state DoS attack > on the refelector, but couldn't its effects be > mitigated by separate accounting? This is, after > all, supposed to be a cache. You continue to assert that rate limiting works so I'll continue to assert that I don't know whether 1 BU per second or 1 million BUs per second is too high. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 22:14:09 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18118 for ; Mon, 10 Dec 2001 22:14:09 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA05854; Mon, 10 Dec 2001 19:12:57 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA23930; Mon, 10 Dec 2001 19:12:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3CDvU017547 for ; Mon, 10 Dec 2001 19:12:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB3CD0N017546 for mobile-ip-dist; Mon, 10 Dec 2001 19:12:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3CAvU017539 for ; Mon, 10 Dec 2001 19:12:10 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04715 for ; Mon, 10 Dec 2001 19:12:11 -0800 (PST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA25971 for ; Mon, 10 Dec 2001 20:12:11 -0700 (MST) 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 fBB3CHQ21193 for ; Mon, 10 Dec 2001 21:12:17 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Dec 2001 21:12:10 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Dec 2001 21:12:12 -0600 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Risks of not verifying the care-of address Date: Mon, 10 Dec 2001 21:12:09 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD246@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Risks of not verifying the care-of address X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcGBjeMxrAipKe2AEdWrzAAIx6S5QwAY3bhw From: "Patil Basavaraj (NET/Dallas)" To: , "Claude Castelluccia" Cc: , X-OriginalArrivalTime: 11 Dec 2001 03:12:12.0778 (UTC) FILETIME=[A0CA04A0:01C181F1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBB3CAvU017540 Sender: owner-mobile-ip@sunroof.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 Homeless MN is not within the scope of the MIP WG at this time. -Basavaraj > > > -we wanted to support homeless MN. > > Just a note that as far as I know "homeless MN" isn't a requirement > the IETF work, at > least I've never seen a discussion whether or not it should > be a requirement. > > Erik > > From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 22:19: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 WAA18226 for ; Mon, 10 Dec 2001 22:19:08 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA10134; Mon, 10 Dec 2001 20:17:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24835; Mon, 10 Dec 2001 19:17:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3HAvU017663 for ; Mon, 10 Dec 2001 19:17:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB3HALY017662 for mobile-ip-dist; Mon, 10 Dec 2001 19:17:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3H6vU017655 for ; Mon, 10 Dec 2001 19:17:06 -0800 (PST) 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 TAA24750 for ; Mon, 10 Dec 2001 19:17:08 -0800 (PST) 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 TAA03862 for ; Mon, 10 Dec 2001 19:17:07 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBB3HDQ21294 for ; Mon, 10 Dec 2001 21:17:13 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Dec 2001 21:17:06 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Dec 2001 21:17:09 -0600 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 21:17:06 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD247@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Routing header Vs tunneling X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcGBq2oVldtSle2dEdWJVwAIx6TWpQARrwMQ From: "Patil Basavaraj (NET/Dallas)" To: Cc: "Erik Nordmark" , X-OriginalArrivalTime: 11 Dec 2001 03:17:09.0328 (UTC) FILETIME=[518BF500:01C181F2] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBB3H7vU017656 Sender: owner-mobile-ip@sunroof.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 > *At 11:35 AM -0600 12/10/01, Glenn Morrow wrote: > *>GM] Why would the mobile not want to use route optimization? > * > *For privacy reasons, the owner of the mobile device may not > *wish to reveal > *it's current location in the network to its correspondent(s). > * > *Steve > > Location privacy is not obtained simply by disabling > route optimization: the visited net addr (Care-of address) > is revealed to the CN by sending to it IPv6 packets > (with source address set to the CoA)... Not using the CoA as > source address comes with some ingress filtering problems... > You could always reverse tunnel to the HA if privacy was a concern. So at the cost of having packets tunnelled to you on the forward and reverse paths, you could achieve privacy. -Basavaraj > > > Alessio > From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 22:19: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 WAA18249 for ; Mon, 10 Dec 2001 22:19:41 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA10938; Mon, 10 Dec 2001 20:18:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24963; Mon, 10 Dec 2001 19:18:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3HwvU017680 for ; Mon, 10 Dec 2001 19:17:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB3Hw4B017679 for mobile-ip-dist; Mon, 10 Dec 2001 19:17:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3HsvU017672 for ; Mon, 10 Dec 2001 19:17:54 -0800 (PST) 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 fBB3Hnq21884; Tue, 11 Dec 2001 04:17:51 +0100 (MET) Date: Tue, 11 Dec 2001 04:16:05 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Risks of not verifying the care-of address To: Erik Anderlind Cc: mobile-ip@sunroof.eng.sun.com, mroe@microsoft.com, erik.nordmark@eng.sun.com In-Reply-To: "Your message with ID" <3C15742A.90307696@lucent.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: > It seems another way a mobile node could deal with this > reflection DoS is to change its COA through use of its > favorite IPv6 address assignment method. Unless > the attacker is explicitly notified about the change > in mobile address, it seems it could not know what the > new address is, and thus the duration of the attack > is bounded. The reflection attack doesn't necessarily attack small mobile nodes - it might be public web servers as in the DDoS attacks that was in the news two years ago. Those nodes don't want to change their IP address. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 22:22: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 WAA18309 for ; Mon, 10 Dec 2001 22:22:02 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12790; Mon, 10 Dec 2001 20:20:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA25407; Mon, 10 Dec 2001 19:20:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3KFvU017790 for ; Mon, 10 Dec 2001 19:20:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB3KEb5017789 for mobile-ip-dist; Mon, 10 Dec 2001 19:20:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3KBvU017782 for ; Mon, 10 Dec 2001 19:20:11 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01387 for ; Mon, 10 Dec 2001 19:20:12 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11515 for ; Mon, 10 Dec 2001 20:20:11 -0700 (MST) Received: from kolumbus.fi (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id BB15A6A905; Tue, 11 Dec 2001 05:19:59 +0200 (EET) Message-ID: <3C157B62.2010706@kolumbus.fi> Date: Tue, 11 Dec 2001 05:20:02 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Charlie Perkins Cc: Tuomas Aura , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] I-D ACTION:draft-aura-mipv6-bu-attacks-00.txt References: <3C153670.6708B42D@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > Isn't it true that much of this document deals with reasons > why it's bad to accept unauthenticated Binding Updates? > > I don't see exactly why we have to keep solving that > same problem, since as I have noted quite a few times > we have already solved it by mandating authentication in > every single revision of Mobile IPv6. Charlie, We certainly didn't mean to imply anything about past versions of Mobile IPv6. Even if we are now putting infrastructureless authentication (used to be called weak authentication) to the protocol we realize well that this isn't the first time someone's come up with the idea that perhaps the BUs should be protected somehow. However, we are trying to design the infrastructureless authentication mechanisms and in doing so we *need* to understand what the problems are, what kinds of attacks are possible. Draft-aura-mipv6-bu-attacks-00.txt is an attempt at that. It does tell you about the dangers of unauthenticated binding updates. But it also tells you about some perhaps not so obvious dangers, such as what could happen to third parties, or what could happen to an authentication protocol if it didn't take in account denial of service issues. It boils down to understanding what "authentication" means for MIPv6. Please don't take any described problems as claims that this is the first time they are being considered. This isn't implied. I'm looking forward to your comments on e.g. whether you think all relevant authentication DoS dangers are listed, whether we have listed all "tools" we have at hand for infrastructureless authentication, and so on. We'd very much appreciate feedback on those issues. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 22:46: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 WAA19537 for ; Mon, 10 Dec 2001 22:46:40 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA27422; Mon, 10 Dec 2001 20:45:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA28444; Mon, 10 Dec 2001 19:45:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3iavU018006 for ; Mon, 10 Dec 2001 19:44:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB3iaSL018005 for mobile-ip-dist; Mon, 10 Dec 2001 19:44:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3iWvU017998 for ; Mon, 10 Dec 2001 19:44:32 -0800 (PST) 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 TAA16498 for ; Mon, 10 Dec 2001 19:44:34 -0800 (PST) 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 TAA13479 for ; Mon, 10 Dec 2001 19:44:33 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBB3idQ21851 for ; Mon, 10 Dec 2001 21:44:39 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Dec 2001 21:44:32 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Dec 2001 21:44:35 -0600 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 21:44:31 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD248@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Routing header Vs tunneling X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcGB0HzZXf6B2e3BEdWxMQAIx6TWeAAJZVcQ From: "Patil Basavaraj (NET/Dallas)" To: Cc: X-OriginalArrivalTime: 11 Dec 2001 03:44:35.0178 (UTC) FILETIME=[268CBCA0:01C181F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBB3iXvU017999 Sender: owner-mobile-ip@sunroof.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 >Agree. This might put me on Glenn Morrow's FUD list, but here's an >extreme position: > Extreme indeed :) >I think this is where the IESG must step in. Yes, the MIP wg can go continue >using RH/HAO, but I think it has been successfully demonstrated that >tunneling with the zill/deering extensions can accomplish the same thing. >It is the IESG's job to avoid proliferation of duplicate mechanisms. Better >one well-known mechanism than a slew of them. Definitely true for >security and firewalls point of view, so it can be couched in those >terms. MIPv6 has been worked on for over five years now. The proposal to drop RH/HAO is equivalent to going back to square one and starting to redesign the IP mobility protocol. I think the IESG would be moving the yardstick on IP mobility a few years back if we decide to take this approach. If you want the perfect solution for IP mobility, then we may as well wait for a few more years and wish that an even better solution for moving packets between MNs and CNs comes up. Or we could take the current solution with the RH/HAO to completion and see if we can have a working solution today. If you really want to redesign IP mobility, there is nothing to stop you from doing so. But I do not believe it has to be at the cost of stopping the MIPv6 work in its tracks. I think we have spent more than enough time on trying to solve this problem. We have a few solutions that will fix the problem. Lets get this done now and then maybe go back to thinking better ways of doing tunnelling and mobility. > >Notice that this nearly happened in IPv4 with Dave Johnson's minimal >encapsulation (rfc2004) but it didn't gain much ground cuz only the >MIP wg was pushing it. This new zill/deering option is now outside >the MIP wg, where it should be. MIP wg should just adopt it, help >spec it, push to put it on the fast-track and get it done. > And spend the next few years without a solution for IPv6 mobility? I would not even consider this as an option for MIP WG to consider at this time. >And yes, we should deprecate RH/HAO. Anything to make mobility less >'weird' and more in line with non-mobile wg's (IPv6) will save us >problems down the road. Maybe while the IESG is thinking of deprecating the RH and DO headers, they could consider a few others as well :( Sorry if this sounds so negative, but we seem to be digging a deeper hole to get ourselves into. > >asbestos shields on, > >-gabriel -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 22:53: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 WAA19607 for ; Mon, 10 Dec 2001 22:53:52 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA01965; Mon, 10 Dec 2001 20:52:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA29223; Mon, 10 Dec 2001 19:52:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3q1vU018107 for ; Mon, 10 Dec 2001 19:52:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB3q1vb018106 for mobile-ip-dist; Mon, 10 Dec 2001 19:52:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB3pwvU018099 for ; Mon, 10 Dec 2001 19:51:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17100 for ; Mon, 10 Dec 2001 19:52:00 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17441 for ; Mon, 10 Dec 2001 20:51:59 -0700 (MST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id C45016A905; Tue, 11 Dec 2001 05:51:46 +0200 (EET) Message-ID: <3C157D6F.3040305@piuha.net> Date: Tue, 11 Dec 2001 05:28:47 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: mat@cisco.com Cc: mobile-ip@sunroof.eng.sun.com, Alexandru Petrescu , Erik Nordmark Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: <15381.12085.355210.508271@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > A sending a packet to B which causes B to send a packet to C > > is quite different. That is my concern. > > Indeed, however, is this possibly solvable > by requiring CN to rate limit verifications? > That is, when a CN sees a new HAO for which > it doesn't have a cache entry, the only traffic > it will send via tha HA is something that will > verify that the MN is, in fact, reachable that > way, and that that traffic is rate limited? Unfortunately, each CN could be seeing just a single packet, while a large number of CNs could be used by the attacker to send individual packets to a single victim. But even so, I'm not exactly sure how serious these attacks are. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 23:05: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 XAA19794 for ; Mon, 10 Dec 2001 23:05:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA26793; Mon, 10 Dec 2001 20:04:22 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00767; Mon, 10 Dec 2001 20:04:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB43WvU018236 for ; Mon, 10 Dec 2001 20:03:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB43VdA018235 for mobile-ip-dist; Mon, 10 Dec 2001 20:03:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB43SvU018228 for ; Mon, 10 Dec 2001 20:03:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00684 for ; Mon, 10 Dec 2001 20:03:30 -0800 (PST) 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 VAA10842 for ; Mon, 10 Dec 2001 21:03:11 -0700 (MST) 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 fBB43P911545; Mon, 10 Dec 2001 20:03:25 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAM41105; Mon, 10 Dec 2001 20:02:50 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA02766; Mon, 10 Dec 2001 20:03:24 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15381.34188.439007.801323@thomasm-u1.cisco.com> Date: Mon, 10 Dec 2001 20:03:24 -0800 (PST) To: jari.arkko@piuha.net Cc: mat@cisco.com, mobile-ip@sunroof.eng.sun.com, Alexandru Petrescu , Erik Nordmark Subject: Re: [mobile-ip] Risks of not verifying the care-of address In-Reply-To: <3C157D6F.3040305@piuha.net> References: <15381.12085.355210.508271@thomasm-u1.cisco.com> <3C157D6F.3040305@piuha.net> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko writes: > Michael Thomas wrote: > > > A sending a packet to B which causes B to send a packet to C > > > is quite different. That is my concern. > > > > Indeed, however, is this possibly solvable > > by requiring CN to rate limit verifications? > > That is, when a CN sees a new HAO for which > > it doesn't have a cache entry, the only traffic > > it will send via tha HA is something that will > > verify that the MN is, in fact, reachable that > > way, and that that traffic is rate limited? > > Unfortunately, each CN could be seeing just a single > packet, while a large number of CNs could be used > by the attacker to send individual packets to a > single victim. If a CN rate limited its BU processing (which may be good idea anyway just to protect against broken MN's), that means that an attacker would only get a fraction of output of each CN it contacts. Yes, it's still a reflector attack, but it wouldn't even be break even for the attacker's effort. This doesn't seem like a very fertile ground; you can do the same thing source spoofing SYN's probably with higher efficiency. It's only if the attacker gets amplification that we should worry. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 23:17:24 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19953 for ; Mon, 10 Dec 2001 23:17:24 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA17134; Mon, 10 Dec 2001 21:16:05 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA02025; Mon, 10 Dec 2001 20:16:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4FEvU018340 for ; Mon, 10 Dec 2001 20:15:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB4FDM8018339 for mobile-ip-dist; Mon, 10 Dec 2001 20:15:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4F9vU018329 for ; Mon, 10 Dec 2001 20:15:09 -0800 (PST) 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 UAA01882 for ; Mon, 10 Dec 2001 20:15:11 -0800 (PST) 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 UAA01597 for ; Mon, 10 Dec 2001 20:15:11 -0800 (PST) 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 fBB4GGQ20886 for ; Mon, 10 Dec 2001 22:16:16 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Dec 2001 22:15:10 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Dec 2001 22:15:12 -0600 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 22:15:09 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF446D07E0@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C181FA.6BCBC30C" Thread-Topic: [mobile-ip] Routing header Vs tunneling X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcGBsjh7YVedse2lEdWxMQAIx6TWeAARwODA From: "Patil Basavaraj (NET/Dallas)" To: Cc: "Erik Nordmark" , X-OriginalArrivalTime: 11 Dec 2001 04:15:12.0241 (UTC) FILETIME=[6D864E10:01C181FA] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------_=_NextPart_001_01C181FA.6BCBC30C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Glenn Morrow wrote: >Thanks for bringing this up. BTW if the definition of location privacy is just the snoopers then your previous SUCV/anonymity work could handle that. Well just to make it clear, location privacy is not a requirement for Mobile IPv6 at this time. We had location privacy as a separate work item in the MIP charter/milsetones earlier but that is a separate problem and needs to be dealt as such.=20 =20 -Basavaraj >Anyway thanks again for bringing up this point.=20 >Glenn=20 ------_=_NextPart_001_01C181FA.6BCBC30C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

Glenn Morrow wrote:

>Thanks for = bringing=20 this up. BTW if the definition of location privacy is just the snoopers = then=20 your previous SUCV/anonymity =20 work could handle that.

Well just to make it = clear,=20 location privacy is not a requirement for Mobile IPv6 at this time. We = had=20 location privacy as a separate work item in the MIP charter/milsetones = earlier=20 but that is a separate problem and needs to be dealt as such. =

 

-Basavaraj

>Anyway = thanks again=20 for bringing up this point.

>Glenn=20

------_=_NextPart_001_01C181FA.6BCBC30C-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 23:17: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 XAA19965 for ; Mon, 10 Dec 2001 23:17:29 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA17159; Mon, 10 Dec 2001 21:16:07 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA02036; Mon, 10 Dec 2001 20:16:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4FBvU018337 for ; Mon, 10 Dec 2001 20:15:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB4FBjW018336 for mobile-ip-dist; Mon, 10 Dec 2001 20:15:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4F7vU018322 for ; Mon, 10 Dec 2001 20:15:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA19809 for ; Mon, 10 Dec 2001 20:15:09 -0800 (PST) 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 VAA16670 for ; Mon, 10 Dec 2001 21:14:50 -0700 (MST) 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 fBB4FEQ22989 for ; Mon, 10 Dec 2001 22:15:14 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 10 Dec 2001 22:15:07 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Dec 2001 22:15:07 -0600 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Re: Binding Update <--> bu3way Date: Mon, 10 Dec 2001 22:15:06 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF446D07DF@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Re: Binding Update <--> bu3way X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcGBvIvG+aSj7+2tEdWrzAAIx6S5QwAO+68Q From: "Patil Basavaraj (NET/Dallas)" To: Cc: "Perkins Charles (IPRG)" , "Erik Nordmark" X-OriginalArrivalTime: 11 Dec 2001 04:15:07.0741 (UTC) FILETIME=[6AD7A8D0:01C181FA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBB4F7vU018323 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > > James Kempf writes: > > Erik, > > > > > Do you think the basic 3-way for every update would perform well > > enough? > > > > If the 3 way update needs to be done for every handover, > then off the > > top of my head, I think the > > answer is no. It would, however, be useful to go through some > > calculations to check this > > intuition. > > Something that needs to be kept in mind here is that > MN/CN updates are probably a long-haul operation. That > is, if you are in any way dependent to their timeliness, > to support the needed performance characteristics, you're > probably already in trouble because they may need to go > half way around the world. > > In this light, it may be that in combination with local > convergence techniques -- FMIP, etc -- you can take the > MN/CN binding update out of the critical handoff path in > which case the performance of _any_ of these proposals > is moot (handoffwise, that is). > LMM solutions are specifically intended for scenarios wherein your CN and HA could be distant and it is optimal to limit the number of BUs that you send to these nodes. > Mike > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 23:18:45 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19990 for ; Mon, 10 Dec 2001 23:18:44 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA17886; Mon, 10 Dec 2001 21:17:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA02369; Mon, 10 Dec 2001 20:17:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4GivU018373 for ; Mon, 10 Dec 2001 20:16:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB4GimR018370 for mobile-ip-dist; Mon, 10 Dec 2001 20:16:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4GdvU018362 for ; Mon, 10 Dec 2001 20:16:40 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA19948 for ; Mon, 10 Dec 2001 20:16:41 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA09442 for ; Mon, 10 Dec 2001 21:16:41 -0700 (MST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Dec 2001 20:16:40 -0800 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 10 Dec 2001 20:16:40 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Dec 2001 20:16:40 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 10 Dec 2001 20:16:40 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Mon, 10 Dec 2001 20:15:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6092.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 20:15:11 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102DB7E87@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [mobile-ip] Routing header Vs tunneling Thread-Index: AcGB0JWDfcTkMiwkRBm3ppUIghzUGAAKYnZQ From: "Dave Thaler" To: X-OriginalArrivalTime: 11 Dec 2001 04:15:12.0641 (UTC) FILETIME=[6DC35710:01C181FA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBB4GevU018363 Sender: owner-mobile-ip@sunroof.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 Gabriel montenegro [mailto:gab@sun.com] [snip] > And yes, we should deprecate RH/HAO. Anything to make mobility less > 'weird' and > more in line with non-mobile wg's (IPv6) will save us problems down the > road. > > asbestos shields on, I agree with Gabriel, and believe this could be done without slowing down the spec (i.e., could be done faster than the security). By simplifying processing (and yes I'm saying it does), I completely agree that it solves various problems now and probably a bunch more we don't know about yet. I don't think it puts anything back to square one. -Dave From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 23:19: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 XAA20041 for ; Mon, 10 Dec 2001 23:19:43 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18721; Mon, 10 Dec 2001 21:18:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA02654; Mon, 10 Dec 2001 20:18:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4HevU018472 for ; Mon, 10 Dec 2001 20:17:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB4HeIJ018470 for mobile-ip-dist; Mon, 10 Dec 2001 20:17:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4HavU018460 for ; Mon, 10 Dec 2001 20:17:36 -0800 (PST) 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 UAA06890 for ; Mon, 10 Dec 2001 20:17:39 -0800 (PST) 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 UAA02488 for ; Mon, 10 Dec 2001 20:17:38 -0800 (PST) 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 fBB4Hb918661; Mon, 10 Dec 2001 20:17:37 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAM41319; Mon, 10 Dec 2001 20:17:02 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA02793; Mon, 10 Dec 2001 20:17:36 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15381.35040.371859.611749@thomasm-u1.cisco.com> Date: Mon, 10 Dec 2001 20:17:36 -0800 (PST) To: Erik Nordmark Cc: Michael Thomas , mobile-ip@sunroof.eng.sun.com, Alexandru Petrescu Subject: Re: [mobile-ip] Risks of not verifying the care-of address In-Reply-To: References: <15381.23859.593678.93683@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: > > > Hmm. It seems to me that the only that is > > necessary is to make the input effort (BU's) > > from the attacker be greater than the output > > effort (verifies). That is, if the attacker doesn't > > get leverage through his reflectors, the attacker > > would either find some other leverage mechanism > > (oh say, IIS zombies), or just direct a spoofed > > flooding attack directly. > > The way reflectors is used during DDoS attacks (Vern Paxon has paper > on this) doesn't assume any packet amplication. > The reflectors are just used to hide the IP addresses of the slaves. Yes, this is a legitimate concern, but you can do the same thing by source spoofing SYN's. It's amplification that makes these attacks attractive though. > > I would think that rate limiting would make that > > true. Yes, you may end up with a state DoS attack > > on the refelector, but couldn't its effects be > > mitigated by separate accounting? This is, after > > all, supposed to be a cache. > > You continue to assert that rate limiting works so I'll continue > to assert that I don't know whether 1 BU per second or 1 million BUs per > second is too high. "Works" is too strong a word. "Makes less attractive" is more like it. At some level, that's what DoS avoidance is all about. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 23:20: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 XAA20058 for ; Mon, 10 Dec 2001 23:20:05 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18801; Mon, 10 Dec 2001 21:18:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA02717; Mon, 10 Dec 2001 20:18:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4HnvU018496 for ; Mon, 10 Dec 2001 20:17:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB4Hn5g018495 for mobile-ip-dist; Mon, 10 Dec 2001 20:17:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4HivU018488 for ; Mon, 10 Dec 2001 20:17:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA06910 for ; Mon, 10 Dec 2001 20:17:46 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA17956; Mon, 10 Dec 2001 21:17:27 -0700 (MST) Received: from T23KEMPF (dhcp53.docomo-usa.com [172.21.96.53]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBB4HiJ29881; Mon, 10 Dec 2001 20:17:44 -0800 (PST) Message-ID: <00ad01c181fa$8ee2a630$566015ac@T23KEMPF> From: "James Kempf" To: Cc: References: <697DAA22C5004B4596E033803A7CEF444CD248@daebe007.NOE.Nokia.com> Subject: Re: [mobile-ip] Routing header Vs tunneling Date: Mon, 10 Dec 2001 20:16:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Raj, I agree with your position. We need to get MIPv6 to RFC yesterday, so that we can start the process of productization and deployment in earnest. The place for research work on next-generation mobility protocols is the IRTF Micromobility Routing group. jak ----- Original Message ----- From: "Patil Basavaraj (NET/Dallas)" To: Cc: Sent: Monday, December 10, 2001 7:44 PM Subject: RE: [mobile-ip] Routing header Vs tunneling > >Agree. This might put me on Glenn Morrow's FUD list, but here's an > >extreme position: > > > > Extreme indeed :) > > >I think this is where the IESG must step in. Yes, the MIP wg can go > continue > >using RH/HAO, but I think it has been successfully demonstrated that > >tunneling with the zill/deering extensions can accomplish the same > thing. > >It is the IESG's job to avoid proliferation of duplicate mechanisms. > Better > >one well-known mechanism than a slew of them. Definitely true for > >security and firewalls point of view, so it can be couched in those > >terms. > > MIPv6 has been worked on for over five years now. The proposal to drop > RH/HAO is equivalent to going back to square one and starting to > redesign the IP mobility protocol. I think the IESG would be moving > the yardstick on IP mobility a few years back if we decide to take > this approach. If you want the perfect solution for IP mobility, then > we may as well wait for a few more years and wish that an even better > solution for moving packets between MNs and CNs comes up. Or we could > take the current solution with the RH/HAO to completion and see if we > can have a working solution today. > > If you really want to redesign IP mobility, there is nothing to stop > you from doing so. But I do not believe it has to be at the cost of > stopping the MIPv6 work in its tracks. I think we have spent more than > enough time on trying to solve this problem. We have a few solutions > that will fix the problem. Lets get this done now and then maybe go > back to thinking better ways of doing tunnelling and mobility. > > > > >Notice that this nearly happened in IPv4 with Dave Johnson's minimal > >encapsulation (rfc2004) but it didn't gain much ground cuz only the > >MIP wg was pushing it. This new zill/deering option is now outside > >the MIP wg, where it should be. MIP wg should just adopt it, help > >spec it, push to put it on the fast-track and get it done. > > > > And spend the next few years without a solution for IPv6 mobility? I > would not even consider this as an option for MIP WG to consider at > this time. > > >And yes, we should deprecate RH/HAO. Anything to make mobility less > >'weird' and more in line with non-mobile wg's (IPv6) will save us > >problems down the road. > > Maybe while the IESG is thinking of deprecating the RH and DO headers, > they could consider a few others as well :( Sorry if this sounds so > negative, but we seem to be digging a deeper hole to get ourselves > into. > > > > >asbestos shields on, > > > >-gabriel > > -Basavaraj > From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 23:21: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 XAA20111 for ; Mon, 10 Dec 2001 23:21:33 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA02185; Mon, 10 Dec 2001 20:20:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA03150; Mon, 10 Dec 2001 20:20:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4JivU018703 for ; Mon, 10 Dec 2001 20:19:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB4JiE9018700 for mobile-ip-dist; Mon, 10 Dec 2001 20:19:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4JevU018686 for ; Mon, 10 Dec 2001 20:19:40 -0800 (PST) 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 UAA07075 for ; Mon, 10 Dec 2001 20:19:42 -0800 (PST) Received: from netmail2.alcatel.com (netmail2.alcatel.com [128.251.168.51]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA27296 for ; Mon, 10 Dec 2001 20:19:41 -0800 (PST) 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 WAA19461; Mon, 10 Dec 2001 22:19:06 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id fBB4J4s20875; Mon, 10 Dec 2001 22:19:04 -0600 (CST) Message-ID: <3C15890F.2010209@alcatel.com> Date: Mon, 10 Dec 2001 22:18:23 -0600 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com CC: seamoby@ietf.org Subject: Re: [mobile-ip] L2 triggers draft References: <0C1353ABB1DEB74DB067ADFF749C4EEF6E5E06@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit John et al., I suggest having a pre BOF meeting here at SLC. Maybe Wednesday night? john.loughney@nokia.com wrote: >Hi all, > >>My opinion is, among existing working groups it best fits PILC. >> >>But, if we want to do a better job (more than L2 triggers), then I'd >>recommend forming a new Sub-IP working group: IP over Wireless. >> > >Its too late for Salt Lake City & maybe too early for Minneapolis, >but I think a bof on this general area would be useful. In >NSIS, there is some discussion on if/how you could tie air >interface (layer 2) QoS properties into layer 3. I think >a BOF with some general discussion on the problem area(s), at >least to give some scope to the problem would be very interesting. >We want to make sure we don't go 'ocean-boiling' .... > >best regards, >John > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 23: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 XAA20468 for ; Mon, 10 Dec 2001 23:32:14 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA04486; Mon, 10 Dec 2001 20:31:12 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA04421; Mon, 10 Dec 2001 20:31:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4TsvU018938 for ; Mon, 10 Dec 2001 20:29:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB4TscL018937 for mobile-ip-dist; Mon, 10 Dec 2001 20:29:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4TpvU018930 for ; Mon, 10 Dec 2001 20:29:51 -0800 (PST) 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 UAA08223; Mon, 10 Dec 2001 20:29:53 -0800 (PST) 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 UAA01193; Mon, 10 Dec 2001 20:29:53 -0800 (PST) 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 fBB4Tq924535; Mon, 10 Dec 2001 20:29:52 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAM41495; Mon, 10 Dec 2001 20:29:17 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id UAA02797; Mon, 10 Dec 2001 20:29:51 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15381.35775.382231.927467@thomasm-u1.cisco.com> Date: Mon, 10 Dec 2001 20:29:51 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: "Perkins Charles (IPRG)" , "Erik Nordmark" Subject: RE: [mobile-ip] Re: Binding Update <--> bu3way In-Reply-To: <697DAA22C5004B4596E033803A7CEF446D07DF@daebe007.NOE.Nokia.com> References: <697DAA22C5004B4596E033803A7CEF446D07DF@daebe007.NOE.Nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Patil Basavaraj (NET/Dallas) writes: > > > > James Kempf writes: > > > Erik, > > > > > > > Do you think the basic 3-way for every update would perform well > > > enough? > > > > > > If the 3 way update needs to be done for every handover, > > then off the > > > top of my head, I think the > > > answer is no. It would, however, be useful to go through some > > > calculations to check this > > > intuition. > > > > Something that needs to be kept in mind here is that > > MN/CN updates are probably a long-haul operation. That > > is, if you are in any way dependent to their timeliness, > > to support the needed performance characteristics, you're > > probably already in trouble because they may need to go > > half way around the world. > > > > In this light, it may be that in combination with local > > convergence techniques -- FMIP, etc -- you can take the > > MN/CN binding update out of the critical handoff path in > > which case the performance of _any_ of these proposals > > is moot (handoffwise, that is). > > > > LMM solutions are specifically intended for scenarios wherein your > CN and HA could be distant and it is optimal to limit the number of > BUs that you send to these nodes. Sure. All I'm trying to say is that the context matters when evaluating performance. Real time flows are going to want local convergence techniques regardless of how efficient MN/CN BU's are. For other flows it's not clear how much difference this makes. After all, the best policy for short flows is not to do _anything_. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 10 23:57: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 XAA22788 for ; Mon, 10 Dec 2001 23:57:25 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA02247; Mon, 10 Dec 2001 21:56:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA24023; Mon, 10 Dec 2001 20:56:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4tdvU019082 for ; Mon, 10 Dec 2001 20:55:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB4tdK4019081 for mobile-ip-dist; Mon, 10 Dec 2001 20:55:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB4tavU019074 for ; Mon, 10 Dec 2001 20:55:36 -0800 (PST) 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 UAA11158 for ; Mon, 10 Dec 2001 20:55:38 -0800 (PST) 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 UAA11962 for ; Mon, 10 Dec 2001 20:55:37 -0800 (PST) Received: from Kniveton.com (245-200-131-12.bellhead.com [12.131.200.245]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id fBB4tZr99968 for ; Mon, 10 Dec 2001 20:55:35 -0800 (PST) Message-ID: <3C15910A.5732E49F@Kniveton.com> Date: Mon, 10 Dec 2001 20:52:27 -0800 From: TJ Kniveton Organization: Nokia Research Center X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling References: <697DAA22C5004B4596E033803A7CEF444CD248@daebe007.NOE.Nokia.com> <00ad01c181fa$8ee2a630$566015ac@T23KEMPF> 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: > Raj, > > I agree with your position. We need to get MIPv6 to RFC yesterday, > so that we can start the process of productization and deployment > in earnest. > > The place for research work on next-generation mobility protocols is the > IRTF Micromobility Routing group. > Good point, James. I would add that if effort is applied and MIPv6 gets to RFC soon, it seems a lot of resources would be freed up to work on other mobility challenges, including a next-generation solution with all of the good ideas generated thus far. However, if energy is applied to getting those ideas into the current solution, no progress will be made on either goal. -TJ From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 00:08: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 AAA25463 for ; Tue, 11 Dec 2001 00:08:27 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07076; Mon, 10 Dec 2001 22:06:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA25228; Mon, 10 Dec 2001 21:06:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB56FvU019170 for ; Mon, 10 Dec 2001 21:06:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB56EAV019169 for mobile-ip-dist; Mon, 10 Dec 2001 21:06:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB56AvU019162 for ; Mon, 10 Dec 2001 21:06:11 -0800 (PST) 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 fBB568q25383; Tue, 11 Dec 2001 06:06:09 +0100 (MET) Date: Tue, 11 Dec 2001 06:04:26 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routing header Vs tunneling To: TJ@Kniveton.com Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C15910A.5732E49F@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: > Good point, James. I would add that if effort is applied and MIPv6 gets to > RFC soon, it seems a lot of resources would be freed up to work on other > mobility challenges, including a next-generation solution with all of the > good ideas generated thus far. Do you think that the HAOpt+RH vs. tunneling is something that an updated MIPv6 protocol would do differently? Or were you considering other ideas? Assuming they are semantically equivalent (i.e. solve the same security requirements etc) then changing from using one encoding to the other wouldn't solve any new problem and wouldn't add any capabilities. But it would require implementations to be capable of interoperating with both the old and the new encoding. This isn't an argument that the right thing is to switch to do tunneling; but it is an argument that this is a "now or never" decision. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 00:54: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 AAA26070 for ; Tue, 11 Dec 2001 00:54:57 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA00245; Mon, 10 Dec 2001 21:53:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12384; Mon, 10 Dec 2001 21:53:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB5qrvU019323 for ; Mon, 10 Dec 2001 21:52:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB5qrf1019322 for mobile-ip-dist; Mon, 10 Dec 2001 21:52:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB5qovU019315 for ; Mon, 10 Dec 2001 21:52:50 -0800 (PST) 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 VAA16891 for ; Mon, 10 Dec 2001 21:52:53 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA05918 for ; Mon, 10 Dec 2001 21:52:52 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBB5qoB18034 for ; Mon, 10 Dec 2001 23:52:51 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Dec 2001 23:51:39 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D82AF602@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] RFC 3012 - what about challenges from HA Date: Mon, 10 Dec 2001 23:51:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18207.EEED5E00" Sender: owner-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_01C18207.EEED5E00 Content-Type: text/plain; charset="iso-8859-1" Hi Henrik; I am not sure about the mechanism of using challenges from HA. If we assume that there is a mechanism to use Challenges from HA, we still need to have a secret key between the HA and the MN to use Challenges. Regards; Ahmad Muhanna Nortel Networks Shasta PDSN-MIP Development Phone. + 1 972 685 1416 ESN. 445-1416 amuhanna@nortelnetworks.com -----Original Message----- From: Henrik Levkowetz [mailto:henrik@ipunplugged.com] Sent: Sunday, December 09, 2001 4:24 AM To: mobile-ip Subject: RE: [mobile-ip] RFC 3012 - what about challenges from HA Hi Charlie, Ah, I see, then I can appreciate the reasoning. However, what if one would like to use a pre-existing authentication infrastructure which was designed to use challenges, instead of creating a new set of shared secrets, public/private keys or whatever for use with mobile ip? Might there not be a place also for challenges from a HA in that case? Regards, Henrik > > Hello Henrik, > > Since the home agent has a security association with the > mobile node, and since the registration request has > replay protection and authentication extension, there > isn't any need for the challenge. The whole registration > message data can properly be considered to be a > challenge, because of the anti-replay data in the > Identificatoin field. > > Regards, > Charlie P. > > > Henrik Levkowetz wrote: > > > On going over RFC 3012 and the 3012bis draft, I'm getting puzzled by > > this: > > > > There is provisions for challenges to the MN from the FA, trough the > > MIP Agent Advertisment Challenge Extension(section 2), and there is > > provisions for challenges from all entities except the HA and FA > > trough the Generalized Mobile IP Authentication Extension (section 5). > > > > But this leaves the HA hanging in the middle - there's no specific > > challenge extension for a HA to use, and the Generalized Mobile IP > > Authentication Extension is not defined for an HA to use. > > > > How Come? > > > > Henrik > > > > ------------------------------------------------------------------------ > > Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com > > ------------------------------------------------------------------------ ------_=_NextPart_001_01C18207.EEED5E00 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] RFC 3012 - what about challenges from HA

Hi Henrik;

I am not sure about the mechanism of using challenges from HA.
If we assume that there is a mechanism to use Challenges from HA,
we still need to have a secret key between the HA and the MN to use Challenges.

Regards;

Ahmad Muhanna
Nortel Networks
Shasta PDSN-MIP Development
Phone. + 1 972 685 1416 ESN. 445-1416
amuhanna@nortelnetworks.com



-----Original Message-----
From: Henrik Levkowetz [mailto:henrik@ipunplugged.com]
Sent: Sunday, December 09, 2001 4:24 AM
To: mobile-ip
Subject: RE: [mobile-ip] RFC 3012 - what about challenges from HA


Hi Charlie,

        Ah, I see, then I can appreciate the reasoning. However,
what if one would like to use a pre-existing authentication
infrastructure which was designed to use challenges, instead
of creating a new set of shared secrets, public/private keys
or whatever for use with mobile ip? Might there not be a place
also for challenges from a HA in that case?

        Regards,
                Henrik

>
> Hello Henrik,
>
> Since the home agent has a security association with the
> mobile node, and since the registration request has
> replay protection and authentication extension, there
> isn't any need for the challenge.  The whole registration
> message data can properly be considered to be a
> challenge, because of the anti-replay data in the
> Identificatoin field.
>
> Regards,
> Charlie P.
>
>
> Henrik Levkowetz wrote:
>
> > On going over RFC 3012 and the 3012bis draft, I'm getting puzzled by
> > this:
> >
> > There is provisions for challenges to the MN from the FA, trough the
> > MIP Agent Advertisment Challenge Extension(section 2), and there is
> > provisions for challenges from all entities except the HA and FA
> > trough the Generalized Mobile IP Authentication Extension (section 5).
> >
> > But this leaves the HA hanging in the middle - there's no specific
> > challenge extension for a HA to use, and the Generalized Mobile IP
> > Authentication Extension is not defined for an HA to use.
> >
> > How Come?
> >
> >                 Henrik
> >
> > ------------------------------------------------------------------------
> > Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com
> > ------------------------------------------------------------------------

------_=_NextPart_001_01C18207.EEED5E00-- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 01:21: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 BAA27136 for ; Tue, 11 Dec 2001 01:21:21 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA08333; Mon, 10 Dec 2001 22:20:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA15836; Mon, 10 Dec 2001 22:20:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB6JGvU019462 for ; Mon, 10 Dec 2001 22:19:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB6JGr8019461 for mobile-ip-dist; Mon, 10 Dec 2001 22:19:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB6JCvU019454 for ; Mon, 10 Dec 2001 22:19:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA15757 for ; Mon, 10 Dec 2001 22:19:16 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA20205 for ; Mon, 10 Dec 2001 23:19:15 -0700 (MST) 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 fBB6KLQ22762 for ; Tue, 11 Dec 2001 00:20:21 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Dec 2001 00:19:14 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Dec 2001 00:19:14 -0600 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Tue, 11 Dec 2001 00:19:14 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD24C@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Routing header Vs tunneling X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcGCAa1FjzWFCO3zEdWxMQAIx6TWeAACfsGg From: "Patil Basavaraj (NET/Dallas)" To: , Cc: X-OriginalArrivalTime: 11 Dec 2001 06:19:14.0875 (UTC) FILETIME=[C1AE20B0:01C1820B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBB6JDvU019455 Sender: owner-mobile-ip@sunroof.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 wrote: > >> Good point, James. I would add that if effort is applied and MIPv6 gets to >> RFC soon, it seems a lot of resources would be freed up to work on other >> mobility challenges, including a next-generation solution with all of the >> good ideas generated thus far. > >Do you think that the HAOpt+RH vs. tunneling is something that an updated >MIPv6 protocol would do differently? Or were you considering other ideas? > >Assuming they are semantically equivalent (i.e. solve the same security >requirements etc) then changing from using one encoding to the other wouldn't >solve any new problem and wouldn't add any capabilities. >But it would require implementations to be capable of interoperating with >both the old and the new encoding. > >This isn't an argument that the right thing is to switch to do tunneling; >but it is an argument that this is a "now or never" decision. > I think we simply need to focus on the problem that we have been dealing with over the past year and resolve that. There is no reason to rush into tunnelling over RH without a fair bit of analysis. So the "now or never" question in my opinion does not apply. Let the IRTF or whoever else wishes to study the implications of changing from the use of RH to tunnelling for IP mobility do so over the next few months (or years) and if the outcome of that analysis says mobility is better done with tunelling, we should consider it at that time. For now, I would be in favor of going forward with what has been done (with significant thinking) over a significant period of time , i.e proceeding with the use of RH and merely solve the security issues around BU, HAO. > Erik -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 01:34: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 BAA27934 for ; Tue, 11 Dec 2001 01:34:58 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA24247; Mon, 10 Dec 2001 23:33:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA21332; Mon, 10 Dec 2001 22:33:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB6X4vU019571 for ; Mon, 10 Dec 2001 22:33:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB6X48Q019570 for mobile-ip-dist; Mon, 10 Dec 2001 22:33:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB6X1vU019563 for ; Mon, 10 Dec 2001 22:33:01 -0800 (PST) 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 WAA26865 for ; Mon, 10 Dec 2001 22:33:04 -0800 (PST) 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 WAA23039 for ; Mon, 10 Dec 2001 22:33:03 -0800 (PST) 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 fBB6Y9Q23021 for ; Tue, 11 Dec 2001 00:34:09 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Dec 2001 00:33:03 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Dec 2001 00:33:02 -0600 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Tue, 11 Dec 2001 00:33:02 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD24D@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] Routing header Vs tunneling X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcGB+sAGsWPTk+3qEdWxMQAIx6TWeAAErqng From: "Patil Basavaraj (NET/Dallas)" To: Cc: X-OriginalArrivalTime: 11 Dec 2001 06:33:02.0921 (UTC) FILETIME=[AF3BEB90:01C1820D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBB6X1vU019564 Sender: owner-mobile-ip@sunroof.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 Dave Thaler wrote: > >Gabriel montenegro [mailto:gab@sun.com] > [snip] >> And yes, we should deprecate RH/HAO. Anything to make mobility less >> 'weird' and more in line with non-mobile wg's (IPv6) will save us >> problems down the road. >> >> asbestos shields on, > >I agree with Gabriel, and believe this could be done without slowing >down the spec (i.e., could be done faster than the security). By Well, if you have followed the MIPv6 trail for some time now, I would not be as optimistic with your view. The (many) security solutions are now reaching a level of considerable maturity and I believe we can reach consensus on solution(s) that can move the current MIPv6 spec forward. >simplifying processing (and yes I'm saying it does), I completely >agree that it solves various problems now and probably a bunch more we >don't know about yet. Problems that we do not know about yet will arise irrespective of what solution you decide to go forward with and there are no guarantees that taking approach "b" instead of "a" will be any better in dealing with "mirage" problems. So I would not consider it as a factor in making decisions on what is the route going forward. > >I don't think it puts anything back to square one. > But it sure drags out the timeline for getting any IPv6 mobility solution in the near future. >-Dave -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 01:37: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 BAA28110 for ; Tue, 11 Dec 2001 01:37:31 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA25862; Mon, 10 Dec 2001 23:36:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA21793; Mon, 10 Dec 2001 22:36:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB6ZovU019660 for ; Mon, 10 Dec 2001 22:35:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB6ZoFv019659 for mobile-ip-dist; Mon, 10 Dec 2001 22:35:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB6ZlvU019652 for ; Mon, 10 Dec 2001 22:35:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA17639 for ; Mon, 10 Dec 2001 22:35:50 -0800 (PST) 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 XAA05233 for ; Mon, 10 Dec 2001 23:36:25 -0700 (MST) Received: from Kniveton.com (219-198-131-12.bellhead.com [12.131.198.219]) by rajma.kniveton.com (8.11.1/8.11.1) with ESMTP id fBB6Zkn01002; Mon, 10 Dec 2001 22:35:46 -0800 (PST) Message-ID: <3C15A886.146423BE@Kniveton.com> Date: Mon, 10 Dec 2001 22:32:38 -0800 From: "T.J. Kniveton" Organization: Nokia Research Center X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling 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: > > > Good point, James. I would add that if effort is applied and MIPv6 gets to > > RFC soon, it seems a lot of resources would be freed up to work on other > > mobility challenges, including a next-generation solution with all of the > > good ideas generated thus far. > > Do you think that the HAOpt+RH vs. tunneling is something that an updated > MIPv6 protocol would do differently? Or were you considering other ideas? Route optimization and security are a really interesting topic of study, and I'm sure that some time down the road, we could look back at how well HAO+RH has worked in the Mobile IPv6 v.RFC deployments, perhaps try out the tunneling idea in some implementations as well and do interop testing as has been done with HAO+RH, and maybe weigh that with some new ideas, to come up with some really good extensions / implementation Info-RFCs, Mobile-IPv6 v.2, or whatever.. > Assuming they are semantically equivalent (i.e. solve the same security > requirements etc) then changing from using one encoding to the other wouldn't > solve any new problem and wouldn't add any capabilities. > But it would require implementations to be capable of interoperating with > both the old and the new encoding. Yes, this is true. And to some extent I imagine that it would be true of the current situation as well: Mobile IPv6 implementations use what has been specified since day 1. And OK, let's say that's not such a big deal, we can with some fixed amount of work, go and change all of these implementations to use something entirely different. It's also my understanding that all IPv6 nodes (CNs) are supposed to implement HAOs, and I would imagine the amount of work to go change all of these implementations and deployments might be very large, and that trying to do so might end up crippling any chance of widescale Mobile IPv6 acceptance on the Internet. > This isn't an argument that the right thing is to switch to do tunneling; > but it is an argument that this is a "now or never" decision. OK, I guess my response would be that it is a "justify or never" decision. Since we're past the design phase, unless an overwhelming reason to change an existing mechanism can be clearly justified and defended, there is no reason to do it. > > Erik -- T.J. Kniveton Communications Systems Lab Nokia Research Center From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 02: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 CAA03060 for ; Tue, 11 Dec 2001 02:05:22 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08618; Tue, 11 Dec 2001 00:02:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25114; Mon, 10 Dec 2001 23:02:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB726vU019817 for ; Mon, 10 Dec 2001 23:02:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB726bP019816 for mobile-ip-dist; Mon, 10 Dec 2001 23:02:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB723vU019809 for ; Mon, 10 Dec 2001 23:02:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA20011 for ; Mon, 10 Dec 2001 23:01:01 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00896 for ; Tue, 11 Dec 2001 00:01:01 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBB6wOB20457; Tue, 11 Dec 2001 00:58:25 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Dec 2001 00:57:13 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D82AF604@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Patil Basavaraj (NET/Dallas)'" , "Perkins Charles (IPRG)" Cc: "Pete Wenzel" , Mobile IP Working Group , Pat Calhoun Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Date: Tue, 11 Dec 2001 00:57:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18211.18041460" Sender: owner-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_01C18211.18041460 Content-Type: text/plain; charset="iso-8859-1" Hello Basavaraj; What about the following scenario: 1. MN sends a RRQ message with NAI1, Home Address 0.0.0.0. 2. MN sends 1st retry of RRQ with NAI1, Home address 0.0.0.0. 3. Now, we have a SMART MN, which figures out that it can use another Profile with NAI2 and Home Address 0.0.0.0. 4. Since section 3.7.1 in RFC2002 does not talk about the user NAI, PDSN will consider this as a retransmission while may be the user would have failed authentication at the AAA. ** Another thing, what about if we support different NAIs over the same PPP session and let us say NAI1, NAI2, and NAI3 have the same HA and all requesting Dynamic MIP calls with Home Addresses of 0.0.0.0. ********** Ahmad Muhanna -----Original Message----- From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] Sent: Tuesday, November 13, 2001 4:20 PM To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles (IPRG) Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP Working Group; Pat Calhoun Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Charlie proposed the following text: >======================================================================= > >Here is the new relevant text, in the same paragraph as your original >quote: > > .... The Foreign Agent SHOULD check that the mobile node is > actually performing a retransmission, by verifying that the relevant > fields of the retransmitted request are the same as represented in > the visitor list entry for the pending Registration Request (section > 3.7.1 of [8]). This verification MUST NOT include the "remaining > Lifetime of the pending registration", or the Identification field > since those values are likely to change even for requests that are > merely retransmissions and not new Registration Requests. In all > other circumstances, if the Foreign Agent receives .... > >======================================================================= > >Comments? > >>Ahmad Muhanna: >>I hope you would agree that the following change will satisfy the need: >> >>"If a mobile node retransmits a Registration Request with the same >>Identification field and the same Challenge extension, and the Foreign >>Agent still has a pending Registration Request record in effect for the >>mobile node, then the Foreign Agent forwards the Registration Request to >>the Home Agent again (see Registration Retransmission, section 3.6.3[8]). >>In all other circumstances, if the Foreign Agent receives a Registration >>Request with a Challenge extension containing a Challenge value previously >>used by that mobile node, the Foreign Agent SHOULD send a Registration >>Reply to the mobile node containing the Code value STALE_CHALLENGE." > >Regards, >Charlie P. > I think the text that Charlie proposes makes it quite clear as to what the FA must do in order to recognize, if it is a retransmission. So I would recommend going with Charlie's text in the revision for this spec. -Basavaraj ------_=_NextPart_001_01C18211.18041460 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] URGENT - rfc3012 interpretation question
Hello Basavaraj;
 
What about the following scenario:
 
1. MN sends a RRQ message with NAI1, Home Address 0.0.0.0.
2. MN sends 1st retry of RRQ with NAI1, Home address 0.0.0.0.
 
3. Now, we have a SMART MN, which figures out that it can use another Profile with NAI2 and Home Address 0.0.0.0.
 
4. Since section 3.7.1 in RFC2002 does not talk about the user NAI, PDSN will consider this as a retransmission while may be the user would have failed authentication at the AAA.
 
** Another thing, what about if we support different NAIs over the same PPP session and let us say NAI1, NAI2, and NAI3
have the same HA and all requesting Dynamic MIP calls with Home Addresses of 0.0.0.0. **********

Ahmad Muhanna 

 -----Original Message-----
From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com]
Sent: Tuesday, November 13, 2001 4:20 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles (IPRG)
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP Working Group; Pat Calhoun
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question


Charlie proposed the following text:
>=======================================================================
>
>Here is the new relevant text, in the same paragraph as your original
>quote:
>
>      ....      The Foreign Agent SHOULD check that the mobile node is
>   actually performing a retransmission, by verifying that the relevant
>   fields of the retransmitted request are the same as represented in
>   the visitor list entry for the pending Registration Request (section
>   3.7.1 of [8]).  This verification MUST NOT include the "remaining
>   Lifetime of the pending registration", or the Identification field
>   since those values are likely to change even for requests that are
>   merely retransmissions and not new Registration Requests.  In all
>   other circumstances, if the Foreign Agent receives   ....
>
>=======================================================================
>
>Comments?
>
>>Ahmad Muhanna:
>>I hope you would agree that the following change will satisfy the need:
>>
>>"If a mobile node retransmits a Registration Request with the same
>>Identification field and the same Challenge extension, and the Foreign
>>Agent still has a pending Registration Request record in effect for the
>>mobile node, then the Foreign Agent forwards the Registration Request to
>>the Home Agent again (see Registration Retransmission, section 3.6.3[8]).
>>In all other circumstances, if the Foreign Agent receives a Registration
>>Request with a Challenge extension containing a Challenge value previously
>>used by that mobile node, the Foreign Agent SHOULD send a Registration
>>Reply to the mobile node containing the Code value STALE_CHALLENGE."
>
>Regards,
>Charlie P.
>
 
I think the text that Charlie proposes makes it quite clear as to what
the FA must do in order to recognize, if it is a retransmission. So I
would recommend going with Charlie's text in the revision for this
spec.
 
-Basavaraj
 
 
 
 
------_=_NextPart_001_01C18211.18041460-- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 02:37: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 CAA10118 for ; Tue, 11 Dec 2001 02:37:01 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA00164; Mon, 10 Dec 2001 23:35:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29268; Mon, 10 Dec 2001 23:35:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB7Z8vU019918 for ; Mon, 10 Dec 2001 23:35:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB7Z8o2019917 for mobile-ip-dist; Mon, 10 Dec 2001 23:35:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB7Z5vU019910 for ; Mon, 10 Dec 2001 23:35:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29152 for ; Mon, 10 Dec 2001 23:35:05 -0800 (PST) Received: from hermes.core.alpha-lab.net (195.211.178.202.ipberlin.com [195.211.178.202]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24437 for ; Tue, 11 Dec 2001 00:34:46 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by hermes.core.alpha-lab.net (Postfix on SuSE Linux 7.2 (i386)) with ESMTP id 7750E295D4 for ; Tue, 11 Dec 2001 08:31:37 +0100 (CET) Subject: [mobile-ip] In search of an implementation From: Jochen Witte To: mobile-ip@sunroof.eng.sun.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0 (Preview Release) Date: 11 Dec 2001 08:31:37 +0100 Message-Id: <1008055897.1047.3.camel@hermes> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I'm just looking for an implementation of mobile-ip for Linux 2.4. Can anybody tell me where I can find one? Greetings -- Jochen Witte PGP fingerprint = 2F92 97EA BB67 E49A EE79 AD55 2FE7 DF05 EA9A 3A32 Keyserver = www.keyserver.net From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 02:42: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 CAA10447 for ; Tue, 11 Dec 2001 02:42:15 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA01981; Mon, 10 Dec 2001 23:41:16 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA29874; Mon, 10 Dec 2001 23:41:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB7ehvU020004 for ; Mon, 10 Dec 2001 23:40:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB7egd6020003 for mobile-ip-dist; Mon, 10 Dec 2001 23:40:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB7edvU019996 for ; Mon, 10 Dec 2001 23:40:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA24213 for ; Mon, 10 Dec 2001 23:40:39 -0800 (PST) Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11628 for ; Tue, 11 Dec 2001 00:40:38 -0700 (MST) 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 fBB7fiQ23960 for ; Tue, 11 Dec 2001 01:41:44 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Dec 2001 01:40:37 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Dec 2001 01:40:37 -0600 content-class: urn:content-classes:message Subject: RE: [mobile-ip] In search of an implementation Date: Tue, 11 Dec 2001 01:40:40 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD253@daebe007.NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [mobile-ip] In search of an implementation X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Index: AcGCFnP+3xKrh+4GEdWxMQAIx6TWeAAAJUkA From: "Patil Basavaraj (NET/Dallas)" To: Cc: X-OriginalArrivalTime: 11 Dec 2001 07:40:37.0391 (UTC) FILETIME=[1FE2F1F0:01C18217] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBB7eevU019997 Sender: owner-mobile-ip@sunroof.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 Try: http://www.cs.hut.fi/Research/Dynamics/software.html -Basavaraj > > Hi, > > I'm just looking for an implementation of mobile-ip for Linux 2.4. > Can anybody tell me where I can find one? > > Greetings > -- > Jochen Witte > > PGP fingerprint = 2F92 97EA BB67 E49A EE79 AD55 2FE7 DF05 EA9A 3A32 > Keyserver = www.keyserver.net > From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 04:04: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 EAA14721 for ; Tue, 11 Dec 2001 04:04:39 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA24568; Tue, 11 Dec 2001 00:59:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08376; Tue, 11 Dec 2001 00:59:29 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB8wivU020189 for ; Tue, 11 Dec 2001 00:58:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBB8wi4E020188 for mobile-ip-dist; Tue, 11 Dec 2001 00:58:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBB8wfvU020181 for ; Tue, 11 Dec 2001 00:58:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08256 for ; Tue, 11 Dec 2001 00:58:42 -0800 (PST) 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 BAA22151 for ; Tue, 11 Dec 2001 01:59:17 -0700 (MST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id fBB8wTP03989; Tue, 11 Dec 2001 09:58:29 +0100 (MET) Message-ID: <3C15CAB4.20D8B8ED@inrialpes.fr> Date: Tue, 11 Dec 2001 09:58:28 +0100 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: mobile-ip@sunroof.eng.sun.com, Erik Nordmark , mroe@microsoft.com, tuomaura@microsoft.com Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: <3C12BA10.5030304@piuha.net> <3C14787C.C5C79043@inrialpes.fr> <3C149F8F.1030203@piuha.net> <3C14F65C.6020901@piuha.net> Content-Type: multipart/alternative; boundary="------------581CEFC6A089B7384C50D198" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------581CEFC6A089B7384C50D198 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Jari, Jari Arkko wrote: > Claude, > > We discussed earlier about why there's return routability or not > at the bottom of these public key hash techniques. Then I said > the following: > > > - In order to prevent trivial DoS attacks against the public > > key hash techniques, CAM-DH uses return routability at the > > bottom and SUCV uses puzzles. > > It seems that I missed an important point though. What CAM and > SUCV are able to do is to conclusively prove that the sending > node really came up with the particular IPv6 address in question. > However, it is still possible for attackers to pick a network X, > generate their own key and address, and claim to be mobile nodes > from X. This could potentially be used for something bad, such > as initiating a session from a CoA and then deleting the BCE and > bombing X with traffic that continues to flow from the CN to the > MN. > > The prevention of this attack is another reason why CAM-DH runs BAKE/2 > at the bottom: the return routability tests ensure that the attackers > can't claim to be from X if they really aren't from there (or on > the path to it). In SUCV, the 4 SUCVp messages are exchanged between the CN and the MN (the CoA). So the MN has to be in the X network (or on the path to it) for the SUCV exchange to succeed... The only weakness (i think) is that this exchange might succeed even if the attacker is on the path to X but return routability does not solve this problem. In fact what prevents, in this case, an attacker to choose a HomeAddress that is also on the path from the CN to X??? I think that return routability might only be useful against an attacker trying to redirect a "legitimate" HomeAddress... but SUCV/CAM also solves this issue... Am i missing something here? Claude. > > Jari -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------581CEFC6A089B7384C50D198 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hello Jari,

Jari Arkko wrote:

Claude,

We discussed earlier about why there's return routability or not
at the bottom of these public key hash techniques. Then I said
the following:

> - In order to prevent trivial DoS attacks against the public
>   key hash techniques, CAM-DH uses return routability at the
>   bottom and SUCV uses puzzles.

It seems that I missed an important point though. What CAM and
SUCV are able to do is to conclusively prove that the sending
node really came up with the particular IPv6 address in question.
However, it is still possible for attackers to pick a network X,
generate their own key and address, and claim to be mobile nodes
from X. This could potentially be used for something bad, such
as initiating a session from a CoA and then deleting the BCE and
bombing X with traffic that continues to flow from the CN to the
MN.

The prevention of this attack is another reason why CAM-DH runs BAKE/2
at the bottom: the return routability tests ensure that the attackers
can't claim to be from X if they really aren't from there (or on
the path to it).

In SUCV, the 4 SUCVp messages are exchanged between the CN and the MN (the CoA).
So the MN has to be in the X network (or on the path to it) for the SUCV exchange to succeed...

The only weakness (i think) is that this exchange might succeed even if the attacker is on the path to X but
return routability does not solve this problem. In fact what prevents, in this case, an attacker to choose
a HomeAddress that is also on the path from the CN to X???

I think that return routability might only be useful against an attacker trying to redirect a "legitimate" HomeAddress...
but SUCV/CAM also solves this issue...

Am i missing something here?

Claude.
 

 
Jari
-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------581CEFC6A089B7384C50D198-- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 07:20: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 HAA16758 for ; Tue, 11 Dec 2001 07:20:28 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA22627; Tue, 11 Dec 2001 05:18:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01926; Tue, 11 Dec 2001 04:19:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBCIJvU020491 for ; Tue, 11 Dec 2001 04:18:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBCIJVt020490 for mobile-ip-dist; Tue, 11 Dec 2001 04:18:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBCIGvU020483 for ; Tue, 11 Dec 2001 04:18:16 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23392 for ; Tue, 11 Dec 2001 04:18:15 -0800 (PST) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA22136 for ; Tue, 11 Dec 2001 05:17:57 -0700 (MST) Received: from uk0006exch001h.wins.lucent.com (h135-86-160-150.lucent.com [135.86.160.150]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fBBCIEx07979 for ; Tue, 11 Dec 2001 07:18:14 -0500 (EST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 11 Dec 2001 12:18:13 -0000 Message-ID: <976F7C55E3B2D111A0720008C728549C0CE5823A@en0060exch001u.uk.lucent.com> From: "Casati, Alessio (Alessio)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Erik Nordmark , deering@cisco.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Tue, 11 Dec 2001 12:18:09 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1823D.E549F5D0" Sender: owner-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_01C1823D.E549F5D0 Content-Type: text/plain; charset="iso-8859-1" Well just to make it clear, location privacy is not a requirement for Mobile IPv6 at this time. We had location privacy as a separate work item in the MIP charter/milsetones earlier but that is a separate problem and needs to be dealt as such. -Basavaraj Location privacy is not an issue if we use MIPv6 with Reverse tunneling and no Route optimization (or, as per somebody's novel definition, no Route Optimization "both ways"). Is there more work on Location privacy with MIPv6 you may think about? Or should you mark this as "done". Alessio ------_=_NextPart_001_01C1823D.E549F5D0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Routing header Vs tunneling

Well just to make it clear, location privacy is not a requirement for Mobile IPv6 at this time. We had location privacy as a separate work item in the MIP charter/milsetones earlier but that is a separate problem and needs to be dealt as such.

 

-Basavaraj 

 

Location privacy is not an issue if

we use MIPv6 with Reverse tunneling and no Route optimization

(or, as per somebody's novel definition, no

Route Optimization "both ways"). Is there more work on Location privacy with MIPv6

you may think about? Or should you mark this as "done".

Alessio 

------_=_NextPart_001_01C1823D.E549F5D0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 08:09: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 IAA17069 for ; Tue, 11 Dec 2001 08:09:07 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA14395; Tue, 11 Dec 2001 05:06:52 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06310; Tue, 11 Dec 2001 05:06:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBD66vU020590 for ; Tue, 11 Dec 2001 05:06:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBD66CK020589 for mobile-ip-dist; Tue, 11 Dec 2001 05:06:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBD63vU020582 for ; Tue, 11 Dec 2001 05:06:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06120 for ; Tue, 11 Dec 2001 05:05:00 -0800 (PST) Received: from cambianetworks.com (66-73-249-62.cambianetworks.com [66.73.249.62] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA05715 for ; Tue, 11 Dec 2001 06:05:00 -0700 (MST) Received: (qmail 17591 invoked by uid 8); 11 Dec 2001 13:04:59 -0000 Received: from pc-01582 (172.16.6.46, claiming to be "USAROSRMARKS1") by gate.cambianetworks.com with SMTP id smtpdKxsnK4; Tue, 11 Dec 2001 08:04:52 EST From: "Robert J Marks" To: , "'Patil Basavaraj \(NET/Dallas\)'" , "'Perkins Charles \(IPRG\)'" Cc: "'Pete Wenzel'" , "'Pat Calhoun'" Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Date: Tue, 11 Dec 2001 07:04:40 -0600 Organization: Cambia Networks Message-ID: <000001c18244$65772a60$2e0610ac@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 Importance: Normal In-Reply-To: <6B49EDFE974BD51197D70002A56079D82AF604@zrc2c013.us.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ahmad, Some observations on your scenarios. Ahmad Muhanna wrote: > What about the following scenario: > 1. MN sends a RRQ message with NAI1, Home Address 0.0.0.0. > 2. MN sends 1st retry of RRQ with NAI1, Home address 0.0.0.0. > > 3. Now, we have a SMART MN, which figures out that it can use another > Profile with NAI2 and Home Address 0.0.0.0. > > 4. Since section 3.7.1 in RFC2002 does not talk about the user NAI, > PDSN will consider this as a retransmission while may be the user > would have failed authentication at the AAA. This situation will be treated as a new Registration Request, independent of the request that used NAI1. The Home Agent will not correlate the two requests, since it identifies the MN by the NAI in this case. > ** Another thing, what about if we support different NAIs over the > same PPP session and let us say NAI1, NAI2, and NAI3 have the same > HA and all requesting Dynamic MIP calls with Home Addresses of 0.0.0.0. All three requests will be treated as independent registrations. The HA does not know about PPP, and again uses the NAI to identify the MN. > ********** > Ahmad Muhanna Bob Robert J Marks Cambia Networks Office: +1 847 627 3703 Mobile: +1 708 829 6329 -----Original Message----- From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] Sent: Tuesday, November 13, 2001 4:20 PM To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles (IPRG) Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP Working Group; Pat Calhoun Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Charlie proposed the following text: >======================================================================= > >Here is the new relevant text, in the same paragraph as your original >quote: > > .... The Foreign Agent SHOULD check that the mobile node is > actually performing a retransmission, by verifying that the relevant > fields of the retransmitted request are the same as represented in > the visitor list entry for the pending Registration Request (section > 3.7.1 of [8]). This verification MUST NOT include the "remaining > Lifetime of the pending registration", or the Identification field > since those values are likely to change even for requests that are > merely retransmissions and not new Registration Requests. In all > other circumstances, if the Foreign Agent receives .... > >======================================================================= > >Comments? > >>Ahmad Muhanna: >>I hope you would agree that the following change will satisfy the need: >> >>"If a mobile node retransmits a Registration Request with the same >>Identification field and the same Challenge extension, and the Foreign >>Agent still has a pending Registration Request record in effect for the >>mobile node, then the Foreign Agent forwards the Registration Request to >>the Home Agent again (see Registration Retransmission, section 3.6.3[8]). >>In all other circumstances, if the Foreign Agent receives a Registration >>Request with a Challenge extension containing a Challenge value previously >>used by that mobile node, the Foreign Agent SHOULD send a Registration >>Reply to the mobile node containing the Code value STALE_CHALLENGE." > >Regards, >Charlie P. > I think the text that Charlie proposes makes it quite clear as to what the FA must do in order to recognize, if it is a retransmission. So I would recommend going with Charlie's text in the revision for this spec. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 10:38: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 KAA19026 for ; Tue, 11 Dec 2001 10:38:30 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09518; Tue, 11 Dec 2001 08:34:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15971; Tue, 11 Dec 2001 07:34:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFXWvU020846 for ; Tue, 11 Dec 2001 07:33:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBFXWF9020845 for mobile-ip-dist; Tue, 11 Dec 2001 07:33:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFXTvU020838 for ; Tue, 11 Dec 2001 07:33:29 -0800 (PST) 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 HAA29336 for ; Tue, 11 Dec 2001 07:32:26 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05011 for ; Tue, 11 Dec 2001 07:32:25 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBBFTrB17767; Tue, 11 Dec 2001 09:29:53 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Dec 2001 09:28:41 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D82AF605@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" , "'Patil Basavaraj (NET/Dallas)'" , "'Perkins Charles (IPRG)'" Cc: "Pete Wenzel" , "'Pat Calhoun'" Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Date: Tue, 11 Dec 2001 09:28:55 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18258.8BD7E780" Sender: owner-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_01C18258.8BD7E780 Content-Type: text/plain; charset="iso-8859-1" Bob; I think our concern here is how the FA handles the RRQ message in these scenarios. Let us remember, if it is a re-transmission, FA does not authenticate the user through AAA. However, if it is considered a new registration, FA MUST authenticate the RRQ message "the USER" before relaying the RRQ to HA. I hope this clarifies the issue at hand. Thanks; Ahmad Muhanna -----Original Message----- From: Robert J Marks [mailto:rjmarks@cambianetworks.com] Sent: Tuesday, December 11, 2001 7:05 AM To: mobile-ip@sunroof.eng.sun.com; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)' Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun' Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Ahmad, Some observations on your scenarios. Ahmad Muhanna wrote: > What about the following scenario: > 1. MN sends a RRQ message with NAI1, Home Address 0.0.0.0. > 2. MN sends 1st retry of RRQ with NAI1, Home address 0.0.0.0. > > 3. Now, we have a SMART MN, which figures out that it can use another > Profile with NAI2 and Home Address 0.0.0.0. > > 4. Since section 3.7.1 in RFC2002 does not talk about the user NAI, > PDSN will consider this as a retransmission while may be the user > would have failed authentication at the AAA. This situation will be treated as a new Registration Request, independent of the request that used NAI1. The Home Agent will not correlate the two requests, since it identifies the MN by the NAI in this case. > ** Another thing, what about if we support different NAIs over the > same PPP session and let us say NAI1, NAI2, and NAI3 have the same > HA and all requesting Dynamic MIP calls with Home Addresses of 0.0.0.0. All three requests will be treated as independent registrations. The HA does not know about PPP, and again uses the NAI to identify the MN. > ********** > Ahmad Muhanna Bob Robert J Marks Cambia Networks Office: +1 847 627 3703 Mobile: +1 708 829 6329 -----Original Message----- From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] Sent: Tuesday, November 13, 2001 4:20 PM To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles (IPRG) Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP Working Group; Pat Calhoun Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Charlie proposed the following text: >======================================================================= > >Here is the new relevant text, in the same paragraph as your original >quote: > > .... The Foreign Agent SHOULD check that the mobile node is > actually performing a retransmission, by verifying that the relevant > fields of the retransmitted request are the same as represented in > the visitor list entry for the pending Registration Request (section > 3.7.1 of [8]). This verification MUST NOT include the "remaining > Lifetime of the pending registration", or the Identification field > since those values are likely to change even for requests that are > merely retransmissions and not new Registration Requests. In all > other circumstances, if the Foreign Agent receives .... > >======================================================================= > >Comments? > >>Ahmad Muhanna: >>I hope you would agree that the following change will satisfy the need: >> >>"If a mobile node retransmits a Registration Request with the same >>Identification field and the same Challenge extension, and the Foreign >>Agent still has a pending Registration Request record in effect for the >>mobile node, then the Foreign Agent forwards the Registration Request to >>the Home Agent again (see Registration Retransmission, section 3.6.3[8]). >>In all other circumstances, if the Foreign Agent receives a Registration >>Request with a Challenge extension containing a Challenge value previously >>used by that mobile node, the Foreign Agent SHOULD send a Registration >>Reply to the mobile node containing the Code value STALE_CHALLENGE." > >Regards, >Charlie P. > I think the text that Charlie proposes makes it quite clear as to what the FA must do in order to recognize, if it is a retransmission. So I would recommend going with Charlie's text in the revision for this spec. -Basavaraj ------_=_NextPart_001_01C18258.8BD7E780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] URGENT - rfc3012 interpretation question

Bob;

I think our concern here is how the FA handles the = RRQ message in these scenarios.
Let us remember, if it is a re-transmission, FA does = not authenticate the user through AAA.
However, if it is considered a new registration, FA = MUST authenticate the RRQ message
"the USER" before relaying the RRQ to = HA.
I hope this clarifies the issue at hand.

Thanks;

Ahmad Muhanna


-----Original Message-----
From: Robert J Marks [mailto:rjmarks@cambianetworks= .com]
Sent: Tuesday, December 11, 2001 7:05 AM
To: mobile-ip@sunroof.eng.sun.com; 'Patil Basavaraj = (NET/Dallas)';
'Perkins Charles (IPRG)'
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat = Calhoun'
Subject: RE: [mobile-ip] URGENT - rfc3012 = interpretation question


Ahmad,

Some observations on your scenarios.
 
Ahmad Muhanna wrote:

> What about the following scenario:

> 1. MN sends a RRQ message with NAI1, Home = Address 0.0.0.0.
> 2. MN sends 1st retry of RRQ with NAI1, Home = address 0.0.0.0.
>
> 3. Now, we have a SMART MN, which figures out = that it can use another
>    Profile with NAI2 and Home = Address 0.0.0.0.
>
> 4. Since section 3.7.1 in RFC2002 does not talk = about the user NAI,
> PDSN will consider this as a retransmission = while may be the user
> would have failed authentication at the = AAA.

This situation will be treated as a new Registration = Request,
independent
of the request that used NAI1. The Home Agent will = not correlate the two
requests, since it identifies the MN by the NAI in = this case.

> ** Another thing, what about if we support = different NAIs over the
> same PPP session and let us say NAI1, NAI2, and = NAI3 have the same
> HA and all requesting Dynamic MIP calls with = Home Addresses of
0.0.0.0.

All three requests will be treated as independent = registrations. The HA
does not know about PPP, and again uses the NAI to = identify the MN.
 
> **********
> Ahmad Muhanna

Bob

Robert J Marks
Cambia Networks
Office: +1 847 627 3703
Mobile: +1 708 829 6329

 -----Original Message-----
From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.c= om]
Sent: Tuesday, November 13, 2001 4:20 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins = Charles (IPRG)
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP = Working Group; Pat Calhoun
Subject: RE: [mobile-ip] URGENT - rfc3012 = interpretation question



Charlie proposed the following text:
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

>
>Here is the new relevant text, in the same = paragraph as your original
>quote:
>
>      = ....      The Foreign Agent SHOULD check that = the mobile node is
>   actually performing a = retransmission, by verifying that the relevant

>   fields of the retransmitted request = are the same as represented in
>   the visitor list entry for the = pending Registration Request (section

>   3.7.1 of [8]).  This = verification MUST NOT include the "remaining
>   Lifetime of the pending = registration", or the Identification field
>   since those values are likely to = change even for requests that are
>   merely retransmissions and not new = Registration Requests.  In all
>   other circumstances, if the Foreign = Agent receives   ....
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

>
>Comments?
>
>>Ahmad Muhanna:
>>I hope you would agree that the following = change will satisfy the
need:
>>
>>"If a mobile node retransmits a = Registration Request with the same
>>Identification field and the same Challenge = extension, and the Foreign

>>Agent still has a pending Registration = Request record in effect for
the
>>mobile node, then the Foreign Agent forwards = the Registration Request
to
>>the Home Agent again (see Registration = Retransmission, section
3.6.3[8]).
>>In all other circumstances, if the Foreign = Agent receives a
Registration
>>Request with a Challenge extension = containing a Challenge value
previously
>>used by that mobile node, the Foreign Agent = SHOULD send a Registration

>>Reply to the mobile node containing the Code = value STALE_CHALLENGE."
>
>Regards,
>Charlie P.
>

I think the text that Charlie proposes makes it quite = clear as to what
the FA must do in order to recognize, if it is a = retransmission. So I
would recommend going with Charlie's text in the = revision for this
spec.

-Basavaraj

------_=_NextPart_001_01C18258.8BD7E780-- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 10:50: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 KAA19209 for ; Tue, 11 Dec 2001 10:50:13 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21061; Tue, 11 Dec 2001 08:48:58 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18570; Tue, 11 Dec 2001 07:49:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFmPvU020989 for ; Tue, 11 Dec 2001 07:48:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBFmPwB020988 for mobile-ip-dist; Tue, 11 Dec 2001 07:48:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFmLvU020980 for ; Tue, 11 Dec 2001 07:48:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01798 for ; Tue, 11 Dec 2001 07:48:21 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08136 for ; Tue, 11 Dec 2001 08:48:20 -0700 (MST) Received: from T23KEMPF (dhcp53.docomo-usa.com [172.21.96.53]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBBFmJJ20010; Tue, 11 Dec 2001 07:48:19 -0800 (PST) Message-ID: <002001c1825b$0805b0b0$356015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: Subject: Re: [mobile-ip] Routing header Vs tunneling Date: Tue, 11 Dec 2001 07:46:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik, Arguably, deployment of MIPv4 was hindered by the fact that it was developed long after IPv4 was deployed. With MIPv6, we have the opportunity to correct this situation. IPv6 may be a curiosity in the US, primarily of interest for toasters and refrigerators, but in China and Japan, it is a vital part of providing people with basic Internet service. The Japanese government has started giving tax relief to ISPs that offer IPv6 service, for example. Since most people in China and Japan are looking for mobile Internet service, getting MIPv6 to proposed standard is crucial in speeding deployment of basic Internet service in Asia. If we start discussing using tunneling instead of header options for MIPv6, we are looking at a minimum 3 year delay before MIPv6 is ready for serious product implementation and widespread deployment. Considering the 9 month delay that the BU security problem has thrown into MIPv6, I'd estimate 6 months to a year to weigh requirements and decide among competing proposals, 6 months to a year to get prototype implementations ready and do interoperability testing, and 6 months to a year for the WG to finish up loose ends and the IESG to weigh and approve the result. This is simply unacceptable. IMHO, unless it is impossible to provide the required level of security with the existing design, we should fix the security problems and get MIPv6 to proposed standard as soon as possible, so non-US wireless ISPs have an opportunity to start deployment. Otherwise, they are going to start seriously looking at GPRS integration with wireless LAN and other non-IP based solutions that are here today. Meanwhile, we should start working on next generation micromobility routing in the IRTF, with the goal of having a solution ready for the IETF within 3 to 5 years. jak ----- Original Message ----- From: "Erik Nordmark" To: Cc: Sent: Monday, December 10, 2001 9:04 PM Subject: Re: [mobile-ip] Routing header Vs tunneling > > Good point, James. I would add that if effort is applied and MIPv6 gets to > > RFC soon, it seems a lot of resources would be freed up to work on other > > mobility challenges, including a next-generation solution with all of the > > good ideas generated thus far. > > Do you think that the HAOpt+RH vs. tunneling is something that an updated > MIPv6 protocol would do differently? Or were you considering other ideas? > > Assuming they are semantically equivalent (i.e. solve the same security > requirements etc) then changing from using one encoding to the other wouldn't > solve any new problem and wouldn't add any capabilities. > But it would require implementations to be capable of interoperating with > both the old and the new encoding. > > This isn't an argument that the right thing is to switch to do tunneling; > but it is an argument that this is a "now or never" decision. > > Erik > > From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 10:57:38 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 KAA19370 for ; Tue, 11 Dec 2001 10:57:38 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27118; Tue, 11 Dec 2001 08:56:14 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19806; Tue, 11 Dec 2001 07:56:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFtmvU021085 for ; Tue, 11 Dec 2001 07:55:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBFtmgJ021084 for mobile-ip-dist; Tue, 11 Dec 2001 07:55:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFtjvU021077 for ; Tue, 11 Dec 2001 07:55:45 -0800 (PST) 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 HAA05153 for ; Tue, 11 Dec 2001 07:55:45 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14279 for ; Tue, 11 Dec 2001 07:55:44 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBBFtgB24686; Tue, 11 Dec 2001 09:55:43 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Dec 2001 09:54:31 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E0122392E@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Tue, 11 Dec 2001 09:54:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1825C.29ABC690" Sender: owner-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_01C1825C.29ABC690 Content-Type: text/plain; charset="iso-8859-1" Erik, Comments labeled GM2] below: > > > - What happens if the MN moves away and other MN appears and > > > acquires the same > > > CoA? > > > > GM]The new mobile would have a new home address which could > be used to > > distinguish the two. > > Yes, but that home address would not be contained in the packet. > So when the CN receives a packet from a CoA how can it tell that > the CoA->HoA mapping has changed? > GM2] See the next sentence. You have to authorize the redirection if you are going to mandate the reflector check. So let me put it this way. If the HAO is there in every packet, you still have to have something extra i.e. some sort of credentials, cookie or digest in some sort of signaling to allow the CN to verify that the MN is on the level during a handoff. I.e. you do need the home address on this signaling exchange. The HOA is redundant on subsequent bearer packets between the MN and CN. If route optimization is being done then the routing header containing the home address is also redundant. > > The home address would have had to be conveyed via some > > signaling i.e. something like a binding update and the > cache maintained. > > This signaling needs to be authorized and authenticated in > order to protect > > against a mobile binding another mobile's home address to a > particular COA. > > Yes, but who would do this binding update when? > The old "owner" of the CoA might have just walked out of radio range. > The new "owner" of the CoA doesn't know which CNs might have > a binding cache > entry. > > BTW: I think it would be useful for you to work out the > details perhaps > as a short I-D. GM2] It is on the way but I think some people understand this already. If someone can find a way to do the reflector check in a stateless manner, then my point becomes invalid; however, I don't know if this is possible. I certainly have an open mind, though. BTW, which security signaling mechanism do you think I use in describing the approach? I am kind of faced with chicken before the egg problem. > > > > GM] Why would the mobile not want to use route > optimization? I don't see why > > a mobile would not want to use route optimization with > every node if it were > > available (ubiquitous). > > Limited resources - e.g. limited memory for the binding update list > or wanting to limit the total amount of bandwidth or CPU spent on > the binding update protocol. GM2] Aaah, I think that if the reflector check is mandated this will result in the mobile having to keep state and maintaining the state with the CN via refreshes etc.. So, I guess what I'm saying is that the resources used would be the same on the MN, as well; irrespective of the tunneling method used. > > > > > > > And I can't even imagine what the security issues would be in > > > such a case. > > > > GM] As far as I can tell, the security issues are exactly the same > > irrespective of whether the extra address is sent. The > statement doesn't > > detail any specific issue - by all means, please do. > > I'll do that once there is a complete proposal I can read. > GM2] Will do. > > > > GM]One thing is for sure, though. The layer-5 > signaling-based node mobility > > solutions gain in credibility each day the MIP spec is > debated over and > > incomplete. It is hard to tell who on the receiver list is > FUDing and who is > > not. I certainly don't believe you (Erik) are one of the > FUD people. > > Thanks for the confidence. > I'm am seriously concerned that we need the right security > requirements > for MIPv6 to avoid creating a new tool for DDoS attacks but I > do realize > that I am on a bit of thin ice since, even without MIPv6, there isn't > a chosen path or paths for tracing back DoS attacks. So there isn't > a very well known idea of what it means to not make it harder > to deal with > DDoS. > > Erik > GM2] You have hit the nail right on the head. I think you doing the right thing but I must say that the right thing needs to be done to IPv6 itself. I know this may not be your responsibility but nevertheless, there are massive gaping DDoS holes in IPv6. The fixes for these holes are not backed up by MUSTs either. Actually some of the fixes aren't even described in IETF documentation. This is a reverberation about Charlie's point about being singled out. Pekka has at least tried to point some of the IPv6 holes out in his ID. For instance compare the DDoS holes in stateless autoconfiguration with the reflector problem of MIPv6. It seems to me that stateless autoconfiguration wouldd not have become an RFC under the same scrutiny. Anyway, sorry about the micro-rant on the "justice due". Your ice is quite solid, though. You are doing the right thing. I just wish the other groups would think a bit more about DDoS and put mandates in to protect against it with the same vigor i.e. do the right thing. Thanks, Glenn ------_=_NextPart_001_01C1825C.29ABC690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

Erik,

Comments labeled GM2] below:
 
> > >  - What happens if the MN moves = away and other MN appears and
> > > acquires the same
> > >    CoA?
> >
> > GM]The new mobile would have a new home = address which could
> be used to
> > distinguish the two.
>
> Yes, but that home address would not be = contained in the packet.
> So when the CN receives a packet from a CoA how = can it tell that
> the CoA->HoA mapping has changed?
>

GM2] See the next sentence. You have to authorize the = redirection if you are going to mandate the reflector check. So let me = put it this way. If the HAO is there in every packet, you still have to = have something extra i.e. some sort of credentials, cookie or digest in = some sort of signaling to allow the CN to verify that the MN is on the = level during a handoff. I.e. you do need the home address on this = signaling exchange. The HOA is redundant on subsequent bearer packets = between the MN and CN. If route optimization is being done then the = routing header containing the home address is also = redundant.

> > The home address would have had to be = conveyed via some
> > signaling i.e. something like a binding = update and the
> cache maintained.
> > This signaling needs to be authorized and = authenticated in
> order to protect
> > against a mobile binding another mobile's = home address to a
> particular COA.
>
> Yes, but who would do this binding update = when?
> The old "owner" of the CoA might have = just walked out of radio range.
> The new "owner" of the CoA doesn't = know which CNs might have
> a binding cache
> entry.
>
> BTW: I think it would be useful for you to work = out the
> details perhaps
> as a short I-D.

GM2] It is on the way but I think some people = understand this already. If someone can find a way to do the reflector = check in a stateless manner, then my point becomes invalid; however, I = don't know if this is possible. I certainly have an open mind, though. = BTW, which security signaling mechanism do you think I use in = describing the approach? I am kind of faced with chicken before the egg = problem.

>
>
> > GM] Why would the mobile not want to use = route
> optimization? I don't see why
> > a mobile would not want to use route = optimization with
> every node if it were
> > available (ubiquitous).
>
> Limited resources - e.g. limited memory for the = binding update list
> or wanting to limit the total amount of = bandwidth or CPU spent on
> the binding update protocol.

GM2] Aaah, I think that if the reflector check is = mandated this will result in the mobile having to keep state and = maintaining the state with the CN via refreshes etc.. So, I guess what = I'm saying is that the resources used would be the same on the MN, as = well; irrespective of the tunneling method used.

>
> > >
> > > And I can't even imagine what the = security issues would be in
> > > such a case.
> >
> > GM] As far as I can tell, the security = issues are exactly the same
> > irrespective of whether the extra address = is sent. The
> statement doesn't
> > detail any specific issue - by all means, = please do.
>
> I'll do that once there is a complete proposal = I can read.
>
 
GM2] Will do.

>
>
> > GM]One thing is for sure, though. The = layer-5
> signaling-based node mobility
> > solutions gain in credibility each day the = MIP spec is
> debated over and
> > incomplete. It is hard to tell who on the = receiver list is
> FUDing and who is
> > not. I certainly don't believe you (Erik) = are one of the
> FUD people.
>
> Thanks for the confidence.
> I'm am seriously concerned that we need the = right security
> requirements
> for MIPv6 to avoid creating a new tool for DDoS = attacks but I
> do realize
> that I am on a bit of thin ice since, even = without MIPv6, there isn't
> a chosen path or paths for tracing back DoS = attacks. So there isn't
> a very well known idea of what it means to not = make it harder
> to deal with
> DDoS.
> 
>    Erik
>

GM2] You have hit the nail right on the head. I think = you doing the right thing but I must say that the right thing needs to = be done to IPv6 itself. I know this may not be your responsibility but = nevertheless, there are massive gaping DDoS holes in IPv6. The fixes = for these holes are not backed up by MUSTs either. Actually some of the = fixes aren't even described in IETF documentation. This is a = reverberation about Charlie's point about being singled out. Pekka has = at least tried to point some of the IPv6 holes out in his ID. For = instance compare the DDoS holes in stateless autoconfiguration with the = reflector problem of MIPv6. It seems to me that stateless = autoconfiguration wouldd not have become an RFC under the same = scrutiny. Anyway, sorry about the micro-rant on the "justice = due". Your ice is quite solid, though. You are doing the right = thing. I just wish the other groups would think a bit more about DDoS = and put mandates in to protect against it with the same vigor i.e. do = the right thing.

Thanks,

Glenn

------_=_NextPart_001_01C1825C.29ABC690-- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 10:58: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 KAA19415 for ; Tue, 11 Dec 2001 10:58:48 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28495; Tue, 11 Dec 2001 08:57:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20113; Tue, 11 Dec 2001 07:57:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFv2vU021122 for ; Tue, 11 Dec 2001 07:57:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBFv2FJ021121 for mobile-ip-dist; Tue, 11 Dec 2001 07:57:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBFuvvU021114 for ; Tue, 11 Dec 2001 07:56:58 -0800 (PST) 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 fBBFurq17636; Tue, 11 Dec 2001 16:56:53 +0100 (MET) Date: Tue, 11 Dec 2001 16:55:09 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] Routing header Vs tunneling To: "Patil Basavaraj (NET/Dallas)" Cc: mobile-ip@sunroof.eng.sun.com, TJ@Kniveton.com, Erik.Nordmark@eng.sun.com In-Reply-To: "Your message with ID" <697DAA22C5004B4596E033803A7CEF444CD24C@daebe007.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: > I think we simply need to focus on the problem that we have been > dealing with over the past year and resolve that. Agreed. How to secure BUs and security requirements for HAOPt and RH is what need to be resolved ASAP. > There is no reason to rush into tunnelling over RH without a fair bit > of analysis. So the "now or never" question in my opinion does not > apply. The "now or never" means that assuming that "we can change this in the next version of MIPv6 after MIPv6 has started to be deployed" makes absolutely no sense. Thus at some point in time we need enough analysis for the WG to be able to make a decision. > Let the IRTF or whoever else wishes to study the implications > of changing from the use of RH to tunnelling for IP mobility do so > over the next few months (or years) and if the outcome of that > analysis says mobility is better done with tunelling, we should > consider it at that time. Makes zero sense to me. Once MIPv6 has been deployed there are close to zero benefits of switching to use a different "encoding" of the IP addresses that go in HAOpt and RH. It would cause potential massive interoperability problems unless everybody implements both the old and new. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 11:11: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 LAA19711 for ; Tue, 11 Dec 2001 11:11:47 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA25627; Tue, 11 Dec 2001 08:09:19 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22598; Tue, 11 Dec 2001 08:09:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBG8SvU021350 for ; Tue, 11 Dec 2001 08:08:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBG8SNw021349 for mobile-ip-dist; Tue, 11 Dec 2001 08:08:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBG8PvU021342 for ; Tue, 11 Dec 2001 08:08:25 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06787 for ; Tue, 11 Dec 2001 08:07:22 -0800 (PST) Received: from cambianetworks.com (66-73-249-62.cambianetworks.com [66.73.249.62] (may be forged)) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA04332 for ; Tue, 11 Dec 2001 09:07:22 -0700 (MST) Received: (qmail 23731 invoked by uid 8); 11 Dec 2001 16:07:21 -0000 Received: from pc-01582 (172.16.6.46, claiming to be "USAROSRMARKS1") by gate.cambianetworks.com with SMTP id smtpdq7vLlB; Tue, 11 Dec 2001 11:07:18 EST From: "Robert J Marks" To: , "'Patil Basavaraj \(NET/Dallas\)'" , "'Perkins Charles \(IPRG\)'" Cc: "'Pete Wenzel'" , "'Pat Calhoun'" Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Date: Tue, 11 Dec 2001 10:07:04 -0600 Organization: Cambia Networks Message-ID: <000601c1825d$e010eea0$2e0610ac@cambianetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C1822B.95767EA0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <6B49EDFE974BD51197D70002A56079D82AF605@zrc2c013.us.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C1822B.95767EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ahmad, I agree. The presence of a "new" NAI at the FA signals that authentication should be performed. If a MN sends a Registration Request using a new NAI, the FA should treat it as a new registration. I guess I don't see the issue. Bob From: Ahmad Muhanna Bob; I think our concern here is how the FA handles the RRQ message in these scenarios. Let us remember, if it is a re-transmission, FA does not authenticate the user through AAA. However, if it is considered a new registration, FA MUST authenticate the RRQ message "the USER" before relaying the RRQ to HA. I hope this clarifies the issue at hand. Thanks; Ahmad Muhanna -----Original Message----- From: Robert J Marks [mailto:rjmarks@cambianetworks.com] Sent: Tuesday, December 11, 2001 7:05 AM To: mobile-ip@sunroof.eng.sun.com; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)' Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun' Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Ahmad, Some observations on your scenarios. Ahmad Muhanna wrote: > What about the following scenario: > 1. MN sends a RRQ message with NAI1, Home Address 0.0.0.0. > 2. MN sends 1st retry of RRQ with NAI1, Home address 0.0.0.0. > > 3. Now, we have a SMART MN, which figures out that it can use another > Profile with NAI2 and Home Address 0.0.0.0. > > 4. Since section 3.7.1 in RFC2002 does not talk about the user NAI, > PDSN will consider this as a retransmission while may be the user > would have failed authentication at the AAA. This situation will be treated as a new Registration Request, independent of the request that used NAI1. The Home Agent will not correlate the two requests, since it identifies the MN by the NAI in this case. > ** Another thing, what about if we support different NAIs over the > same PPP session and let us say NAI1, NAI2, and NAI3 have the same > HA and all requesting Dynamic MIP calls with Home Addresses of 0.0.0.0. All three requests will be treated as independent registrations. The HA does not know about PPP, and again uses the NAI to identify the MN. > ********** > Ahmad Muhanna Bob Robert J Marks Cambia Networks Office: +1 847 627 3703 Mobile: +1 708 829 6329 -----Original Message----- From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] Sent: Tuesday, November 13, 2001 4:20 PM To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles (IPRG) Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP Working Group; Pat Calhoun Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Charlie proposed the following text: >======================================================================= > >Here is the new relevant text, in the same paragraph as your original >quote: > > .... The Foreign Agent SHOULD check that the mobile node is > actually performing a retransmission, by verifying that the relevant > fields of the retransmitted request are the same as represented in > the visitor list entry for the pending Registration Request (section > 3.7.1 of [8]). This verification MUST NOT include the "remaining > Lifetime of the pending registration", or the Identification field > since those values are likely to change even for requests that are > merely retransmissions and not new Registration Requests. In all > other circumstances, if the Foreign Agent receives .... > >======================================================================= > >Comments? > >>Ahmad Muhanna: >>I hope you would agree that the following change will satisfy the need: >> >>"If a mobile node retransmits a Registration Request with the same >>Identification field and the same Challenge extension, and the Foreign >>Agent still has a pending Registration Request record in effect for the >>mobile node, then the Foreign Agent forwards the Registration Request to >>the Home Agent again (see Registration Retransmission, section 3.6.3[8]). >>In all other circumstances, if the Foreign Agent receives a Registration >>Request with a Challenge extension containing a Challenge value previously >>used by that mobile node, the Foreign Agent SHOULD send a Registration >>Reply to the mobile node containing the Code value STALE_CHALLENGE." > >Regards, >Charlie P. > I think the text that Charlie proposes makes it quite clear as to what the FA must do in order to recognize, if it is a retransmission. So I would recommend going with Charlie's text in the revision for this spec. -Basavaraj ------=_NextPart_000_0007_01C1822B.95767EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Ahmad,
 
I=20 agree. The presence of a "new" NAI at the FA signals that=20 authentication should be performed.
If a=20 MN sends a Registration Request using a new NAI, the FA should = treat it as=20 a new registration.
I=20 guess I don't see the issue.
 
Bob 
 
From: Ahmad=20 Muhanna

Bob;

I think our concern here is how the FA handles the = RRQ message=20 in these scenarios.
Let us remember, if it = is a=20 re-transmission, FA does not authenticate the user through AAA. =
However, if it is considered a new registration, FA = MUST=20 authenticate the RRQ message
"the USER" = before=20 relaying the RRQ to HA.
I hope this = clarifies the=20 issue at hand.

Thanks;

Ahmad Muhanna


-----Original Message-----
From:=20 Robert J Marks [mailto:rjmarks@cambianetworks.= com]=20
Sent: Tuesday, December 11, 2001 7:05 AM =
To: mobile-ip@sunroof.eng.sun.com; 'Patil Basavaraj=20 (NET/Dallas)';
'Perkins Charles = (IPRG)'=20
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat = Calhoun'=20
Subject: RE: [mobile-ip] URGENT - rfc3012 = interpretation=20 question


Ahmad,

Some observations on your scenarios. =
 
Ahmad Muhanna wrote: =

> What about the following scenario:

> 1. MN sends a RRQ message with NAI1, Home = Address=20 0.0.0.0.
> 2. MN sends 1st retry of RRQ = with NAI1,=20 Home address 0.0.0.0.
>
> 3. Now, we have a SMART MN, which figures out that it = can use=20 another
>    Profile with = NAI2 and=20 Home Address 0.0.0.0.
>
> 4. Since section 3.7.1 in RFC2002 does not talk about = the user=20 NAI,
> PDSN will consider this as a = retransmission=20 while may be the user
> would have failed = authentication at the AAA.

This situation will be treated as a new Registration = Request,
independent
of the=20 request that used NAI1. The Home Agent will not correlate the = two=20
requests, since it identifies the MN by the NAI in = this=20 case.

> ** Another thing, what about if we support = different NAIs=20 over the
> same PPP session and let us = say NAI1,=20 NAI2, and NAI3 have the same
> HA and all = requesting Dynamic MIP calls with Home Addresses of
0.0.0.0.

All three requests will be treated as independent=20 registrations. The HA
does not know about = PPP, and=20 again uses the NAI to identify the MN.
 =20
> **********
> = Ahmad Muhanna=20

Bob

Robert J Marks
Cambia = Networks=20
Office: +1 847 627 3703
Mobile: +1=20 708 829 6329

 -----Original Message-----
From:=20 Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.co= m]=20
Sent: Tuesday, November 13, 2001 4:20 PM =
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles = (IPRG)=20
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP = Working Group;=20 Pat Calhoun
Subject: RE: [mobile-ip] URGENT = - rfc3012=20 interpretation question



Charlie proposed the following text: =
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=20

>
>Here is the new = relevant=20 text, in the same paragraph as your original
>quote:
>
>      = ....     =20 The Foreign Agent SHOULD check that the mobile node is =
>   actually performing a retransmission, by = verifying=20 that the relevant

>   fields of the retransmitted request = are the=20 same as represented in
>   the = visitor=20 list entry for the pending Registration Request (section

>   3.7.1 of [8]).  This = verification MUST=20 NOT include the "remaining
>   = Lifetime=20 of the pending registration", or the Identification field =
>   since those values are likely to change even = for=20 requests that are
>   merely=20 retransmissions and not new Registration Requests.  In all=20
>   other circumstances, if the = Foreign=20 Agent receives   ....
> =
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=20

>
>Comments? =
>
>>Ahmad Muhanna: =
>>I hope you would agree that the following change will = satisfy=20 the
need:
>>=20
>>"If a mobile node retransmits a = Registration Request=20 with the same
>>Identification field = and the=20 same Challenge extension, and the Foreign

>>Agent still has a pending Registration = Request record=20 in effect for
the
>>mobile node, then the Foreign Agent forwards the = Registration=20 Request
to
>>the Home=20 Agent again (see Registration Retransmission, section
3.6.3[8]).
>>In all other = circumstances,=20 if the Foreign Agent receives a
Registration =
>>Request with a Challenge extension = containing=20 a Challenge value
previously =
>>used by that mobile node, the Foreign Agent SHOULD = send a=20 Registration

>>Reply to the mobile node containing the Code = value=20 STALE_CHALLENGE."
>
>Regards,
>Charlie P. =
>

I think the text that Charlie proposes makes it = quite clear as=20 to what
the FA must do in order to = recognize, if it is=20 a retransmission. So I
would recommend going = with=20 Charlie's text in the revision for this
spec.=20

-Basavaraj

------=_NextPart_000_0007_01C1822B.95767EA0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 11:17: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 LAA19808 for ; Tue, 11 Dec 2001 11:17:53 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29388; Tue, 11 Dec 2001 08:16:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23830; Tue, 11 Dec 2001 08:16:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBGG5vU021440 for ; Tue, 11 Dec 2001 08:16:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBGG5g3021439 for mobile-ip-dist; Tue, 11 Dec 2001 08:16:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBGG0vU021432 for ; Tue, 11 Dec 2001 08:16:01 -0800 (PST) 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 fBBGFrq20562; Tue, 11 Dec 2001 17:15:53 +0100 (MET) Date: Tue, 11 Dec 2001 17:14:08 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routing header Vs tunneling To: "T.J. Kniveton" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C15A886.146423BE@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: > Route optimization and security are a really interesting topic of study, > and I'm sure that some time down the road, we could look back at how > well HAO+RH has worked in the Mobile IPv6 v.RFC deployments, perhaps try > out the tunneling idea in some implementations as well and do interop > testing as has been done with HAO+RH, and maybe weigh that with some new > ideas, to come up with some really good extensions / implementation > Info-RFCs, Mobile-IPv6 v.2, or whatever.. With a potential MIPV6.2 using tunneling would you obsolete MIPV6.1 (using HAOpt/RH)? Or require that everybody implement both? > Yes, this is true. And to some extent I imagine that it would be true of > the current situation as well: Mobile IPv6 implementations use what has > been specified since day 1. And OK, let's say that's not such a big > deal, we can with some fixed amount of work, go and change all of these > implementations to use something entirely different. It's also my > understanding that all IPv6 nodes (CNs) are supposed to implement HAOs, > and I would imagine the amount of work to go change all of these > implementations and deployments might be very large, and that trying to > do so might end up crippling any chance of widescale Mobile IPv6 > acceptance on the Internet. The CNs that implement HAOpts today are unlikely to satisfy the security requirements around those options since the draft has said it is ok to accept HAOpt without any checks. Thus all those CNs need to be updated in any case. (In the interest of full disclosure I did implement HAOpt processing in Solaris 8 per the I-D at the time.) > OK, I guess my response would be that it is a "justify or never" > decision. Since we're past the design phase, unless an overwhelming > reason to change > an existing mechanism can be clearly justified and defended, there is no > reason to do it. I agree that the pronents for making the change need to make the arguments. I do observe that such suggestions were made to the MIP mailing list about 2 years ago which met utter silence. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 11:40: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 LAA20200 for ; Tue, 11 Dec 2001 11:40:48 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06788; Tue, 11 Dec 2001 09:38:55 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12620; Tue, 11 Dec 2001 08:39:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBGcTvU021563 for ; Tue, 11 Dec 2001 08:38:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBGcTUw021562 for mobile-ip-dist; Tue, 11 Dec 2001 08:38:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBGcQvU021555 for ; Tue, 11 Dec 2001 08:38:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10263 for ; Tue, 11 Dec 2001 08:38:26 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06178 for ; Tue, 11 Dec 2001 09:38:07 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBBGcNB07072; Tue, 11 Dec 2001 10:38:24 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Dec 2001 10:37:12 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01223A39@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Cc: Erik Nordmark , deering@cisco.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Tue, 11 Dec 2001 10:37:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18262.202EFA00" Sender: owner-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_01C18262.202EFA00 Content-Type: text/plain; charset="iso-8859-1" The deal was that after the MIPv6 spec is a proposed standard, we can start addressing the simultaneous operation of LP and RO. This agreement was made some two years ago. We didn't think the spec would take that long. I think this simultaneous operation is what was meant by the statement below. -----Original Message----- From: Casati, Alessio (Alessio) [mailto:acasati@lucent.com] Sent: Tuesday, December 11, 2001 6:18 AM To: 'mobile-ip@sunroof.eng.sun.com' Cc: Erik Nordmark; deering@cisco.com Subject: RE: [mobile-ip] Routing header Vs tunneling Well just to make it clear, location privacy is not a requirement for Mobile IPv6 at this time. We had location privacy as a separate work item in the MIP charter/milsetones earlier but that is a separate problem and needs to be dealt as such. -Basavaraj Location privacy is not an issue if we use MIPv6 with Reverse tunneling and no Route optimization (or, as per somebody's novel definition, no Route Optimization "both ways"). Is there more work on Location privacy with MIPv6 you may think about? Or should you mark this as "done". Alessio ------_=_NextPart_001_01C18262.202EFA00 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Routing header Vs tunneling
The deal was that after the MIPv6 spec is a proposed standard, we can start addressing the simultaneous operation of LP and RO. This agreement was made some two years ago. We didn't think the spec would take that long. I think this simultaneous operation is what was meant by the statement below.
-----Original Message-----
From: Casati, Alessio (Alessio) [mailto:acasati@lucent.com]
Sent: Tuesday, December 11, 2001 6:18 AM
To: 'mobile-ip@sunroof.eng.sun.com'
Cc: Erik Nordmark; deering@cisco.com
Subject: RE: [mobile-ip] Routing header Vs tunneling

Well just to make it clear, location privacy is not a requirement for Mobile IPv6 at this time. We had location privacy as a separate work item in the MIP charter/milsetones earlier but that is a separate problem and needs to be dealt as such.

 

-Basavaraj 

 

Location privacy is not an issue if

we use MIPv6 with Reverse tunneling and no Route optimization

(or, as per somebody's novel definition, no

Route Optimization "both ways"). Is there more work on Location privacy with MIPv6

you may think about? Or should you mark this as "done".

Alessio 

------_=_NextPart_001_01C18262.202EFA00-- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 11:52:20 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 LAA20355 for ; Tue, 11 Dec 2001 11:52:20 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA17378; Tue, 11 Dec 2001 08:51:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14739; Tue, 11 Dec 2001 08:51:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBGoMvU021657 for ; Tue, 11 Dec 2001 08:50:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBGoM0b021656 for mobile-ip-dist; Tue, 11 Dec 2001 08:50:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBGoJvU021649 for ; Tue, 11 Dec 2001 08:50:19 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29741 for ; Tue, 11 Dec 2001 08:50:20 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01241 for ; Tue, 11 Dec 2001 09:50:19 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBBGoHB10130 for ; Tue, 11 Dec 2001 10:50:18 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Dec 2001 10:49:06 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01223A79@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Tue, 11 Dec 2001 10:49:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18263.C9D5CDD0" Sender: owner-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_01C18263.C9D5CDD0 Content-Type: text/plain; charset="iso-8859-1" All we are seeing is IPv6 being reduced to IPv4 with expanded address space. You are just seeing the RH being nuked for the fast-path. Perhaps we should have seen it coming. > -----Original Message----- > From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] > Sent: Monday, December 10, 2001 9:45 PM > To: mobile-ip > Cc: gab > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > >Agree. This might put me on Glenn Morrow's FUD list, but here's an > >extreme position: > > > > Extreme indeed :) > > >I think this is where the IESG must step in. Yes, the MIP wg can go > continue > >using RH/HAO, but I think it has been successfully demonstrated that > >tunneling with the zill/deering extensions can accomplish the same > thing. > >It is the IESG's job to avoid proliferation of duplicate mechanisms. > Better > >one well-known mechanism than a slew of them. Definitely true for > >security and firewalls point of view, so it can be couched in those > >terms. > > MIPv6 has been worked on for over five years now. The proposal to drop > RH/HAO is equivalent to going back to square one and starting to > redesign the IP mobility protocol. I think the IESG would be moving > the yardstick on IP mobility a few years back if we decide to take > this approach. If you want the perfect solution for IP mobility, then > we may as well wait for a few more years and wish that an even better > solution for moving packets between MNs and CNs comes up. Or we could > take the current solution with the RH/HAO to completion and see if we > can have a working solution today. > > If you really want to redesign IP mobility, there is nothing to stop > you from doing so. But I do not believe it has to be at the cost of > stopping the MIPv6 work in its tracks. I think we have spent more than > enough time on trying to solve this problem. We have a few solutions > that will fix the problem. Lets get this done now and then maybe go > back to thinking better ways of doing tunnelling and mobility. > > > > >Notice that this nearly happened in IPv4 with Dave Johnson's minimal > >encapsulation (rfc2004) but it didn't gain much ground cuz only the > >MIP wg was pushing it. This new zill/deering option is now outside > >the MIP wg, where it should be. MIP wg should just adopt it, help > >spec it, push to put it on the fast-track and get it done. > > > > And spend the next few years without a solution for IPv6 mobility? I > would not even consider this as an option for MIP WG to consider at > this time. > > >And yes, we should deprecate RH/HAO. Anything to make mobility less > >'weird' and more in line with non-mobile wg's (IPv6) will save us > >problems down the road. > > Maybe while the IESG is thinking of deprecating the RH and DO headers, > they could consider a few others as well :( Sorry if this sounds so > negative, but we seem to be digging a deeper hole to get ourselves > into. > > > > >asbestos shields on, > > > >-gabriel > > -Basavaraj > ------_=_NextPart_001_01C18263.C9D5CDD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

All we are seeing is IPv6 being reduced to IPv4 with = expanded address space. You are just seeing the RH being nuked for the = fast-path. Perhaps we should have seen it coming.

> -----Original Message-----
> From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.c= om]
> Sent: Monday, December 10, 2001 9:45 PM
> To: mobile-ip
> Cc: gab
> Subject: RE: [mobile-ip] Routing header Vs = tunneling
>
>
> >Agree. This might put me on Glenn Morrow's = FUD list, but here's an
> >extreme position:
> >
>
> Extreme indeed :)
>
> >I think this is where the IESG must step = in. Yes, the MIP wg can go
> continue
> >using RH/HAO, but I think it has been = successfully demonstrated that
> >tunneling with the zill/deering extensions = can accomplish the same
> thing.
> >It is the IESG's job to avoid proliferation = of duplicate mechanisms.
> Better
> >one well-known mechanism than a slew of = them. Definitely true for
> >security and firewalls point of view, so it = can be couched in those
> >terms.
>
> MIPv6 has been worked on for over five years = now. The proposal to drop
> RH/HAO is equivalent to going back to square = one and starting to
> redesign the IP mobility protocol. I think the = IESG would be moving
> the yardstick on IP mobility a few years back = if we decide to take
> this approach. If you want the perfect solution = for IP mobility, then
> we may as well wait for a few more years and = wish that an even better
> solution for moving packets between MNs and CNs = comes up. Or we could
> take the current solution with the RH/HAO to = completion and see if we
> can have a working solution today.
>
> If you really want to redesign IP mobility, = there is nothing to stop
> you from doing so. But I do not believe it has = to be at the cost of
> stopping the MIPv6 work in its tracks. I think = we have spent more than
> enough time on trying to solve this problem. We = have a few solutions
> that will fix the problem. Lets get this done = now and then maybe go
> back to thinking better ways of doing = tunnelling and mobility.
>
> >
> >Notice that this nearly happened in IPv4 = with Dave Johnson's minimal
> >encapsulation (rfc2004) but it didn't gain = much ground cuz only the
> >MIP wg was pushing it. This new = zill/deering option is now outside
> >the MIP wg, where it should be. MIP wg = should just adopt it, help
> >spec it, push to put it on the fast-track = and get it done.
> >
>
> And spend the next few years without a solution = for IPv6 mobility? I
> would not even consider this as an option for = MIP WG to consider at
> this time.
>
> >And yes, we should deprecate RH/HAO. = Anything to make mobility less
> >'weird' and more in line with non-mobile = wg's (IPv6) will save us
> >problems down the road.
>
> Maybe while the IESG is thinking of deprecating = the RH and DO headers,
> they could consider a few others as well :( = Sorry if this sounds so
> negative, but we seem to be digging a deeper = hole to get ourselves
> into.
>
> >
> >asbestos shields on,
> >
> >-gabriel
>
> -Basavaraj
>

------_=_NextPart_001_01C18263.C9D5CDD0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 12:19:15 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20989 for ; Tue, 11 Dec 2001 12:19:15 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01845; Tue, 11 Dec 2001 09:18:09 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20966; Tue, 11 Dec 2001 09:18:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHHOvU021773 for ; Tue, 11 Dec 2001 09:17:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBHHOb2021772 for mobile-ip-dist; Tue, 11 Dec 2001 09:17:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHHJvU021765 for ; Tue, 11 Dec 2001 09:17:20 -0800 (PST) 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 JAA13331 for ; Tue, 11 Dec 2001 09:17:20 -0800 (PST) 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 JAA03311 for ; Tue, 11 Dec 2001 09:17:18 -0800 (PST) Received: from chardonnay (india.local.ipunplugged.com [192.168.4.78]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA20583 for ; Tue, 11 Dec 2001 18:16:23 +0100 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] RFC 3012 - what about challenges from HA Date: Tue, 11 Dec 2001 18:17:15 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6B49EDFE974BD51197D70002A56079D82AF602@zrc2c013.us.nortel.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 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 Well, a shared secret or public-private keypair I guess. The point is that there are a lot of companies which already have security solutions in place that provide the shared secrets or public-private keypairs, but are designed to work only with challenges. For instance there are ID cards with a builtin chip which can be fed a challenge and output a response, but the shared secret itself is not available for use. If we could avoid having to establish an additional security infrastructure for the MIP security associations, it would sit well with companies that already have such solutions out there. Best regards, Henrik Ahmad wrote: > > I am not sure about the mechanism of using challenges from HA. > If we assume that there is a mechanism to use Challenges from HA, > we still need to have a secret key between the HA and the MN to use Challenges. > > Regards; > Ahmad Muhanna > > Nortel Networks > Shasta PDSN-MIP Development > Phone. + 1 972 685 1416 ESN. 445-1416 > amuhanna@nortelnetworks.com > > > > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@ipunplugged.com] > Sent: Sunday, December 09, 2001 4:24 AM > To: mobile-ip > Subject: RE: [mobile-ip] RFC 3012 - what about challenges from HA > > > Hi Charlie, > Ah, I see, then I can appreciate the reasoning. However, > what if one would like to use a pre-existing authentication > infrastructure which was designed to use challenges, instead > of creating a new set of shared secrets, public/private keys > or whatever for use with mobile ip? Might there not be a place > also for challenges from a HA in that case? > Regards, > Henrik > > > > Hello Henrik, > > > > Since the home agent has a security association with the > > mobile node, and since the registration request has > > replay protection and authentication extension, there > > isn't any need for the challenge. The whole registration > > message data can properly be considered to be a > > challenge, because of the anti-replay data in the > > Identificatoin field. > > > > Regards, > > Charlie P. > > > > > > Henrik Levkowetz wrote: > > > > > On going over RFC 3012 and the 3012bis draft, I'm getting puzzled by > > > this: > > > > > > There is provisions for challenges to the MN from the FA, trough the > > > MIP Agent Advertisment Challenge Extension(section 2), and there is > > > provisions for challenges from all entities except the HA and FA > > > trough the Generalized Mobile IP Authentication Extension (section 5). > > > > > > But this leaves the HA hanging in the middle - there's no specific > > > challenge extension for a HA to use, and the Generalized Mobile IP > > > Authentication Extension is not defined for an HA to use. > > > > > > How Come? > > > > > > Henrik > > > > > > ------------------------------------------------------------------------ > > > Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com > > > ------------------------------------------------------------------------ From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 12:25: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 MAA21089 for ; Tue, 11 Dec 2001 12:25:18 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14124; Tue, 11 Dec 2001 10:23:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22745; Tue, 11 Dec 2001 09:24:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHNYvU021856 for ; Tue, 11 Dec 2001 09:23:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBHNXk3021855 for mobile-ip-dist; Tue, 11 Dec 2001 09:23:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHNTvU021848 for ; Tue, 11 Dec 2001 09:23:29 -0800 (PST) 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 JAA19403 for ; Tue, 11 Dec 2001 09:23:30 -0800 (PST) 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 JAA06691 for ; Tue, 11 Dec 2001 09:23:28 -0800 (PST) Received: from chardonnay (india.local.ipunplugged.com [192.168.4.78]) by mailgw.ipunplugged.com (8.9.3/8.9.3) with SMTP id SAA20722 for ; Tue, 11 Dec 2001 18:22:34 +0100 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] RFC 3012 - what about challenges from HA Date: Tue, 11 Dec 2001 18:23:26 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <6B49EDFE974BD51197D70002A56079D82AF602@zrc2c013.us.nortel.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 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 Well, a shared secret or public-private keypair I guess. The point is that there are a lot of companies which already have security solutions in place that provide the shared secrets or public-private keypairs, but are designed to work only with challenges. For instance there are ID cards with a builtin chip which can be fed a challenge and output a response, but the shared secret itself is not available for use. If we could avoid having to establish an additional security infrastructure for the MIP security associations, it would sit well with companies that already have such solutions out there. Best regards, Henrik Ahmad wrote: > > I am not sure about the mechanism of using challenges from HA. > If we assume that there is a mechanism to use Challenges from HA, > we still need to have a secret key between the HA and the MN to use Challenges. > > Regards; > Ahmad Muhanna > > Nortel Networks > Shasta PDSN-MIP Development > Phone. + 1 972 685 1416 ESN. 445-1416 > amuhanna@nortelnetworks.com > > > > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@ipunplugged.com] > Sent: Sunday, December 09, 2001 4:24 AM > To: mobile-ip > Subject: RE: [mobile-ip] RFC 3012 - what about challenges from HA > > > Hi Charlie, > Ah, I see, then I can appreciate the reasoning. However, > what if one would like to use a pre-existing authentication > infrastructure which was designed to use challenges, instead > of creating a new set of shared secrets, public/private keys > or whatever for use with mobile ip? Might there not be a place > also for challenges from a HA in that case? > Regards, > Henrik > > > > Hello Henrik, > > > > Since the home agent has a security association with the > > mobile node, and since the registration request has > > replay protection and authentication extension, there > > isn't any need for the challenge. The whole registration > > message data can properly be considered to be a > > challenge, because of the anti-replay data in the > > Identificatoin field. > > > > Regards, > > Charlie P. > > > > > > Henrik Levkowetz wrote: > > > > > On going over RFC 3012 and the 3012bis draft, I'm getting puzzled by > > > this: > > > > > > There is provisions for challenges to the MN from the FA, trough the > > > MIP Agent Advertisment Challenge Extension(section 2), and there is > > > provisions for challenges from all entities except the HA and FA > > > trough the Generalized Mobile IP Authentication Extension (section 5). > > > > > > But this leaves the HA hanging in the middle - there's no specific > > > challenge extension for a HA to use, and the Generalized Mobile IP > > > Authentication Extension is not defined for an HA to use. > > > > > > How Come? > > > > > > Henrik > > > > > > ------------------------------------------------------------------------ > > > Henrik Levkowetz +46708321608 henrik@ipunplugged.com www.ipunplugged.com > > > ------------------------------------------------------------------------ From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 12:26: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 MAA21139 for ; Tue, 11 Dec 2001 12:26:53 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05713; Tue, 11 Dec 2001 09:25:21 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22905; Tue, 11 Dec 2001 09:24:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHNtvU021873 for ; Tue, 11 Dec 2001 09:23:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBHNtcT021872 for mobile-ip-dist; Tue, 11 Dec 2001 09:23:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHNpvU021858 for ; Tue, 11 Dec 2001 09:23:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19499 for ; Tue, 11 Dec 2001 09:23:51 -0800 (PST) Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02518 for ; Tue, 11 Dec 2001 10:23:47 -0700 (MST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 221A16A905; Tue, 11 Dec 2001 19:23:42 +0200 (EET) Message-ID: <3C1635A3.2070105@piuha.net> Date: Tue, 11 Dec 2001 18:34:43 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Claude Castelluccia Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark , mroe@microsoft.com, tuomaura@microsoft.com Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: <3C12BA10.5030304@piuha.net> <3C14787C.C5C79043@inrialpes.fr> <3C149F8F.1030203@piuha.net> <3C14F65C.6020901@piuha.net> <3C15CAB4.20D8B8ED@inrialpes.fr> 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 Claude Castelluccia wrote: > The prevention of this attack is another reason why CAM-DH runs BAKE/2 > at the bottom: the return routability tests ensure that the attackers > can't claim to be from X if they really aren't from there (or on > the path to it). > > In SUCV, the 4 SUCVp messages are exchanged between the CN and the > MN (the CoA). > So the MN has to be in the X network (or on the path to it) for the SUCV > exchange to succeed... Ah yes, but in my attack above X was the prefix of the home network and it was assumed to be different from Y, the prefix of the CoA network. > The only weakness (i think) is that this exchange might succeed even if > the attacker is on the path to X but > return routability does not solve this problem. In fact what prevents, > in this case, an attacker to choose > a HomeAddress that is also on the path from the CN to X??? > > I think that return routability might only be useful against an attacker > trying to redirect a "legitimate" HomeAddress... > but SUCV/CAM also solves this issue... Here's the attack: 1. Invent a new SUCV-address (you can do it) of the form X: 2. Go to network Y and get an address Y: 3. Run SUCV against any CN. This will succeed, because the attacker generated the address by himself. 4. Start some session with the CN, using Route Optimization 5. Send a BU to the CN with lifetime 0. This will kill the BCE. 6. CN continues to send a number of packets towards X: on the open session (e.g. RTP videostream). 7. The packets arrive at network X, and do not hit any specific node because in step 1 we obviously can't pick any existing address. However, the network will be full of packets, and X's Internet pipe may be full. This attack has a relatively high amplification factor. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 12:44: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 MAA21457 for ; Tue, 11 Dec 2001 12:44:01 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15414; Tue, 11 Dec 2001 09:42:38 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28396; Tue, 11 Dec 2001 09:42:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHfuvU022132 for ; Tue, 11 Dec 2001 09:41:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBHfuXS022131 for mobile-ip-dist; Tue, 11 Dec 2001 09:41:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHfrvU022124 for ; Tue, 11 Dec 2001 09:41:53 -0800 (PST) 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 JAA23890 for ; Tue, 11 Dec 2001 09:41:54 -0800 (PST) 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 JAA20180 for ; Tue, 11 Dec 2001 09:41:53 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id BC8656A905; Tue, 11 Dec 2001 19:41:48 +0200 (EET) Message-ID: <3C1643C5.30505@piuha.net> Date: Tue, 11 Dec 2001 19:35:01 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Glenn Morrow Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark Subject: Re: [mobile-ip] Routing header Vs tunneling References: <933FADF5E673D411B8A30002A5608A0E0122392E@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Glenn Morrow wrote: > GM2] You have hit the nail right on the head. I think you doing the > right thing but I must say that the right thing needs to be done to IPv6 > itself. I know this may not be your responsibility but nevertheless, > there are massive gaping DDoS holes in IPv6. The fixes for these holes Very much agreed. > are not backed up by MUSTs either. Actually some of the fixes aren't > even described in IETF documentation. This is a reverberation about > Charlie's point about being singled out. Pekka has at least tried to > point some of the IPv6 holes out in his ID. For instance compare the > DDoS holes in stateless autoconfiguration with the reflector problem of > MIPv6. It seems to me that stateless autoconfiguration wouldd not have > become an RFC under the same scrutiny. Anyway, sorry about the There could still be differences in the seriousness of attacks. In your particular example, I'm not sure autoconfiguration has similar global problems as MIPv6 has; the autoconfiguration procedures are full of holes but can we launch attacks against some non-local parties through them in an easy way while at the same time escaping to be located? Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 12:57: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 MAA21744 for ; Tue, 11 Dec 2001 12:57:43 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA23197; Tue, 11 Dec 2001 09:56:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02912; Tue, 11 Dec 2001 09:56:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHtmvU022351 for ; Tue, 11 Dec 2001 09:55:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBHtmwU022350 for mobile-ip-dist; Tue, 11 Dec 2001 09:55:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBHtivU022343 for ; Tue, 11 Dec 2001 09:55:45 -0800 (PST) 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 fBBHtfq05859; Tue, 11 Dec 2001 18:55:41 +0100 (MET) Date: Tue, 11 Dec 2001 18:53:58 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] Routing header Vs tunneling To: Glenn Morrow Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark In-Reply-To: "Your message with ID" <933FADF5E673D411B8A30002A5608A0E0122392E@zrc2c012.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > GM2] You have hit the nail right on the head. I think you doing the right > thing but I must say that the right thing needs to be done to IPv6 itself. I > know this may not be your responsibility but nevertheless, there are massive > gaping DDoS holes in IPv6. The fixes for these holes are not backed up by > MUSTs either. Actually some of the fixes aren't even described in IETF > documentation. This is a reverberation about Charlie's point about being > singled out. Pekka has at least tried to point some of the IPv6 holes out in > his ID. For instance compare the DDoS holes in stateless autoconfiguration > with the reflector problem of MIPv6. It seems to me that stateless > autoconfiguration wouldd not have become an RFC under the same scrutiny. Some people feel that RFC 2461 and RFC 2462 should not be draft standards since there was no interoperability testing of the suggested security mechanism (use IPsec). This is a case where we learn as we go along. I think that earlier it was viewed that limiting the threats to attackers on the same link was good enough protection. There are known holes (some documented in existing RFCs) limited to a single link (neighbor discovery and stateless addrconf). And the tunneling in RFC 2473 is silent on threats related to blindly decapsulating received packets. What other security holes are you aware of? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 13:36: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 NAA22407 for ; Tue, 11 Dec 2001 13:36:10 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22114; Tue, 11 Dec 2001 11:34:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07379; Tue, 11 Dec 2001 10:35:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBIYKvU022535 for ; Tue, 11 Dec 2001 10:34:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBIYKqw022534 for mobile-ip-dist; Tue, 11 Dec 2001 10:34:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBIYGvU022527 for ; Tue, 11 Dec 2001 10:34:17 -0800 (PST) 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 fBBIY9q09507; Tue, 11 Dec 2001 19:34:09 +0100 (MET) Date: Tue, 11 Dec 2001 19:32:13 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] Routing header Vs tunneling To: kempf@docomolabs-usa.com Cc: mobile-ip@sunroof.eng.sun.com, TJ@Kniveton.com In-Reply-To: "Your message with ID" <002001c1825b$0805b0b0$356015ac@T23KEMPF> 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 start discussing using tunneling instead of header options for > MIPv6, we are looking at a minimum 3 year > delay before MIPv6 is ready for serious product implementation and > widespread deployment. Can you quantify where the additional 3 years would come from? (Or is this a total number taking into account solving the BU security issue?) > Considering > the 9 month delay that the BU security problem has thrown into MIPv6, > I'd estimate 6 months to a year to > weigh requirements and decide among competing proposals, 6 months to a > year to get prototype implementations > ready and do interoperability testing, and 6 months to a year for the WG > to finish up loose ends and the IESG > to weigh and approve the result. This is simply unacceptable. For BU security? Or if the WG decides to use tunneling instead of HAOpt/RH? Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 13:50: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 NAA22777 for ; Tue, 11 Dec 2001 13:50:57 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04429; Tue, 11 Dec 2001 11:49:25 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11782; Tue, 11 Dec 2001 10:49:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBImvvU022640 for ; Tue, 11 Dec 2001 10:48:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBImvk7022639 for mobile-ip-dist; Tue, 11 Dec 2001 10:48:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBImsvU022632 for ; Tue, 11 Dec 2001 10:48:54 -0800 (PST) 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 KAA11609 for ; Tue, 11 Dec 2001 10:48:56 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24024 for ; Tue, 11 Dec 2001 10:48:55 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBBIj8002297 for ; Tue, 11 Dec 2001 12:45:09 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Dec 2001 12:43:57 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01223C3F@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Tue, 11 Dec 2001 12:44:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18273.D43900C0" Sender: owner-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_01C18273.D43900C0 Content-Type: text/plain; charset="iso-8859-1" While this thread answered the question, out of context, of why a mobile would not always want to use route optimization, the original context was discussing the route optimized path between the MN and the CN and the need or lack thereof for the extra home address in every packet - not the reverse tunnel path between the MN and the HA. To avoid this out of context diversion from the original mail, I try once again to make the point about the MN-CN route optimized path: If the reflector attack is to be prevented then state must be installed and maintained on the CN to insure that an MN is authorized to use the home address for communications - even on handoff. Because this state must be installed via signaling, in order for CN to protect against the reflector attack the home address has to be conveyed in this signaling which installs the authorization state; furthermore the CN must keep the knowledge of not only the home address but also the care of address(es) that match up with a particular home address in order to perform the authorization check on each packet. Therefore it is useless, redundant and bandwidth inefficient to send the home address on each subsequent packet between the MNs and the CNs (i.e. packets that do not contain signaling which affects the mobility bindings mapping the care of address to the home address). This is due to the fact that the address binding knowledge had to already be conveyed and maintained. And finally because this state has to be maintained on the CN to protect against the reflector attack, if protection of the reflector attack is mandated, we should realize that this is the same state that would have to be maintained by CNs in order to achieve route optimization. The path between the home agent and the MN is a completely different subject but before I go off and spend time on a draft describing the above, I would like to float the question, "Is the requirement for all IPv6 nodes to support the routing header functionality in question?" If this is not the case then I suspect the draft will be a waste of time in that someone can always claim stack size reduction i.e. I don't want to have to support more than one redirection technology. Thanks in advance, Glenn > -----Original Message----- > From: Jari T. Malinen [mailto:jmalinen@iprg.nokia.com] > Sent: Monday, December 10, 2001 3:46 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Routing header Vs tunneling > > > Michael Thomas wrote: > > > > Steve Deering writes: > > > At 6:48 PM +0000 12/10/01, Casati, Alessio (Alessio) wrote: > > > >Location privacy is not obtained simply by disabling > > > >route optimization: the visited net addr (Care-of address) > > > >is revealed to the CN by sending to it IPv6 packets > > > >(with source address set to the CoA)... Not using the CoA as > > > >source address comes with some ingress filtering problems... > > > > > > You do bidirectional tunneling through the home agent > when you want to > > > keep your location hidden from your corrrespondents > (i.e., you disable > > > route optimization on both directions). The outer > source address in > > > the tunneled packets from MH to HA is the care-of address, so it > > > gets through the ingress filters fine, and then gets > removed by the > > > HA as a natural side-effect of decapsulation, before the > packet goes > > > to the correspondent. > > > > Right, and I think that given the hazard for the > > CN with spooofed HAO, there needs to be a failsafe > > way for the MN to communicate with the CN if, for > > whatever reason, the CN will not accept the binding > > updated. > > However, and this also applies to the early work we've done in > mobile routers, if the scalability requirement of extending beyond > infrastructures in authentication are taken seriously, also the leg > from HA to CN is equally M to N tunneling: weak authentication (or > something) would logically be needed even with the reverse tunneling > via HA. > > > Mike > > BR, > > -Jari > ------_=_NextPart_001_01C18273.D43900C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

While this thread answered the question, out of = context, of why a mobile would not always want to use route = optimization, the original context was discussing the route optimized = path between the MN and the CN and the need or lack thereof for the = extra home address in every packet - not the reverse tunnel path = between the MN and the HA.

To avoid this out of context diversion from the = original mail, I try once again to make the point about the MN-CN route = optimized path:

If the reflector attack is to be prevented then state = must be installed and maintained on the CN to insure that an MN is = authorized to use the home address for communications - even on = handoff. Because this state must be installed via signaling, in order = for CN to protect against the reflector attack the home address has to = be conveyed in this signaling which installs the authorization state; = furthermore the CN must keep the knowledge of not only the home address = but also the care of address(es) that match up with a particular home = address in order to perform the authorization check on each packet. = Therefore it is useless, redundant and bandwidth inefficient to send = the home address on each subsequent packet between the MNs and the CNs = (i.e. packets that do not contain signaling which affects the mobility = bindings mapping the care of address to the home address). This is due = to the fact that the address binding knowledge had to already be = conveyed and maintained. And finally because this state has to be = maintained on the CN to protect against the reflector attack, if = protection of the reflector attack is mandated, we should realize that = this is the same state that would have to be maintained by CNs in order = to achieve route optimization.

The path between the home agent and the MN is a = completely different subject but before I go off and spend time on a = draft describing the above, I would like to float the question, = "Is the requirement for all IPv6 nodes to support the routing = header functionality in question?" If this is not the case then I = suspect the draft will be a waste of time in that someone can always = claim stack size reduction i.e. I don't want to have to support more = than one redirection technology.

Thanks in advance,

Glenn

> -----Original Message-----
> From: Jari T. Malinen [mailto:jmalinen@iprg.nokia.com]
> Sent: Monday, December 10, 2001 3:46 PM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] Routing header Vs = tunneling
>
>
> Michael Thomas wrote:
> >
> > Steve Deering writes:
> >  > At 6:48 PM +0000 12/10/01, = Casati, Alessio (Alessio) wrote:
> >  > >Location privacy is not = obtained simply by disabling
> >  > >route optimization: the = visited net addr (Care-of address)
> >  > >is revealed to the CN by = sending to it IPv6 packets
> >  > >(with source address set to = the CoA)... Not using the CoA as
> >  > >source address comes with = some ingress filtering problems...
> >  >
> >  > You do bidirectional tunneling = through the home agent
> when you want to
> >  > keep your location hidden from = your corrrespondents
> (i.e., you disable
> >  > route optimization on both = directions).  The outer
> source address in
> >  > the tunneled packets from MH to = HA is the care-of address, so it
> >  > gets through the ingress = filters fine, and then gets
> removed by the
> >  > HA as a natural side-effect of = decapsulation, before the
> packet goes
> >  > to the correspondent.
> >
> >    Right, and I think that = given the hazard for the
> >    CN with spooofed HAO, = there needs to be a failsafe
> >    way for the MN to = communicate with the CN if, for
> >    whatever reason, the CN = will not accept the binding
> >    updated.
>
> However, and this also applies to the early = work we've done in
> mobile routers, if the scalability requirement = of extending beyond
> infrastructures in authentication are taken = seriously, also the leg
> from HA to CN is equally M to N tunneling: weak = authentication (or
> something) would logically be needed even with = the reverse tunneling
> via HA.
>
> = >           &n= bsp;     Mike
>
> BR,
>
> -Jari
>

------_=_NextPart_001_01C18273.D43900C0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 14:17: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 OAA23329 for ; Tue, 11 Dec 2001 14:17:45 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27569; Tue, 11 Dec 2001 12:16:17 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17111; Tue, 11 Dec 2001 11:16:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBJF7vU022869 for ; Tue, 11 Dec 2001 11:15:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBJF7or022868 for mobile-ip-dist; Tue, 11 Dec 2001 11:15:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBJF4vU022861 for ; Tue, 11 Dec 2001 11:15:04 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18926; Tue, 11 Dec 2001 11:15:03 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25941; Tue, 11 Dec 2001 12:15:02 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBBJF1007929; Tue, 11 Dec 2001 13:15:01 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Dec 2001 13:13:49 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01223CB9@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Tue, 11 Dec 2001 13:14:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18277.FE5384D0" Sender: owner-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_01C18277.FE5384D0 Content-Type: text/plain; charset="iso-8859-1" What prevents a node from obtaining and using any number of free or not free (i.e. in use by another legitimate node) IP addresses such that they can spoof addresses albeit only on the same subnet IF INGRESS FILTERING is used on the first hop. Use of IPSEC is not mandated. Use of INGRESS FILTERING is not mandated, either. What is the interaction with control lists, etc.. etc.. etc.. Are there any provisions for anti-mac-spoofing, etc.. etc.. etc.. Pekka's draft which detailed most of the holes has expired, perhaps he is listening and will republish it. Ask yourself this Erik, would Sun use it and would Sun want to connect their 5 9's network to a network they have no control over that did use it, as is? Would a bank want to be connected to a network they had no control over that used it, as is? Would a government, military department, police department, fire department, FEMA, etc.. That is if they had a choice. IPv6 is somewhat of an expensive proposition, wouldn't it be good to build in new mandatory anti-DDoS mechanisms to help satisfy that return on investment. Don't get me wrong, I think autoconfig is neat and I like it but it isn't in any better shape than MIPv6 with respect to DDoS prevention. This is Charlie's point. I personally think both need to be fixed and backed up by mandates but I'm amazed that autoconfig became a standard as is in the first place. Regards, Glenn > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Tuesday, December 11, 2001 11:54 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: mobile-ip@sunroof.eng.sun.com; Erik Nordmark > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > > GM2] You have hit the nail right on the head. I think you > doing the right > > thing but I must say that the right thing needs to be done > to IPv6 itself. I > > know this may not be your responsibility but nevertheless, > there are massive > > gaping DDoS holes in IPv6. The fixes for these holes are > not backed up by > > MUSTs either. Actually some of the fixes aren't even > described in IETF > > documentation. This is a reverberation about Charlie's > point about being > > singled out. Pekka has at least tried to point some of the > IPv6 holes out in > > his ID. For instance compare the DDoS holes in stateless > autoconfiguration > > with the reflector problem of MIPv6. It seems to me that stateless > > autoconfiguration wouldd not have become an RFC under the > same scrutiny. > > Some people feel that RFC 2461 and RFC 2462 should not be > draft standards > since there was no interoperability testing of the suggested > security mechanism > (use IPsec). This is a case where we learn as we go along. I > think that > earlier it was viewed that limiting the threats to attackers > on the same link > was good enough protection. > > There are known holes (some documented in existing RFCs) > limited to a single link (neighbor discovery and stateless addrconf). > And the tunneling in RFC 2473 is silent on threats related to > blindly decapsulating received packets. > > What other security holes are you aware of? > > Erik > > ------_=_NextPart_001_01C18277.FE5384D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

What prevents a node from obtaining and using any = number of free or not free (i.e. in use by another legitimate node) IP = addresses such that they can spoof addresses albeit only on the same = subnet IF INGRESS FILTERING is used on the first hop. Use of IPSEC is = not mandated. Use of INGRESS FILTERING is not mandated, either. What is = the interaction with control lists, etc.. etc.. etc.. Are there any = provisions for anti-mac-spoofing, etc.. etc.. etc.. Pekka's draft which = detailed most of the holes has expired, perhaps he is listening and = will republish it.

Ask yourself this Erik, would Sun use it and would = Sun want to connect their 5 9's network to a network they have no = control over that did use it, as is? Would a bank want to be connected = to a network they had no control over that used it, as is? Would a = government, military department, police department, fire department, = FEMA, etc.. That is if they had a choice. IPv6 is somewhat of an = expensive proposition, wouldn't it be good to build in new mandatory = anti-DDoS mechanisms to help satisfy that return on = investment.

Don't get me wrong, I think autoconfig is neat and I = like it but it isn't in any better shape than MIPv6 with respect to = DDoS prevention. This is Charlie's point. I personally think both need = to be fixed and backed up by mandates but I'm amazed that autoconfig = became a standard as is in the first place.


Regards,

Glenn

> -----Original Message-----
> From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.c= om]
> Sent: Tuesday, December 11, 2001 11:54 = AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: mobile-ip@sunroof.eng.sun.com; Erik = Nordmark
> Subject: RE: [mobile-ip] Routing header Vs = tunneling
>
>
> > GM2] You have hit the nail right on the = head. I think you
> doing the right
> > thing but I must say that the right thing = needs to be done
> to IPv6 itself. I
> > know this may not be your responsibility = but nevertheless,
> there are massive
> > gaping DDoS holes in IPv6. The fixes for = these holes are
> not backed up by
> > MUSTs either. Actually some of the fixes = aren't even
> described in IETF
> > documentation. This is a reverberation = about Charlie's
> point about being
> > singled out. Pekka has at least tried to = point some of the
> IPv6 holes out in
> > his ID. For instance compare the DDoS = holes in stateless
> autoconfiguration
> > with the reflector problem of MIPv6. It = seems to me that stateless
> > autoconfiguration wouldd not have become = an RFC under the
> same scrutiny.
>
> Some people feel that RFC 2461 and RFC 2462 = should not be
> draft standards
> since there was no interoperability testing of = the suggested
> security mechanism
> (use IPsec). This is a case where we learn as = we go along. I
> think that
> earlier it was viewed that limiting the threats = to attackers
> on the same link
> was good enough protection.
>
> There are known holes (some documented in = existing RFCs)
> limited to a single link (neighbor discovery = and stateless addrconf).
> And the tunneling in RFC 2473 is silent on = threats related to
> blindly decapsulating received packets.
>
> What other security holes are you aware = of?
>
>   Erik
>
>

------_=_NextPart_001_01C18277.FE5384D0-- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 15:12: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 PAA24134 for ; Tue, 11 Dec 2001 15:12:28 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13346; Tue, 11 Dec 2001 13:11:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21217; Tue, 11 Dec 2001 12:11:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBKAavU023097 for ; Tue, 11 Dec 2001 12:10:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBKAaof023096 for mobile-ip-dist; Tue, 11 Dec 2001 12:10:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBKAWvU023089 for ; Tue, 11 Dec 2001 12:10:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01335 for ; Tue, 11 Dec 2001 12:10:32 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA02096 for ; Tue, 11 Dec 2001 13:00:59 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBBK0Fw16971; Tue, 11 Dec 2001 14:00:15 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Dec 2001 13:58:54 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01223DB4@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: jari.arkko@piuha.net Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Tue, 11 Dec 2001 13:59:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1827E.4D231700" Sender: owner-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_01C1827E.4D231700 Content-Type: text/plain; charset="iso-8859-1" Jari, Perhaps you are right. Your statement below assumes that at least RFP checks are being used on all 1st hop interfaces. Earlier on the IPv6 mail list and the itrace maillist, it was brought up that topological checks should be mandated on the first hop for IPv6. But an argument came up that FIB caches may expire and so there may be no knowledge of whether a router is a first hop or not. One could; however, detect the use of autoconfig on interfaces and then have a pretty good idea that the router was a first hop. This autoconfig detection could turn on topoligical correctness checks such as RFP. It could also be a MUST that this happen. This would fill holes and make your statement 100% true. It seems to me that this type of thing is implementable and keeps the stateless nature of autoconfig intact. I'm sure there are other more granular stateful things such as control list/MAC spoofing checks that could be done as well but that wouldn't exactly be stateless anymore nor conform to the high fidelity definition of scalability. They still might provide for plug and play, though. This sort of thing is a different beast, though. Again, your statement is true if topology checks are mandated on the 1st hop. Glenn > > There could still be differences in the seriousness of attacks. > In your particular example, I'm not sure autoconfiguration has > similar global problems as MIPv6 has; the autoconfiguration procedures > are full of holes but can we launch attacks against some non-local > parties through them in an easy way while at the same time escaping > to be located? > > Jari > > > ------_=_NextPart_001_01C1827E.4D231700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

Jari,

Perhaps you are right. Your statement below assumes = that at least RFP checks are  being used on all 1st hop = interfaces. Earlier on the IPv6 mail list and the itrace maillist, it = was brought up that topological checks should be mandated on the first = hop for IPv6. But an argument came up that FIB caches may expire and so = there may be no knowledge of whether a router is a first hop or not. = One could; however, detect the use of autoconfig on interfaces and then = have a pretty good idea that the router was a first hop. This = autoconfig detection could turn on topoligical correctness checks such = as RFP. It could also be a MUST that this happen. This would fill holes = and make your statement 100% true. It seems to me that this type of = thing is implementable and keeps the stateless nature of autoconfig = intact.

I'm sure there are other more granular stateful = things such as control list/MAC spoofing checks that could be done as = well but that wouldn't exactly be stateless anymore nor conform to the = high fidelity definition of scalability. They still might provide for = plug and play, though. This sort of thing is a different beast, though. =

Again, your statement is true if topology checks are = mandated on the 1st hop.

Glenn
 
>
> There could still be differences in the = seriousness of attacks.
> In your particular example, I'm not sure = autoconfiguration has
> similar global problems as MIPv6 has; the = autoconfiguration procedures
> are full of holes but can we launch attacks = against some non-local
> parties through them in an easy way while at = the same time escaping
> to be located?
>
> Jari
>
>
>

------_=_NextPart_001_01C1827E.4D231700-- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 17:23: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 RAA26309 for ; Tue, 11 Dec 2001 17:23:27 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29397; Tue, 11 Dec 2001 14:21:46 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02482; Tue, 11 Dec 2001 14:19:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBMIuvU023944 for ; Tue, 11 Dec 2001 14:18:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBMIuqG023943 for mobile-ip-dist; Tue, 11 Dec 2001 14:18:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBMIrvU023936 for ; Tue, 11 Dec 2001 14:18:53 -0800 (PST) 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 OAA10412 for ; Tue, 11 Dec 2001 14:18:55 -0800 (PST) Received: from e31.co.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 OAA22300 for ; Tue, 11 Dec 2001 14:18:54 -0800 (PST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id RAA65730 for ; Tue, 11 Dec 2001 17:16:04 -0500 Received: from d03nm036.boulder.ibm.com (d03nm036.boulder.ibm.com [9.99.140.36]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBBMI5d214898 for ; Tue, 11 Dec 2001 15:18:05 -0700 From: "Venkata Jagana" Importance: Normal Subject: Re: [mobile-ip] Question on performing DAD for BU's To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 11 Dec 2001 15:17:59 -0700 X-MIMETrack: Serialize by Router on D03NM036/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/11/2001 03:18:04 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: >> >> My problem is only with manual configuration , I agree that >> autoconfiguration doesn't create this problem at all. >you are right. but it comes from somebody making mistake while >manually configuring the address on the MN. Just wanted to clarify this problem further. One more thing I must say at this point is that this identified problem happens not only with the manual configuration of the addresses of the nodes but may also be with the temporary addresses assigned through DHCPv6 as long as these assigned addresses do not make use of the corresponding interface identifier. Thanks, Venkat > > Also, the 'S' bit doesn't solve the problem, it is not defending all the > addresses, the 'S' bit is used for tunnelling packets with any of the many > home addresses values based on the prefixes supported, instead of just the > home address. acutally section 9.1 talks about creating a binding cache entry for each address that can be derived from other prefixes on the home link. and when you talk about creating a binding cache entry, it also means that the home agent is defending that particular address. it answers to neighbor solicitations for that address. otherwise the packets would never reach the home agent and would never be tunneled to the mobile node. so we can assume the if the 'S' bit is not set in the BU, the home agent defends and creats a binding cache entry for each address that can be derived from other prefixes on the home link. if the wording is not clear maybe we can add some text. > > > this is based on the common policy where DAD is only performed on > link-local addresses *and* no address uses a different interface ID. > > If this restriction is enforced, this problem does not exist. But that is > exactly what I am trying to find out. If a node can configure an address > with a different interface identifier, then DAD should be done on all > addresses values. I am not sure about the answer to this question. maybe others can comment on this. Vijay > > Please let me know if this is wrong in any way. > > Thanks, > > - KK > > > Vijay Devarapalli > To: mobile-ip@sunroof.eng.sun.com > Sent by: cc: > owner-mobile-ip@sunroof.e Subject: Re: [mobile-ip] Question on performing DAD for BU's > ng.sun.com > > > 12/06/2001 05:20 PM > Please respond to > mobile-ip > > > > Hi KK, > > I think this comes from RFC 2462 which says if you have stateless > address configuration, its enough if you do duplicate address > detection on just the link local address. the other addresses are > a MAY. > > heres the relevant text from RFC 2462, section 5.4 > > --------------- > > - Each individual unicast address SHOULD be tested for uniqueness. > However, when stateless address autoconfiguration is used, > address uniqueness is determined solely by the interface > identifier, assuming that subnet prefixes are assigned correctly > (i.e., if all of an interface's addresses are generated from the > same identifier, either all addresses or none of them will be > duplicates). Thus, for a set of addresses formed from the same > interface identifier, it is sufficient to check that the link- > local address generated from the identifier is unique on the > link. In such cases, the link-local address MUST be tested for > uniqueness, and if no duplicate address is detected, an > implementation MAY choose to skip Duplicate Address Detection > for additional addresses derived from the same interface > identifier. > > --------------- > > And I guess the intention was that Mobile IPv6 did not want to > specify anything in addition to what is there in RFC 2462. > > and regarding more than prefix on the home link there is > something specified in draft 15 for that. if the 'S' bit in the > BU is set, the Home Agent defends just the home address > specified in the home address option. if the 'S' bit is not set, > the home agent forms a home address from each prefix on the home > link and defends all of them. and even in this case, by RFC 2462, > its enough if you do DAD from just the link local address if > stateless address configuration is being used. > > one more thing, in your example below node 'X' MUST configure a > link local address. it cant configure a site local address alone > and not configure a link local address. it is there in some RFC, > I forgot which. > > regards > Vijay > > Krishna Kumar wrote: > > > > Hi Charlie, > > > > I feel there is a small problem in the Draft 15 regarding the address > used > > for performing DAD. > > > > 1. Page 67 for BU processing says that DAD should be performed on the > Link > > Local Address. > > 2. Pg 94 says that : If some time elapses during which the mobile node > has > > no binding at the home agent, it might be possible for another node to > > autoconfigure the mobile node's home address. > > > > A new node 'X' can configure it's address either through > autoconfiguration > > (in which case #1 is sufficient), or by manual means. Since the address > can > > be configured manually, I feel the specification should be changed to > state > > that DAD should be performed on the Link Local address and all Home > > Addresses (if Prefix Length is > 0) based on different prefixes supported > > by the Home Agent. > > > > The reason is that the MN might configure a site local address as it's > home > > address and move to a foreign network. Before HA gets the BU, another > node > > 'X' manually configures it's address to the site local address used by > the > > MN, and it succeeds. When HA gets the BU, it does a Neighbor Solicitation > > on the Link Local Address, and since X has not configured that link local > > address, it doesn't respond to the NS. Now packets meant for 'X' get > > wrongly tunneled to the MN. The node X doesn't even need to take the same > > site local address for this to fail, it can configure any other address > > based on the prefixes supported and the interface identifier. In this > case, > > after the BU succeeds, any packets meant for this different address will > > still be tunnelled wrongly by the HA to the MN since Prefix Length was > > greater than zero. Hence I feel HA must perform DAD on all addresses (can > > be done parallely and probably take almost the same time as it would take > > for one DAD) if Prefix Length > 0. > > > > Secondly, is it a good idea for Mobility to change the value of > > RetransTimer to a smaller value like 0.5 seconds or smaller ? This means > > faster handoff for the MN. Otherwise the MN has to wait for > > 1.5*(RetransTimer*DupAddrDetectTransmits) = atleast 1.5 seconds before > the > > MN gets a response, and before it is allowed to send BU's to CN's. > Reducing > > this time ensures faster movement mechanism for the MN. > > > > Thanks, > > > > - KK From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 17:24: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 RAA26331 for ; Tue, 11 Dec 2001 17:24:31 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00541; Tue, 11 Dec 2001 14:22:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03707; Tue, 11 Dec 2001 14:22:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBMLwvU023979 for ; Tue, 11 Dec 2001 14:21:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBMLwQZ023978 for mobile-ip-dist; Tue, 11 Dec 2001 14:21:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBMLrvU023971 for ; Tue, 11 Dec 2001 14:21:54 -0800 (PST) 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 fBBMLeq25151; Tue, 11 Dec 2001 23:21:40 +0100 (MET) Date: Tue, 11 Dec 2001 23:19:52 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] Routing header Vs tunneling To: Glenn Morrow Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <933FADF5E673D411B8A30002A5608A0E01223CB9@zrc2c012.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Ask yourself this Erik, would Sun use it and would Sun want to connect their > 5 9's network to a network they have no control over that did use it, as is? > Would a bank want to be connected to a network they had no control over that > used it, as is? Would a government, military department, police department, > fire department, FEMA, etc.. That is if they had a choice. IPv6 is somewhat > of an expensive proposition, wouldn't it be good to build in new mandatory > anti-DDoS mechanisms to help satisfy that return on investment. While I understand and agree with your desire to improve security I don't know of a magic bullet to prevent DoS and DDoS. The best we can do is to minimize such opportunities and try to make it possible to somehow trace back to the attacker for the other cases. But the latter part is an IETF wide problem. See ITRACE WG and IPPT BoF. > Don't get me wrong, I think autoconfig is neat and I like it but it isn't in > any better shape than MIPv6 with respect to DDoS prevention. This is > Charlie's point. I personally think both need to be fixed and backed up by > mandates but I'm amazed that autoconfig became a standard as is in the first > place. The significant difference is that the Neighbor Discovery and addrconf attacks are limited to attackers on the link. MIPv6 is global by design thus it makes sense to have stricter security requirements. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 17:54:20 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 RAA26859 for ; Tue, 11 Dec 2001 17:54:19 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA13005; Tue, 11 Dec 2001 14:53:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11435; Tue, 11 Dec 2001 14:53:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBMqAvU024223 for ; Tue, 11 Dec 2001 14:52:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBMqA14024222 for mobile-ip-dist; Tue, 11 Dec 2001 14:52:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBMq7vU024215 for ; Tue, 11 Dec 2001 14:52:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18676; Tue, 11 Dec 2001 14:52:02 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05401; Tue, 11 Dec 2001 15:52:01 -0700 (MST) Received: from T23KEMPF (dhcp152.docomo-usa.com [172.21.96.152]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBBMq0J08384; Tue, 11 Dec 2001 14:52:00 -0800 (PST) Message-ID: <00ad01c18296$37d86b80$986015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" Cc: , References: Subject: Re: [mobile-ip] Routing header Vs tunneling Date: Tue, 11 Dec 2001 14:50:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > If we start discussing using tunneling instead of header options for > > MIPv6, we are looking at a minimum 3 year > > delay before MIPv6 is ready for serious product implementation and > > widespread deployment. > > Can you quantify where the additional 3 years would come from? > (Or is this a total number taking into account solving the BU > security issue?) > See below. These are rough and somewhat subjective estimates, based on my observation of the time it requires for major feature changes in protocols. > > Considering > > the 9 month delay that the BU security problem has thrown into MIPv6, > > I'd estimate 6 months to a year to > > weigh requirements and decide among competing proposals, 6 months to a > > year to get prototype implementations > > ready and do interoperability testing, and 6 months to a year for the WG > > to finish up loose ends and the IESG > > to weigh and approve the result. This is simply unacceptable. > > For BU security? > Or if the WG decides to use tunneling instead of HAOpt/RH? > > Specifically for using tunneling instead of HAOpt/RH. I think BU security could be wrapped up by the end of next year, if the IESG fast tracks the security review and implementors come back sometime next year with a clean bill of health as far as interoperability is concerned. I think it will take much longer to work thorough the implications of replacing HAOpt/RH with tunneling. jak From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 18:24: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 SAA27378 for ; Tue, 11 Dec 2001 18:24:44 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA25254; Tue, 11 Dec 2001 15:23:27 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26096; Tue, 11 Dec 2001 15:23:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBNMfvU024386 for ; Tue, 11 Dec 2001 15:22:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBNMf2f024385 for mobile-ip-dist; Tue, 11 Dec 2001 15:22:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBNMcvU024378 for ; Tue, 11 Dec 2001 15:22:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25661 for ; Tue, 11 Dec 2001 15:22:33 -0800 (PST) Received: from web11002.mail.yahoo.com (web11002.mail.yahoo.com [216.136.131.52]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA06914 for ; Tue, 11 Dec 2001 16:23:07 -0700 (MST) Message-ID: <20011211232229.80286.qmail@web11002.mail.yahoo.com> Received: from [130.207.231.77] by web11002.mail.yahoo.com via HTTP; Tue, 11 Dec 2001 15:22:28 PST Date: Tue, 11 Dec 2001 15:22:28 -0800 (PST) From: Vasos Vassiliou Subject: [mobile-ip] Tables maintained at MIP nodes 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: Hello all, Can someone point me to a document (RFC, ID, Paper, Book) which has a collective list of the tables maintained at MIP nodes? I remeber seeing a paper with a nice graphic illustration of the different Tables and fields in them, but, obviously, have no clue where. I am not only interested for info about the basic MIP, but also for RO and HMIP. Thanks for any help Vasos Vassiliou Georgia Tech __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 19:01: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 TAA28002 for ; Tue, 11 Dec 2001 19:01:55 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06082; Tue, 11 Dec 2001 17:00:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15551; Tue, 11 Dec 2001 16:00:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBNxfvU024533 for ; Tue, 11 Dec 2001 15:59:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBBNxfv4024531 for mobile-ip-dist; Tue, 11 Dec 2001 15:59:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBNxZvU024518 for ; Tue, 11 Dec 2001 15:59:35 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25948 for ; Tue, 11 Dec 2001 15:59:35 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25589 for ; Tue, 11 Dec 2001 16:59:35 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBBNxYJ23181 for ; Wed, 12 Dec 2001 00:59:34 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Dec 12 00:59:33 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Dec 2001 00:51:08 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C126@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: ipng@sunroof.eng.sun.com Subject: [mobile-ip] Mobile nets meeting Date: Wed, 12 Dec 2001 00:52:11 +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: Folks, Sorry for the cross posting. For those of you who expressed interest in attending the monet bar bof, here is the info: Day: Wednesday Time 5.30 - 7.00 pm Room name: Fountainblue (3rd floor at Grand America) Please note that the room is quite small and is based on the number of people who expressed interest. Cheers, Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 19:24: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 TAA28322 for ; Tue, 11 Dec 2001 19:24:39 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA18274; Tue, 11 Dec 2001 16:23:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA20959; Tue, 11 Dec 2001 16:23:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC0MOvU024810 for ; Tue, 11 Dec 2001 16:22:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBC0MOVY024809 for mobile-ip-dist; Tue, 11 Dec 2001 16:22:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC0MMvU024802 for ; Tue, 11 Dec 2001 16:22:22 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14107 for ; Tue, 11 Dec 2001 19:22:18 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id TAA05843 for mobile-ip@sunroof.eng.sun.com; Tue, 11 Dec 2001 19:22:54 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBBJiGvU023040 for ; Tue, 11 Dec 2001 11:44:16 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25306 for ; Tue, 11 Dec 2001 11:44:16 -0800 (PST) Received: from LITEXCH3.alltel.com ([198.133.108.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05845 for ; Tue, 11 Dec 2001 12:44:15 -0700 (MST) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] privacy? Date: Tue, 11 Dec 2001 13:44:59 -0600 Message-ID: Thread-Topic: RE: [mobile-ip] privacy? Thread-Index: AcGCfDV/Dm5u5GroSd+BIGgHBc4/xA== From: "Hjelm, Bjorn" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBBJiGvU023041 Sender: owner-mobile-ip@sunroof.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 All, If also could receive a copy of draft-castelluccia-mobileip-privacy-00.txt, it would be much appreciated. Thanks, Bjorn ----------------------------------------------------------------- From the Desk of.. Bjorn Hjelm Network Planning and Advanced Technology ALLTEL Communications, Inc. Tel: (501) 905-8612 Fax: (501) 905-6324 E-mail: bjorn.hjelm@alltel.com From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 20:50: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 UAA00021 for ; Tue, 11 Dec 2001 20:50:51 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07207; Tue, 11 Dec 2001 18:49:20 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27685; Tue, 11 Dec 2001 17:49:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC1mhvU025243 for ; Tue, 11 Dec 2001 17:48:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBC1mhPF025242 for mobile-ip-dist; Tue, 11 Dec 2001 17:48:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC1mevU025235 for ; Tue, 11 Dec 2001 17:48:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA08764 for ; Tue, 11 Dec 2001 17:48:41 -0800 (PST) Received: from e31.co.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 SAA04223 for ; Tue, 11 Dec 2001 18:49:15 -0700 (MST) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e31.co.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA75780; Tue, 11 Dec 2001 20:45:42 -0500 Received: from d03nm066.boulder.ibm.com (d03nm066.boulder.ibm.com [9.99.140.50]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fBC1mUd237690; Tue, 11 Dec 2001 18:48:31 -0700 Subject: [mobile-ip] Conflicting Information in Mobile IP Draft 15 ? To: mobile-ip@sunroof.eng.sun.com, charliep@iprg.nokia.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Tue, 11 Dec 2001 17:44:57 -0800 X-MIMETrack: Serialize by Router on D03NM066/03/M/IBM(Release 5.0.8 |June 18, 2001) at 12/11/2001 06:48:30 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 have a couple of queries about draft 15. I don't know if they have come up earlier so please excuse me if it did. - Sections 9.3, 9.4 and 10.7 talk of Prefix Length fields of the Binding Update message. Wasn't this removed after draft 14 ? So is it supposed to change to reflect the new 'S' field contained in the BU ? - Section 9.3, in 2 places mentions that for adding to Binding cache and for sending NA, the Router (R) bit should be copied from the Home Agent's binding cache entry for the Mobile Node. Should this be removed since Mobile Router was removed ? If this is to be removed, similarly section 4.5 on data structure for Binding Cache should delete references to 'mobile router' field and 'prefix length' field. Thanks for any clarification, - KK From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 22: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 WAA01936 for ; Tue, 11 Dec 2001 22:04:02 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12433; Tue, 11 Dec 2001 20:02:43 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA09039; Tue, 11 Dec 2001 19:02:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC31ivU025441 for ; Tue, 11 Dec 2001 19:01:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBC31iZj025440 for mobile-ip-dist; Tue, 11 Dec 2001 19:01:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC31fvU025433 for ; Tue, 11 Dec 2001 19:01:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA20300 for ; Tue, 11 Dec 2001 19:01:41 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04014 for ; Tue, 11 Dec 2001 20:01:40 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBC31cI21085; Wed, 12 Dec 2001 04:01:38 +0100 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 EAA19579; Wed, 12 Dec 2001 04:01:38 +0100 (MET) 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 fBC31bD23546; Wed, 12 Dec 2001 04:01:38 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112120301.fBC31bD23546@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: charliep@iprg.nokia.com Subject: Re: [mobile-ip] Conflicting Information in Mobile IP Draft 15 ? In-reply-to: Your message of Tue, 11 Dec 2001 17:44:57 PST. Date: Wed, 12 Dec 2001 04:01:37 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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 have a couple of queries about draft 15. I don't know if they have come up earlier so please excuse me if it did. - Sections 9.3, 9.4 and 10.7 talk of Prefix Length fields of the Binding Update message. Wasn't this removed after draft 14 ? So is it supposed to change to reflect the new 'S' field contained in the BU ? => IMHO this is a mistake (editing error). - Section 9.3, in 2 places mentions that for adding to Binding cache and for sending NA, the Router (R) bit should be copied from the Home Agent's binding cache entry for the Mobile Node. Should this be removed since Mobile Router was removed ? => the R bit is for neihbor discovery (proxy advertisements need it). I think this is another editing error with more consequences ... (i.e. now the MN must be a host :-) If this is to be removed, similarly section 4.5 on data structure for Binding Cache should delete references to 'mobile router' field and 'prefix length' field. => idem. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 23:55: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 XAA04479 for ; Tue, 11 Dec 2001 23:55:28 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA27855; Tue, 11 Dec 2001 20:53:21 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA21069; Tue, 11 Dec 2001 20:53:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC4qcvU025697 for ; Tue, 11 Dec 2001 20:52:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBC4qc76025696 for mobile-ip-dist; Tue, 11 Dec 2001 20:52:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC4qZvU025689 for ; Tue, 11 Dec 2001 20:52:35 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA03258 for ; Tue, 11 Dec 2001 20:51:32 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12721 for ; Tue, 11 Dec 2001 21:51:32 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBC4mxn25648; Tue, 11 Dec 2001 22:48:59 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Dec 2001 22:47:48 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D82AF608@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" , "'Patil Basavaraj (NET/Dallas)'" , "'Perkins Charles (IPRG)'" Cc: "Pete Wenzel" , "'Pat Calhoun'" Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Date: Tue, 11 Dec 2001 22:48:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C182C8.2F737390" Sender: owner-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_01C182C8.2F737390 Content-Type: text/plain; charset="iso-8859-1" Bob; By adopting the new version proposed for RFC3012bis, the third paragraph in section 3.2. of RFC3012bis as mentioned below, specifically identify what FA should check to determine if the RRQ is a re-transmission or not. NAI is not one of these criteria. In other words, if we reference section 3.7.1. of RFC2002 to determine if the RRQ message is a re-transmission, any RRQ with different NAI on the same PPP session and using the same Home address still will be considered as a re-transmission rather than a new RRQ. I hope this makes it clearer. Regards; Ahmad Muhanna Nortel Networks Shasta PDSN-MIP Development Phone. + 1 972 685 1416 ESN. 445-1416 amuhanna@nortelnetworks.com -----Original Message----- From: Robert J Marks [mailto:rjmarks@cambianetworks.com] Sent: Tuesday, December 11, 2001 10:07 AM To: mobile-ip; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)' Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun' Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Ahmad, I agree. The presence of a "new" NAI at the FA signals that authentication should be performed. If a MN sends a Registration Request using a new NAI, the FA should treat it as a new registration. I guess I don't see the issue. Bob From: Ahmad Muhanna Bob; I think our concern here is how the FA handles the RRQ message in these scenarios. Let us remember, if it is a re-transmission, FA does not authenticate the user through AAA. However, if it is considered a new registration, FA MUST authenticate the RRQ message "the USER" before relaying the RRQ to HA. I hope this clarifies the issue at hand. Thanks; Ahmad Muhanna -----Original Message----- From: Robert J Marks [ mailto:rjmarks@cambianetworks.com ] Sent: Tuesday, December 11, 2001 7:05 AM To: mobile-ip@sunroof.eng.sun.com; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)' Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun' Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Ahmad, Some observations on your scenarios. Ahmad Muhanna wrote: > What about the following scenario: > 1. MN sends a RRQ message with NAI1, Home Address 0.0.0.0. > 2. MN sends 1st retry of RRQ with NAI1, Home address 0.0.0.0. > > 3. Now, we have a SMART MN, which figures out that it can use another > Profile with NAI2 and Home Address 0.0.0.0. > > 4. Since section 3.7.1 in RFC2002 does not talk about the user NAI, > PDSN will consider this as a retransmission while may be the user > would have failed authentication at the AAA. This situation will be treated as a new Registration Request, independent of the request that used NAI1. The Home Agent will not correlate the two requests, since it identifies the MN by the NAI in this case. > ** Another thing, what about if we support different NAIs over the > same PPP session and let us say NAI1, NAI2, and NAI3 have the same > HA and all requesting Dynamic MIP calls with Home Addresses of 0.0.0.0. All three requests will be treated as independent registrations. The HA does not know about PPP, and again uses the NAI to identify the MN. > ********** > Ahmad Muhanna Bob Robert J Marks Cambia Networks Office: +1 847 627 3703 Mobile: +1 708 829 6329 -----Original Message----- From: Patil Basavaraj (NET/Dallas) [ mailto:Basavaraj.Patil@nokia.com ] Sent: Tuesday, November 13, 2001 4:20 PM To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles (IPRG) Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP Working Group; Pat Calhoun Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Charlie proposed the following text: >======================================================================= > >Here is the new relevant text, in the same paragraph as your original >quote: > > .... The Foreign Agent SHOULD check that the mobile node is > actually performing a retransmission, by verifying that the relevant > fields of the retransmitted request are the same as represented in > the visitor list entry for the pending Registration Request (section > 3.7.1 of [8]). This verification MUST NOT include the "remaining > Lifetime of the pending registration", or the Identification field > since those values are likely to change even for requests that are > merely retransmissions and not new Registration Requests. In all > other circumstances, if the Foreign Agent receives .... > >======================================================================= > >Comments? > >>Ahmad Muhanna: >>I hope you would agree that the following change will satisfy the need: >> >>"If a mobile node retransmits a Registration Request with the same >>Identification field and the same Challenge extension, and the Foreign >>Agent still has a pending Registration Request record in effect for the >>mobile node, then the Foreign Agent forwards the Registration Request to >>the Home Agent again (see Registration Retransmission, section 3.6.3[8]). >>In all other circumstances, if the Foreign Agent receives a Registration >>Request with a Challenge extension containing a Challenge value previously >>used by that mobile node, the Foreign Agent SHOULD send a Registration >>Reply to the mobile node containing the Code value STALE_CHALLENGE." > >Regards, >Charlie P. > I think the text that Charlie proposes makes it quite clear as to what the FA must do in order to recognize, if it is a retransmission. So I would recommend going with Charlie's text in the revision for this spec. -Basavaraj ------_=_NextPart_001_01C182C8.2F737390 Content-Type: text/html; charset="iso-8859-1" Message
Bob;
 
By adopting the new version proposed for RFC3012bis, the third paragraph in section 3.2. of RFC3012bis as mentioned below, specifically identify what FA should check to determine if the RRQ is a re-transmission or not.
NAI is not one of these criteria.
In other words, if we reference section 3.7.1. of RFC2002 to determine if the RRQ message is a re-transmission, any RRQ with different NAI on the same PPP session and using the same Home address still will be considered as a re-transmission rather than a new RRQ.
 
I hope this makes it clearer.
 

Regards;

Ahmad Muhanna
Nortel Networks
Shasta PDSN-MIP Development
Phone. + 1 972 685 1416 ESN. 445-1416
amuhanna@nortelnetworks.com

-----Original Message-----
From: Robert J Marks [mailto:rjmarks@cambianetworks.com]
Sent: Tuesday, December 11, 2001 10:07 AM
To: mobile-ip; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)'
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun'
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

Ahmad,
 
I agree. The presence of a "new" NAI at the FA signals that authentication should be performed.
If a MN sends a Registration Request using a new NAI, the FA should treat it as a new registration.
I guess I don't see the issue.
 
Bob 
 
From: Ahmad Muhanna

Bob;

I think our concern here is how the FA handles the RRQ message in these scenarios.
Let us remember, if it is a re-transmission, FA does not authenticate the user through AAA.
However, if it is considered a new registration, FA MUST authenticate the RRQ message
"the USER" before relaying the RRQ to HA.
I hope this clarifies the issue at hand.

Thanks;

Ahmad Muhanna


-----Original Message-----
From: Robert J Marks [mailto:rjmarks@cambianetworks.com]
Sent: Tuesday, December 11, 2001 7:05 AM
To: mobile-ip@sunroof.eng.sun.com; 'Patil Basavaraj (NET/Dallas)';
'Perkins Charles (IPRG)'
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun'
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question


Ahmad,

Some observations on your scenarios.
 
Ahmad Muhanna wrote:

> What about the following scenario:

> 1. MN sends a RRQ message with NAI1, Home Address 0.0.0.0.
> 2. MN sends 1st retry of RRQ with NAI1, Home address 0.0.0.0.
>
> 3. Now, we have a SMART MN, which figures out that it can use another
>    Profile with NAI2 and Home Address 0.0.0.0.
>
> 4. Since section 3.7.1 in RFC2002 does not talk about the user NAI,
> PDSN will consider this as a retransmission while may be the user
> would have failed authentication at the AAA.

This situation will be treated as a new Registration Request,
independent
of the request that used NAI1. The Home Agent will not correlate the two
requests, since it identifies the MN by the NAI in this case.

> ** Another thing, what about if we support different NAIs over the
> same PPP session and let us say NAI1, NAI2, and NAI3 have the same
> HA and all requesting Dynamic MIP calls with Home Addresses of
0.0.0.0.

All three requests will be treated as independent registrations. The HA
does not know about PPP, and again uses the NAI to identify the MN.
 
> **********
> Ahmad Muhanna

Bob

Robert J Marks
Cambia Networks
Office: +1 847 627 3703
Mobile: +1 708 829 6329

 -----Original Message-----
From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com]
Sent: Tuesday, November 13, 2001 4:20 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles (IPRG)
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP Working Group; Pat Calhoun
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question



Charlie proposed the following text:
>=======================================================================

>
>Here is the new relevant text, in the same paragraph as your original
>quote:
>
>      ....      The Foreign Agent SHOULD check that the mobile node is
>   actually performing a retransmission, by verifying that the relevant

>   fields of the retransmitted request are the same as represented in
>   the visitor list entry for the pending Registration Request (section

>   3.7.1 of [8]).  This verification MUST NOT include the "remaining
>   Lifetime of the pending registration", or the Identification field
>   since those values are likely to change even for requests that are
>   merely retransmissions and not new Registration Requests.  In all
>   other circumstances, if the Foreign Agent receives   ....
>
>=======================================================================

>
>Comments?
>
>>Ahmad Muhanna:
>>I hope you would agree that the following change will satisfy the
need:
>>
>>"If a mobile node retransmits a Registration Request with the same
>>Identification field and the same Challenge extension, and the Foreign

>>Agent still has a pending Registration Request record in effect for
the
>>mobile node, then the Foreign Agent forwards the Registration Request
to
>>the Home Agent again (see Registration Retransmission, section
3.6.3[8]).
>>In all other circumstances, if the Foreign Agent receives a
Registration
>>Request with a Challenge extension containing a Challenge value
previously
>>used by that mobile node, the Foreign Agent SHOULD send a Registration

>>Reply to the mobile node containing the Code value STALE_CHALLENGE."
>
>Regards,
>Charlie P.
>

I think the text that Charlie proposes makes it quite clear as to what
the FA must do in order to recognize, if it is a retransmission. So I
would recommend going with Charlie's text in the revision for this
spec.

-Basavaraj

------_=_NextPart_001_01C182C8.2F737390-- From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 11 23:59: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 XAA04545 for ; Tue, 11 Dec 2001 23:59:11 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA29157; Tue, 11 Dec 2001 21:57:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA21488; Tue, 11 Dec 2001 20:58:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC4vgvU025771 for ; Tue, 11 Dec 2001 20:57:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBC4vfXe025770 for mobile-ip-dist; Tue, 11 Dec 2001 20:57:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC4vcvU025763 for ; Tue, 11 Dec 2001 20:57:38 -0800 (PST) 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 UAA21445 for ; Tue, 11 Dec 2001 20:57:39 -0800 (PST) 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 UAA17109 for ; Tue, 11 Dec 2001 20:57:38 -0800 (PST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id fBC4vkQ08529 for ; Tue, 11 Dec 2001 22:57:47 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Dec 2001 22:57:38 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 11 Dec 2001 22:57:38 -0600 content-class: urn:content-classes:message Subject: RE: [mobile-ip] Routing header Vs tunneling MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 11 Dec 2001 22:57:14 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD263@daebe007.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Thread-Topic: [mobile-ip] Routing header Vs tunneling Thread-Index: AcGCXHg2ZMT3MO5PEdWJVwAIx6TWpQAbKh8A From: "Patil Basavaraj (NET/Dallas)" To: "'Erik Nordmark'" Cc: , X-OriginalArrivalTime: 12 Dec 2001 04:57:38.0216 (UTC) FILETIME=[85750280:01C182C9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBC4vdvU025764 Sender: owner-mobile-ip@sunroof.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 > > Let the IRTF or whoever else wishes to study the implications > > of changing from the use of RH to tunnelling for IP mobility do so > > over the next few months (or years) and if the outcome of that > > analysis says mobility is better done with tunelling, we should > > consider it at that time. > > Makes zero sense to me. > Once MIPv6 has been deployed there are close to zero benefits > of switching > to use a different "encoding" of the IP addresses that go in > HAOpt and RH. > It would cause potential massive interoperability problems > unless everybody > implements both the old and new. > I understand your point Erik. But what I mean is that we cannot delay MIPv6 because we believe there may be a better mechanism down the pipeline and hence we should wait for it. I mean look at the security WG, they went ahead and specified IKE and deployed it. And a few years later they are revisiting the issue. So while I am not suggesting that we make a decision that we know we will regret later, we should at least make a decision based on what we know now and what we have in terms of solutions that would allow MIPv6 to move forward. > Erik > -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 12 04: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 EAA23812 for ; Wed, 12 Dec 2001 04:56:09 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04289; Wed, 12 Dec 2001 02:54:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21241; Wed, 12 Dec 2001 01:55:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC9sVvU026375 for ; Wed, 12 Dec 2001 01:54:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBC9sVfS026374 for mobile-ip-dist; Wed, 12 Dec 2001 01:54:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBC9sSvU026367 for ; Wed, 12 Dec 2001 01:54:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24715 for ; Wed, 12 Dec 2001 01:54:29 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11922 for ; Wed, 12 Dec 2001 02:55:08 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBC9sQS16525; Wed, 12 Dec 2001 11:54:26 +0200 Date: Wed, 12 Dec 2001 11:54:25 +0200 (EET) From: Pekka Savola To: cc: "'Erik Nordmark'" , Subject: RE: [mobile-ip] Routing header Vs tunneling In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CD263@daebe007.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: On Tue, 11 Dec 2001, Patil Basavaraj (NET/Dallas) wrote: > I understand your point Erik. But what I mean is that we cannot delay > MIPv6 because we believe there may be a better mechanism down the > pipeline and hence we should wait for it. I mean look at the security > WG, > they went ahead and specified IKE and deployed it. And a few years later > they are revisiting the issue. Disclaimer: I've not formed an opinion on this matter yet. IKE may not be the best mechanism to compare to -- it doesn't (quite) work. Do we want the same realization for MIPv6? If IPSEC people would now be asked whether they'd like to go back in time, redesign IKE "for good", taking more time on it rather than getting it deployed, I bet they would! -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 12 05:02: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 FAA23867 for ; Wed, 12 Dec 2001 05:02:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA07231; Wed, 12 Dec 2001 03:00:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21841; Wed, 12 Dec 2001 02:01:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCA0RvU026456 for ; Wed, 12 Dec 2001 02:00:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCA0RGk026455 for mobile-ip-dist; Wed, 12 Dec 2001 02:00:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCA0JvU026437; Wed, 12 Dec 2001 02:00:19 -0800 (PST) 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 CAA08101; Wed, 12 Dec 2001 02:00:20 -0800 (PST) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17636; Wed, 12 Dec 2001 02:00:19 -0800 (PST) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id CC09B74407; Wed, 12 Dec 2001 12:07:38 +0200 (EET) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id B27D2BA21; Wed, 12 Dec 2001 12:00:15 +0200 (EET) Message-ID: <3C172996.6050706@nomadiclab.com> Date: Wed, 12 Dec 2001 11:55:34 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011 X-Accept-Language: en-us MIME-Version: 1.0 To: gmorrow@nortelnetworks.com Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: IPv6 address ownership and autoconfig problems (was Re: [mobile-ip] Routing header Vs tunneling References: <933FADF5E673D411B8A30002A5608A0E01223CB9@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Glenn, [I am redirecting this to ipng, in addition to mobile-ip, since the address ownership problems are a larger issue than just a Mobile IPv6 security thing.] Glenn Morrow writes: > What prevents a node from obtaining and using any number of free or > not free (i.e. in use by another legitimate node) IP addresses such > that they can spoof addresses albeit only on the same subnet IF INGRESS > FILTERING is used on the first hop. Use of IPSEC is not mandated. Use of > INGRESS FILTERING is not mandated, either. What is the interaction with > control lists, etc.. etc.. etc.. Are there any provisions for > anti-mac-spoofing, etc.. etc.. etc.. Pekka's draft which detailed most > of the holes has expired, perhaps he is listening and will republish it. The old address-ownership draft is available at http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-address-ownership-00.txt If there is demand I'd be happy to revise it. Would it be useful to revise it and publish it as an informational RFC? Please note that many of the issues discussed in that draft are also discussed in my Cambridge Security Protocols Workshop paper, which will eventually be published in the LNCS series. A pre-publication version of that is available at http://www.tml.hut.fi/~pnr/publications/cam2001.pdf BTW, while you consider ingress filtering etc, you may find it entertaining to read our recent half-serious half-joking paper titled "IPv6 Source Addresses Considered Harmful", available at http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 12 05:07: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 FAA23925 for ; Wed, 12 Dec 2001 05:07:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10177; Wed, 12 Dec 2001 03:06:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22703; Wed, 12 Dec 2001 02:06:56 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCA6FvU026555 for ; Wed, 12 Dec 2001 02:06:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCA6E7k026554 for mobile-ip-dist; Wed, 12 Dec 2001 02:06:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCA6BvU026547 for ; Wed, 12 Dec 2001 02:06:11 -0800 (PST) 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 CAA25807 for ; Wed, 12 Dec 2001 02:06:12 -0800 (PST) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03432 for ; Wed, 12 Dec 2001 02:06:11 -0800 (PST) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id 91CA774403; Wed, 12 Dec 2001 12:13:31 +0200 (EET) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 0614BBA21; Wed, 12 Dec 2001 12:06:08 +0200 (EET) Message-ID: <3C172AF5.8040903@nomadiclab.com> Date: Wed, 12 Dec 2001 12:01:25 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: "'Erik Nordmark'" , TJ@Kniveton.com Subject: Re: [mobile-ip] Routing header Vs tunneling References: 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 Pekka, Pekka Savola wrote: > IKE may not be the best mechanism to compare to -- it doesn't (quite) > work. Do we want the same realization for MIPv6? If IPSEC people would > now be asked whether they'd like to go back in time, redesign IKE "for > good", taking more time on it rather than getting it deployed, I bet they > would! IPSEC WG certainly has its own problems, and progress there is sometimes not quite "smooth", but IKE certainly _works_. It's just not very good. I'd be very surprised to find any considerable number of people that would have liked to slow down IKE deployment, it has been slow enough in any case. If we can finish MIPv6 soon, I'd very much like see that happening, even if MIPv6 would never be used very much. It still would give us good information how to design a better IPv6 mobility protocol. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 12 05:50: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 FAA24285 for ; Wed, 12 Dec 2001 05:50:45 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01382; Wed, 12 Dec 2001 03:49:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26704; Wed, 12 Dec 2001 02:49:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCAn5vU026717 for ; Wed, 12 Dec 2001 02:49:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCAn5xN026716 for mobile-ip-dist; Wed, 12 Dec 2001 02:49:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCAn2vU026709 for ; Wed, 12 Dec 2001 02:49:02 -0800 (PST) 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 CAA17413 for ; Wed, 12 Dec 2001 02:49:04 -0800 (PST) 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 CAA22977 for ; Wed, 12 Dec 2001 02:49:02 -0800 (PST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id fBCAmlP10214; Wed, 12 Dec 2001 11:48:47 +0100 (MET) Message-ID: <3C173610.BEF73BD2@inrialpes.fr> Date: Wed, 12 Dec 2001 11:48:49 +0100 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: mobile-ip@sunroof.eng.sun.com, Erik Nordmark , mroe@microsoft.com, tuomaura@microsoft.com, gab@sun.com Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: <3C12BA10.5030304@piuha.net> <3C14787C.C5C79043@inrialpes.fr> <3C149F8F.1030203@piuha.net> <3C14F65C.6020901@piuha.net> <3C15CAB4.20D8B8ED@inrialpes.fr> <3C1635A3.2070105@piuha.net> Content-Type: multipart/alternative; boundary="------------CCFC73B5EF9F62266DB549E2" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------CCFC73B5EF9F62266DB549E2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Claude Castelluccia wrote: > > > The prevention of this attack is another reason why CAM-DH runs BAKE/2 > > at the bottom: the return routability tests ensure that the attackers > > can't claim to be from X if they really aren't from there (or on > > the path to it). > > > > In SUCV, the 4 SUCVp messages are exchanged between the CN and the > > MN (the CoA). > > So the MN has to be in the X network (or on the path to it) for the SUCV > > exchange to succeed... > > Ah yes, but in my attack above X was the prefix of the home network and > it was assumed to be different from Y, the prefix of the CoA network. > > > The only weakness (i think) is that this exchange might succeed even if > > the attacker is on the path to X but > > return routability does not solve this problem. In fact what prevents, > > in this case, an attacker to choose > > a HomeAddress that is also on the path from the CN to X??? > > > > I think that return routability might only be useful against an attacker > > trying to redirect a "legitimate" HomeAddress... > > but SUCV/CAM also solves this issue... > > Here's the attack: > > 1. Invent a new SUCV-address (you can do it) of the form X: > > 2. Go to network Y and get an address Y: > > 3. Run SUCV against any CN. This will succeed, because the > attacker generated the address by himself. > 4. Start some session with the CN, using Route Optimization > 5. Send a BU to the CN with lifetime 0. This will kill the BCE. > 6. CN continues to send a number of packets towards X: > on the open session (e.g. RTP videostream). > 7. The packets arrive at network X, and do not hit any > specific node because in step 1 we obviously can't > pick any existing address. However, the network will > be full of packets, and X's Internet pipe may be full. > > This attack has a relatively high amplification factor. Ok that should work but steps 1, 2 and 3 is SUCV...5,6,7 is IPSec.... IPSec (i.e. BU authentication part) seems to be the problem here ;-) but anyway you can do much better than that ;-) Most of the proposed schemes, except BU3WAY, (correct me if i am wrong) propose a solution to establish a SA between the MN and the CN...then BU are securized using the generated SKEY.... So what someone could do is: 1- establish a SA with a CN using SUCV/CAM, Bake.... 2- Start some session with the CN using route optimization 3- register X (the network or host target) as your CoA... ..packets will be sent to X!! I believe that most of the schemes will fail against this attack...(note that in SUCV you won't be able to attack a host address but a network). If we really want to solve these problems, the requirements are then: 1- How to avoid the initial messages to go through the HA before the MN is authenticated to avoid "3rd party reflection" (that was the start of this thread)? 2- How to avoid someone generating a fake Home Address and redirect msg to it (this is the attack you've described)? 3- How to avoid someone registering someone'else address as CoA (this is the attack that i've described above).... 4-+ the initial requirements (i.e. How to avoid MiTM + how to avoid HoA redirection....) One solution would be: 1- establish the SA between the MN and CN using something like SUCV (i.e. without going through the HA). 2 - secure BU using a protocol combining BU3WAY and the previously establish SA. For example, we could have the following mesg exchange each time the MN moves: a- MN-> CN : BUR authenticated with SKEY b- CN-> HA: BUC authenticated with SKEY c- HA->MN: BUC authenticated with SKEY d- MN->CN: BU authenticated with SKEY.. Comments? thanks. Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------CCFC73B5EF9F62266DB549E2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Jari Arkko wrote:
Claude Castelluccia wrote:

>     The prevention of this attack is another reason why CAM-DH runs BAKE/2
>     at the bottom: the return routability tests ensure that the attackers
>     can't claim to be from X if they really aren't from there (or on
>     the path to it).
>
> In SUCV, the 4 SUCVp messages are exchanged between the CN and the
> MN (the CoA).
> So the MN has to be in the X network (or on the path to it) for the SUCV
> exchange to succeed...

Ah yes, but in my attack above X was the prefix of the home network and
it was assumed to be different from Y, the prefix of the CoA network.

> The only weakness (i think) is that this exchange might succeed even if
> the attacker is on the path to X but
> return routability does not solve this problem. In fact what prevents,
> in this case, an attacker to choose
> a HomeAddress that is also on the path from the CN to X???
>
> I think that return routability might only be useful against an attacker
> trying to redirect a "legitimate" HomeAddress...
> but SUCV/CAM also solves this issue...

Here's the attack:

1. Invent a new SUCV-address (you can do it) of the form X:<HoA>

2. Go to network Y and get an address Y:<CoA>

3. Run SUCV against any CN. This will succeed, because the
    attacker generated the address by himself.
4. Start some session with the CN, using Route Optimization
5. Send a BU to the CN with lifetime 0. This will kill the BCE.
6. CN continues to send a number of packets towards X:<HoA>
    on the open session (e.g. RTP videostream).
7. The packets arrive at network X, and do not hit any
    specific node because in step 1 we obviously can't
    pick any existing address. However, the network will
    be full of packets, and X's Internet pipe may be full.

This attack has a relatively high amplification factor.

Ok that should work but
steps 1, 2 and 3 is SUCV...5,6,7 is IPSec....
IPSec (i.e. BU authentication part) seems to be the problem here ;-)

but anyway you can do much better than that ;-)
Most of the proposed schemes, except BU3WAY, (correct me if i am wrong)
propose a solution to establish a SA between the MN and the CN...then
BU are securized using the generated SKEY....

So what someone could do is:
1- establish a SA with a CN using SUCV/CAM, Bake....
2- Start some session with the CN using route optimization
3- register X  (the network or host target) as your CoA...
..packets will be sent to X!!

I believe that most of the schemes will fail against this attack...(note that in SUCV you won't
be able to attack a host address but a network).

If we really want to solve these problems, the requirements are then:
1- How to avoid the initial messages to go through the HA before the MN is authenticated
to avoid "3rd party reflection" (that was the start of this thread)?
2- How to avoid someone generating a fake Home Address and redirect msg to it (this is the
attack you've described)?
3- How to avoid someone registering someone'else address as CoA (this is the attack that i've
described above)....
4-+ the initial requirements (i.e. How to avoid MiTM + how to avoid HoA redirection....)

One solution would be:
1- establish the SA between the MN and CN using something like SUCV (i.e. without going through
the HA).
2 - secure BU using a protocol combining  BU3WAY and the previously establish SA. For example,
we could have the following mesg exchange each time the MN moves:
  a- MN-> CN : BUR authenticated with SKEY
  b- CN-> HA: BUC authenticated with SKEY
  c- HA->MN: BUC authenticated with SKEY
  d- MN->CN:  BU authenticated  with SKEY..
 

Comments?
thanks.

Claude.
 
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------CCFC73B5EF9F62266DB549E2-- From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 12 05:51: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 FAA24313 for ; Wed, 12 Dec 2001 05:51:46 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27068; Wed, 12 Dec 2001 02:50:44 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26846; Wed, 12 Dec 2001 02:50:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCAo9vU026737 for ; Wed, 12 Dec 2001 02:50:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCAo9oW026736 for mobile-ip-dist; Wed, 12 Dec 2001 02:50:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCAo5vU026726 for ; Wed, 12 Dec 2001 02:50:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA17500 for ; Wed, 12 Dec 2001 02:50:07 -0800 (PST) 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 DAA05735 for ; Wed, 12 Dec 2001 03:50:44 -0700 (MST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id fBCAnxP10262 for ; Wed, 12 Dec 2001 11:49:59 +0100 (MET) Message-ID: <3C173659.C122F629@inrialpes.fr> Date: Wed, 12 Dec 2001 11:50:01 +0100 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] privacy? References: Content-Type: multipart/alternative; boundary="------------A4B4C3982B837DB27148A54A" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------A4B4C3982B837DB27148A54A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt "Hjelm, Bjorn" wrote: > All, > If also could receive a copy of > draft-castelluccia-mobileip-privacy-00.txt, it would be much > appreciated. > > Thanks, > Bjorn > > ----------------------------------------------------------------- > From the Desk of.. > > Bjorn Hjelm > Network Planning and Advanced Technology > ALLTEL Communications, Inc. > Tel: (501) 905-8612 > Fax: (501) 905-6324 > E-mail: bjorn.hjelm@alltel.com -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------A4B4C3982B837DB27148A54A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-mobileip-privacy-00.txt

"Hjelm, Bjorn" wrote:

All,
If also could receive a copy of
draft-castelluccia-mobileip-privacy-00.txt, it would be much
appreciated.

Thanks,
Bjorn

-----------------------------------------------------------------
From the Desk of..

Bjorn Hjelm
Network Planning and Advanced Technology
ALLTEL Communications, Inc.
Tel: (501) 905-8612
Fax: (501) 905-6324
E-mail: bjorn.hjelm@alltel.com

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------A4B4C3982B837DB27148A54A-- From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 12 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 KAA09115 for ; Wed, 12 Dec 2001 10:29:11 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25852; Wed, 12 Dec 2001 08:27:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13021; Wed, 12 Dec 2001 07:28:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCFRIvU027082 for ; Wed, 12 Dec 2001 07:27:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCFRIlV027081 for mobile-ip-dist; Wed, 12 Dec 2001 07:27:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCFRFvU027074 for ; Wed, 12 Dec 2001 07:27:15 -0800 (PST) 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 HAA18680 for ; Wed, 12 Dec 2001 07:27:16 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22233 for ; Wed, 12 Dec 2001 07:27:15 -0800 (PST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBCFRDn16757 for ; Wed, 12 Dec 2001 09:27:13 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Dec 2001 09:26:02 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01287289@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Risks of not verifying the care-of address Date: Wed, 12 Dec 2001 09:26:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18321.59C44940" Sender: owner-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_01C18321.59C44940 Content-Type: text/plain; charset="iso-8859-1" Claude, Another approach would be to somehow use the routers close to the MNs to ensure that the MN is using COA's they are supposed to be using. Ingress Filtering can restrict such abuses to just the originating subnet being spoofed. Control Lists would offer more protection against this. I think this threat is the same threat that ingress filtering was trying to deal with on non-mobile nodes. Thanks, Glenn -----Original Message----- From: Claude Castelluccia [mailto:claude.castelluccia@inrialpes.fr] Sent: Wednesday, December 12, 2001 4:49 AM To: jari.arkko@piuha.net Cc: mobile-ip@sunroof.eng.sun.com; Erik Nordmark; mroe@microsoft.com; tuomaura@microsoft.com; gab@sun.com Subject: Re: [mobile-ip] Risks of not verifying the care-of address Jari Arkko wrote: Claude Castelluccia wrote: > The prevention of this attack is another reason why CAM-DH runs BAKE/2 > at the bottom: the return routability tests ensure that the attackers > can't claim to be from X if they really aren't from there (or on > the path to it). > > In SUCV, the 4 SUCVp messages are exchanged between the CN and the > MN (the CoA). > So the MN has to be in the X network (or on the path to it) for the SUCV > exchange to succeed... Ah yes, but in my attack above X was the prefix of the home network and it was assumed to be different from Y, the prefix of the CoA network. > The only weakness (i think) is that this exchange might succeed even if > the attacker is on the path to X but > return routability does not solve this problem. In fact what prevents, > in this case, an attacker to choose > a HomeAddress that is also on the path from the CN to X??? > > I think that return routability might only be useful against an attacker > trying to redirect a "legitimate" HomeAddress... > but SUCV/CAM also solves this issue... Here's the attack: 1. Invent a new SUCV-address (you can do it) of the form X: 2. Go to network Y and get an address Y: 3. Run SUCV against any CN. This will succeed, because the attacker generated the address by himself. 4. Start some session with the CN, using Route Optimization 5. Send a BU to the CN with lifetime 0. This will kill the BCE. 6. CN continues to send a number of packets towards X: on the open session (e.g. RTP videostream). 7. The packets arrive at network X, and do not hit any specific node because in step 1 we obviously can't pick any existing address. However, the network will be full of packets, and X's Internet pipe may be full. This attack has a relatively high amplification factor. Ok that should work but steps 1, 2 and 3 is SUCV...5,6,7 is IPSec.... IPSec (i.e. BU authentication part) seems to be the problem here ;-) but anyway you can do much better than that ;-) Most of the proposed schemes, except BU3WAY, (correct me if i am wrong) propose a solution to establish a SA between the MN and the CN...then BU are securized using the generated SKEY.... So what someone could do is: 1- establish a SA with a CN using SUCV/CAM, Bake.... 2- Start some session with the CN using route optimization 3- register X (the network or host target) as your CoA... ..packets will be sent to X!! I believe that most of the schemes will fail against this attack...(note that in SUCV you won't be able to attack a host address but a network). If we really want to solve these problems, the requirements are then: 1- How to avoid the initial messages to go through the HA before the MN is authenticated to avoid "3rd party reflection" (that was the start of this thread)? 2- How to avoid someone generating a fake Home Address and redirect msg to it (this is the attack you've described)? 3- How to avoid someone registering someone'else address as CoA (this is the attack that i've described above).... 4-+ the initial requirements (i.e. How to avoid MiTM + how to avoid HoA redirection....) One solution would be: 1- establish the SA between the MN and CN using something like SUCV (i.e. without going through the HA). 2 - secure BU using a protocol combining BU3WAY and the previously establish SA. For example, we could have the following mesg exchange each time the MN moves: a- MN-> CN : BUR authenticated with SKEY b- CN-> HA: BUC authenticated with SKEY c- HA->MN: BUC authenticated with SKEY d- MN->CN: BU authenticated with SKEY.. Comments? thanks. Claude. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ ------_=_NextPart_001_01C18321.59C44940 Content-Type: text/html; charset="iso-8859-1"
Claude,
 
Another approach would be to somehow use the routers close to the MNs to ensure that the MN is using COA's they are supposed to be using. Ingress Filtering can restrict such abuses to just the originating subnet being spoofed. Control Lists would offer more protection against this. I think this threat is the same threat that ingress filtering was trying to deal with on non-mobile nodes.
 
Thanks,
 
Glenn
-----Original Message-----
From: Claude Castelluccia [mailto:claude.castelluccia@inrialpes.fr]
Sent: Wednesday, December 12, 2001 4:49 AM
To: jari.arkko@piuha.net
Cc: mobile-ip@sunroof.eng.sun.com; Erik Nordmark; mroe@microsoft.com; tuomaura@microsoft.com; gab@sun.com
Subject: Re: [mobile-ip] Risks of not verifying the care-of address <draft-roe-mobileip-updateauth-01>

Jari Arkko wrote:
Claude Castelluccia wrote:

>     The prevention of this attack is another reason why CAM-DH runs BAKE/2
>     at the bottom: the return routability tests ensure that the attackers
>     can't claim to be from X if they really aren't from there (or on
>     the path to it).
>
> In SUCV, the 4 SUCVp messages are exchanged between the CN and the
> MN (the CoA).
> So the MN has to be in the X network (or on the path to it) for the SUCV
> exchange to succeed...

Ah yes, but in my attack above X was the prefix of the home network and
it was assumed to be different from Y, the prefix of the CoA network.

> The only weakness (i think) is that this exchange might succeed even if
> the attacker is on the path to X but
> return routability does not solve this problem. In fact what prevents,
> in this case, an attacker to choose
> a HomeAddress that is also on the path from the CN to X???
>
> I think that return routability might only be useful against an attacker
> trying to redirect a "legitimate" HomeAddress...
> but SUCV/CAM also solves this issue...

Here's the attack:

1. Invent a new SUCV-address (you can do it) of the form X:<HoA>

2. Go to network Y and get an address Y:<CoA>

3. Run SUCV against any CN. This will succeed, because the
    attacker generated the address by himself.
4. Start some session with the CN, using Route Optimization
5. Send a BU to the CN with lifetime 0. This will kill the BCE.
6. CN continues to send a number of packets towards X:<HoA>
    on the open session (e.g. RTP videostream).
7. The packets arrive at network X, and do not hit any
    specific node because in step 1 we obviously can't
    pick any existing address. However, the network will
    be full of packets, and X's Internet pipe may be full.

This attack has a relatively high amplification factor.

Ok that should work but
steps 1, 2 and 3 is SUCV...5,6,7 is IPSec....
IPSec (i.e. BU authentication part) seems to be the problem here ;-)

but anyway you can do much better than that ;-)
Most of the proposed schemes, except BU3WAY, (correct me if i am wrong)
propose a solution to establish a SA between the MN and the CN...then
BU are securized using the generated SKEY....

So what someone could do is:
1- establish a SA with a CN using SUCV/CAM, Bake....
2- Start some session with the CN using route optimization
3- register X  (the network or host target) as your CoA...
..packets will be sent to X!!

I believe that most of the schemes will fail against this attack...(note that in SUCV you won't
be able to attack a host address but a network).

If we really want to solve these problems, the requirements are then:
1- How to avoid the initial messages to go through the HA before the MN is authenticated
to avoid "3rd party reflection" (that was the start of this thread)?
2- How to avoid someone generating a fake Home Address and redirect msg to it (this is the
attack you've described)?
3- How to avoid someone registering someone'else address as CoA (this is the attack that i've
described above)....
4-+ the initial requirements (i.e. How to avoid MiTM + how to avoid HoA redirection....)

One solution would be:
1- establish the SA between the MN and CN using something like SUCV (i.e. without going through
the HA).
2 - secure BU using a protocol combining  BU3WAY and the previously establish SA. For example,
we could have the following mesg exchange each time the MN moves:
  a- MN-> CN : BUR authenticated with SKEY
  b- CN-> HA: BUC authenticated with SKEY
  c- HA->MN: BUC authenticated with SKEY
  d- MN->CN:  BU authenticated  with SKEY..
 

Comments?
thanks.

Claude.
 
  

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
 
------_=_NextPart_001_01C18321.59C44940-- From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 12 10:36:59 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 KAA09681 for ; Wed, 12 Dec 2001 10:36:58 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24578; Wed, 12 Dec 2001 07:32:36 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14139; Wed, 12 Dec 2001 07:32:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCFVmvU027131 for ; Wed, 12 Dec 2001 07:31:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCFVmZB027130 for mobile-ip-dist; Wed, 12 Dec 2001 07:31:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCFVjvU027122 for ; Wed, 12 Dec 2001 07:31:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11056 for ; Wed, 12 Dec 2001 07:30:42 -0800 (PST) Received: from cambianetworks.com (66-73-249-62.cambianetworks.com [66.73.249.62] (may be forged)) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA21323 for ; Wed, 12 Dec 2001 08:30:42 -0700 (MST) Received: (qmail 26627 invoked by uid 8); 12 Dec 2001 15:30:41 -0000 Received: from pc-01996 (172.16.7.204, claiming to be "USAROSRMARKS1") by gate.cambianetworks.com with SMTP id smtpdyrvNFy; Wed, 12 Dec 2001 10:30:35 EST From: "Robert J Marks" To: , "'Patil Basavaraj \(NET/Dallas\)'" , "'Perkins Charles \(IPRG\)'" Cc: "'Pete Wenzel'" , "'Pat Calhoun'" Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Date: Wed, 12 Dec 2001 09:30:21 -0600 Organization: Cambia Networks Message-ID: <001101c18321$e9c18da0$6401a8c0@cambianetworks.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C182EF.9F28A440" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <6B49EDFE974BD51197D70002A56079D82AF608@zrc2c013.us.nortel.com> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C182EF.9F28A440 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Ahmad, I understand your point now. However, in regard to NAI, I think that RFC2794 modifies RFC2002. If the MN requests dynamic home address assignment, then RFC2794 requires the NAI to be recorded in the pending registration request record, and thus NAI can be used to differentiate retransmissions from new registration requests. Section 3.2 in rfc3012-bis states that the Foreign Agent "SHOULD check that the mobile node is actually performing a retransmission, by verifying that the relevant fields of the retransmitted request are the same as represented in the visitor list entry for the pending Registration Request...". So I think the Foreign Agent will use the NAI to determine whether a request is new or a retransmission. Regards, Bob Robert J Marks Cambia Networks Office: +1 847 627 3703 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 Ahmad Muhanna Sent: Tuesday, December 11, 2001 10:48 PM To: 'mobile-ip@sunroof.eng.sun.com'; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)' Cc: Pete Wenzel; 'Pat Calhoun' Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Bob; By adopting the new version proposed for RFC3012bis, the third paragraph in section 3.2. of RFC3012bis as mentioned below, specifically identify what FA should check to determine if the RRQ is a re-transmission or not. NAI is not one of these criteria. In other words, if we reference section 3.7.1. of RFC2002 to determine if the RRQ message is a re-transmission, any RRQ with different NAI on the same PPP session and using the same Home address still will be considered as a re-transmission rather than a new RRQ. I hope this makes it clearer. Regards; Ahmad Muhanna Nortel Networks Shasta PDSN-MIP Development Phone. + 1 972 685 1416 ESN. 445-1416 amuhanna@nortelnetworks.com -----Original Message----- From: Robert J Marks [mailto:rjmarks@cambianetworks.com] Sent: Tuesday, December 11, 2001 10:07 AM To: mobile-ip; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)' Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun' Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Ahmad, I agree. The presence of a "new" NAI at the FA signals that authentication should be performed. If a MN sends a Registration Request using a new NAI, the FA should treat it as a new registration. I guess I don't see the issue. Bob From: Ahmad Muhanna Bob; I think our concern here is how the FA handles the RRQ message in these scenarios. Let us remember, if it is a re-transmission, FA does not authenticate the user through AAA. However, if it is considered a new registration, FA MUST authenticate the RRQ message "the USER" before relaying the RRQ to HA. I hope this clarifies the issue at hand. Thanks; Ahmad Muhanna -----Original Message----- From: Robert J Marks [mailto:rjmarks@cambianetworks.com] Sent: Tuesday, December 11, 2001 7:05 AM To: mobile-ip@sunroof.eng.sun.com; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)' Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun' Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Ahmad, Some observations on your scenarios. Ahmad Muhanna wrote: > What about the following scenario: > 1. MN sends a RRQ message with NAI1, Home Address 0.0.0.0. > 2. MN sends 1st retry of RRQ with NAI1, Home address 0.0.0.0. > > 3. Now, we have a SMART MN, which figures out that it can use another > Profile with NAI2 and Home Address 0.0.0.0. > > 4. Since section 3.7.1 in RFC2002 does not talk about the user NAI, > PDSN will consider this as a retransmission while may be the user > would have failed authentication at the AAA. This situation will be treated as a new Registration Request, independent of the request that used NAI1. The Home Agent will not correlate the two requests, since it identifies the MN by the NAI in this case. > ** Another thing, what about if we support different NAIs over the > same PPP session and let us say NAI1, NAI2, and NAI3 have the same > HA and all requesting Dynamic MIP calls with Home Addresses of 0.0.0.0. All three requests will be treated as independent registrations. The HA does not know about PPP, and again uses the NAI to identify the MN. > ********** > Ahmad Muhanna Bob Robert J Marks Cambia Networks Office: +1 847 627 3703 Mobile: +1 708 829 6329 -----Original Message----- From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com] Sent: Tuesday, November 13, 2001 4:20 PM To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles (IPRG) Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP Working Group; Pat Calhoun Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Charlie proposed the following text: >======================================================================= > >Here is the new relevant text, in the same paragraph as your original >quote: > > .... The Foreign Agent SHOULD check that the mobile node is > actually performing a retransmission, by verifying that the relevant > fields of the retransmitted request are the same as represented in > the visitor list entry for the pending Registration Request (section > 3.7.1 of [8]). This verification MUST NOT include the "remaining > Lifetime of the pending registration", or the Identification field > since those values are likely to change even for requests that are > merely retransmissions and not new Registration Requests. In all > other circumstances, if the Foreign Agent receives .... > >======================================================================= > >Comments? > >>Ahmad Muhanna: >>I hope you would agree that the following change will satisfy the need: >> >>"If a mobile node retransmits a Registration Request with the same >>Identification field and the same Challenge extension, and the Foreign >>Agent still has a pending Registration Request record in effect for the >>mobile node, then the Foreign Agent forwards the Registration Request to >>the Home Agent again (see Registration Retransmission, section 3.6.3[8]). >>In all other circumstances, if the Foreign Agent receives a Registration >>Request with a Challenge extension containing a Challenge value previously >>used by that mobile node, the Foreign Agent SHOULD send a Registration >>Reply to the mobile node containing the Code value STALE_CHALLENGE." > >Regards, >Charlie P. > I think the text that Charlie proposes makes it quite clear as to what the FA must do in order to recognize, if it is a retransmission. So I would recommend going with Charlie's text in the revision for this spec. -Basavaraj ------=_NextPart_000_0012_01C182EF.9F28A440 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Ahmad,
 
I=20 understand your point now. However, in regard to NAI, I think that = RFC2794=20 modifies RFC2002.
 
If the=20 MN requests dynamic home address assignment, then RFC2794 requires the = NAI to be=20 recorded in the pending registration request record, and thus NAI can be = used to=20 differentiate retransmissions from new registration=20 requests.
 
Section 3.2 in rfc3012-bis states that the Foreign Agent = "SHOULD check=20 that the mobile node is actually performing a retransmission, by = verifying that=20 the relevant fields of the retransmitted request are the same as = represented in=20 the visitor list entry for the pending Registration=20 Request...".
 
So I=20 think the Foreign Agent will use the NAI to determine whether a request = is new=20 or a retransmission.
 
Regards,
 
Bob
 
Robert J Marks
Cambia Networks
Office: +1 847 627 = 3703
Mobile:=20 +1 708 829 6329
-----Original = Message-----
From:=20 owner-mobile-ip@sunroof.eng.sun.com = [mailto:owner-mobile-ip@sunroof.eng.sun.com]=20 On Behalf Of Ahmad Muhanna
Sent: Tuesday, December 11, = 2001=20 10:48 PM
To: 'mobile-ip@sunroof.eng.sun.com'; 'Patil Basavaraj = (NET/Dallas)'; 'Perkins Charles (IPRG)'
Cc: Pete Wenzel; 'Pat=20 Calhoun'
Subject: RE: [mobile-ip] URGENT - rfc3012 = interpretation=20 question

Bob;
 
By=20 adopting the new version proposed for RFC3012bis, the third = paragraph in=20 section 3.2. of RFC3012bis as mentioned below, specifically identify = what FA=20 should check to determine if the RRQ is a re-transmission or=20 not.
NAI=20 is not one of these criteria.
In=20 other words, if we reference section 3.7.1. of RFC2002 to determine if = the RRQ=20 message is a re-transmission, any RRQ with different NAI = on=20 the same PPP session and using the same Home address still will be = considered=20 as a re-transmission rather than a new RRQ.
 
I=20 hope this makes it clearer.
 

Regards;=20

Ahmad=20 Muhanna
Nortel Networks
Shasta PDSN-MIP=20 Development
Phone. + 1 972 685 1416 ESN. 445-1416 =
amuhanna@nortelnetworks.com

-----Original Message-----
From: Robert J Marks=20 [mailto:rjmarks@cambianetworks.com]
Sent: Tuesday, = December 11,=20 2001 10:07 AM
To: mobile-ip; 'Patil Basavaraj = (NET/Dallas)';=20 'Perkins Charles (IPRG)'
Cc: Wenzel, Pete = [RICH2:2Q00:EXCH]; 'Pat=20 Calhoun'
Subject: RE: [mobile-ip] URGENT - rfc3012 = interpretation=20 question

Ahmad,
 
I=20 agree. The presence of a "new" NAI at the FA signals that=20 authentication should be performed.
If=20 a MN sends a Registration Request using a new NAI, the FA = should treat=20 it as a new registration.
I=20 guess I don't see the issue.
 
Bob 
 
From: Ahmad=20 Muhanna

Bob;

I think our concern here is how the FA handles = the RRQ=20 message in these scenarios.
Let us = remember, if it=20 is a re-transmission, FA does not authenticate the user through=20 AAA.
However, if it is considered a new=20 registration, FA MUST authenticate the RRQ message =
"the USER" before relaying the RRQ to HA. =
I=20 hope this clarifies the issue at hand.

Thanks;

Ahmad Muhanna


-----Original Message-----
From:=20 Robert J Marks [mailto:rjmarks@cambianetworks.= com]=20
Sent: Tuesday, December 11, 2001 7:05 AM =
To: mobile-ip@sunroof.eng.sun.com; 'Patil Basavaraj=20 (NET/Dallas)';
'Perkins Charles = (IPRG)'=20
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat = Calhoun'=20
Subject: RE: [mobile-ip] URGENT - rfc3012 = interpretation=20 question


Ahmad,

Some observations on your scenarios. =
 
Ahmad Muhanna = wrote:

> What about the following scenario: =

> 1. MN sends a RRQ message with NAI1, Home = Address=20 0.0.0.0.
> 2. MN sends 1st retry of = RRQ with=20 NAI1, Home address 0.0.0.0.
> =
> 3. Now, we have a SMART MN, which figures out that = it can use=20 another
>    Profile = with NAI2=20 and Home Address 0.0.0.0.
> =
> 4. Since section 3.7.1 in RFC2002 does not talk = about the user=20 NAI,
> PDSN will consider this as a=20 retransmission while may be the user
> would=20 have failed authentication at the AAA.

This situation will be treated as a new = Registration=20 Request,
independent
of=20 the request that used NAI1. The Home Agent will not correlate the=20 two
requests, since it identifies the MN = by the=20 NAI in this case.

> ** Another thing, what about if we support = different=20 NAIs over the
> same PPP session and = let us say=20 NAI1, NAI2, and NAI3 have the same
> = HA and all=20 requesting Dynamic MIP calls with Home Addresses of =
0.0.0.0.

All three requests will be treated as = independent=20 registrations. The HA
does not know = about PPP, and=20 again uses the NAI to identify the MN.
 
> ********** =
> Ahmad Muhanna

Bob

Robert J Marks
Cambia=20 Networks
Office: +1 847 627 3703 =
Mobile: +1 708 829 6329

 -----Original Message----- =
From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.co= m]=20
Sent: Tuesday, November 13, 2001 4:20 PM =
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles = (IPRG)=20
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP = Working=20 Group; Pat Calhoun
Subject: RE: = [mobile-ip] URGENT=20 - rfc3012 interpretation question



Charlie proposed the following text: =
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=20

>
>Here is the = new relevant=20 text, in the same paragraph as your original
>quote:
> =
>     =20 ....      The Foreign Agent SHOULD check = that the=20 mobile node is
>   actually = performing a retransmission, by verifying that the relevant =

>   fields of the retransmitted = request are=20 the same as represented in
>   the=20 visitor list entry for the pending Registration Request = (section=20

>   3.7.1 of [8]).  This = verification=20 MUST NOT include the "remaining
>  =20 Lifetime of the pending registration", or the Identification field =
>   since those values are = likely to=20 change even for requests that are
>  =20 merely retransmissions and not new Registration Requests.  In = all=20
>   other circumstances, if = the=20 Foreign Agent receives   ....
>
>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=20

>
>Comments?=20
>
>>Ahmad=20 Muhanna:
>>I hope you would agree = that the=20 following change will satisfy the
need:=20
>>
>>"If a=20 mobile node retransmits a Registration Request with the same=20
>>Identification field and the = same=20 Challenge extension, and the Foreign

>>Agent still has a pending Registration = Request=20 record in effect for
the =
>>mobile node, then the Foreign Agent forwards the=20 Registration Request
to
>>the Home Agent again (see Registration = Retransmission,=20 section
3.6.3[8]).
>>In all other circumstances, if the Foreign Agent = receives=20 a
Registration
>>Request with a Challenge extension containing a = Challenge=20 value
previously
>>used by that mobile node, the Foreign Agent = SHOULD send a=20 Registration

>>Reply to the mobile node containing the = Code value=20 STALE_CHALLENGE."
>
>Regards,
>Charlie P.=20
>

I think the text that Charlie proposes makes it = quite=20 clear as to what
the FA must do in order = to=20 recognize, if it is a retransmission. So I
would=20 recommend going with Charlie's text in the revision for = this=20
spec.

-Basavaraj=20

------=_NextPart_000_0012_01C182EF.9F28A440-- From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 12 11:37:54 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12880 for ; Wed, 12 Dec 2001 11:37:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17549; Wed, 12 Dec 2001 09:35:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00918; Wed, 12 Dec 2001 08:35:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCGYivU027379 for ; Wed, 12 Dec 2001 08:34:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBCGYiHu027378 for mobile-ip-dist; Wed, 12 Dec 2001 08:34:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBCGYcvU027365 for ; Wed, 12 Dec 2001 08:34:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12640 for ; Wed, 12 Dec 2001 08:33:37 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25697 for ; Wed, 12 Dec 2001 09:33:36 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBCGV4n07268; Wed, 12 Dec 2001 10:31:04 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Dec 2001 10:29:52 -0600 Message-ID: <6B49EDFE974BD51197D70002A56079D82AF60A@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip@sunroof.eng.sun.com'" , "'Patil Basavaraj (NET/Dallas)'" , "'Perkins Charles (IPRG)'" Cc: "Pete Wenzel" , "'Pat Calhoun'" Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Date: Wed, 12 Dec 2001 10:30:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1832A.43A338C0" Sender: owner-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_01C1832A.43A338C0 Content-Type: text/plain; charset="iso-8859-1" Bob; Thanks; I think you are right and the proposed text is fine with the consideration of RFC2794. Regards; Ahmad Muhanna Nortel Networks Shasta PDSN-MIP Development Phone. + 1 972 685 1416 ESN. 445-1416 amuhanna@nortelnetworks.com -----Original Message----- From: Robert J Marks [mailto:rjmarks@cambianetworks.com] Sent: Wednesday, December 12, 2001 9:30 AM To: mobile-ip; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)' Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun' Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Ahmad, I understand your point now. However, in regard to NAI, I think that RFC2794 modifies RFC2002. If the MN requests dynamic home address assignment, then RFC2794 requires the NAI to be recorded in the pending registration request record, and thus NAI can be used to differentiate retransmissions from new registration requests. Section 3.2 in rfc3012-bis states that the Foreign Agent "SHOULD check that the mobile node is actually performing a retransmission, by verifying that the relevant fields of the retransmitted request are the same as represented in the visitor list entry for the pending Registration Request...". So I think the Foreign Agent will use the NAI to determine whether a request is new or a retransmission. Regards, Bob Robert J Marks Cambia Networks Office: +1 847 627 3703 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 Ahmad Muhanna Sent: Tuesday, December 11, 2001 10:48 PM To: 'mobile-ip@sunroof.eng.sun.com'; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)' Cc: Pete Wenzel; 'Pat Calhoun' Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Bob; By adopting the new version proposed for RFC3012bis, the third paragraph in section 3.2. of RFC3012bis as mentioned below, specifically identify what FA should check to determine if the RRQ is a re-transmission or not. NAI is not one of these criteria. In other words, if we reference section 3.7.1. of RFC2002 to determine if the RRQ message is a re-transmission, any RRQ with different NAI on the same PPP session and using the same Home address still will be considered as a re-transmission rather than a new RRQ. I hope this makes it clearer. Regards; Ahmad Muhanna Nortel Networks Shasta PDSN-MIP Development Phone. + 1 972 685 1416 ESN. 445-1416 amuhanna@nortelnetworks.com -----Original Message----- From: Robert J Marks [mailto:rjmarks@cambianetworks.com] Sent: Tuesday, December 11, 2001 10:07 AM To: mobile-ip; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)' Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun' Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Ahmad, I agree. The presence of a "new" NAI at the FA signals that authentication should be performed. If a MN sends a Registration Request using a new NAI, the FA should treat it as a new registration. I guess I don't see the issue. Bob From: Ahmad Muhanna Bob; I think our concern here is how the FA handles the RRQ message in these scenarios. Let us remember, if it is a re-transmission, FA does not authenticate the user through AAA. However, if it is considered a new registration, FA MUST authenticate the RRQ message "the USER" before relaying the RRQ to HA. I hope this clarifies the issue at hand. Thanks; Ahmad Muhanna -----Original Message----- From: Robert J Marks [ mailto:rjmarks@cambianetworks.com ] Sent: Tuesday, December 11, 2001 7:05 AM To: mobile-ip@sunroof.eng.sun.com; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)' Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun' Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Ahmad, Some observations on your scenarios. Ahmad Muhanna wrote: > What about the following scenario: > 1. MN sends a RRQ message with NAI1, Home Address 0.0.0.0. > 2. MN sends 1st retry of RRQ with NAI1, Home address 0.0.0.0. > > 3. Now, we have a SMART MN, which figures out that it can use another > Profile with NAI2 and Home Address 0.0.0.0. > > 4. Since section 3.7.1 in RFC2002 does not talk about the user NAI, > PDSN will consider this as a retransmission while may be the user > would have failed authentication at the AAA. This situation will be treated as a new Registration Request, independent of the request that used NAI1. The Home Agent will not correlate the two requests, since it identifies the MN by the NAI in this case. > ** Another thing, what about if we support different NAIs over the > same PPP session and let us say NAI1, NAI2, and NAI3 have the same > HA and all requesting Dynamic MIP calls with Home Addresses of 0.0.0.0. All three requests will be treated as independent registrations. The HA does not know about PPP, and again uses the NAI to identify the MN. > ********** > Ahmad Muhanna Bob Robert J Marks Cambia Networks Office: +1 847 627 3703 Mobile: +1 708 829 6329 -----Original Message----- From: Patil Basavaraj (NET/Dallas) [ mailto:Basavaraj.Patil@nokia.com ] Sent: Tuesday, November 13, 2001 4:20 PM To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles (IPRG) Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP Working Group; Pat Calhoun Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question Charlie proposed the following text: >======================================================================= > >Here is the new relevant text, in the same paragraph as your original >quote: > > .... The Foreign Agent SHOULD check that the mobile node is > actually performing a retransmission, by verifying that the relevant > fields of the retransmitted request are the same as represented in > the visitor list entry for the pending Registration Request (section > 3.7.1 of [8]). This verification MUST NOT include the "remaining > Lifetime of the pending registration", or the Identification field > since those values are likely to change even for requests that are > merely retransmissions and not new Registration Requests. In all > other circumstances, if the Foreign Agent receives .... > >======================================================================= > >Comments? > >>Ahmad Muhanna: >>I hope you would agree that the following change will satisfy the need: >> >>"If a mobile node retransmits a Registration Request with the same >>Identification field and the same Challenge extension, and the Foreign >>Agent still has a pending Registration Request record in effect for the >>mobile node, then the Foreign Agent forwards the Registration Request to >>the Home Agent again (see Registration Retransmission, section 3.6.3[8]). >>In all other circumstances, if the Foreign Agent receives a Registration >>Request with a Challenge extension containing a Challenge value previously >>used by that mobile node, the Foreign Agent SHOULD send a Registration >>Reply to the mobile node containing the Code value STALE_CHALLENGE." > >Regards, >Charlie P. > I think the text that Charlie proposes makes it quite clear as to what the FA must do in order to recognize, if it is a retransmission. So I would recommend going with Charlie's text in the revision for this spec. -Basavaraj ------_=_NextPart_001_01C1832A.43A338C0 Content-Type: text/html; charset="iso-8859-1" Message
Bob;
 
Thanks;
 
I think you are right and the proposed text is fine with the consideration of RFC2794.
 

Regards;

Ahmad Muhanna
Nortel Networks
Shasta PDSN-MIP Development
Phone. + 1 972 685 1416 ESN. 445-1416
amuhanna@nortelnetworks.com

-----Original Message-----
From: Robert J Marks [mailto:rjmarks@cambianetworks.com]
Sent: Wednesday, December 12, 2001 9:30 AM
To: mobile-ip; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)'
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun'
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

Ahmad,
 
I understand your point now. However, in regard to NAI, I think that RFC2794 modifies RFC2002.
 
If the MN requests dynamic home address assignment, then RFC2794 requires the NAI to be recorded in the pending registration request record, and thus NAI can be used to differentiate retransmissions from new registration requests.
 
Section 3.2 in rfc3012-bis states that the Foreign Agent "SHOULD check that the mobile node is actually performing a retransmission, by verifying that the relevant fields of the retransmitted request are the same as represented in the visitor list entry for the pending Registration Request...".
 
So I think the Foreign Agent will use the NAI to determine whether a request is new or a retransmission.
 
Regards,
 
Bob
 
Robert J Marks
Cambia Networks
Office: +1 847 627 3703
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 Ahmad Muhanna
Sent: Tuesday, December 11, 2001 10:48 PM
To: 'mobile-ip@sunroof.eng.sun.com'; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)'
Cc: Pete Wenzel; 'Pat Calhoun'
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

Bob;
 
By adopting the new version proposed for RFC3012bis, the third paragraph in section 3.2. of RFC3012bis as mentioned below, specifically identify what FA should check to determine if the RRQ is a re-transmission or not.
NAI is not one of these criteria.
In other words, if we reference section 3.7.1. of RFC2002 to determine if the RRQ message is a re-transmission, any RRQ with different NAI on the same PPP session and using the same Home address still will be considered as a re-transmission rather than a new RRQ.
 
I hope this makes it clearer.
 

Regards;

Ahmad Muhanna
Nortel Networks
Shasta PDSN-MIP Development
Phone. + 1 972 685 1416 ESN. 445-1416
amuhanna@nortelnetworks.com

-----Original Message-----
From: Robert J Marks [mailto:rjmarks@cambianetworks.com]
Sent: Tuesday, December 11, 2001 10:07 AM
To: mobile-ip; 'Patil Basavaraj (NET/Dallas)'; 'Perkins Charles (IPRG)'
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun'
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question

Ahmad,
 
I agree. The presence of a "new" NAI at the FA signals that authentication should be performed.
If a MN sends a Registration Request using a new NAI, the FA should treat it as a new registration.
I guess I don't see the issue.
 
Bob 
 
From: Ahmad Muhanna

Bob;

I think our concern here is how the FA handles the RRQ message in these scenarios.
Let us remember, if it is a re-transmission, FA does not authenticate the user through AAA.
However, if it is considered a new registration, FA MUST authenticate the RRQ message
"the USER" before relaying the RRQ to HA.
I hope this clarifies the issue at hand.

Thanks;

Ahmad Muhanna


-----Original Message-----
From: Robert J Marks [mailto:rjmarks@cambianetworks.com]
Sent: Tuesday, December 11, 2001 7:05 AM
To: mobile-ip@sunroof.eng.sun.com; 'Patil Basavaraj (NET/Dallas)';
'Perkins Charles (IPRG)'
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; 'Pat Calhoun'
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question


Ahmad,

Some observations on your scenarios.
 
Ahmad Muhanna wrote:

> What about the following scenario:

> 1. MN sends a RRQ message with NAI1, Home Address 0.0.0.0.
> 2. MN sends 1st retry of RRQ with NAI1, Home address 0.0.0.0.
>
> 3. Now, we have a SMART MN, which figures out that it can use another
>    Profile with NAI2 and Home Address 0.0.0.0.
>
> 4. Since section 3.7.1 in RFC2002 does not talk about the user NAI,
> PDSN will consider this as a retransmission while may be the user
> would have failed authentication at the AAA.

This situation will be treated as a new Registration Request,
independent
of the request that used NAI1. The Home Agent will not correlate the two
requests, since it identifies the MN by the NAI in this case.

> ** Another thing, what about if we support different NAIs over the
> same PPP session and let us say NAI1, NAI2, and NAI3 have the same
> HA and all requesting Dynamic MIP calls with Home Addresses of
0.0.0.0.

All three requests will be treated as independent registrations. The HA
does not know about PPP, and again uses the NAI to identify the MN.
 
> **********
> Ahmad Muhanna

Bob

Robert J Marks
Cambia Networks
Office: +1 847 627 3703
Mobile: +1 708 829 6329

 -----Original Message-----
From: Patil Basavaraj (NET/Dallas) [mailto:Basavaraj.Patil@nokia.com]
Sent: Tuesday, November 13, 2001 4:20 PM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; Perkins Charles (IPRG)
Cc: Wenzel, Pete [RICH2:2Q00:EXCH]; Mobile IP Working Group; Pat Calhoun
Subject: RE: [mobile-ip] URGENT - rfc3012 interpretation question



Charlie proposed the following text:
>=======================================================================

>
>Here is the new relevant text, in the same paragraph as your original
>quote:
>
>      ....      The Foreign Agent SHOULD check that the mobile node is
>   actually performing a retransmission, by verifying that the relevant

>   fields of the retransmitted request are the same as represented in
>   the visitor list entry for the pending Registration Request (section

>   3.7.1 of [8]).  This verification MUST NOT include the "remaining
>   Lifetime of the pending registration", or the Identification field
>   since those values are likely to change even for requests that are
>   merely retransmissions and not new Registration Requests.  In all
>   other circumstances, if the Foreign Agent receives   ....
>
>=======================================================================

>
>Comments?
>
>>Ahmad Muhanna:
>>I hope you would agree that the following change will satisfy the
need:
>>
>>"If a mobile node retransmits a Registration Request with the same
>>Identification field and the same Challenge extension, and the Foreign

>>Agent still has a pending Registration Request record in effect for
the
>>mobile node, then the Foreign Agent forwards the Registration Request
to
>>the Home Agent again (see Registration Retransmission, section
3.6.3[8]).
>>In all other circumstances, if the Foreign Agent receives a
Registration
>>Request with a Challenge extension containing a Challenge value
previously
>>used by that mobile node, the Foreign Agent SHOULD send a Registration

>>Reply to the mobile node containing the Code value STALE_CHALLENGE."
>
>Regards,
>Charlie P.
>

I think the text that Charlie proposes makes it quite clear as to what
the FA must do in order to recognize, if it is a retransmission. So I
would recommend going with Charlie's text in the revision for this
spec.

-Basavaraj

------_=_NextPart_001_01C1832A.43A338C0-- From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 13 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 EAA18734 for ; Thu, 13 Dec 2001 04:00:24 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA18173; Thu, 13 Dec 2001 00:59:20 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01889; Thu, 13 Dec 2001 00:59:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD8w4vU029747 for ; Thu, 13 Dec 2001 00:58:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBD8w4hV029746 for mobile-ip-dist; Thu, 13 Dec 2001 00:58:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBD8w1vU029739 for ; Thu, 13 Dec 2001 00:58:01 -0800 (PST) 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 AAA19382 for ; Thu, 13 Dec 2001 00:58:02 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11696 for ; Thu, 13 Dec 2001 00:58:00 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBD8vxm26797 for ; Thu, 13 Dec 2001 10:57:59 +0200 Date: Thu, 13 Dec 2001 10:57:59 +0200 (EET) From: Pekka Savola To: Subject: RE: [mobile-ip] Routing header Vs tunneling In-Reply-To: <933FADF5E673D411B8A30002A5608A0E01223CB9@zrc2c012.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Tue, 11 Dec 2001, Glenn Morrow wrote: > What prevents a node from obtaining and using any number of free or not free > (i.e. in use by another legitimate node) IP addresses such that they can > spoof addresses albeit only on the same subnet IF INGRESS FILTERING is used > on the first hop. Use of IPSEC is not mandated. Use of INGRESS FILTERING is > not mandated, either. What is the interaction with control lists, etc.. > etc.. etc.. Are there any provisions for anti-mac-spoofing, etc.. etc.. > etc.. Pekka's draft which detailed most of the holes has expired, perhaps he > is listening and will republish it. A new revision was issued: http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-01.txt Thanks. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 13 09:04: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 JAA20900 for ; Thu, 13 Dec 2001 09:04:19 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00119; Thu, 13 Dec 2001 07:02:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22671; Thu, 13 Dec 2001 06:03:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDE1vvU000603 for ; Thu, 13 Dec 2001 06:01:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDE1v6Z000602 for mobile-ip-dist; Thu, 13 Dec 2001 06:01:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDE1pvU000584; Thu, 13 Dec 2001 06:01:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22471; Thu, 13 Dec 2001 06:01:52 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11913; Thu, 13 Dec 2001 07:01:50 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBDE1mG28970; Thu, 13 Dec 2001 16:01:48 +0200 Date: Thu, 13 Dec 2001 16:01:48 +0200 (EET) From: Pekka Savola To: cc: , Subject: [mobile-ip] Re: IPv6 address ownership and autoconfig problems (was Re: [mobile-ip] Routing header Vs tunneling In-Reply-To: <3C172996.6050706@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: On Wed, 12 Dec 2001, Pekka Nikander wrote: > BTW, while you consider ingress filtering etc, you may find > it entertaining to read our recent half-serious half-joking > paper titled "IPv6 Source Addresses Considered Harmful", > available at http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf Perhaps you should tentatively schedule a re-presentation for the tenth anniversary of this paper, in 2011, and hope a global IPSEC will be a reality then. Oh, make that 15. :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 13 12:57: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 MAA25485 for ; Thu, 13 Dec 2001 12:57:08 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08809; Thu, 13 Dec 2001 10:55:39 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06739; Thu, 13 Dec 2001 09:55:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDHspvU001235 for ; Thu, 13 Dec 2001 09:54:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDHsp3G001234 for mobile-ip-dist; Thu, 13 Dec 2001 09:54:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDHsmvU001227 for ; Thu, 13 Dec 2001 09:54:48 -0800 (PST) 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 JAA14428 for ; Thu, 13 Dec 2001 09:54:49 -0800 (PST) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08958 for ; Thu, 13 Dec 2001 09:54:49 -0800 (PST) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 1FEEE1834; Thu, 13 Dec 2001 11:54:49 -0600 (CST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id E752A1842 for ; Thu, 13 Dec 2001 11:54:48 -0600 (CST) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id 8856D7C1; Thu, 13 Dec 2001 09:54:48 -0800 (PST) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 3C5C96E7 for ; Thu, 13 Dec 2001 09:54:48 -0800 (PST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id MAA0000011778; Thu, 13 Dec 2001 12:53:49 -0500 (EST) From: Brian Haley USG Received: from dogbert.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id MAA0000031924; Thu, 13 Dec 2001 12:53:56 -0500 (EST) Received: by dogbert.zk3.dec.com (5.65v4.0/1.1.19.2/27Mar98-0945AM) id AA28814; Thu, 13 Dec 2001 12:53:20 -0500 Date: Thu, 13 Dec 2001 12:53:20 -0500 Message-Id: <200112131753.AA28814@dogbert.zk3.dec.com> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] draft 15 cruft Sender: owner-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 noticed the following cruft in the mipv6 -15 draft this week, it's all left-over from draft -14. Section 9.3 on Intercepting packets for a mobile node On multicasting NAs... "The Router (R) bit in the Advertisement MUST be copied from the corresponding bit in the home agent's Binding Cache entry for the mobile node." There is no R-bit anymore. And later in that section... "This check MUST include all possible home addresses for the mobile node, based on the subnet prefixes currently considered to be on-link by the home agent (including the corresponding link-local address and site-local address), if the Prefix Length in the Binding Cache entry for this mobile node (from the Binding Update that created this Cache entry) is nonzero." We don't have 'prefix length' anymore either, just the S-bit. Section 9.4 on Tunneling packets to a mobile node "While the mobile node is away from home and this node is acting as the mobile node's home agent, the home agent intercepts any packets on the home link addressed to the mobile node's home address (including addresses formed from other on-link prefixes, if the Prefix Length field was nonzero in the Binding Update), as described in Section 9.3." 'Prefix length' again, should reference S-bit. Section 10.7 on Sending binding updates to the home agent "The Prefix Length field in the Binding Update allows..." Thanks, -Brian From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 13 14:32: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 OAA27755 for ; Thu, 13 Dec 2001 14:32:30 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05151; Thu, 13 Dec 2001 12:31:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16777; Thu, 13 Dec 2001 11:31:27 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDJUMvU001773 for ; Thu, 13 Dec 2001 11:30:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fBDJULOU001772 for mobile-ip-dist; Thu, 13 Dec 2001 11:30:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fBDJUDvU001764 for ; Thu, 13 Dec 2001 11:30:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15834 for ; Thu, 13 Dec 2001 11:30:09 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15454 for ; Thu, 13 Dec 2001 12:30:08 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBDJU7m11338 for ; Thu, 13 Dec 2001 13:30:07 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 13 Dec 2001 13:28:56 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E012DA453@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Thu, 13 Dec 2001 13:29:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1840C.76066890" Sender: owner-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_01C1840C.76066890 Content-Type: text/plain; charset="iso-8859-1" Thank You > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Thursday, December 13, 2001 2:58 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > On Tue, 11 Dec 2001, Glenn Morrow wrote: > > > What prevents a node from obtaining and using any number of > free or not free > > (i.e. in use by another legitimate node) IP addresses such > that they can > > spoof addresses albeit only on the same subnet IF INGRESS > FILTERING is used > > on the first hop. Use of IPSEC is not mandated. Use of > INGRESS FILTERING is > > not mandated, either. What is the interaction with control > lists, etc.. > > etc.. etc.. Are there any provisions for anti-mac-spoofing, > etc.. etc.. > > etc.. Pekka's draft which detailed most of the holes has > expired, perhaps he > > is listening and will republish it. > > A new revision was issued: > > http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-se curity-01.txt Thanks. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords ------_=_NextPart_001_01C1840C.76066890 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Routing header Vs tunneling

Thank You

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Thursday, December 13, 2001 2:58 = AM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Routing header Vs = tunneling
>
>
> On Tue, 11 Dec 2001, Glenn Morrow wrote:
>
> > What prevents a node from obtaining and = using any number of
> free or not free
> > (i.e. in use by another legitimate node) = IP addresses such
> that they can
> > spoof addresses albeit only on the same = subnet IF INGRESS
> FILTERING is used
> > on the first hop. Use of IPSEC is not = mandated. Use of
> INGRESS FILTERING is
> > not mandated, either. What is the = interaction with control
> lists, etc..
> > etc.. etc.. Are there any provisions for = anti-mac-spoofing,
> etc.. etc..
> > etc.. Pekka's draft which detailed most of = the holes has
> expired, perhaps he
> > is listening and will republish it. =
>
> A new revision was issued:
>
> http://www.ietf.org/internet-drafts/draft-savola-ipv6-= rh-ha-se
curity-01.txt

Thanks.

--
Pekka = Savola           =       "Tell me of difficulties = surmounted,
Netcore = Oy           &nbs= p;       not those you stumble over and = fall"
Systems. Networks. Security.  -- Robert Jordan: = A Crown of Swords



------_=_NextPart_001_01C1840C.76066890-- From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 14 11:22: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 LAA02002 for ; Fri, 14 Dec 2001 11:22:27 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00773; Fri, 14 Dec 2001 09:21:05 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07106; Fri, 14 Dec 2001 08:21:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBEGKZFp005556 for ; Fri, 14 Dec 2001 08:20:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBEGKZQ9005555 for mobile-ip-dist; Fri, 14 Dec 2001 08:20:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBEGKWFp005548 for ; Fri, 14 Dec 2001 08:20:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06992 for ; Fri, 14 Dec 2001 08:20:33 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02118 for ; Fri, 14 Dec 2001 09:21:06 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBEGHom15340 for ; Fri, 14 Dec 2001 10:17:50 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 14 Dec 2001 10:16:39 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E012DACC2@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Date: Fri, 14 Dec 2001 10:17:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C184BA.C6FD0A20" Sender: owner-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_01C184BA.C6FD0A20 Content-Type: text/plain; charset="iso-8859-1" Sorry Pekkas - wrong Pekka. The draft you (P.S.) refer to below is not the draft I was referring to. This little error forced me to go dig up the draft and even then it did not address all of the holes and it focused too much on the MIP stuff. There also a draft on AAA and what that solved but this lead to the universal AAA issues. So I think what we need is an informational due diligence draft specific to the DDoS threats of the IPv6 stand-alone base (i.e. no MIP, no AAA). Sorry about the mix-up. Glenn -----Original Message----- From: Morrow, Glenn [RICH2:C330:EXCH] Sent: Thursday, December 13, 2001 1:29 PM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Routing header Vs tunneling Thank You > -----Original Message----- > From: Pekka Savola [ mailto:pekkas@netcore.fi ] > Sent: Thursday, December 13, 2001 2:58 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > On Tue, 11 Dec 2001, Glenn Morrow wrote: > > > What prevents a node from obtaining and using any number of > free or not free > > (i.e. in use by another legitimate node) IP addresses such > that they can > > spoof addresses albeit only on the same subnet IF INGRESS > FILTERING is used > > on the first hop. Use of IPSEC is not mandated. Use of > INGRESS FILTERING is > > not mandated, either. What is the interaction with control > lists, etc.. > > etc.. etc.. Are there any provisions for anti-mac-spoofing, > etc.. etc.. > > etc.. Pekka's draft which detailed most of the holes has > expired, perhaps he > > is listening and will republish it. > > A new revision was issued: > > http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-se curity-01.txt Thanks. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords ------_=_NextPart_001_01C184BA.C6FD0A20 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Routing header Vs tunneling
Sorry Pekkas - wrong Pekka. The draft you (P.S.) refer to below  is not  the draft I was referring to. This little error forced me to go dig up the draft and even then it did not address all of the holes and it focused too much on the MIP stuff. There also a draft on AAA and what that solved but this lead to the universal AAA issues. So I think what we need is an informational due diligence draft specific to the DDoS threats of the IPv6 stand-alone base (i.e. no MIP, no AAA).
 
Sorry about the mix-up.
 
Glenn
 
 
 
-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH]
Sent: Thursday, December 13, 2001 1:29 PM
To: mobile-ip@sunroof.eng.sun.com
Subject: RE: [mobile-ip] Routing header Vs tunneling

Thank You

> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Thursday, December 13, 2001 2:58 AM
> To: mobile-ip@sunroof.eng.sun.com
> Subject: RE: [mobile-ip] Routing header Vs tunneling
>
>
> On Tue, 11 Dec 2001, Glenn Morrow wrote:
>
> > What prevents a node from obtaining and using any number of
> free or not free
> > (i.e. in use by another legitimate node) IP addresses such
> that they can
> > spoof addresses albeit only on the same subnet IF INGRESS
> FILTERING is used
> > on the first hop. Use of IPSEC is not mandated. Use of
> INGRESS FILTERING is
> > not mandated, either. What is the interaction with control
> lists, etc..
> > etc.. etc.. Are there any provisions for anti-mac-spoofing,
> etc.. etc..
> > etc.. Pekka's draft which detailed most of the holes has
> expired, perhaps he
> > is listening and will republish it.
>
> A new revision was issued:
>
> http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-se
curity-01.txt

Thanks.

--
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords



------_=_NextPart_001_01C184BA.C6FD0A20-- From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 14 19:41: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 TAA10103 for ; Fri, 14 Dec 2001 19:41:56 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA14528; Fri, 14 Dec 2001 17:39:18 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19481; Fri, 14 Dec 2001 16:39:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBF0cZFp006749 for ; Fri, 14 Dec 2001 16:38:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBF0cZMr006748 for mobile-ip-dist; Fri, 14 Dec 2001 16:38:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBF0cWFp006741 for ; Fri, 14 Dec 2001 16:38:32 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01445 for ; Fri, 14 Dec 2001 16:38:34 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA25902 for ; Fri, 14 Dec 2001 17:38:33 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA12991 for ; Fri, 14 Dec 2001 16:38:33 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBF0cW610274 for ; Fri, 14 Dec 2001 16:38:32 -0800 X-mProtect: Fri, 14 Dec 2001 16:38:32 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.174.5, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdoVn9Qs; Fri, 14 Dec 2001 16:38:31 PST Message-ID: <3C1A9AFD.302@iprg.nokia.com> Date: Fri, 14 Dec 2001 16:36:13 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Routing header Vs tunneling References: <933FADF5E673D411B8A30002A5608A0E012DACC2@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pekka, also take a look at Jim Kempf and Erik Normark's draft http://www.ietf.org/internet-drafts/draft-kempf-ipng-netaccess-threats-00.txt vijay Glenn Morrow wrote: > Sorry Pekkas - wrong Pekka. The draft you (P.S.) refer to below is not > the draft I was referring to. This little error forced me to go dig up > the draft and even then it did not address all of the holes and it > focused too much on the MIP stuff. There also a draft on AAA and what > that solved but this lead to the universal AAA issues. So I think what > we need is an informational due diligence draft specific to the DDoS > threats of the IPv6 stand-alone base (i.e. no MIP, no AAA). > > > > Sorry about the mix-up. > > > > Glenn > > > > > > > > -----Original Message----- > From: Morrow, Glenn [RICH2:C330:EXCH] > Sent: Thursday, December 13, 2001 1:29 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Routing header Vs tunneling > > Thank You > > > -----Original Message----- > > From: Pekka Savola [mailto:pekkas@netcore.fi] > > Sent: Thursday, December 13, 2001 2:58 AM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: RE: [mobile-ip] Routing header Vs tunneling > > > > > > On Tue, 11 Dec 2001, Glenn Morrow wrote: > > > > > What prevents a node from obtaining and using any number of > > free or not free > > > (i.e. in use by another legitimate node) IP addresses such > > that they can > > > spoof addresses albeit only on the same subnet IF INGRESS > > FILTERING is used > > > on the first hop. Use of IPSEC is not mandated. Use of > > INGRESS FILTERING is > > > not mandated, either. What is the interaction with control > > lists, etc.. > > > etc.. etc.. Are there any provisions for anti-mac-spoofing, > > etc.. etc.. > > > etc.. Pekka's draft which detailed most of the holes has > > expired, perhaps he > > > is listening and will republish it. > > > > A new revision was issued: > > > > http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-se > curity-01.txt > > Thanks. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 17 09:25: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 JAA02829 for ; Mon, 17 Dec 2001 09:25:14 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28753; Mon, 17 Dec 2001 07:23:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11110; Mon, 17 Dec 2001 06:23:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHEMcFp009423 for ; Mon, 17 Dec 2001 06:22:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHEMcZ2009422 for mobile-ip-dist; Mon, 17 Dec 2001 06:22:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHEMYFp009415 for ; Mon, 17 Dec 2001 06:22:35 -0800 (PST) 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 GAA26002 for ; Mon, 17 Dec 2001 06:22:37 -0800 (PST) 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 GAA26181 for ; Mon, 17 Dec 2001 06:22:36 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02694; Mon, 17 Dec 2001 09:22:32 -0500 (EST) Message-Id: <200112171422.JAA02694@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-02.txt Date: Mon, 17 Dec 2001 09:22:32 -0500 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SUCV Identifiers and Addresses Author(s) : G. Montenegro, C. Castelluccia Filename : draft-montenegro-sucv-02.txt Pages : 28 Date : 14-Dec-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-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-montenegro-sucv-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-montenegro-sucv-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: <20011214140011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-sucv-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-sucv-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011214140011.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 17 14: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 OAA15028 for ; Mon, 17 Dec 2001 14:01:20 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26537; Mon, 17 Dec 2001 11:59:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05585; Mon, 17 Dec 2001 11:00:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHIxJFp009814 for ; Mon, 17 Dec 2001 10:59:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHIxJkK009813 for mobile-ip-dist; Mon, 17 Dec 2001 10:59:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHIxGFp009806 for ; Mon, 17 Dec 2001 10:59:16 -0800 (PST) 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 KAA03485 for ; Mon, 17 Dec 2001 10:59:17 -0800 (PST) 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 KAA26155 for ; Mon, 17 Dec 2001 10:59:16 -0800 (PST) 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 fBHJ0SQ21076 for ; Mon, 17 Dec 2001 13:00:28 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 17 Dec 2001 12:59:16 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 17 Dec 2001 12:59:16 -0600 content-class: urn:content-classes:message Subject: [mobile-ip] Discussion slides of MIP WG at IETF52 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 17 Dec 2001 12:58:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Message-ID: <697DAA22C5004B4596E033803A7CEF444CD283@daebe007.NOE.Nokia.com> Thread-Topic: Discussion slides of MIP WG at IETF52 Thread-Index: AcGHLOxyW3FuofMUEdWxawAAhj/HZA== From: "Patil Basavaraj (NET/Dallas)" To: "'Mobile IP'" X-OriginalArrivalTime: 17 Dec 2001 18:59:16.0189 (UTC) FILETIME=[ECA8F0D0:01C1872C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBHIxGFp009807 Sender: owner-mobile-ip@sunroof.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 http://people.nokia.net/~patil/IETF52/MIP/ -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 17 14:42: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 OAA16142 for ; Mon, 17 Dec 2001 14:42:30 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27611; Mon, 17 Dec 2001 11:41:24 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09179; Mon, 17 Dec 2001 11:41:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHJeWFp009928 for ; Mon, 17 Dec 2001 11:40:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHJeW2Y009927 for mobile-ip-dist; Mon, 17 Dec 2001 11:40:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHJeTFp009920 for ; Mon, 17 Dec 2001 11:40:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03154 for ; Mon, 17 Dec 2001 11:40:30 -0800 (PST) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19448 for ; Mon, 17 Dec 2001 12:40:29 -0700 (MST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id OAA13793 for ; Mon, 17 Dec 2001 14:40:28 -0500 (EST) From: "Subrata Goswami" To: Subject: [mobile-ip] icmpv6 Date: Mon, 17 Dec 2001 11:44:33 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <697DAA22C5004B4596E033803A7CEF444CD283@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 this may not be an appropriate question for this group, although it impacts mobile-ip indirectly. on going through the ICMPv6 , we noticed that the Link-Layer Options in Neighbor Discovery Protocol(rfc 2461) may not support the 64-bit IEEE-EUI address. although it can be easily resolved placing 6 bytes of padding with length=2. subrata From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 17 16:14:17 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18451 for ; Mon, 17 Dec 2001 16:14:17 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29993; Mon, 17 Dec 2001 14:12:34 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29377; Mon, 17 Dec 2001 13:12:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLBNFp010073 for ; Mon, 17 Dec 2001 13:11:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHLBNGS010072 for mobile-ip-dist; Mon, 17 Dec 2001 13:11:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLBKFp010065 for ; Mon, 17 Dec 2001 13:11:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29100 for ; Mon, 17 Dec 2001 13:11:08 -0800 (PST) Received: from web11002.mail.yahoo.com (web11002.mail.yahoo.com [216.136.131.52]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA00820 for ; Mon, 17 Dec 2001 14:11:08 -0700 (MST) Message-ID: <20011217211107.89953.qmail@web11002.mail.yahoo.com> Received: from [130.207.231.77] by web11002.mail.yahoo.com via HTTP; Mon, 17 Dec 2001 13:11:07 PST Date: Mon, 17 Dec 2001 13:11:07 -0800 (PST) From: Vasos Vassiliou Subject: [mobile-ip] BU piggybacking To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <20011211232229.80286.qmail@web11002.mail.yahoo.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: I am not sure if this was addressed before in this list, so forgive me if I am repeating things... and please point me to the relevant discussion. Besides piggybacking a BU to packets towrds the HA and the CNs every time a MN moves or when the BU lifetime expires. Can we also piggyback a BU on the first packet sent to a CN for which the MN does not have an entry in its Binding Update List? Thanks Vasos Vassiliou Georgia Tech __________________________________________________ Do You Yahoo!? Check out Yahoo! Shopping and Yahoo! Auctions for all of your unique holiday gifts! Buy at http://shopping.yahoo.com or bid at http://auctions.yahoo.com From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 17 16:35: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 QAA19586 for ; Mon, 17 Dec 2001 16:35:29 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16214; Mon, 17 Dec 2001 13:34:16 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26338; Mon, 17 Dec 2001 13:34:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLXQFp010237 for ; Mon, 17 Dec 2001 13:33:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBHLXP0X010236 for mobile-ip-dist; Mon, 17 Dec 2001 13:33:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHLXLFp010229 for ; Mon, 17 Dec 2001 13:33:22 -0800 (PST) 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 NAA14242 for ; Mon, 17 Dec 2001 13:33:24 -0800 (PST) From: Internet-Drafts@ietf.org Received: from NEXUS.replicants.org.uk ([212.56.122.201]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19823 for ; Mon, 17 Dec 2001 13:33:18 -0800 (PST) Received: from mail pickup service by NEXUS.replicants.org.uk with Microsoft SMTPSVC; Mon, 17 Dec 2001 21:33:08 +0000 X-From_: ietf-123-owner@loki.ietf.org Mon Dec 17 17:32:21 2001 Envelope-to: david@REPLICANTS.FREESERVE.CO.UK Delivery-date: Mon, 17 Dec 2001 17:32:21 +0000 Received: from [132.151.1.177] (helo=loki.ietf.org) by imailg2b.svr.pol.co.uk with esmtp (Exim 3.33 #1) id 16G1cj-0007OZ-00; Mon, 17 Dec 2001 17:32:21 +0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id LAA03602 for ietf-123-outbound.10@ietf.org; Mon, 17 Dec 2001 11:35:02 -0500 (EST) 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 JAA02126 for ; Mon, 17 Dec 2001 09:22:36 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02694; Mon, 17 Dec 2001 09:22:32 -0500 (EST) Message-Id: <200112171422.JAA02694@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] I-D ACTION:draft-montenegro-sucv-02.txt Date: Mon, 17 Dec 2001 09:22:32 -0500 X-OriginalArrivalTime: 17 Dec 2001 21:33:08.0506 (UTC) FILETIME=[6B8CB7A0:01C18742] Sender: owner-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-02.txt Pages : 28 Date : 14-Dec-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-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-montenegro-sucv-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-montenegro-sucv-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: <20011214140011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montenegro-sucv-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-montenegro-sucv-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-dra" --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 17 21:38: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 VAA24615 for ; Mon, 17 Dec 2001 21:38:57 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04060; Mon, 17 Dec 2001 19:37:27 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02026; Mon, 17 Dec 2001 18:37:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI2ZFFp010889 for ; Mon, 17 Dec 2001 18:35:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBI2ZFXa010888 for mobile-ip-dist; Mon, 17 Dec 2001 18:35:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI2ZDFp010881 for ; Mon, 17 Dec 2001 18:35:13 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA15693 for ; Mon, 17 Dec 2001 21:35:15 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id VAA04499 for mobile-ip@sunroof.eng.sun.com; Mon, 17 Dec 2001 21:35:52 -0500 (EST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBEIo6Fp006117 for ; Fri, 14 Dec 2001 10:50:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12088 for ; Fri, 14 Dec 2001 10:50:09 -0800 (PST) Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16364 for ; Fri, 14 Dec 2001 11:50:08 -0700 (MST) Received: from yasmine.ece.arizona.edu (yasmine [128.196.28.123]) by tiquini.ece.arizona.edu (8.11.0.Beta3/8.11.0.Beta3) with ESMTP id fBEIo8n26641 for ; Fri, 14 Dec 2001 11:50:08 -0700 (MST) Received: (from krunz@localhost) by yasmine.ece.arizona.edu (8.10.2+Sun/8.10.2) id fBEIrDF26605 for mobile-ip@sunroof.eng.sun.com; Fri, 14 Dec 2001 11:53:13 -0700 (MST) Date: Fri, 14 Dec 2001 11:53:13 -0700 (MST) Message-Id: <200112141853.fBEIrDF26605@yasmine.ece.arizona.edu> From: krunz@ece.arizona.edu To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] CFP - Mobicom 2002 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: [Appologies if you receive multiple copies of this Call for Papers ] ********************************************************************* Call for Papers *** ACM MobiCom 2002 *** The Eighth Annual International Conference on Mobile Computing and Networking September 23-26, 2002 Westin Peachtree Plaza Atlanta, Georgia, USA http://www.acm.org/sigmobile/mobicom/2002/ Sponsored by ACM SIGMOBILE Submission Deadline: March 1, 2002 ********************************************************************* MobiCom 2002 is the eighth annual conference dedicated to addressing new challenges in mobile computing and networking. MobiCom 2002 solicits papers describing significant research contributions to the field of mobile computing and networking. PAPERS: Authors are invited to submit full papers related to the theory and practice of mobile computing and networking. Original research papers (that are not currently under review by another conference or journal) are solicited. Areas of interest include, but not limited to: * Applications and computing services supporting mobile users * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Database and data management issues in mobile computing * Performance of mobile/wireless networks and systems * Security and privacy of mobile/wireless systems * Interaction between different layers of mobile/wireless systems * Integration and interworking of wired and wireless networks * Adaptive applications and systems for mobile environments * Distributed-system aspects of mobile systems * Operating system support for mobility * Location-dependent applications * Wireless multimedia systems * Power management * Mobile agents * Pervasive computing * Wireless sensor networks * Wireless/mobile service management and delivery All papers will be refereed by the program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks (WINET) and Mobile Networks and Applications (MONET) journals. CHALLENGES SESSION: Short papers (maximum of 8 pages) that challenge the mobile computing community with new technologies or visionary applications are solicited. Such papers should provide stimulating ideas or visions that may open up exciting avenues of mobile computing research. Papers will be reviewed and should be submitted using the normal submission procedure. Submitted papers should be clearly identified as intended for the Challenges Session. SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their full paper. Papers must meet the following restrictions: - No longer than 12 pages (double column); in font no smaller than 10 points - Fit properly on US Letter-sized paper (8.5 ' 11 inches) with reasonable margins - PostScript version 2 or later, or Portable Document Format (PDF) - Use only Computer Modern or standard Adobe printer fonts (i.e., Courier,Times, Roman, or Helvetica) - Other fonts may be used, but must be included in the PostScript/PDF file Instructions for submission are available at: http://www.acm.org/sigmobile/mobicom/2002/submissions/ All submitted papers will be judged based on their quality through double-blind reviewing, where the identities of the authors are withheld from the reviewers. Authors' names must not appear in the paper or in the PostScript or PDF file. Submitted papers must not be currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. TUTORIALS: Proposals for tutorials are solicited, and will be evaluated based on the expertise of the instructors and the relevance of the subject matter. Potential instructors should submit a tutorial proposal of at most five pages, including a biographical sketch, to the Tutorial Co-chairs (cath@ecn.purdue.edu or nhv@crhc.uiuc.edu). PANELS: Proposals are solicited for panels that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-chairs (shroff@ecn.purdue.edu or marie-jose.montpetit@nokia.com). RESEARCH DEMOS: Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of the demo and equipment that will be used. Proposals for demos should be sent to the Research Demo Chair (ron@oit.gatech.edu). BEST STUDENT PAPER AWARD: Papers with a student as the primary author will be considered for the Best Student Paper Award with a cash award of $1,000 USD. Students must indicate with their submissions that they would like to be considered for this award. IMPORTANT DATES: * Paper submissions due: March 1, 2002 * Notification of acceptance: June 30, 2002 * Camera-ready version due: July 31, 2002 FOR MORE INFORMATION: Check the conference website or send email to mobicom2002@comet.columbia.edu ORGANIZING COMMITTEE: * General Chair: Ian F. Akyildiz, Georgia Institute of Technology * General Vice-Chairs: - Jason Y. B. Lin, National Chiao Tung University - Ravi Jain, Telcordia * Program Co-Chairs: - Vaduvur Bharghavan, Bytemobile - Andrew T. Campbell, Columbia University * Panels Co-Chairs: - Ness Shroff, Purdue University - Marie-Jose Montpetit, Nokia * Tutorials Co-Chairs: - Catherine Rosenberg, Purdue University - Nitin Vaidya, University of Illinois at Urbana Champaign * Publicity Co-Chairs: - Chuanyi Ji, Georgia Institute of Technology - Marwan M. Krunz, University of Arizona * Workshop Co-Chairs: - Taieb Znati, NSF and University of Pittsburgh - Mehmet Ulema, Monmouth Internet Corporation * Research Demos Chair: Ron Hutchins, Georgia Institute of Technology * Finance Chair: Edward Knightly, Rice University * Registration Chair: Suresh Singh, Portland State University * Sponsorship/Exhibit Chair: Ramesh Govindan, Univ. of Southern California * Local Arrangements Chair: Raghupathy Sivakumar: Georgia Institute of Technology * Steering Committee Chair: Imrich Chlamtac, University of Texas at Dallas From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 17 21:40:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24656 for ; Mon, 17 Dec 2001 21:40:15 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04628; Mon, 17 Dec 2001 19:38:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA02274; Mon, 17 Dec 2001 18:39:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI2cRFp010936 for ; Mon, 17 Dec 2001 18:38:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBI2cQTQ010935 for mobile-ip-dist; Mon, 17 Dec 2001 18:38:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBI2cOFp010926 for ; Mon, 17 Dec 2001 18:38:25 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10316 for ; Mon, 17 Dec 2001 21:38:27 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id VAA04569 for mobile-ip@sunroof.eng.sun.com; Mon, 17 Dec 2001 21:39:03 -0500 (EST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBHCh4Fp009184 for ; Mon, 17 Dec 2001 04:43:04 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA00643 for ; Mon, 17 Dec 2001 04:43:06 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24260 for ; Mon, 17 Dec 2001 05:43:05 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id FAA16633 for ; Mon, 17 Dec 2001 05:43:05 -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 FAA07330 for ; Mon, 17 Dec 2001 05:32:50 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r2.mot.com with ESMTP for mobile-ip@sunroof.eng.sun.com; Mon, 17 Dec 2001 06:43:03 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 273822EC83 for ; Mon, 17 Dec 2001 13:41:43 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] re-announcement of monet mailing list From: Alexandru Petrescu Date: 17 Dec 2001 12:40:06 +0100 Message-Id: Lines: 78 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, At the end of the bar bof on Mobile Networks at Salt Lake it was suggested to re-send the information on how to join the monet mailing list. In order to join, please send mail to monet-request@crm.mot.com with subscribe in the body. An archive file is kept locally but not yet available publicly. Until becoming available I can send it personally to anyone interested. Thank you, Alex PS: here's the original announcement sent earlier. Dear colleagues, I would like to announce the monet (mobile network) mailing list for future discussion of the mobile networks subject. Until the last IETF meeting, Thierry Ernst has submitted several times I-Ds and made presentations on the subject. At IETF-51, I was encouraged by the mobileip WG co-chair Phil Roberts to set up a separate mailing list to further discuss the subject. Since then, there has been some discussions online and offline, to the extent that a BOF may be on its way to address the subject. Having sensed the need to have a proper forum of discussion on mobile network, the Monet mailing list is created, so that we could discuss and share: - work out the problem scope/statement - define terminology - technical discussions - define the solution requirements - plan the necessary activities - how to address the subject in IETF (creation of a BOF?) - etc To start with, I would like to put forward the following 2 I-Ds: - draft-ernst-mobileip-v6-network-02.txt - draft-ernst-mobileip-monetv6-00.txt In particular I would like to solicit comments on draft-ernst-mobileip-monetv6-00.txt about the problem scope and solution requirements. After London IETF a long discussion took place on the mobileip list with respect to mobile networks and routers: terminology for "router" and "mobile router", MR and router adjacency, interactions of mobile networks with routing protocols, multiple Care-of-Addresses, mobile routers as NAT's, tunnelling and routing headers, security aspects, mobile networks as PANs and many other subjects. Several solutions could be designed as a result of those discussions. Besides, I would also like to gather your ideas and comments on the creation of a monet BOF. I am looking forward to your participation in the monet mailing list discussion. Subscribe to the monet mailing list by sending mail to monet-request@crm.mot.com with the word "subscribe" (without the quotes) in the body. You need to subscribe to the list in order to send to the list. You can post to the list by sending mail to monet@crm.mot.com. Unsubscribe by sending mail to monet-request@crm.mot.com with the two words "unsubscribe monet" (again without the quotes) in the body. Cheers, Hong-Yon Lach Alexandru Petrescu Christophe Janneteau John Boot From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 18 06:25: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 GAA17122 for ; Tue, 18 Dec 2001 06:25:15 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25682; Tue, 18 Dec 2001 04:23:48 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23861; Tue, 18 Dec 2001 03:24:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIBNNFp011680 for ; Tue, 18 Dec 2001 03:23:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBIBNNIf011679 for mobile-ip-dist; Tue, 18 Dec 2001 03:23:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIBNKFp011672 for ; Tue, 18 Dec 2001 03:23:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29352 for ; Tue, 18 Dec 2001 03:23:20 -0800 (PST) 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 EAA25251 for ; Tue, 18 Dec 2001 04:23:01 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBIBNHI10598 for ; Tue, 18 Dec 2001 12:23:17 +0100 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 MAA25609 for ; Tue, 18 Dec 2001 12:23:17 +0100 (MET) 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 fBIBNHD53987 for ; Tue, 18 Dec 2001 12:23:17 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112181123.fBIBNHD53987@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] icmpv6 In-reply-to: Your message of Mon, 17 Dec 2001 11:44:33 PST. Date: Tue, 18 Dec 2001 12:23:17 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: this may not be an appropriate question for this group, although it impacts mobile-ip indirectly. on going through the ICMPv6 , we noticed that the Link-Layer Options in Neighbor Discovery Protocol(rfc 2461) may not support the 64-bit IEEE-EUI address. => this is false: link-layer options support any kind of link-layer addresses. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 18 19:14: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 TAA01274 for ; Tue, 18 Dec 2001 19:14:49 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16347; Tue, 18 Dec 2001 16:51:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14270; Tue, 18 Dec 2001 15:52:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBINpIFp012826 for ; Tue, 18 Dec 2001 15:51:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBINpIE2012825 for mobile-ip-dist; Tue, 18 Dec 2001 15:51:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBINpFFp012818 for ; Tue, 18 Dec 2001 15:51:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18786 for ; Tue, 18 Dec 2001 15:51:16 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01058 for ; Tue, 18 Dec 2001 16:51:15 -0700 (MST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Tue, 18 Dec 2001 18:46:46 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] WG Feedback Requested Date: Tue, 18 Dec 2001 18:46:43 -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: I'd like to get working group feedback on the low latency draft and part of the route optimization draft. First, how urgent is the need for the low latency draft to become an RFC? I was rather disappointed to see that only a few people are planning on implementing any part of this. Given that, it's hard for me to see whether there is any urgency at all. Second, it was proposed that PFANE from the RO draft might be stripped into a separate draft to accelerate progress on low latency. The background issue here is that the chairs (well, me) have sat on the route optimization draft pending some resolution of the route optimization issues for MIPv6. I'd like to have some feedback about the RO draft, so could you please comment on whether you are actually going to use any part of route optimization (other than PFANE), and whether you'd like to push me to go ahead and send route optimization for v4 to the IESG before the MIPv6 issues are resolved. Route optimization completed WG last call sometime before March of this year. Phil From owner-mobile-ip@sunroof.eng.sun.com Tue Dec 18 21:22: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 VAA03486 for ; Tue, 18 Dec 2001 21:22:22 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA27958; Tue, 18 Dec 2001 07:57:12 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00066; Tue, 18 Dec 2001 07:57:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIFuIFp012031 for ; Tue, 18 Dec 2001 07:56:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2/Submit) id fBIFuI2l012030 for mobile-ip-dist; Tue, 18 Dec 2001 07:56:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta2+Sun/8.12.2.Beta2) with ESMTP id fBIFuEFp012023 for ; Tue, 18 Dec 2001 07:56:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28351 for ; Tue, 18 Dec 2001 07:56:15 -0800 (PST) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17656 for ; Tue, 18 Dec 2001 08:55:56 -0700 (MST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id KAA28882 for ; Tue, 18 Dec 2001 10:52:51 -0500 (EST) From: "Subrata Goswami" To: Subject: RE: [mobile-ip] icmpv6 Date: Tue, 18 Dec 2001 07:57:16 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <200112181123.fBIBNHD53987@givry.rennes.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: Content-Transfer-Encoding: 7bit well, how do you make a 64 bit address in accordance with the following in RFC 2461 ? 4.6.1. Source/Target Link-layer Address 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 | Link-Layer Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type 1 for Source Link-layer Address 2 for Target Link-layer Address Length The length of the option (including the type and length fields) in units of 8 octets. For example, the length for IEEE 802 addresses is 1 [IPv6- ETHER]. Link-Layer Address The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. For instance, [IPv6-ETHER]. -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Francis Dupont Sent: Tuesday, December 18, 2001 3:23 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] icmpv6 this may not be an appropriate question for this group, although it impacts mobile-ip indirectly. on going through the ICMPv6 , we noticed that the Link-Layer Options in Neighbor Discovery Protocol(rfc 2461) may not support the 64-bit IEEE-EUI address. => this is false: link-layer options support any kind of link-layer addresses. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 04:22: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 EAA26120 for ; Wed, 19 Dec 2001 04:22:01 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12223; Wed, 19 Dec 2001 02:20:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24593; Wed, 19 Dec 2001 01:20:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJ9JnZR013656 for ; Wed, 19 Dec 2001 01:19:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJ9JnRs013655 for mobile-ip-dist; Wed, 19 Dec 2001 01:19:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJ9JjZR013648 for ; Wed, 19 Dec 2001 01:19:45 -0800 (PST) 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 BAA06200 for ; Wed, 19 Dec 2001 01:19:46 -0800 (PST) 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 BAA24633 for ; Wed, 19 Dec 2001 01:19:45 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBJ9JhI21222 for ; Wed, 19 Dec 2001 10:19:43 +0100 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 KAA15955 for ; Wed, 19 Dec 2001 10:19:43 +0100 (MET) 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 fBJ9JgD57186 for ; Wed, 19 Dec 2001 10:19:42 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112190919.fBJ9JgD57186@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] icmpv6 In-reply-to: Your message of Tue, 18 Dec 2001 07:57:16 PST. Date: Wed, 19 Dec 2001 10:19:42 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: well, how do you make a 64 bit address in accordance with the following in RFC 2461 ? => the answer is in your mail (I apologize because I have to keep this long message :-). 4.6.1. Source/Target Link-layer Address 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 | Link-Layer Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type 1 for Source Link-layer Address 2 for Target Link-layer Address Length The length of the option (including the type and length fields) in units of 8 octets. For example, the length for IEEE 802 addresses is 1 [IPv6- ETHER]. Link-Layer Address The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. For instance, [IPv6-ETHER]. => read, reread, etc the link-layer address definition. BTW I don't know a link-layer using EUI 64 as addresses (but there already are more complex link-layers, for instance ATM). If your concern is padding, look at RFC 2529. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 06:45: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 GAA27179 for ; Wed, 19 Dec 2001 06:45:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08683; Wed, 19 Dec 2001 04:44:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15960; Wed, 19 Dec 2001 03:44:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJBi7ZR013948 for ; Wed, 19 Dec 2001 03:44:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJBi7mG013947 for mobile-ip-dist; Wed, 19 Dec 2001 03:44:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJBi2ZR013940 for ; Wed, 19 Dec 2001 03:44:03 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA19244 for ; Wed, 19 Dec 2001 03:44:03 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12383 for ; Wed, 19 Dec 2001 04:44:02 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBJBi1J07034 for ; Wed, 19 Dec 2001 12:44:01 +0100 (MET) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Dec 19 12:44:01 2001 +0100 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 12:43:46 +0100 Message-ID: From: "Peter Grimstrup (TED)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Prefix lifetime Date: Wed, 19 Dec 2001 12:43:45 +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: I'm not very familiar with the ND procedures, but anyway here is my question: Section 9.1 in ID-15 says: "The lifetime for the each Binding Cache entry MUST NOT be greater than the minimum remaining valid lifetime for all subnet prefixes on the mobile node's home link." When a prefix is no longer to be used, the lifetime is decreased eventually to zero, when the prefix is removed. While decreasing the lifetime, i.e. when the value has become "low", it doesn't seem reasonable to use this value as limit on granted lifetime of a BU. Could this be avoided by only minimising over prefixes with nonzero preferred lifetime - or have I misunderstood? Thanks Peter ---------------------------------------------------------------- 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 Dec 19 10:19:53 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29270 for ; Wed, 19 Dec 2001 10:19:52 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25974; Wed, 19 Dec 2001 07:18:45 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12060; Wed, 19 Dec 2001 07:18:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJFHPZR014272 for ; Wed, 19 Dec 2001 07:17:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJFHPgZ014271 for mobile-ip-dist; Wed, 19 Dec 2001 07:17:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJFHKZR014261 for ; Wed, 19 Dec 2001 07:17:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00922 for ; Wed, 19 Dec 2001 07:17:21 -0800 (PST) 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 IAA07599 for ; Wed, 19 Dec 2001 08:18:07 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBJFHIJ18464 for ; Wed, 19 Dec 2001 16:17:19 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Dec 19 16:17:17 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 16:17:18 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEE4D@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 16:17:00 +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: > I'd like to get working group feedback on the low latency draft and > part of the route optimization draft. > > First, how urgent is the need for the low latency draft to > become an RFC? > I was rather disappointed to see that only a few people are > planning on > implementing any part of this. Given that, it's hard for me > to see whether > there is any urgency at all. IMO unless we finish the work off people won't have a chance to see if it fits their requirements. Until we have an RFC we can't really say IETF has a stable solution for low latency MIPv4 handoffs which people can implement and try out. Early implementation is useful but few implementations doesn't mean it shouldn't make it to RFC. We also need to consider that low latency is closely knit to wireless (through L2 triggers and their timing) which makes the real implementation harder than many other drafts. > > Second, it was proposed that PFANE from the RO draft might > be stripped > into a separate draft to accelerate progress on low latency. The previous FA extension has no relation to the low latency draft. In fact the PFANE is sent by the MN along with the registration request when it has attached to the new FA and is completing the L3 handoff. The low latency solutions aim at reducing L3 handoff latency to zero, which means that the MN must be in communication as soon as it attaches to the new FA. /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 10:38: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 KAA29629 for ; Wed, 19 Dec 2001 10:38:25 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24313; Wed, 19 Dec 2001 08:37:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14961; Wed, 19 Dec 2001 07:37:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJFafZR014492 for ; Wed, 19 Dec 2001 07:36:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJFafjo014491 for mobile-ip-dist; Wed, 19 Dec 2001 07:36:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJFacZR014484 for ; Wed, 19 Dec 2001 07:36:38 -0800 (PST) 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 HAA16297 for ; Wed, 19 Dec 2001 07:36:39 -0800 (PST) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18515 for ; Wed, 19 Dec 2001 07:36:38 -0800 (PST) Received: from sgoswamipcl (dsl-65-184-63-5.telocity.com [65.184.63.5]) by changeofhabit.mr.itd.umich.edu (8.9.3/3.2r) with SMTP id KAA01368 for ; Wed, 19 Dec 2001 10:36:37 -0500 (EST) From: "Subrata Goswami" To: Subject: RE: [mobile-ip] icmpv6 Date: Wed, 19 Dec 2001 07:40:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <200112190919.fBJ9JgD57186@givry.rennes.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: Content-Transfer-Encoding: 7bit sorry, i still do not understand what you are trying to say. consider the following 0x01:0xY:0xAAAAAAAA questions are: 1. what is the value of Y ? 2. If it is 2 then where and what padding do you add ? subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Francis Dupont Sent: Wednesday, December 19, 2001 1:20 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] icmpv6 In your previous mail you wrote: well, how do you make a 64 bit address in accordance with the following in RFC 2461 ? => the answer is in your mail (I apologize because I have to keep this long message :-). 4.6.1. Source/Target Link-layer Address 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 | Link-Layer Address ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type 1 for Source Link-layer Address 2 for Target Link-layer Address Length The length of the option (including the type and length fields) in units of 8 octets. For example, the length for IEEE 802 addresses is 1 [IPv6- ETHER]. Link-Layer Address The variable length link-layer address. The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. For instance, [IPv6-ETHER]. => read, reread, etc the link-layer address definition. BTW I don't know a link-layer using EUI 64 as addresses (but there already are more complex link-layers, for instance ATM). If your concern is padding, look at RFC 2529. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 11:02:24 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 LAA00522 for ; Wed, 19 Dec 2001 11:02:24 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12842; Wed, 19 Dec 2001 09:00:48 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19255; Wed, 19 Dec 2001 08:01:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJG0KZR014632 for ; Wed, 19 Dec 2001 08:00:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJG0KNS014631 for mobile-ip-dist; Wed, 19 Dec 2001 08:00:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJG0HZR014624 for ; Wed, 19 Dec 2001 08:00:17 -0800 (PST) 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 IAA06691 for ; Wed, 19 Dec 2001 08:00:18 -0800 (PST) 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 IAA24232 for ; Wed, 19 Dec 2001 08:00:18 -0800 (PST) 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 fBJG1VQ29420 for ; Wed, 19 Dec 2001 10:01:31 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 19 Dec 2001 10:00:17 -0600 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 19 Dec 2001 10:00:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message Subject: RE: [mobile-ip] WG Feedback Requested MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 19 Dec 2001 10:00:13 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF440968BD@daebe007.NOE.Nokia.com> Thread-Topic: [mobile-ip] WG Feedback Requested Thread-Index: AcGII4kHTAe/APQWEdWJXAAIx6TWpQAfRo+A From: "Patil Basavaraj (NET/Dallas)" To: X-OriginalArrivalTime: 19 Dec 2001 16:00:13.0021 (UTC) FILETIME=[3E0F18D0:01C188A6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fBJG0HZR014625 Sender: owner-mobile-ip@sunroof.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 One possbility is to consider making the low-latency draft an experimental RFC. That will give implementers an opportunity to work with a spec that is "relatively" stable while discovering issues. We could take it to proposed standard once we have a better understanding of the low-latency implementations for MIPv4. -Basavaraj > > I'd like to get working group feedback on the low latency draft and > part of the route optimization draft. > > First, how urgent is the need for the low latency draft to > become an RFC? > I was rather disappointed to see that only a few people are > planning on > implementing any part of this. Given that, it's hard for me > to see whether > there is any urgency at all. > > Second, it was proposed that PFANE from the RO draft might be stripped > into a separate draft to accelerate progress on low latency. > The background > issue here is that the chairs (well, me) have sat on the > route optimization > draft pending some resolution of the route optimization > issues for MIPv6. > I'd like to have some feedback about the RO draft, so could you please > comment > on whether you are actually going to use any part of route > optimization > (other > than PFANE), and whether you'd like to push me to go ahead > and send route > optimization for v4 to the IESG before the MIPv6 issues are > resolved. Route > optimization completed WG last call sometime before March of > this year. > > Phil > From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 11:48: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 LAA01460 for ; Wed, 19 Dec 2001 11:48:12 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07857; Wed, 19 Dec 2001 08:43:29 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27934; Wed, 19 Dec 2001 08:42:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJGg0ZR014846 for ; Wed, 19 Dec 2001 08:42:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJGg0Em014845 for mobile-ip-dist; Wed, 19 Dec 2001 08:42:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJGfvZR014838 for ; Wed, 19 Dec 2001 08:41:57 -0800 (PST) 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 IAA27767 for ; Wed, 19 Dec 2001 08:41:59 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11581 for ; Wed, 19 Dec 2001 08:41:59 -0800 (PST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 11:41:55 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB890@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 11:41:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Karim Comments inline... -----Original Message----- From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] Sent: Wednesday, December 19, 2001 3:17 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] WG Feedback Requested IMO unless we finish the work off people won't have a chance to see if it fits their requirements. Until we have an RFC we can't really say IETF has a stable solution for low latency MIPv4 handoffs which people can implement and try out. Early implementation is useful but few implementations doesn't mean it shouldn't make it to RFC. We also need to consider that low latency is closely knit to wireless (through L2 triggers and their timing) which makes the real implementation harder than many other drafts. GT> I think that the community has been overwhelmed by the MIPv6 security discussion and has reviewed the fast handoff specs very little. Also these specs are full of new mechanisms...some of them very complex. Fast handoffs are also "optimizations" and as Eric N. said recently, IETF is not very good at producing optimization techniques. Even worst, parts of the fast handoff specs are about optimizing the optimization...see Handoff To Third (HTT)....what about the Forth, Fifth and Hundredth? What I am saying is that the IETF must be very careful and rather conservative in this standardization effort. Peer review and experimentation is needed here more than anywhere. > > Second, it was proposed that PFANE from the RO draft might > be stripped > into a separate draft to accelerate progress on low latency. The previous FA extension has no relation to the low latency draft. GT> This is true. In fact the PFANE is sent by the MN along with the registration request when it has attached to the new FA and is completing the L3 handoff. The low latency solutions aim at reducing L3 handoff latency to zero, which means that the MN must be in communication as soon as it attaches to the new FA. GT> The point is though that PFANE extension has been very stable for long time and provides lossless handoff that can be used in the short term and until either fast handoffs mature or link layers get make before break capability...in which case fast handoff specs are not needed. The only reason PFANEs are not a standard today is because they are part of the Route Optimization draft that is notionaly kept behind because of the MIPv6 security discussion. Yet PFANEs have no security issue themselves...hence the discussion about publishing them independently of Routing Optimization. Regards George From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 12:11: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 MAA01883 for ; Wed, 19 Dec 2001 12:11:51 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21522; Wed, 19 Dec 2001 09:10:09 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06536; Wed, 19 Dec 2001 09:09:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJH8JZR014982 for ; Wed, 19 Dec 2001 09:08:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJH8JKW014981 for mobile-ip-dist; Wed, 19 Dec 2001 09:08:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJH8GZR014974 for ; Wed, 19 Dec 2001 09:08:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04765 for ; Wed, 19 Dec 2001 09:08:18 -0800 (PST) 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 KAA28621 for ; Wed, 19 Dec 2001 10:09:04 -0700 (MST) 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 fBJH8GJ03425 for ; Wed, 19 Dec 2001 18:08:16 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Dec 19 17:04:53 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 16:56:35 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C154@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 17:04:52 +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: > One possbility is to consider making the low-latency draft an > experimental RFC. That will give implementers an opportunity to > work with a spec that is "relatively" stable while > discovering issues. > We could take it to proposed standard once we have a better > understanding of the low-latency implementations for MIPv4. => Certainly, that's a possibility, but the question is why ? I sure hope this wasn't due to the last presentation in SLC. It was already shown on the mailing list that the understanding of RFC2002 and the low latency draft were not correct in that implementation. I think the draft should move on, there is no need for more unnecessary delays. Hesham > > -Basavaraj > > > > > I'd like to get working group feedback on the low latency > draft and > > part of the route optimization draft. > > > > First, how urgent is the need for the low latency draft to > > become an RFC? > > I was rather disappointed to see that only a few people are > > planning on > > implementing any part of this. Given that, it's hard for me > > to see whether > > there is any urgency at all. > > > > Second, it was proposed that PFANE from the RO draft > might be stripped > > into a separate draft to accelerate progress on low latency. > > The background > > issue here is that the chairs (well, me) have sat on the > > route optimization > > draft pending some resolution of the route optimization > > issues for MIPv6. > > I'd like to have some feedback about the RO draft, so > could you please > > comment > > on whether you are actually going to use any part of route > > optimization > > (other > > than PFANE), and whether you'd like to push me to go ahead > > and send route > > optimization for v4 to the IESG before the MIPv6 issues are > > resolved. Route > > optimization completed WG last call sometime before March of > > this year. > > > > Phil > > > From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 12:41:16 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02418 for ; Wed, 19 Dec 2001 12:41:16 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02710; Wed, 19 Dec 2001 10:39:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15492; Wed, 19 Dec 2001 09:40:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJHdGZR015170 for ; Wed, 19 Dec 2001 09:39:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJHdFAw015169 for mobile-ip-dist; Wed, 19 Dec 2001 09:39:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJHdCZR015162 for ; Wed, 19 Dec 2001 09:39:12 -0800 (PST) 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 JAA25765 for ; Wed, 19 Dec 2001 09:39:15 -0800 (PST) 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 JAA15787 for ; Wed, 19 Dec 2001 09:39:13 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBJHdCJ03797 for ; Wed, 19 Dec 2001 18:39:12 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Dec 19 18:39:11 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 18:30:39 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEE4F@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 18:38:48 +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: > IMO unless we finish the work off people won't have a chance > to see if it fits their requirements. Until we have an RFC we > can't really say IETF has a stable solution for low latency > MIPv4 handoffs which people can implement and try out. Early > implementation is useful but few implementations doesn't > mean it shouldn't make it to RFC. We also need to consider that > low latency is closely knit to wireless (through L2 triggers and > their timing) which makes the real implementation harder than > many other drafts. > > GT> I think that the community has been overwhelmed by the > MIPv6 security > discussion and has reviewed the fast handoff specs very > little. Also these > specs are full of new mechanisms...some of them very > complex. Fast handoffs > are also "optimizations" and as Eric N. said recently, IETF > is not very good > at producing optimization techniques. Even worst, parts of > the fast handoff > specs are about optimizing the optimization...see Handoff To Third > (HTT)....what about the Forth, Fifth and Hundredth? What I > am saying is that > the IETF must be very careful and rather conservative in this > standardization effort. Peer review and experimentation is > needed here more > than anywhere. I agree that experimentation is useful. The point is that here experimentation is not easy since you need to make this work with your wireless L2, so we can't expect everyone to implement it or for it to fit all wireless systems. If there's no stable solution there's no chance wireless people will implement this, so it would be like going round in circles if we didn't finish this work. The lack of fast MIP handoff on most L2s (as you say those which do not allow the make-before-break where the MN talks both to oFA and nFA contemporarily) has been given as a problem of Mobile IP which we aim to solve in low latency. That's stated in the spec and is as far as this draft goes. Regarding the optimisations I agree things should be kept simple but so far people have not opposed things like HTT. By the way, HTT is a SHOULD for those wireless systems where the MN moves fast enough for it not to be able to register with nFA. It isn't needed for all cases. If you want to propose ways of simplifying the spec like removing HTT or other parts while keeping the basic functionality and the WG agrees I'm all for it. My point is that this doesn't justify putting low latency on hold. > In fact the PFANE is sent by the MN along with the registration > request when it has attached to the new FA and is completing the > L3 handoff. The low latency solutions aim at reducing L3 handoff > latency to zero, which means that the MN must be in communication > as soon as it attaches to the new FA. > > GT> The point is though that PFANE extension has been very > stable for long > time and provides lossless handoff that can be used in the > short term and > until either fast handoffs mature or link layers get make > before break > capability...in which case fast handoff specs are not > needed. The only > reason PFANEs are not a standard today is because they are > part of the Route > Optimization draft that is notionaly kept behind because of the MIPv6 > security discussion. Yet PFANEs have no security issue > themselves...hence > the discussion about publishing them independently of > Routing Optimization. I'm not against splitting PFANE from route opt. since I agree that it solves a different problem than generic route opt. However I can't agree with the argument that PFANE can be used for loss-less handoff on the way to a next step. PFANE in route opt is used after the MN has attached so that implies some latency/loss. I say we provide the necessary fast handoff tools and let people make their implementation choices. /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 12:45: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 MAA02505 for ; Wed, 19 Dec 2001 12:45:43 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06831; Wed, 19 Dec 2001 10:44:20 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16940; Wed, 19 Dec 2001 09:44:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJHhuZR015288 for ; Wed, 19 Dec 2001 09:43:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJHhusi015287 for mobile-ip-dist; Wed, 19 Dec 2001 09:43:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJHhrZR015280 for ; Wed, 19 Dec 2001 09:43:53 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26929 for ; Wed, 19 Dec 2001 09:43:55 -0800 (PST) Received: from mail11.speakeasy.net (mail11.speakeasy.net [216.254.0.211]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06209 for ; Wed, 19 Dec 2001 10:43:36 -0700 (MST) Received: (qmail 23963 invoked from network); 19 Dec 2001 17:43:53 -0000 Received: from unknown (HELO localhost) ([66.92.15.156]) (envelope-sender ) by mail11.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 19 Dec 2001 17:43:53 -0000 Date: Wed, 19 Dec 2001 09:43:55 -0800 Subject: Re: [mobile-ip] WG Feedback Requested Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v475) From: Jonathan Wood To: mobile-ip@sunroof.eng.sun.com Content-Transfer-Encoding: 7bit In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C154@Esealnt861.al.sw.ericsson.se> Message-Id: X-Mailer: Apple Mail (2.475) Sender: owner-mobile-ip@sunroof.eng.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 Wednesday, December 19, 2001, at 08:04 AM, Hesham Soliman (ERA) wrote: > => Certainly, that's a possibility, but the question > is why ? > I sure hope this wasn't due to the last presentation > in SLC. It was already shown on the mailing list > that the understanding of RFC2002 and the low > latency draft were not correct in that implementation. This has not been shown, either on the mailing list or elsewhere. > > I think the draft should move on, there is no need > for more unnecessary delays. > I agree that we need more implementation experience with these complex proposals. If we move the draft to proposed now, yes, more people will implement it, but only because they assume it's stable and well-understood, when that is not the case. Jonathan > Hesham > > >> >> -Basavaraj >> >>> >>> I'd like to get working group feedback on the low latency >> draft and >>> part of the route optimization draft. >>> >>> First, how urgent is the need for the low latency draft to >>> become an RFC? >>> I was rather disappointed to see that only a few people are >>> planning on >>> implementing any part of this. Given that, it's hard for me >>> to see whether >>> there is any urgency at all. >>> >>> Second, it was proposed that PFANE from the RO draft >> might be stripped >>> into a separate draft to accelerate progress on low latency. >>> The background >>> issue here is that the chairs (well, me) have sat on the >>> route optimization >>> draft pending some resolution of the route optimization >>> issues for MIPv6. >>> I'd like to have some feedback about the RO draft, so >> could you please >>> comment >>> on whether you are actually going to use any part of route >>> optimization >>> (other >>> than PFANE), and whether you'd like to push me to go ahead >>> and send route >>> optimization for v4 to the IESG before the MIPv6 issues are >>> resolved. Route >>> optimization completed WG last call sometime before March of >>> this year. >>> >>> Phil >>> >> > From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 12:55:18 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02714 for ; Wed, 19 Dec 2001 12:55:13 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14847; Wed, 19 Dec 2001 10:53:44 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16118; Wed, 19 Dec 2001 09:54:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJHrDZR015454 for ; Wed, 19 Dec 2001 09:53:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJHrDIv015453 for mobile-ip-dist; Wed, 19 Dec 2001 09:53:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJHrAZR015446 for ; Wed, 19 Dec 2001 09:53:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28946 for ; Wed, 19 Dec 2001 09:53:12 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA21893 for ; Wed, 19 Dec 2001 10:53:56 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 12:53:10 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB891@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 12:53: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: -----Original Message----- From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] Sent: Wednesday, December 19, 2001 5:39 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] WG Feedback Requested > IMO unless we finish the work off people won't have a chance > to see if it fits their requirements. Until we have an RFC we > can't really say IETF has a stable solution for low latency > MIPv4 handoffs which people can implement and try out. Early > implementation is useful but few implementations doesn't > mean it shouldn't make it to RFC. We also need to consider that > low latency is closely knit to wireless (through L2 triggers and > their timing) which makes the real implementation harder than > many other drafts. > > GT> I think that the community has been overwhelmed by the > MIPv6 security > discussion and has reviewed the fast handoff specs very > little. Also these > specs are full of new mechanisms...some of them very > complex. Fast handoffs > are also "optimizations" and as Eric N. said recently, IETF > is not very good > at producing optimization techniques. Even worst, parts of > the fast handoff > specs are about optimizing the optimization...see Handoff To Third > (HTT)....what about the Forth, Fifth and Hundredth? What I > am saying is that > the IETF must be very careful and rather conservative in this > standardization effort. Peer review and experimentation is > needed here more > than anywhere. I agree that experimentation is useful. The point is that here experimentation is not easy since you need to make this work with your wireless L2, so we can't expect everyone to implement it or for it to fit all wireless systems. If there's no stable solution there's no chance wireless people will implement this, so it would be like going round in circles if we didn't finish this work. The lack of fast MIP handoff on most L2s (as you say those which do not allow the make-before-break where the MN talks both to oFA and nFA contemporarily) has been given as a problem of Mobile IP which we aim to solve in low latency. That's stated in the spec and is as far as this draft goes. Regarding the optimisations I agree things should be kept simple but so far people have not opposed things like HTT. By the way, HTT is a SHOULD for those wireless systems where the MN moves fast enough for it not to be able to register with nFA. It isn't needed for all cases. If you want to propose ways of simplifying the spec like removing HTT or other parts while keeping the basic functionality and the WG agrees I'm all for it. GT> Yes I am saying that these specs are too big and complex to go through the standards process as they are...they need to be broken down but to do that we first need to figure out what is the basic functionality... My point is that this doesn't justify putting low latency on hold. GT> If we do break them down then clearly we have some work to do before we can push them forward. > In fact the PFANE is sent by the MN along with the registration > request when it has attached to the new FA and is completing the > L3 handoff. The low latency solutions aim at reducing L3 handoff > latency to zero, which means that the MN must be in communication > as soon as it attaches to the new FA. > > GT> The point is though that PFANE extension has been very > stable for long > time and provides lossless handoff that can be used in the > short term and > until either fast handoffs mature or link layers get make > before break > capability...in which case fast handoff specs are not > needed. The only > reason PFANEs are not a standard today is because they are > part of the Route > Optimization draft that is notionaly kept behind because of the MIPv6 > security discussion. Yet PFANEs have no security issue > themselves...hence > the discussion about publishing them independently of > Routing Optimization. I'm not against splitting PFANE from route opt. since I agree that it solves a different problem than generic route opt. However I can't agree with the argument that PFANE can be used for loss-less handoff on the way to a next step. PFANE in route opt is used after the MN has attached so that implies some latency/loss. I say we provide the necessary fast handoff tools and let people make their implementation choices. GT> Karim, it is well understood that for Make Before Break handoffs such as all the inter-technology handoffs and any good enough link layers that also allow it there is no need for the fast handoff specs. These are specifically needed for break before make handoffs. But lets not get hanged up on this the point is that you also agree that the PFANE proposal could be standardized independently. Cheers George From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:03:11 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02903 for ; Wed, 19 Dec 2001 13:03:10 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18086; Wed, 19 Dec 2001 10:02:03 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18839; Wed, 19 Dec 2001 10:02:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJI1QZR015630 for ; Wed, 19 Dec 2001 10:01:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJI1Qao015629 for mobile-ip-dist; Wed, 19 Dec 2001 10:01:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJI1MZR015622 for ; Wed, 19 Dec 2001 10:01:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02226 for ; Wed, 19 Dec 2001 10:01:25 -0800 (PST) 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 LAA25547 for ; Wed, 19 Dec 2001 11:02:11 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBJI1NJ14555 for ; Wed, 19 Dec 2001 19:01:23 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Dec 19 19:01:07 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 18:52:49 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C15B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 19:01:06 +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: Jonathan Wood wrote: > > => Certainly, that's a possibility, but the question > > is why ? > > I sure hope this wasn't due to the last presentation > > in SLC. It was already shown on the mailing list > > that the understanding of RFC2002 and the low > > latency draft were not correct in that implementation. > > This has not been shown, either on the mailing list or elsewhere. > => Please see Karim's response to you some weeks ago, I've attached it below in case you missed it. Also the same claim is made in section 4.1.1 of your paper. This is clearly wrong. There are also other claims about race conditions which are false. > > I agree that we need more implementation experience with > these complex > proposals. If we move the draft to proposed now, yes, more > people will > implement it, but only because they assume it's stable and > well-understood, when that is not the case. > => So what do you propose ? Keep it a WG item for another year till enough people prove that it is implementable ? Hesham -----Original Message----- From: Karim El-Malki (ERA) Sent: den 7 november 2001 16:56 To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] Low Latency MIPv4 Handoffs: Coverage Area Transit ion > > > First I should call out one place where it looks like we may have > > > differing assumptions. I assert that the MN MUST know whether or > > > not it is in a PRE-REG or rfc2002 coverage area, since the actions > > > it takes on movement detection will be different. For rfc2002, a > > > MN typically on receipt on an advert will flush L2 caches and > > > routing tables, add a default and host route through the FA, and > > > send a registration reply. > > > > It would do that after it received a registration reply. I > guess that's > > what you meant. > > Actually the MN can set the default route whenever it wants after it > gets an advert; so far as I can tell rfc2002 is silent on the matter > and it makes little difference. The implementation I am using sets > the default route after getting the advert and before sending the > registration request (yes I typoed above - s/reply/request/). This > is significantly different for PRE-REG, where it is critical the > default route is not reset until the MN is on the new FAs link. (You > do touch on this in section 3.6.) I don't think RFC2002bis is silent on this. It says the following under MN considerations (4.2.1): When registered on a foreign network, the mobile node chooses a default router by the following rules: - If the mobile node is registered using a foreign agent care-of address, it MAY use its foreign agent as a first-hop router. ..... From the above I understand that the MN chooses the default router once registered and MAY use the FA with which it is registered. When a MN has an active registration and receives another agent advertisement it shouldn't immediately change default router. It has to do movement detection and wait until a successful registration goes through before making routing changes. Otherwise any ongoing communication (through the current FA) would be disrupted since the new FA shouldn't let traffic through (to and from MN) until it gets the successful reply. /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:14: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 NAA03151 for ; Wed, 19 Dec 2001 13:14:48 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24316; Wed, 19 Dec 2001 10:13:33 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23197; Wed, 19 Dec 2001 10:13:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJICkZR015797 for ; Wed, 19 Dec 2001 10:12:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJICkSX015796 for mobile-ip-dist; Wed, 19 Dec 2001 10:12:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIChZR015789 for ; Wed, 19 Dec 2001 10:12:43 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06368 for ; Wed, 19 Dec 2001 10:12:45 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14802 for ; Wed, 19 Dec 2001 11:12:44 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05246 for ; Wed, 19 Dec 2001 10:12:44 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBJICi405800 for ; Wed, 19 Dec 2001 10:12:44 -0800 X-mProtect: Wed, 19 Dec 2001 10:12:44 -0800 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 smtpdhbuKws; Wed, 19 Dec 2001 10:12:42 PST Message-ID: <3C20D89A.588859EB@iprg.nokia.com> Date: Wed, 19 Dec 2001 10:12:42 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Feedback Requested References: <795A014AF92DD21182AF0008C7A404320DFBEE4D@esealnt117> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Just a minor comment. Anything that uses L2 triggers is extremely hard to implement in a small laboratory kind of place. That is why you dont see any implementations. the same thing goes for FMIPv6. it is easy to implement the anticipated part of it. Tunnel based handovers are just not possible for us. Vijay "Karim El-Malki (ERA)" wrote: > > IMO unless we finish the work off people won't have a chance > to see if it fits their requirements. Until we have an RFC we > can't really say IETF has a stable solution for low latency > MIPv4 handoffs which people can implement and try out. Early > implementation is useful but few implementations doesn't > mean it shouldn't make it to RFC. We also need to consider that > low latency is closely knit to wireless (through L2 triggers and > their timing) which makes the real implementation harder than > many other drafts. > > > > > Second, it was proposed that PFANE from the RO draft might > > be stripped > > into a separate draft to accelerate progress on low latency. > > The previous FA extension has no relation to the low latency draft. > In fact the PFANE is sent by the MN along with the registration > request when it has attached to the new FA and is completing the > L3 handoff. The low latency solutions aim at reducing L3 handoff > latency to zero, which means that the MN must be in communication > as soon as it attaches to the new FA. > > /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:17: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 NAA03187 for ; Wed, 19 Dec 2001 13:17:45 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25783; Wed, 19 Dec 2001 10:16:32 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24569; Wed, 19 Dec 2001 10:16:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIFjZR015892 for ; Wed, 19 Dec 2001 10:15:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIFjci015891 for mobile-ip-dist; Wed, 19 Dec 2001 10:15:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIFgZR015884 for ; Wed, 19 Dec 2001 10:15:42 -0800 (PST) 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 KAA00079 for ; Wed, 19 Dec 2001 10:15:45 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04071 for ; Wed, 19 Dec 2001 10:15:44 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJIFi814498 for ; Wed, 19 Dec 2001 10:15:44 -0800 (PST) Message-ID: <008601c188b8$f37c1580$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <795A014AF92DD21182AF0008C7A404320DFBEE4D@esealnt117> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 10:14:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Karim, > IMO unless we finish the work off people won't have a chance > to see if it fits their requirements. Well, this seems sort of backwards to me. Requirements should be done first. However, in this case, we went right to the solution because at the time we started the work, there was a perceived need to have the solution done quickly. If that need has abated or people have changed their minds, then we need to revisit. > Until we have an RFC we > can't really say IETF has a stable solution for low latency > MIPv4 handoffs which people can implement and try out. Early > implementation is useful but few implementations doesn't > mean it shouldn't make it to RFC. We also need to consider that > low latency is closely knit to wireless (through L2 triggers and > their timing) which makes the real implementation harder than > many other drafts. > I think it is as important to have running code as to have rough concensus. The difficulty with this work is that it is making a performance claim. IETF has difficulty with performance claims, since typically all that is important to approve a protocol for draft standard is that the code run and some degree of interoperability be demonstrated. For proposed standard, even that level of implementability is not necessary, except for routing protocols. Arguably, MIP is a routing protocol, but recently the IESG seems to be backing away from treating it like one. My own opinion is that the IESG ought to require a protocol making a performance claim to demonstrate that claim, and, in particular, demonstrate when the claim holds and when it doesn't. If there are other, similar protocols that can make an equivalent or better claim that is more broadly applicable, obviously they are better candidates for standardization. Charaterizing a protocol with a performance claim is critical for implementation and deployment. > > > > Second, it was proposed that PFANE from the RO draft might > > be stripped > > into a separate draft to accelerate progress on low latency. > > The previous FA extension has no relation to the low latency draft. > In fact the PFANE is sent by the MN along with the registration > request when it has attached to the new FA and is completing the > L3 handoff. The low latency solutions aim at reducing L3 handoff > latency to zero, which means that the MN must be in communication > as soon as it attaches to the new FA. > PFANE is a form of "forwarding from previous care of address", which provides an alternative to Prereg. Like Prereg, it allows the MN to control movement. Because it is sent after the MN moves to the new FA, it does not suffer from the problem of having signaling cut off before completion, requiring the MN to recover on the new FA, as does Prereg. Because it allows the old FA to tunnel traffic for the MN, it maintains connectivity until the routing update is done through the HA. Based on our experiments with a similar, though slightly different, technique, PFANE is likely to perform about as well as Prereg when the MN is moving at the optimal speed, and much better where Prereg performance deteriorates as the MN moves faster or slower than the optimal speed. It should also perform better than standard MIPv4 handover because the MN doesn't have to wait for routing to change at the HA, but not as good as Postreg because of the delay associated with L2 handover and PFANE signalling. Of course, to verify this, we will have to test PFANE. Thus, I think PFANE is quite relevent to the low latency work. I believe that it should be moved from the route optimization draft to a separate draft, because the security issues are much more straightforward. PFANE involves security between FAs, which is solved problem, and not between the MN and an arbitrary CN, which has proved a fairly difficult problem to solve. Keeping these security issues separate will help facilitate IESG approval. However, I really think we need to uplevel the context here a bit and look at the meta-issue. Phil's question at the meeting about who was going to implement this work was not encouraging. I had thought that 3GPP2 was an obvious customer, but they already do something like Postreg for PPP. If nobody is going to implement this work, or it will just be implemented as a research project, then what is the point of doing it? We should just make the whole thing experimental and concentrate on getting FMIPv6 right. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:24: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 NAA03378 for ; Wed, 19 Dec 2001 13:24:38 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11401; Wed, 19 Dec 2001 11:23:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26648; Wed, 19 Dec 2001 10:23:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIMdZR016050 for ; Wed, 19 Dec 2001 10:22:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIMdY6016049 for mobile-ip-dist; Wed, 19 Dec 2001 10:22:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIMaZR016042 for ; Wed, 19 Dec 2001 10:22:36 -0800 (PST) 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 KAA02549 for ; Wed, 19 Dec 2001 10:22:38 -0800 (PST) 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 KAA27379 for ; Wed, 19 Dec 2001 10:22:38 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBJIMaJ23529 for ; Wed, 19 Dec 2001 19:22:37 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Dec 19 19:22:21 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 19:14:03 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEE52@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 19:22:20 +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: > GT> Yes I am saying that these specs are too big and complex > to go through > the standards process as they are...they need to be broken > down but to do > that we first need to figure out what is the basic functionality... > > My point is that this doesn't justify putting low latency on hold. > > GT> If we do break them down then clearly we have some work > to do before we > can push them forward. Going back to where we were several IETFs ago just sounds to me like delaying the work. I thought basic functionality was already clear in the doc through the MAY/SHOULD/MUSTs, but if not let's clarify it now. > > GT> Karim, it is well understood that for Make Before Break > handoffs such as > all the inter-technology handoffs and any good enough link > layers that also > allow it there is no need for the fast handoff specs. These > are specifically > needed for break before make handoffs. But lets not get > hanged up on this > the point is that you also agree that the PFANE proposal could be > standardized independently. We agree this is outside the scope of low latency. Appendix B spells out that there MAY be different ways of doing fast handoffs in certain cases. /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:26:03 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03407 for ; Wed, 19 Dec 2001 13:26:03 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29567; Wed, 19 Dec 2001 10:24:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26896; Wed, 19 Dec 2001 10:23:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIMxZR016070 for ; Wed, 19 Dec 2001 10:22:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIMxJ9016069 for mobile-ip-dist; Wed, 19 Dec 2001 10:22:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIMsZR016052 for ; Wed, 19 Dec 2001 10:22:54 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02626 for ; Wed, 19 Dec 2001 10:22:56 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11007 for ; Wed, 19 Dec 2001 11:22:37 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA06009 for ; Wed, 19 Dec 2001 10:22:55 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBJIMtj23969 for ; Wed, 19 Dec 2001 10:22:55 -0800 X-mProtect: Wed, 19 Dec 2001 10:22:55 -0800 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 smtpdvSYqy1; Wed, 19 Dec 2001 10:22:53 PST Message-ID: <3C20DAFE.594F0904@iprg.nokia.com> Date: Wed, 19 Dec 2001 10:22:54 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Feedback Requested References: <8C92E23A3E87FB479988285F9E22BE465AB891@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit George Tsirtsis wrote: > GT> Yes I am saying that these specs are too big and complex to go through > the standards process as they are...they need to be broken down but to do > that we first need to figure out what is the basic functionality... this is incredible. Why werent you protesting when FMIPv6 spec bloated from 25 pages to over 62 pages? It was nice and simple when I started implemented it. Only a couple of us protested merging BETH with FMIPv6. I wish BETH had been a separate proposal. regards Vijay > > My point is that this doesn't justify putting low latency on hold. > > GT> If we do break them down then clearly we have some work to do before we > can push them forward. > > > In fact the PFANE is sent by the MN along with the registration > > request when it has attached to the new FA and is completing the > > L3 handoff. The low latency solutions aim at reducing L3 handoff > > latency to zero, which means that the MN must be in communication > > as soon as it attaches to the new FA. > > > > GT> The point is though that PFANE extension has been very > > stable for long > > time and provides lossless handoff that can be used in the > > short term and > > until either fast handoffs mature or link layers get make > > before break > > capability...in which case fast handoff specs are not > > needed. The only > > reason PFANEs are not a standard today is because they are > > part of the Route > > Optimization draft that is notionaly kept behind because of the MIPv6 > > security discussion. Yet PFANEs have no security issue > > themselves...hence > > the discussion about publishing them independently of > > Routing Optimization. > > I'm not against splitting PFANE from route opt. since I agree that > it solves a different problem than generic route opt. > However I can't agree with the argument that PFANE can be used for > loss-less handoff on the way to a next step. PFANE in route opt > is used after the MN has attached so that implies some latency/loss. > I say we provide the necessary fast handoff tools and let people > make their implementation choices. > > GT> Karim, it is well understood that for Make Before Break handoffs such as > all the inter-technology handoffs and any good enough link layers that also > allow it there is no need for the fast handoff specs. These are specifically > needed for break before make handoffs. But lets not get hanged up on this > the point is that you also agree that the PFANE proposal could be > standardized independently. > > Cheers > George From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:26: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 NAA03430 for ; Wed, 19 Dec 2001 13:26:46 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00019; Wed, 19 Dec 2001 10:24:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27270; Wed, 19 Dec 2001 10:24:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIO8ZR016120 for ; Wed, 19 Dec 2001 10:24:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIO80D016119 for mobile-ip-dist; Wed, 19 Dec 2001 10:24:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIO4ZR016109 for ; Wed, 19 Dec 2001 10:24:04 -0800 (PST) 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 KAA09517 for ; Wed, 19 Dec 2001 10:24:07 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08104 for ; Wed, 19 Dec 2001 10:24:06 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJIO6814966 for ; Wed, 19 Dec 2001 10:24:06 -0800 (PST) Message-ID: <00a901c188ba$1ed08080$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <8C92E23A3E87FB479988285F9E22BE465AB890@ftmail> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 10:22:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit George, > GT> I think that the community has been overwhelmed by the MIPv6 security > discussion and has reviewed the fast handoff specs very little. Also these > specs are full of new mechanisms...some of them very complex. Fast handoffs > are also "optimizations" and as Eric N. said recently, IETF is not very good > at producing optimization techniques. I agree. >Even worst, parts of the fast handoff > specs are about optimizing the optimization...see Handoff To Third > (HTT)....what about the Forth, Fifth and Hundredth? I see you haven't read the spec. If you had, you would see that the "Third" in this case is the highest it can go. >What I am saying is that > the IETF must be very careful and rather conservative in this > standardization effort. Peer review and experimentation is needed here more > than anywhere. > I agree!! > > > > Second, it was proposed that PFANE from the RO draft might > > be stripped > > into a separate draft to accelerate progress on low latency. > > The previous FA extension has no relation to the low latency draft. > > GT> This is true. > > In fact the PFANE is sent by the MN along with the registration > request when it has attached to the new FA and is completing the > L3 handoff. The low latency solutions aim at reducing L3 handoff > latency to zero, which means that the MN must be in communication > as soon as it attaches to the new FA. > > GT> The point is though that PFANE extension has been very stable for long > time and provides lossless handoff that can be used in the short term and > until either fast handoffs mature or link layers get make before break > capability...in which case fast handoff specs are not needed. The only > reason PFANEs are not a standard today is because they are part of the Route > Optimization draft that is notionaly kept behind because of the MIPv6 > security discussion. Yet PFANEs have no security issue themselves...hence > the discussion about publishing them independently of Routing Optimization. > I agree with this as well. PFANE can perform optimization now, and is particularly important for protocols such as 802.11 in which the MN controls movement. The only reason it is being held up is that the security issues of full route optimization are much more complex than the simple FA/FA security required for PFANE. Therefore, I think it needs to be moved into a separate draft. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:30: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 NAA03528 for ; Wed, 19 Dec 2001 13:30:19 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01375; Wed, 19 Dec 2001 10:27:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28189; Wed, 19 Dec 2001 10:27:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIQnZR016247 for ; Wed, 19 Dec 2001 10:26:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIQnXW016246 for mobile-ip-dist; Wed, 19 Dec 2001 10:26:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIQjZR016236 for ; Wed, 19 Dec 2001 10:26:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27965 for ; Wed, 19 Dec 2001 10:26:48 -0800 (PST) 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 LAA10203 for ; Wed, 19 Dec 2001 11:27:33 -0700 (MST) 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 fBJIQjJ24902 for ; Wed, 19 Dec 2001 19:26:46 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed Dec 19 19:26:30 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 19:26:45 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C15C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 19:26:30 +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: > > Anything that uses L2 triggers is extremely hard to implement > in a small laboratory kind of place. That is why you dont > see any implementations. => Amen ! Especially if all you have is an ethernet link. You can't claim to have implemented something like BETH, POSTREG ...etc on an ethernet, unless you're triggering it manually ! Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:31: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 NAA03604 for ; Wed, 19 Dec 2001 13:31:58 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17591; Wed, 19 Dec 2001 11:30:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00124; Wed, 19 Dec 2001 10:30:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJITbZR016371 for ; Wed, 19 Dec 2001 10:29:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJITbBZ016370 for mobile-ip-dist; Wed, 19 Dec 2001 10:29:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJITXZR016360 for ; Wed, 19 Dec 2001 10:29:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04615 for ; Wed, 19 Dec 2001 10:29:36 -0800 (PST) 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 LAA16846 for ; Wed, 19 Dec 2001 11:29:17 -0700 (MST) 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.11.0/WIREfire-1.3) with SMTP id fBJITYK27679 for ; Wed, 19 Dec 2001 19:29:34 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Dec 19 19:29:34 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 19:21:01 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C15D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 19:29:18 +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: That was a reply to Vijay actually, don't know why half my email disappeared ! > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, December 19, 2001 7:27 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] WG Feedback Requested > > > => Amen ! Especially if all you have is an ethernet > link. You can't claim to have implemented something > like BETH, POSTREG ...etc on an ethernet, unless you're > triggering it manually ! > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:34: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 NAA03677 for ; Wed, 19 Dec 2001 13:34:09 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20152; Wed, 19 Dec 2001 11:32:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01145; Wed, 19 Dec 2001 10:33:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIWTZR016577 for ; Wed, 19 Dec 2001 10:32:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIWTqa016576 for mobile-ip-dist; Wed, 19 Dec 2001 10:32:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIWQZR016569 for ; Wed, 19 Dec 2001 10:32:26 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28103 for ; Wed, 19 Dec 2001 10:32:29 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21455 for ; Wed, 19 Dec 2001 11:32:28 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJIWR815476 for ; Wed, 19 Dec 2001 10:32:27 -0800 (PST) Message-ID: <00b301c188bb$49a61e90$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <4DA6EA82906FD511BE2F00508BCF053801C4C154@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 10:30:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, > => Certainly, that's a possibility, but the question > is why ? > I sure hope this wasn't due to the last presentation > in SLC. It was already shown on the mailing list > that the understanding of RFC2002 and the low > latency draft were not correct in that implementation. > This is a misrepresentation and has nothing to do with the results shown in SLC. I sent theoretical calculations to the list last summer that showed exactly the same effect. In science, when experimental results conform closely to theoretical, it is known as "confirming the theory." If you want to prove these wrong, then I suggest you implement Prereg and show results that contradict the ones I presented. We are not talking about extraterristrial abductions here. > I think the draft should move on, there is no need > for more unnecessary delays. > > I disagree. One way to make progress is for the WG to do the hard call and separate the two proposals into two drafts, as I suggested in SLC. Since the WG and chairs don't seem inclined to make that hard call, another way would be to move the whole thing to experimental, as Raj has proposed. Meanwhile, we can separate out PFANE from the route optimization draft, and those who want something that's already had a good deal of implementation experience can use that. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:38:52 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03771 for ; Wed, 19 Dec 2001 13:38:51 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23832; Wed, 19 Dec 2001 11:37:27 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02351; Wed, 19 Dec 2001 10:37:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIaiZR016771 for ; Wed, 19 Dec 2001 10:36:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIaiXm016770 for mobile-ip-dist; Wed, 19 Dec 2001 10:36:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIafZR016760 for ; Wed, 19 Dec 2001 10:36:41 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13584 for ; Wed, 19 Dec 2001 10:36:43 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12294 for ; Wed, 19 Dec 2001 11:36:43 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 13:36:42 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB894@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 13:36:33 -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: Vijay, Relax. All my references to Fast Handoffs are in plural...meaning both v4 and v6 specs....And yes, I also think that it was a mistake to merge BETH (as well as HTT) in the specs, although I am partly responsible as a co-author of FMIPv6 and since I let this happen in a moment of unbelievable weakness or temporary insanity or both. So, lets try to correct things. George -----Original Message----- From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] Sent: Wednesday, December 19, 2001 6:23 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Feedback Requested George Tsirtsis wrote: > GT> Yes I am saying that these specs are too big and complex to go through > the standards process as they are...they need to be broken down but to do > that we first need to figure out what is the basic functionality... this is incredible. Why werent you protesting when FMIPv6 spec bloated from 25 pages to over 62 pages? It was nice and simple when I started implemented it. Only a couple of us protested merging BETH with FMIPv6. I wish BETH had been a separate proposal. regards Vijay > > My point is that this doesn't justify putting low latency on hold. > > GT> If we do break them down then clearly we have some work to do before we > can push them forward. > > > In fact the PFANE is sent by the MN along with the registration > > request when it has attached to the new FA and is completing the > > L3 handoff. The low latency solutions aim at reducing L3 handoff > > latency to zero, which means that the MN must be in communication > > as soon as it attaches to the new FA. > > > > GT> The point is though that PFANE extension has been very > > stable for long > > time and provides lossless handoff that can be used in the > > short term and > > until either fast handoffs mature or link layers get make > > before break > > capability...in which case fast handoff specs are not > > needed. The only > > reason PFANEs are not a standard today is because they are > > part of the Route > > Optimization draft that is notionaly kept behind because of the MIPv6 > > security discussion. Yet PFANEs have no security issue > > themselves...hence > > the discussion about publishing them independently of > > Routing Optimization. > > I'm not against splitting PFANE from route opt. since I agree that > it solves a different problem than generic route opt. > However I can't agree with the argument that PFANE can be used for > loss-less handoff on the way to a next step. PFANE in route opt > is used after the MN has attached so that implies some latency/loss. > I say we provide the necessary fast handoff tools and let people > make their implementation choices. > > GT> Karim, it is well understood that for Make Before Break handoffs such as > all the inter-technology handoffs and any good enough link layers that also > allow it there is no need for the fast handoff specs. These are specifically > needed for break before make handoffs. But lets not get hanged up on this > the point is that you also agree that the PFANE proposal could be > standardized independently. > > Cheers > George From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:39: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 NAA03798 for ; Wed, 19 Dec 2001 13:39:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24324; Wed, 19 Dec 2001 11:38:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02633; Wed, 19 Dec 2001 10:38:04 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIb9ZR016805 for ; Wed, 19 Dec 2001 10:37:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIb9Mf016804 for mobile-ip-dist; Wed, 19 Dec 2001 10:37:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIb1ZR016797 for ; Wed, 19 Dec 2001 10:37:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02177 for ; Wed, 19 Dec 2001 10:37:04 -0800 (PST) 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 LAA23219 for ; Wed, 19 Dec 2001 11:36:44 -0700 (MST) 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 fBJIb2J28748 for ; Wed, 19 Dec 2001 19:37:02 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Dec 19 19:36:46 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 19:28:28 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C15E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 19:36:42 +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: James, > > I agree with this as well. PFANE can perform optimization > now, and is > particularly important for protocols such as 802.11 in which the > MN controls movement. The only reason it is being held up > is that the > security > issues of full route optimization are much more complex > than the simple > FA/FA security > required for PFANE. Therefore, I think it needs to be moved into a > separate > draft. => I'm stunned by this discussion, I thought we were all aware of the existence of PFANE when we did the lowlatency draft ! Obviously I was wrong. The _entire_ purpose of the draft was to show that the handover speed can be reduced due to anticipation of the handover, so how can you possibly claim that PFANE is an alternative ? Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:47: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 NAA03984 for ; Wed, 19 Dec 2001 13:47:46 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01369; Wed, 19 Dec 2001 11:46:12 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05299; Wed, 19 Dec 2001 10:46:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIjjZR017155 for ; Wed, 19 Dec 2001 10:45:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIjj8l017154 for mobile-ip-dist; Wed, 19 Dec 2001 10:45:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIjfZR017147 for ; Wed, 19 Dec 2001 10:45:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01811 for ; Wed, 19 Dec 2001 10:45:44 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15723 for ; Wed, 19 Dec 2001 11:45:43 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBJIjhJ02585 for ; Wed, 19 Dec 2001 19:45:43 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Dec 19 19:45:27 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 19:45:42 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEE53@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 19:45:26 +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: > PFANE is a form of "forwarding from previous care of address", which > provides an alternative to Prereg. PFANE is an extension of the registration request so it's not really an alternative. PFANE can be used as an extension to the pre-reg registration request but I'm not necessarily saying this is a good idea. > Based on our experiments with a similar, though slightly different, > technique, PFANE is likely to perform about as well as Prereg > when the MN is moving at the optimal speed, and much better where > Prereg performance deteriorates as the MN moves faster > or slower than the optimal speed. What is this optimal speed? Optimal for who? Hopefully not Schumacher in his Ferrari ;-) > It should also perform > better than standard MIPv4 handover because the MN > doesn't have to wait for routing to change at the HA, but > not as good as Postreg because of the delay associated with > L2 handover and PFANE signalling. Of course, to verify > this, we will have to test PFANE. How can pre-reg which anticipates the mobility be worse than a protocol which runs after then MN has moved? > However, I really think we need to uplevel the context > here a bit and look at the meta-issue. Phil's question at the meeting > about who was going to implement this work was not encouraging. > I had thought that 3GPP2 was an obvious customer, > but they already do something like Postreg for PPP. > If nobody is going to implement this work, or it > will just be implemented as a research project, then what > is the point of doing it? We should just make the whole > thing experimental and concentrate on getting FMIPv6 > right. I think I've already said what I think about the implementation issue. If we don't have a spec which is stable enough we're just going in circles. How do you know what FMIPv6 is going to be used for? If you apply this argument to low latency soon people will be applying the same to FMIPv6 and we'll just go back to where we started. We should just get low latency into some RFC form, do the same for FMIPv6 once MIPv6 is done and put this issue aside awaiting real deployment. There have been several specs which were not used because they were not RFCs. 3GPP2 could well be a good example and provide a reason why this work needs to be completed. RFCs can get revisited as it becomes clear changes are needed. /Karim From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:49: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 NAA04040 for ; Wed, 19 Dec 2001 13:49:49 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03424; Wed, 19 Dec 2001 11:48:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05874; Wed, 19 Dec 2001 10:48:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIm1ZR017232 for ; Wed, 19 Dec 2001 10:48:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIm1gx017231 for mobile-ip-dist; Wed, 19 Dec 2001 10:48:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIlvZR017218 for ; Wed, 19 Dec 2001 10:47:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02355 for ; Wed, 19 Dec 2001 10:48:00 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02770 for ; Wed, 19 Dec 2001 11:47:40 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA07572 for ; Wed, 19 Dec 2001 10:47:57 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBJIlud01157 for ; Wed, 19 Dec 2001 10:47:56 -0800 X-mProtect: Wed, 19 Dec 2001 10:47:56 -0800 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 smtpd9OOz0f; Wed, 19 Dec 2001 10:47:54 PST Message-ID: <3C20E0DA.1792AF45@iprg.nokia.com> Date: Wed, 19 Dec 2001 10:47:54 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Feedback Requested References: <8C92E23A3E87FB479988285F9E22BE465AB894@ftmail> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Great!! But I am not sure how to proceed. I guess lot of work went in merging BETH into FMIPv6. I can see Gopal getting ready to kill me :) Vijay George Tsirtsis wrote: > > Vijay, > > Relax. All my references to Fast Handoffs are in plural...meaning both v4 > and v6 specs....And yes, I also think that it was a mistake to merge BETH > (as well as HTT) in the specs, although I am partly responsible as a > co-author of FMIPv6 and since I let this happen in a moment of unbelievable > weakness or temporary insanity or both. > > So, lets try to correct things. > > George > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Wednesday, December 19, 2001 6:23 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] WG Feedback Requested > > George Tsirtsis wrote: > > > GT> Yes I am saying that these specs are too big and complex to go through > > the standards process as they are...they need to be broken down but to do > > that we first need to figure out what is the basic functionality... > > this is incredible. Why werent you protesting when FMIPv6 spec > bloated from 25 pages to over 62 pages? It was nice and simple > when I started implemented it. > > Only a couple of us protested merging BETH with FMIPv6. I wish > BETH had been a separate proposal. > > regards > Vijay > > > > > My point is that this doesn't justify putting low latency on hold. > > > > GT> If we do break them down then clearly we have some work to do before > we > > can push them forward. > > > > > In fact the PFANE is sent by the MN along with the registration > > > request when it has attached to the new FA and is completing the > > > L3 handoff. The low latency solutions aim at reducing L3 handoff > > > latency to zero, which means that the MN must be in communication > > > as soon as it attaches to the new FA. > > > > > > GT> The point is though that PFANE extension has been very > > > stable for long > > > time and provides lossless handoff that can be used in the > > > short term and > > > until either fast handoffs mature or link layers get make > > > before break > > > capability...in which case fast handoff specs are not > > > needed. The only > > > reason PFANEs are not a standard today is because they are > > > part of the Route > > > Optimization draft that is notionaly kept behind because of the MIPv6 > > > security discussion. Yet PFANEs have no security issue > > > themselves...hence > > > the discussion about publishing them independently of > > > Routing Optimization. > > > > I'm not against splitting PFANE from route opt. since I agree that > > it solves a different problem than generic route opt. > > However I can't agree with the argument that PFANE can be used for > > loss-less handoff on the way to a next step. PFANE in route opt > > is used after the MN has attached so that implies some latency/loss. > > I say we provide the necessary fast handoff tools and let people > > make their implementation choices. > > > > GT> Karim, it is well understood that for Make Before Break handoffs such > as > > all the inter-technology handoffs and any good enough link layers that > also > > allow it there is no need for the fast handoff specs. These are > specifically > > needed for break before make handoffs. But lets not get hanged up on this > > the point is that you also agree that the PFANE proposal could be > > standardized independently. > > > > Cheers > > George From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:54: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 NAA04111 for ; Wed, 19 Dec 2001 13:54:10 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06881; Wed, 19 Dec 2001 11:52:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06977; Wed, 19 Dec 2001 10:52:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIq3ZR017381 for ; Wed, 19 Dec 2001 10:52:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIq3w5017380 for mobile-ip-dist; Wed, 19 Dec 2001 10:52:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIq0ZR017373 for ; Wed, 19 Dec 2001 10:52:00 -0800 (PST) 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 KAA06808 for ; Wed, 19 Dec 2001 10:52:03 -0800 (PST) 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 KAA20306 for ; Wed, 19 Dec 2001 10:52:01 -0800 (PST) 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 fBJIq0J04726 for ; Wed, 19 Dec 2001 19:52:00 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Dec 19 19:51:45 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 19:43:27 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C15F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 19:51:45 +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: > I sent theoretical calculations to the list last summer > that showed exactly the same effect. In science, > when experimental results conform closely to > theoretical, it is known as "confirming the > theory." => Aha ! Thanks for the enlightenment, but you've missed my point. Your theoritical analysis was based on an implementation on a cellular link with certain characteristics (e.g. you had to send MIP signalling on the same channel as the traffic data). Now your implementation is on an ethernet, so I'm not sure which theory that confirms. In addition, the standard we follow is RFC2002, your implementation didn't follow that standard, so what do you disagree with when I say that the implementation is not correct ? Please clarify this to me. > > If you want to prove these wrong, then I suggest > you implement Prereg and show results that > contradict the ones I presented. We are not talking about > extraterristrial abductions here. => I don't have to implement it to show you you've done something wrong, I can read text ! section 4.1.1 of your paper is only one example of the wrong implementation and there is more. > One way to make progress is for the WG to > do the hard call and separate the two > proposals into two drafts, as I suggested > in SLC. Since the WG and chairs don't > seem inclined to make that hard call, > another way would be to move the > whole thing to experimental, as Raj > has proposed. => Separating the draft again is simply irrational and takes us back a year. If the WG decides on the next steps, we should abide of course, but I want to make it clear that we have the right foundations for othe decision. And that definitely (no offence) should not be based on the presentation in SLC, because anyone who reads the paper will realise where the errors are. > Meanwhile, we can separate out PFANE > from the route optimization draft, and > those who want something that's already > had a good deal of implementation > experience can use that. > => I'm neutral to that, but what implementations are you referring too. Is the route opt draft actually widely implemented ? George T has an implementation, but does anyone else ? Just curious. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 13:56: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 NAA04177 for ; Wed, 19 Dec 2001 13:56:13 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09075; Wed, 19 Dec 2001 11:54:50 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07800; Wed, 19 Dec 2001 10:55:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIsSZR017607 for ; Wed, 19 Dec 2001 10:54:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIsSD3017606 for mobile-ip-dist; Wed, 19 Dec 2001 10:54:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIsOZR017593 for ; Wed, 19 Dec 2001 10:54:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18958 for ; Wed, 19 Dec 2001 10:54:25 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24584 for ; Wed, 19 Dec 2001 11:55:10 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 13:54:23 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB895@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 13:54:15 -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: James, We agree on most things in this thread so lets desagree on one :-)....see below. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Wednesday, December 19, 2001 6:23 PM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Feedback Requested ... >Even worst, parts of the fast handoff > specs are about optimizing the optimization...see Handoff To Third > (HTT)....what about the Forth, Fifth and Hundredth? I see you haven't read the spec. If you had, you would see that the "Third" in this case is the highest it can go. GT> Actually I have.... Just because HTT is currently limited in scope it does not mean that someone can not be tempted to extend it. HTT is for fast mobiles. What about super fast mobiles? Say someone goes a bit mad and tries to cover the bullet-train track with microcells...A bullet train can go through a large number of microcells in very short time indeed! Just kidding of course but you see my point about how far do you go with optimizing something? Maybe specifying such an optimization separately would help isolate the essential part of fast handoff from its optimization...which is always a good thing. George From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 14: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 OAA04275 for ; Wed, 19 Dec 2001 14:00:24 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA17327; Wed, 19 Dec 2001 10:58:41 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08985; Wed, 19 Dec 2001 10:58:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIvqZR017781 for ; Wed, 19 Dec 2001 10:57:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJIvpb7017780 for mobile-ip-dist; Wed, 19 Dec 2001 10:57:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJIvmZR017773 for ; Wed, 19 Dec 2001 10:57:48 -0800 (PST) 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 KAA08728 for ; Wed, 19 Dec 2001 10:57:49 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23644 for ; Wed, 19 Dec 2001 10:57:48 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJIvm817033 for ; Wed, 19 Dec 2001 10:57:48 -0800 (PST) Message-ID: <00c501c188be$d3d3ee50$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <795A014AF92DD21182AF0008C7A404320DFBEE4F@esealnt117> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 10:56:12 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I agree that experimentation is useful. The point is that here > experimentation is not easy since you need to make this work with > your wireless L2, so we can't expect everyone to implement it > or for it to fit all wireless systems. I disagree. Simulation has proven successful in a variety of areas (particularly with routing protocols), and I think it can be used quite successfully here. If one implements the protocol for one particular wireless L2, that only proves it works for that particular wireless L2. For another wireless L2 with different properties, it may not work. >If there's no stable solution > there's no chance wireless people will implement this, so it would be > like going round in circles if we didn't finish this work. The lack of > fast MIP handoff on most L2s (as you say those which do not allow the > make-before-break where the MN talks both to oFA and nFA contemporarily) > has been given as a problem of Mobile IP which we aim to solve in low > latency. That's stated in the spec and is as far as this draft goes. Making it experimental should solve this problem. > Regarding the optimisations I agree things should be kept simple but so > far people have not opposed things like HTT. By the way, HTT is a SHOULD > for those wireless systems where the MN moves fast enough for it not to be > able to register with nFA. It isn't needed for all cases. If you want > to propose ways of simplifying the spec like removing HTT or other parts > while keeping the basic functionality and the WG agrees I'm all for it. > My point is that this doesn't justify putting low latency on hold. > Making it experimental isn't putting it on hold, it is saying that we don't know enough yet to make it standards track. > I'm not against splitting PFANE from route opt. since I agree that > it solves a different problem than generic route opt. > However I can't agree with the argument that PFANE can be used for > loss-less handoff on the way to a next step. PFANE in route opt > is used after the MN has attached so that implies some latency/loss. I disagree. If the old FA buffers traffic until it receives the PFANE message, lossless handover is possible. The techniques in the low latency draft require exactly the same support. Buffering is required in any case during L2 handover when there is absolutely no way to get traffic across L2 to the MN. > I say we provide the necessary fast handoff tools and let people > make their implementation choices. > If the IETF is approving a protocol with a performance claim, then I think it is incumbent upon the authors of the protocol that they prove that claim. A protocol that claims to be have lower latency than standard MIPv4 should define when it does and when or if it doesn't. The IETF isn't an academic conference, it's a standards body. RFCs are designed to be implemented and deployed. If the IETF is making a recommendation that something be implemented and deployed, it had better have confidence that the protocol does what it says. What ever happened to "running code?" jak From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 14:05: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 OAA04335 for ; Wed, 19 Dec 2001 14:04:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16739; Wed, 19 Dec 2001 12:03:30 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10673; Wed, 19 Dec 2001 11:03:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJ3BZR018050 for ; Wed, 19 Dec 2001 11:03:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJ3BB8018049 for mobile-ip-dist; Wed, 19 Dec 2001 11:03:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJ37ZR018042 for ; Wed, 19 Dec 2001 11:03:07 -0800 (PST) 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 LAA13204 for ; Wed, 19 Dec 2001 11:03:08 -0800 (PST) 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 LAA26065 for ; Wed, 19 Dec 2001 11:03:02 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA08823 for ; Wed, 19 Dec 2001 11:03:01 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBJJ30u32298 for ; Wed, 19 Dec 2001 11:03:00 -0800 X-mProtect: Wed, 19 Dec 2001 11:03:00 -0800 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 smtpdTwU5Lq; Wed, 19 Dec 2001 11:02:59 PST Message-ID: <3C20E463.7FB362@iprg.nokia.com> Date: Wed, 19 Dec 2001 11:02:59 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Feedback Requested References: <4DA6EA82906FD511BE2F00508BCF053801C4C15D@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, Is this for me? I havent implemented BETH or POSTREQ. And I never claimed I did. on the contrary, I was saying that we cant implement anything which depends on L2 triggers. Vijay "Hesham Soliman (ERA)" wrote: > > That was a reply to Vijay actually, don't know why > half my email disappeared ! > > > -----Original Message----- > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > Sent: Wednesday, December 19, 2001 7:27 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] WG Feedback Requested > > > > > > => Amen ! Especially if all you have is an ethernet > > link. You can't claim to have implemented something > > like BETH, POSTREG ...etc on an ethernet, unless you're > > triggering it manually ! > > > > Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 14:08: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 OAA04437 for ; Wed, 19 Dec 2001 14:08:41 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19444; Wed, 19 Dec 2001 12:07:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11663; Wed, 19 Dec 2001 11:07:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJ6iZR018184 for ; Wed, 19 Dec 2001 11:06:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJ6iiV018183 for mobile-ip-dist; Wed, 19 Dec 2001 11:06:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJ6eZR018176 for ; Wed, 19 Dec 2001 11:06:41 -0800 (PST) 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 LAA14153 for ; Wed, 19 Dec 2001 11:06:41 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16783 for ; Wed, 19 Dec 2001 11:06:41 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJJ6f817624 for ; Wed, 19 Dec 2001 11:06:41 -0800 (PST) Message-ID: <00d101c188c0$11af8b20$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <4DA6EA82906FD511BE2F00508BCF053801C4C15B@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 11:05:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, > There are also other claims about race conditions which > are false. > Karim and I discussed this before the MIP meeting and he agreed that Prereg has this problem, but so does standard MIPv4. Are you saying that Karim is wrong here? Also, I would like you to specifically answer this question, without any prevarication or attempt to divert the debate in another direction: Do you disagree with the theoretical data presented to the list last summer, and the experimental data presented at the SLC meeting, that Prereg will have worse performance than standard MIPv4 handover if the MN moves too fast for the Prereg signaling to complete while the MN is still on the old FA? *That* is the issue, not the implementation. If you think we implemented it wrong, then implement it yourself and prove it! > => So what do you propose ? Keep it a WG item for another > year till enough people prove that it is implementable ? > If Raj, Phil, and Thomas don't want to make the hard call and separate out Prereg, then let's take the whole thing to experimental. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 14:11: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 OAA04477 for ; Wed, 19 Dec 2001 14:11:40 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22265; Wed, 19 Dec 2001 11:08:46 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11955; Wed, 19 Dec 2001 11:08:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJ7UZR018204 for ; Wed, 19 Dec 2001 11:07:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJ7ULg018203 for mobile-ip-dist; Wed, 19 Dec 2001 11:07:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJ7RZR018196 for ; Wed, 19 Dec 2001 11:07:27 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23601 for ; Wed, 19 Dec 2001 11:07:27 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24697 for ; Wed, 19 Dec 2001 12:07:26 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBJJ7QJ09726 for ; Wed, 19 Dec 2001 20:07:26 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Dec 19 20:07:24 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 19:58:52 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C160@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 20:07:10 +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: Vijay, I know, I was confirming what you said actually, I should say 'one can't claim to have implemented ...' sorry for the confusion. Hesham > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Wednesday, December 19, 2001 8:03 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] WG Feedback Requested > > > Hesham, > > Is this for me? I havent implemented BETH or POSTREQ. > And I never claimed I did. on the contrary, I was saying > that we cant implement anything which depends on L2 > triggers. > > Vijay > > > "Hesham Soliman (ERA)" wrote: > > > > That was a reply to Vijay actually, don't know why > > half my email disappeared ! > > > > > -----Original Message----- > > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > Sent: Wednesday, December 19, 2001 7:27 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] WG Feedback Requested > > > > > > => Amen ! Especially if all you have is an ethernet > > link. You can't claim to have implemented something > > like BETH, POSTREG ...etc on an ethernet, unless you're > > triggering it manually ! > > > > Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 14:17:05 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04727 for ; Wed, 19 Dec 2001 14:17:04 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26174; Wed, 19 Dec 2001 12:15:33 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14920; Wed, 19 Dec 2001 11:15:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJEqZR018656 for ; Wed, 19 Dec 2001 11:14:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJEqvK018655 for mobile-ip-dist; Wed, 19 Dec 2001 11:14:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJEnZR018648 for ; Wed, 19 Dec 2001 11:14:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25780 for ; Wed, 19 Dec 2001 11:14:50 -0800 (PST) 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 MAA25345 for ; Wed, 19 Dec 2001 12:14:30 -0700 (MST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBJJEmJ12946 for ; Wed, 19 Dec 2001 20:14:48 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Dec 19 20:14:46 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 20:14:47 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEE54@esealnt117> From: "Karim El-Malki (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 20:14:26 +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: > Hesham, > > > There are also other claims about race conditions which > > are false. > > > > Karim and I discussed this before the MIP meeting and > he agreed that Prereg has this problem, but so does > standard MIPv4. Are you saying that Karim is wrong > here? Just to clarify I said exactly the opposite.....neither will have such a condition. You send the reg. reply before sending traffic to the MN, not the other way round. /K. From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 14:19: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 OAA04786 for ; Wed, 19 Dec 2001 14:19:32 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28272; Wed, 19 Dec 2001 12:18:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15972; Wed, 19 Dec 2001 11:18:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJHeZR018777 for ; Wed, 19 Dec 2001 11:17:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJHeGY018776 for mobile-ip-dist; Wed, 19 Dec 2001 11:17:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJHbZR018767 for ; Wed, 19 Dec 2001 11:17:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16637 for ; Wed, 19 Dec 2001 11:17:38 -0800 (PST) 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 MAA05741 for ; Wed, 19 Dec 2001 12:18:23 -0700 (MST) 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.11.0/WIREfire-1.3) with SMTP id fBJJHaK04783 for ; Wed, 19 Dec 2001 20:17:36 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Dec 19 20:17:36 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 19 Dec 2001 20:09:03 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C161@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 20:17:19 +0100 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 fBJJHbZR018770 Sender: owner-mobile-ip@sunroof.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 > Karim and I discussed this before the MIP meeting and > he agreed that Prereg has this problem, but so does > standard MIPv4. Are you saying that Karim is wrong > here? => No I'm saying you are. Karim DISagreed with this, I don't know how you got that impression though. > > Also, I would like you to specifically answer this question, > without any prevarication or attempt to divert the > debate in another direction: > > Do you disagree with the theoretical data presented > to the list last summer, and the experimental data > presented at the SLC meeting, that Prereg will > have worse performance than standard MIPv4 > handover if the MN moves too fast for the > Prereg signaling to complete while the MN > is still on the old FA? => Sigh ..... James, IF you make certain assumptions on your link layer capabilities(e.g. separating signalling from payload bearers ...etc), then I agree, you would see that PREREG is not optimal. HOWEVER, these assumptions need not be made and I don't know how many times we've discussed this and I said the sentence above. So if you have this inflexible link layer, then use POST REG, this is the whole rationale of the draft. > > *That* is the issue, not the implementation. If you think > we implemented it wrong, then implement it yourself > and prove it! > => Obviously you're not reading my messages. If I tell I've implemented IPv6 with 64 bit addresses, will you believe me ? Well if you think you have to implement to prove me wrong then ...... well it's strange to think that. So can you PLEASE answer my question on section 4.1.1 ? otherwise there is no point in this discussion. Hesham > > If Raj, Phil, and Thomas don't want to make the hard call > and separate out Prereg, then let's take the whole thing > to experimental. > => Again, if that¨s what the WG wants we have to go with it. BUT for the right reasons. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 14:20: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 OAA04812 for ; Wed, 19 Dec 2001 14:20:10 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26265; Wed, 19 Dec 2001 11:16:51 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15147; Wed, 19 Dec 2001 11:16:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJFhZR018685 for ; Wed, 19 Dec 2001 11:15:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJFhgF018684 for mobile-ip-dist; Wed, 19 Dec 2001 11:15:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJFdZR018674 for ; Wed, 19 Dec 2001 11:15:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08667 for ; Wed, 19 Dec 2001 11:15:25 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05076 for ; Wed, 19 Dec 2001 12:15:24 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJJFN818191 for ; Wed, 19 Dec 2001 11:15:23 -0800 (PST) Message-ID: <00e101c188c1$49267f90$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <795A014AF92DD21182AF0008C7A404320DFBEE4D@esealnt117> <3C20D89A.588859EB@iprg.nokia.com> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 11:13:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay, Simulations are always possible. That's what we did. People have been using simulations to validate the scalability of routing protocols for years. It is not possible to deploy a huge network to test a routing protocol, but a simulation can do it. I think this case is similar. It is not possible to implement and deploy on all possible wireless protocols, so a simulation that captures the important characteristics of wireless protocols can help to characterize the protocol. I really hope others will do some simulation work, and also for the FMIPv6 protocols. jak ----- Original Message ----- From: "Vijay Devarapalli" To: Sent: Wednesday, December 19, 2001 10:12 AM Subject: Re: [mobile-ip] WG Feedback Requested > Just a minor comment. > > Anything that uses L2 triggers is extremely hard to implement > in a small laboratory kind of place. That is why you dont > see any implementations. > > the same thing goes for FMIPv6. it is easy to implement the > anticipated part of it. Tunnel based handovers are just not > possible for us. > > Vijay > > > "Karim El-Malki (ERA)" wrote: > > > > IMO unless we finish the work off people won't have a chance > > to see if it fits their requirements. Until we have an RFC we > > can't really say IETF has a stable solution for low latency > > MIPv4 handoffs which people can implement and try out. Early > > implementation is useful but few implementations doesn't > > mean it shouldn't make it to RFC. We also need to consider that > > low latency is closely knit to wireless (through L2 triggers and > > their timing) which makes the real implementation harder than > > many other drafts. > > > > > > > > Second, it was proposed that PFANE from the RO draft might > > > be stripped > > > into a separate draft to accelerate progress on low latency. > > > > The previous FA extension has no relation to the low latency draft. > > In fact the PFANE is sent by the MN along with the registration > > request when it has attached to the new FA and is completing the > > L3 handoff. The low latency solutions aim at reducing L3 handoff > > latency to zero, which means that the MN must be in communication > > as soon as it attaches to the new FA. > > > > /Karim > From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 14:26: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 OAA04949 for ; Wed, 19 Dec 2001 14:26:57 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01079; Wed, 19 Dec 2001 11:25:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19005; Wed, 19 Dec 2001 11:25:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJP7ZR019135 for ; Wed, 19 Dec 2001 11:25:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJP7ej019133 for mobile-ip-dist; Wed, 19 Dec 2001 11:25:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJP3ZR019126 for ; Wed, 19 Dec 2001 11:25:03 -0800 (PST) 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 LAA11099 for ; Wed, 19 Dec 2001 11:25:05 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24578 for ; Wed, 19 Dec 2001 11:25:00 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJJP0818780 for ; Wed, 19 Dec 2001 11:25:00 -0800 (PST) Message-ID: <010a01c188c2$a0d60ca0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <4DA6EA82906FD511BE2F00508BCF053801C4C15E@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 11:23:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, > > > > I agree with this as well. PFANE can perform optimization > > now, and is > > particularly important for protocols such as 802.11 in which the > > MN controls movement. The only reason it is being held up > > is that the > > security > > issues of full route optimization are much more complex > > than the simple > > FA/FA security > > required for PFANE. Therefore, I think it needs to be moved into a > > separate > > draft. > > => I'm stunned by this discussion, I thought we were > all aware of the existence of PFANE when we did > the lowlatency draft ! Well, maybe we missed it because it was bundled into the route optimization draft. I don't think there is any harm in admiting that a simple existing technique which we know works is preferable to something that is not yet well understood, for the short term. >Obviously I was wrong. Really?! > The _entire_ purpose of the draft was to show > that the handover speed can be reduced due to > anticipation of the handover, so how can you > possibly claim that PFANE is an alternative ? > The simulation results we did showed that a technique similar to PFANE worked about as well as Prereg. The paper is at http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx t Of course, we will have to do simulations for PFANE itself to be sure. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 14:41: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 OAA05319 for ; Wed, 19 Dec 2001 14:41:22 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06377; Wed, 19 Dec 2001 11:37:03 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20927; Wed, 19 Dec 2001 11:36:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJZNZR019381 for ; Wed, 19 Dec 2001 11:35:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJZNds019380 for mobile-ip-dist; Wed, 19 Dec 2001 11:35:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJZJZR019373 for ; Wed, 19 Dec 2001 11:35:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13981 for ; Wed, 19 Dec 2001 11:35:21 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14808 for ; Wed, 19 Dec 2001 12:36:08 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJJZJ819402 for ; Wed, 19 Dec 2001 11:35:19 -0800 (PST) Message-ID: <011001c188c4$11f040d0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <795A014AF92DD21182AF0008C7A404320DFBEE53@esealnt117> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 11:33:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Karim, > PFANE is an extension of the registration request so it's not really an > alternative. PFANE can be used as an extension to the pre-reg registration > request but I'm not necessarily saying this is a good idea. > It is an alternative because it does forwarding from previous FA by tunneling, exactly like Postreg, so the MN keeps getting its traffic while routing is updated on the HA. > > Based on our experiments with a similar, though slightly different, > > technique, PFANE is likely to perform about as well as Prereg > > when the MN is moving at the optimal speed, and much better where > > Prereg performance deteriorates as the MN moves faster > > or slower than the optimal speed. > > What is this optimal speed? Optimal for who? Hopefully not > Schumacher in his Ferrari ;-) > Given a 10 ms latency on the radio link, movement of the MN is such that: For a 9.6 kbps radio link, the time between L2 handover and the prehandover trigger is between 110 and 300 ms. For a 15 kbps radio link, the time between L2 handover and the prehandover trigger is between 65 and 160 ms. For a 300 kbps radio link, the time between L2 handover and the prehandover trigger is between 20 and 80 ms. That's what I mean by optimal. For other radio link latency and other data rates, the region is different (which is part of the problem). > > It should also perform > > better than standard MIPv4 handover because the MN > > doesn't have to wait for routing to change at the HA, but > > not as good as Postreg because of the delay associated with > > L2 handover and PFANE signalling. Of course, to verify > > this, we will have to test PFANE. > > How can pre-reg which anticipates the mobility be worse than > a protocol which runs after then MN has moved? > Because if the MN is moving so fast that it fails to complete the Prereg signaling on the old FA, it needs to recover with standard MIPv4 signaling on the new FA. While on the old FA, data traffic is blocked because of the Prereg signaling. While on the new FA, it can't get traffic until the routing changes on the HA. Please see http://geocities.com/kempf42/llanalysis.pdf for details. > I think I've already said what I think about the implementation issue. > If we don't have a spec which is stable enough we're just going in circles. > How do you know what FMIPv6 is going to be used for? If you apply this > argument to low latency soon people will be applying the same to > FMIPv6 and we'll just go back to where we started. We should just > get low latency into some RFC form, do the same for FMIPv6 once > MIPv6 is done and put this issue aside awaiting real deployment. > > There have been several specs which were not used because they > were not RFCs. 3GPP2 could well be a good example and provide a > reason why this work needs to be completed. RFCs can get revisited > as it becomes clear changes are needed. > I agree that the specs need to be stabilized. The question before the WG is how. I don't want something to get the imprinteur of an IETF standard before it is well understood and known to work. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 14:42: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 OAA05419 for ; Wed, 19 Dec 2001 14:42:55 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18530; Wed, 19 Dec 2001 12:41:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22472; Wed, 19 Dec 2001 11:41:50 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJf7ZR019481 for ; Wed, 19 Dec 2001 11:41:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJf71H019480 for mobile-ip-dist; Wed, 19 Dec 2001 11:41:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJf4ZR019473 for ; Wed, 19 Dec 2001 11:41:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15123 for ; Wed, 19 Dec 2001 11:41:05 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13434 for ; Wed, 19 Dec 2001 12:41:04 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJJf3819751 for ; Wed, 19 Dec 2001 11:41:03 -0800 (PST) Message-ID: <011601c188c4$df109ce0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <8C92E23A3E87FB479988285F9E22BE465AB894@ftmail> <3C20E0DA.1792AF45@iprg.nokia.com> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 11:39:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vjay, We are trying to do a complete job with FMIPv6. We did a lot of work on specifying interaction that was not done for low latency. Besides, there is no guarantee that the same discussion won't occur for FMIPv6 when we have similar simulation results, though I am willing to wait until the data are in before making any claims. My feeling is that the discussion here is not about whether the spec is too complex, it is more about whether the theoretical and experimental results presented so far are sufficient to judge the Prereg performance claims as inferior. And whether the promising results for a technique similar to PFANE are sufficient to justify considering it as an alternative for Prereg. Perhaps making the spec simpler would faciliatate understanding and IESG approval (I'm told 40 pages is the maximum if you want the IESG to read it in a short period of time), but to my mind that is the lesser issue. jak ----- Original Message ----- From: "Vijay Devarapalli" To: Sent: Wednesday, December 19, 2001 10:47 AM Subject: Re: [mobile-ip] WG Feedback Requested > Great!! But I am not sure how to proceed. I guess lot of work > went in merging BETH into FMIPv6. I can see Gopal getting ready > to kill me :) > > Vijay > > George Tsirtsis wrote: > > > > Vijay, > > > > Relax. All my references to Fast Handoffs are in plural...meaning both v4 > > and v6 specs....And yes, I also think that it was a mistake to merge BETH > > (as well as HTT) in the specs, although I am partly responsible as a > > co-author of FMIPv6 and since I let this happen in a moment of unbelievable > > weakness or temporary insanity or both. > > > > So, lets try to correct things. > > > > George > > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: Wednesday, December 19, 2001 6:23 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] WG Feedback Requested > > > > George Tsirtsis wrote: > > > > > GT> Yes I am saying that these specs are too big and complex to go through > > > the standards process as they are...they need to be broken down but to do > > > that we first need to figure out what is the basic functionality... > > > > this is incredible. Why werent you protesting when FMIPv6 spec > > bloated from 25 pages to over 62 pages? It was nice and simple > > when I started implemented it. > > > > Only a couple of us protested merging BETH with FMIPv6. I wish > > BETH had been a separate proposal. > > > > regards > > Vijay > > > > > > > > My point is that this doesn't justify putting low latency on hold. > > > > > > GT> If we do break them down then clearly we have some work to do before > > we > > > can push them forward. > > > > > > > In fact the PFANE is sent by the MN along with the registration > > > > request when it has attached to the new FA and is completing the > > > > L3 handoff. The low latency solutions aim at reducing L3 handoff > > > > latency to zero, which means that the MN must be in communication > > > > as soon as it attaches to the new FA. > > > > > > > > GT> The point is though that PFANE extension has been very > > > > stable for long > > > > time and provides lossless handoff that can be used in the > > > > short term and > > > > until either fast handoffs mature or link layers get make > > > > before break > > > > capability...in which case fast handoff specs are not > > > > needed. The only > > > > reason PFANEs are not a standard today is because they are > > > > part of the Route > > > > Optimization draft that is notionaly kept behind because of the MIPv6 > > > > security discussion. Yet PFANEs have no security issue > > > > themselves...hence > > > > the discussion about publishing them independently of > > > > Routing Optimization. > > > > > > I'm not against splitting PFANE from route opt. since I agree that > > > it solves a different problem than generic route opt. > > > However I can't agree with the argument that PFANE can be used for > > > loss-less handoff on the way to a next step. PFANE in route opt > > > is used after the MN has attached so that implies some latency/loss. > > > I say we provide the necessary fast handoff tools and let people > > > make their implementation choices. > > > > > > GT> Karim, it is well understood that for Make Before Break handoffs such > > as > > > all the inter-technology handoffs and any good enough link layers that > > also > > > allow it there is no need for the fast handoff specs. These are > > specifically > > > needed for break before make handoffs. But lets not get hanged up on this > > > the point is that you also agree that the PFANE proposal could be > > > standardized independently. > > > > > > Cheers > > > George > From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 14: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 ESMTP id OAA05676 for ; Wed, 19 Dec 2001 14:57:13 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15907; Wed, 19 Dec 2001 11:55:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26025; Wed, 19 Dec 2001 11:55:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJsXZR019658 for ; Wed, 19 Dec 2001 11:54:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJJsXQ5019657 for mobile-ip-dist; Wed, 19 Dec 2001 11:54:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJJsUZR019650 for ; Wed, 19 Dec 2001 11:54:30 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26416 for ; Wed, 19 Dec 2001 11:54:32 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10895 for ; Wed, 19 Dec 2001 12:54:31 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJJsU820531 for ; Wed, 19 Dec 2001 11:54:30 -0800 (PST) Message-ID: <012201c188c6$bff79320$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <4DA6EA82906FD511BE2F00508BCF053801C4C15F@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 11:52:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, ----- Hesham, > => Aha ! Thanks for the enlightenment, but you've missed > my point. Your theoritical analysis was > based on an implementation on a cellular link > with certain characteristics (e.g. you had to > send MIP signalling on the same channel as the > traffic data). Now your implementation is > on an ethernet, so I'm not sure which theory > that confirms. Look at the simulation description in http://geocities.com/kempf42/llanalysis.pdf. The simulation was designed to work like a cellular link (10 ms latency on the simulated radio channel). > In addition, the standard we follow is RFC2002, > your implementation didn't follow that standard, > so what do you disagree with when I say that > the implementation is not correct ? > Please clarify this to me. > Again, you are misrepresenting the discussion that Jon and Karim had on the mailing list. Our code was based on Solaris MIPv4, which implements RFC2002. How can you say that our implementation doesn't follow the standard when you've never looked at it? > > > > > If you want to prove these wrong, then I suggest > > you implement Prereg and show results that > > contradict the ones I presented. We are not talking about > > extraterristrial abductions here. > > => I don't have to implement it to show you > you've done something wrong, I can read > text ! section 4.1.1 of your paper is only one > example of the wrong implementation and there > is more. > No, but you have to implement something to prove to the working group that you've done something worth having lots of people implement as a standard. IETF is not an academic conference where people publish theoretical papers then everybody forgets about them. The work we do is implemented and deployed by many companies at great expense. It is incumbent upon us to prove that what we promote as a standard works as claimed. Now, Jon and I have done some implementation work that shows Prereg doesn't work very well for particular kinds of radio links. You and Karim are the authors of Prereg. If you think we are wrong, implement it yourselves and prove us wrong! > => Separating the draft again is simply > irrational and takes us back a year. > If the WG decides on the next steps, we > should abide of course, but I want to make > it clear that we have the right foundations > for othe decision. And that definitely (no offence) > should not be based on the presentation in SLC, > because anyone who reads the paper will realise > where the errors are. > Hesham, I've argued from the start that the WG should select either one or another of the techniques. The so-called "errors" in the SLC presentation are your misrepresentations of conversations between Jon and Karim on the mailing list. You have not ever addressed my specific question of Prereg's failure when the MN is moving too fast to complete the Prereg signaling on the old FA. Until you address this, your arguments are completely baseless. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 15:04: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 PAA05840 for ; Wed, 19 Dec 2001 15:04:34 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18824; Wed, 19 Dec 2001 12:03:05 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28005; Wed, 19 Dec 2001 12:03:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJK2NZR019805 for ; Wed, 19 Dec 2001 12:02:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJK2NB8019804 for mobile-ip-dist; Wed, 19 Dec 2001 12:02:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJK2KZR019797 for ; Wed, 19 Dec 2001 12:02:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28821 for ; Wed, 19 Dec 2001 12:02:22 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03649 for ; Wed, 19 Dec 2001 13:01:59 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJK2G821059 for ; Wed, 19 Dec 2001 12:02:16 -0800 (PST) Message-ID: <012a01c188c7$d5c5bd20$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <8C92E23A3E87FB479988285F9E22BE465AB895@ftmail> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 12:00:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit George, > GT> Actually I have.... Just because HTT is currently limited in scope it > does not mean that someone can not be tempted to extend it. HTT is for fast > mobiles. What about super fast mobiles? Say someone goes a bit mad and tries > to cover the bullet-train track with microcells...A bullet train can go > through a large number of microcells in very short time indeed! > Just kidding of course but you see my point about how far do you go with > optimizing something? Well, my sense of humor seems to have atrophied this morning. Maybe I need to go get stem cell therapy or something to get it back. :-) Actually, I don't see the need for anything further. And HTT is not just for superfast mobiles. It also works if the mobile wants to postpone getting a new care of address for any reason. Maybe the name sounds too "bell-shaped" for you? > Maybe specifying such an optimization separately would > help isolate the essential part of fast handoff from its > optimization...which is always a good thing. > I don't think so. IMHO, the fundamental problems are that: 1) Simulation results indicate that Prereg performance could be worse the standard MIPv4 for certain kinds of radio links. 2) Postreg doesn't handle MN initiated handover. We can solve 2) with PFANE. We can solve 1) by making Prereg informational or experimental so it is not Least Required to Implement for the standard. If the WG doesn't want to make the hard call, then let's take low latency to experimental and separate out PFANE as standards track for now. It might be worthwhile looking at splitting the draft up just to facilitate the IESG reading it, but that's a separate issue from what should be a proposed standard and what not. I think we ought to settle that issue first. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 15:15: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 PAA06091 for ; Wed, 19 Dec 2001 15:15:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11318; Wed, 19 Dec 2001 13:13:23 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01550; Wed, 19 Dec 2001 12:13:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKCrZR019920 for ; Wed, 19 Dec 2001 12:12:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJKCrN7019919 for mobile-ip-dist; Wed, 19 Dec 2001 12:12:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKCoZR019912 for ; Wed, 19 Dec 2001 12:12:50 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00240 for ; Wed, 19 Dec 2001 12:12:51 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10751 for ; Wed, 19 Dec 2001 13:12:32 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJKCo821548 for ; Wed, 19 Dec 2001 12:12:50 -0800 (PST) Message-ID: <014401c188c9$4f5b44b0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <4DA6EA82906FD511BE2F00508BCF053801C4C161@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 12:11:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, > => No I'm saying you are. Karim DISagreed with > this, I don't know how you got that impression > though. > Because he told me that both standard MIPv4 and Prereg have this problem. And if you look at the spec, you will see this is so. Karim...are you there? Did we not have this conversation in SLC? > > > > Also, I would like you to specifically answer this question, > > without any prevarication or attempt to divert the > > debate in another direction: > > > > Do you disagree with the theoretical data presented > > to the list last summer, and the experimental data > > presented at the SLC meeting, that Prereg will > > have worse performance than standard MIPv4 > > handover if the MN moves too fast for the > > Prereg signaling to complete while the MN > > is still on the old FA? > > > => Sigh ..... > James, IF you make certain assumptions on your link > layer capabilities(e.g. separating signalling You mean having the same signaling and bearer... > from payload bearers ...etc), then I agree, > you would see that PREREG is not optimal. HOWEVER, > these assumptions need not be made and I don't > know how many times we've discussed this and I said > the sentence above. > But the point is that Postreg does not have these problems regardless of *what* assumptions you make about the radio link. And neither does PFANE. > So if you have this inflexible link layer, > then use POST REG, this is the whole rationale > of the draft. > Then what is the point of even having Prereg? PFANE and Postreg both cover the space of what the MN and network need, and what Layer 2 triggers might be provided. > => Obviously you're not reading my messages. > If I tell I've implemented IPv6 with 64 bit addresses, > will you believe me ? Well if you think you have > to implement to prove me wrong then ...... well > it's strange to think that. > > So can you PLEASE answer my question on section 4.1.1 ? > otherwise there is no point in this discussion. > As I've said, you have misrepresented the discussion between Jon and Karim on the mailing list. Jon implemented our version of low latency in accordance with RFC 2002 and draft-ietf-mobileip-lowlatency-handoffs.txt. Now YOU answer MY question: Given that you admit that certain combinations of radio link parameters will result in suboptimal preformance for Prereg, and that both Postreg and PFANE don't have this problem, what is the point of keeping Prereg in the spec? jak From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 15:18: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 PAA06229 for ; Wed, 19 Dec 2001 15:18:28 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13950; Wed, 19 Dec 2001 13:16:58 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02148; Wed, 19 Dec 2001 12:15:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKEcZR019991 for ; Wed, 19 Dec 2001 12:14:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJKEc7L019990 for mobile-ip-dist; Wed, 19 Dec 2001 12:14:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKEYZR019983 for ; Wed, 19 Dec 2001 12:14:34 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00529 for ; Wed, 19 Dec 2001 12:14:36 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17022 for ; Wed, 19 Dec 2001 13:14:35 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJKEZ821637 for ; Wed, 19 Dec 2001 12:14:35 -0800 (PST) Message-ID: <014e01c188c9$8dc7cc50$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <795A014AF92DD21182AF0008C7A404320DFBEE54@esealnt117> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 12:12:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Karim, > Just to clarify I said exactly the opposite.....neither > will have such a condition. You send the reg. reply > before sending traffic to the MN, not the other way round. > Right, the HA sends it...but that doesn't guarantee that it will get to the FA before the MN's traffic gets there. Anyway, we differ on what we remember about this. Rashoman... jak From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 15:33: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 PAA06453 for ; Wed, 19 Dec 2001 15:33:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA00797; Wed, 19 Dec 2001 12:31:56 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05778; Wed, 19 Dec 2001 12:31:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKU7ZR020306 for ; Wed, 19 Dec 2001 12:30:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJKU7Nu020305 for mobile-ip-dist; Wed, 19 Dec 2001 12:30:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKU4ZR020298 for ; Wed, 19 Dec 2001 12:30:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03834 for ; Wed, 19 Dec 2001 12:30:06 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10993 for ; Wed, 19 Dec 2001 13:30:50 -0700 (MST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Dec 2001 15:25:33 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] WG Feedback Requested - differently asked Date: Wed, 19 Dec 2001 15:25:28 -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: Looks like I asked the wrong question. So, here's the question I'd like an answer to: - how many people are planning on this list are planning to *use* the MIP v4 low latency draft? Please identify yourselves. Re: the other items. The exchanges back and forth on the claims made about the performance of what's in the low latency draft don't seem to be getting us anywhere. Could we have two things: 1) discussions about who said and who claimed what off the list 2) results and rebuttals written up in draft format. I know this takes longer, but it's a lot easier to point to that and read it than something that is thrown on the list. From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 15:36: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 PAA06555 for ; Wed, 19 Dec 2001 15:36:50 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA02184; Wed, 19 Dec 2001 12:35:15 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06609; Wed, 19 Dec 2001 12:35:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKYbZR020374 for ; Wed, 19 Dec 2001 12:34:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJKYbfl020373 for mobile-ip-dist; Wed, 19 Dec 2001 12:34:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKYYZR020366 for ; Wed, 19 Dec 2001 12:34:34 -0800 (PST) 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 MAA14165 for ; Wed, 19 Dec 2001 12:34:36 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA07076 for ; Wed, 19 Dec 2001 12:34:34 -0800 (PST) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2650.21) id ; Wed, 19 Dec 2001 15:30:03 -0500 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] On Promoting the Low Latency Document Date: Wed, 19 Dec 2001 15:29:59 -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: One of the difficulties is that Low Latency claims to document methods for improving the performance of plain MIP. This is somewhat different than the claim typically made that a protocol will work. Perhaps a document with this sort of claim deserves a treatment different than what is normally given to Proposed Standards. There are a couple of ways this could be done - through the experimental process to allow implementors time to determine how it actually stands up to the claims made for it, or through more work up front with implementations and analysis of those. From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 16:00: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 QAA06995 for ; Wed, 19 Dec 2001 16:00:53 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA11162; Wed, 19 Dec 2001 12:59:27 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13031; Wed, 19 Dec 2001 12:59:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKwEZR020705 for ; Wed, 19 Dec 2001 12:58:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJKwEQk020704 for mobile-ip-dist; Wed, 19 Dec 2001 12:58:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJKwBZR020697 for ; Wed, 19 Dec 2001 12:58:11 -0800 (PST) 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 MAA00487 for ; Wed, 19 Dec 2001 12:58:13 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01371 for ; Wed, 19 Dec 2001 12:58:13 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJKwD823579 for ; Wed, 19 Dec 2001 12:58:13 -0800 (PST) Message-ID: <019201c188cf$a64aeae0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: Subject: Re: [mobile-ip] WG Feedback Requested - differently asked Date: Wed, 19 Dec 2001 12:56:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Phil, > So, here's the question I'd like an answer to: > > - how many people are planning on this list are planning to *use* the MIP v4 > low latency draft? Please > identify yourselves. > We have a project here at DoCoMo Labs USA in which we are planning to use the MIPv4 low latency draft (and possibly PFANE now that it has come up, we haven't discussed it yet). However, we are not planning this as a product or for deployment purposes, but rather as research. Our goal is to characterize the different algorithms. > > Re: the other items. The exchanges back and forth on the claims made about > the performance > of what's in the low latency draft don't seem to be getting us anywhere. > Could we have two > things: > 1) discussions about who said and who claimed what off the list OK. > 2) results and rebuttals written up in draft format. I know this takes > longer, but it's a lot > easier to point to that and read it than something that is thrown on the > list. > Sure, I've been in favor of this all along. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 16:04: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 QAA07102 for ; Wed, 19 Dec 2001 16:04:30 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16411; Wed, 19 Dec 2001 14:03:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14040; Wed, 19 Dec 2001 13:03:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJL2QZR020808 for ; Wed, 19 Dec 2001 13:02:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJL2Ph0020807 for mobile-ip-dist; Wed, 19 Dec 2001 13:02:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJL2MZR020800 for ; Wed, 19 Dec 2001 13:02:22 -0800 (PST) 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 NAA01687 for ; Wed, 19 Dec 2001 13:02:24 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19275 for ; Wed, 19 Dec 2001 13:02:24 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBJL2N823832 for ; Wed, 19 Dec 2001 13:02:23 -0800 (PST) Message-ID: <019801c188d0$3baf8be0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: Subject: Re: [mobile-ip] On Promoting the Low Latency Document Date: Wed, 19 Dec 2001 13:00:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Phil, > One of the difficulties is that Low Latency claims to document methods for > improving the > performance of plain MIP. This is somewhat different than the claim > typically made that > a protocol will work. Perhaps a document with this sort of claim deserves a > treatment > different than what is normally given to Proposed Standards. There are a > couple of ways > this could be done - through the experimental process to allow implementors > time to determine > how it actually stands up to the claims made for it, or through more work up > front with > implementations and analysis of those. > I agree with this. The problem is that, by IETF rules, this is not strictly necessary. So it becomes a judgement call on the part of the WG chairs and ADs, and therefore subject to second guessing from disgruntled WG members. Long term, perhaps we need to start a Poisson action to modify the IETF rules in this area. Short term, I like Raj's idea of taking the low latency document to experimental until more people have had a chance to implement and characterize it. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 17:25: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 RAA09182 for ; Wed, 19 Dec 2001 17:25:02 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14160; Wed, 19 Dec 2001 15:23:29 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02912; Wed, 19 Dec 2001 14:23:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJMMeZR021163 for ; Wed, 19 Dec 2001 14:22:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBJMMexk021162 for mobile-ip-dist; Wed, 19 Dec 2001 14:22:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJMMbZR021155 for ; Wed, 19 Dec 2001 14:22:37 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14441 for ; Wed, 19 Dec 2001 14:22:40 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01060 for ; Wed, 19 Dec 2001 15:22:39 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id PAA11923 for ; Wed, 19 Dec 2001 15:22:39 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA26203 for ; Wed, 19 Dec 2001 15:22:38 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 19 Dec 2001 16:22:38 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested - differently asked Date: Wed, 19 Dec 2001 16:22:38 -0600 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: Hello Phil, We are implementing low latency handoff draft. Probably we will have some results by March. regards, ajoy -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Wednesday, December 19, 2001 2:25 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] WG Feedback Requested - differently asked Looks like I asked the wrong question. So, here's the question I'd like an answer to: - how many people are planning on this list are planning to *use* the MIP v4 low latency draft? Please identify yourselves. Re: the other items. The exchanges back and forth on the claims made about the performance of what's in the low latency draft don't seem to be getting us anywhere. Could we have two things: 1) discussions about who said and who claimed what off the list 2) results and rebuttals written up in draft format. I know this takes longer, but it's a lot easier to point to that and read it than something that is thrown on the list. From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 19 23:48: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 XAA15525 for ; Wed, 19 Dec 2001 23:48:05 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA26754; Wed, 19 Dec 2001 21:46:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA01830; Wed, 19 Dec 2001 20:46:53 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK4kAZR021852 for ; Wed, 19 Dec 2001 20:46:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBK4kAQA021851 for mobile-ip-dist; Wed, 19 Dec 2001 20:46:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK4k7ZR021844 for ; Wed, 19 Dec 2001 20:46:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA01762 for ; Wed, 19 Dec 2001 20:46:09 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA18005 for ; Wed, 19 Dec 2001 21:46:08 -0700 (MST) Received: from AlperVAIO (dhcp68.docomo-usa.com [172.21.96.68]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBK4k8810699 for ; Wed, 19 Dec 2001 20:46:08 -0800 (PST) Message-ID: <006201c18910$55a91170$446015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: <4DA6EA82906FD511BE2F00508BCF053801C4C15F@Esealnt861.al.sw.ericsson.se> <012201c188c6$bff79320$7e6015ac@T23KEMPF> Subject: Re: [mobile-ip] WG Feedback Requested Date: Wed, 19 Dec 2001 20:39:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 Few general comments.... The discussions on FMIPv4 surely maps to FMIPv6... (an obvious observation) I think while PFANE is an improvement over regular MIPv4 as far as low latency is concerned, I don't think it can be as fast as prereg. Exchanging protocol signaling after the L2 handover would be slower. I think both approaches have L2 trigger requirements. How can one not require any? So saying postreg requires triggers is misleading. prereg does too. It's just they have different L2 trigger requirements. Because what postreg requires (source/target triggers) is not available on every link, we need prereg. And that's where people can use prereg. I think this is obvious even without comparing numbers. alper ----- Original Message ----- From: "James Kempf" To: Sent: Wednesday, December 19, 2001 11:52 AM Subject: Re: [mobile-ip] WG Feedback Requested > Hesham, > > ----- > Hesham, > > > => Aha ! Thanks for the enlightenment, but you've missed > > my point. Your theoritical analysis was > > based on an implementation on a cellular link > > with certain characteristics (e.g. you had to > > send MIP signalling on the same channel as the > > traffic data). Now your implementation is > > on an ethernet, so I'm not sure which theory > > that confirms. > > Look at the simulation description > in http://geocities.com/kempf42/llanalysis.pdf. > The simulation was designed to work like a cellular link > (10 ms latency on the simulated radio channel). > > > In addition, the standard we follow is RFC2002, > > your implementation didn't follow that standard, > > so what do you disagree with when I say that > > the implementation is not correct ? > > Please clarify this to me. > > > > Again, you are misrepresenting the discussion that > Jon and Karim had on the mailing list. Our > code was based on Solaris MIPv4, which > implements RFC2002. How can you say > that our implementation doesn't follow > the standard when you've never looked at it? > > > > > > > > > If you want to prove these wrong, then I suggest > > > you implement Prereg and show results that > > > contradict the ones I presented. We are not talking about > > > extraterristrial abductions here. > > > > => I don't have to implement it to show you > > you've done something wrong, I can read > > text ! section 4.1.1 of your paper is only one > > example of the wrong implementation and there > > is more. > > > > No, but you have to implement something > to prove to the working group > that you've done something worth having > lots of people implement as a standard. IETF > is not an academic conference where people > publish theoretical papers then everybody > forgets about them. The work we do is > implemented and deployed by many companies > at great expense. It is incumbent upon us > to prove that what we promote as a standard > works as claimed. > > Now, Jon and I have done some implementation > work that shows Prereg doesn't work very > well for particular kinds of radio links. You > and Karim are the authors of Prereg. If you > think we are wrong, implement it yourselves > and prove us wrong! > > > => Separating the draft again is simply > > irrational and takes us back a year. > > If the WG decides on the next steps, we > > should abide of course, but I want to make > > it clear that we have the right foundations > > for othe decision. And that definitely (no offence) > > should not be based on the presentation in SLC, > > because anyone who reads the paper will realise > > where the errors are. > > > > Hesham, I've argued from the start that the > WG should select either one or another of > the techniques. The so-called "errors" in > the SLC presentation are your misrepresentations > of conversations between Jon and Karim on > the mailing list. You have not ever addressed > my specific question of Prereg's failure > when the MN is moving too fast to > complete the Prereg signaling on the > old FA. > > Until you address this, your arguments are > completely baseless. > > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 04:14: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 EAA04306 for ; Thu, 20 Dec 2001 04:14:34 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA25576; Thu, 20 Dec 2001 01:13:15 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03207; Thu, 20 Dec 2001 01:13:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK9CEZR022359 for ; Thu, 20 Dec 2001 01:12:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBK9CE92022358 for mobile-ip-dist; Thu, 20 Dec 2001 01:12:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK9CBZR022351 for ; Thu, 20 Dec 2001 01:12:11 -0800 (PST) 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 BAA03404 for ; Thu, 20 Dec 2001 01:12:12 -0800 (PST) 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 BAA02548 for ; Thu, 20 Dec 2001 01:12:11 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBK9C9I26604 for ; Thu, 20 Dec 2001 10:12:09 +0100 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 KAA08845 for ; Thu, 20 Dec 2001 10:12:09 +0100 (MET) 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 fBK9C9D62433 for ; Thu, 20 Dec 2001 10:12:09 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112200912.fBK9C9D62433@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] icmpv6 In-reply-to: Your message of Wed, 19 Dec 2001 07:40:40 PST. Date: Thu, 20 Dec 2001 10:12:09 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: sorry, i still do not understand what you are trying to say. => argh! I can't say really more than the specs... consider the following 0x01:0xY:0xAAAAAAAA => 0x01:0xYY:0xAAAAAAAAAAAAAAAA questions are: 1. what is the value of Y ? => 0x02 if there is no extra padding. 2. If it is 2 then where and what padding do you add ? The content and format of this field (including byte and bit ordering) is expected to be specified in specific documents that describe how IPv6 operates over different link layers. For instance, [IPv6-ETHER]. => so there should be a specific (to the link-layer) document that describes how IPv6 operates over this link-layer and specifies the content and format of the link-layer address field, including the padding because 2+8 != 0 [8]. I don't know a link-layer using EUI 64 as addresses nor an IPv6 over foo document for it. But IMHO the only thing should be to decide where to put the padding, likely after the length field in order to keep the address 8 byte aligned. (BTW can you say more about the link-layer using EUI 64 as addresses?) Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 04:23: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 EAA04425 for ; Thu, 20 Dec 2001 04:23:31 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA27653; Thu, 20 Dec 2001 02:21:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04672; Thu, 20 Dec 2001 01:22:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK9LVZR022525 for ; Thu, 20 Dec 2001 01:21:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBK9LVh3022524 for mobile-ip-dist; Thu, 20 Dec 2001 01:21:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBK9LSZR022517 for ; Thu, 20 Dec 2001 01:21:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17198 for ; Thu, 20 Dec 2001 01:21:29 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13090 for ; Thu, 20 Dec 2001 02:21:28 -0700 (MST) 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 fBK9LRJ02938 for ; Thu, 20 Dec 2001 10:21:27 +0100 (MET) Received: from era-t.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA12263; Thu, 20 Dec 2001 10:21:27 +0100 Message-ID: <3C21ACD8.19B0738@era-t.ericsson.se> Date: Thu, 20 Dec 2001 10:18:16 +0100 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] Prefix lifetime 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 Peter, "Peter Grimstrup (TED)" wrote: > > I'm not very familiar with the ND procedures, but anyway here is > my question: > > Section 9.1 in ID-15 says: > "The lifetime for > the each Binding Cache entry MUST NOT be greater than the minimum > remaining valid lifetime for all subnet prefixes on the mobile > node's home link." > > When a prefix is no longer to be used, the lifetime is decreased > eventually to zero, when the prefix is removed. > While decreasing the lifetime, i.e. when the value has become > "low", it doesn't seem reasonable to use this value as limit > on granted lifetime of a BU. > Could this be avoided by only minimising over prefixes with > nonzero preferred lifetime - or have I misunderstood? There's something on this as well: 9.8.4. Lifetimes for Changed Prefixes As described in Section 9.1, the lifetime returned by the home agent in a Binding Acknowledgement MUST be no greater than the remaining valid lifetime for the subnet prefix in the mobile node's home address. Furthermore, as described in Section 10.9, Binding Updates sent by the mobile node to other nodes MUST use a lifetime no greater than the remaining lifetime of its home registration of its primary care-of address. These limits on the binding lifetime serve to prohibit use of a mobile node's home address after it becomes invalid. The mobile node SHOULD further limit the lifetimes that it sends on any Binding Updates to be within the remaining preferred lifetime for the prefix in its home address. So MN SHOULD limit BU lifetime to preferred lifetime, and HA MUST limit it to valid lifetime. Sounds fine to me. Deprecated (pref <= 0) addresses are still valid to use. /Mattias > > Thanks > Peter > ---------------------------------------------------------------- > 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 Thu Dec 20 05:31: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 FAA05158 for ; Thu, 20 Dec 2001 05:31:12 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA20930; Thu, 20 Dec 2001 02:30:08 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25802; Thu, 20 Dec 2001 02:30:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKATJZR022948 for ; Thu, 20 Dec 2001 02:29:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKATJor022947 for mobile-ip-dist; Thu, 20 Dec 2001 02:29:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKATGZR022940 for ; Thu, 20 Dec 2001 02:29:16 -0800 (PST) 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 CAA15614 for ; Thu, 20 Dec 2001 02:29:17 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26863 for ; Thu, 20 Dec 2001 02:29:16 -0800 (PST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 05:29:15 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB897@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested - differently asked Date: Thu, 20 Dec 2001 05:29:08 -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: Ajoy, Is it possible to tell us which parts? Thanks George -----Original Message----- From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Wednesday, December 19, 2001 10:23 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] WG Feedback Requested - differently asked Hello Phil, We are implementing low latency handoff draft. Probably we will have some results by March. regards, ajoy -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Wednesday, December 19, 2001 2:25 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] WG Feedback Requested - differently asked Looks like I asked the wrong question. So, here's the question I'd like an answer to: - how many people are planning on this list are planning to *use* the MIP v4 low latency draft? Please identify yourselves. Re: the other items. The exchanges back and forth on the claims made about the performance of what's in the low latency draft don't seem to be getting us anywhere. Could we have two things: 1) discussions about who said and who claimed what off the list 2) results and rebuttals written up in draft format. I know this takes longer, but it's a lot easier to point to that and read it than something that is thrown on the list. From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 05:50: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 FAA05367 for ; Thu, 20 Dec 2001 05:50:10 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA10975; Thu, 20 Dec 2001 03:48:47 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27088; Thu, 20 Dec 2001 02:49:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKAmIZR023181 for ; Thu, 20 Dec 2001 02:48:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKAmInU023180 for mobile-ip-dist; Thu, 20 Dec 2001 02:48:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKAmFZR023173 for ; Thu, 20 Dec 2001 02:48:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27497 for ; Thu, 20 Dec 2001 02:48:17 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06642 for ; Thu, 20 Dec 2001 03:48:16 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 05:48:16 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB89A@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Thu, 20 Dec 2001 05:48:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Yes, I do not know where the idea of PFANE *replacing* fast handoffs came from. What I said is that make before break handoffs do not need fast handoffs, which I hope is well understood since it was clearly stated when we started working on fast handoffs...Yet for break before make these are essential for good performance. PFANE can help with packet loss not with letancy. George -----Original Message----- From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] Sent: Thursday, December 20, 2001 4:40 AM To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] WG Feedback Requested Few general comments.... The discussions on FMIPv4 surely maps to FMIPv6... (an obvious observation) I think while PFANE is an improvement over regular MIPv4 as far as low latency is concerned, I don't think it can be as fast as prereg. Exchanging protocol signaling after the L2 handover would be slower. I think both approaches have L2 trigger requirements. How can one not require any? So saying postreg requires triggers is misleading. prereg does too. It's just they have different L2 trigger requirements. Because what postreg requires (source/target triggers) is not available on every link, we need prereg. And that's where people can use prereg. I think this is obvious even without comparing numbers. alper ----- Original Message ----- From: "James Kempf" To: Sent: Wednesday, December 19, 2001 11:52 AM Subject: Re: [mobile-ip] WG Feedback Requested > Hesham, > > ----- > Hesham, > > > => Aha ! Thanks for the enlightenment, but you've missed > > my point. Your theoritical analysis was > > based on an implementation on a cellular link > > with certain characteristics (e.g. you had to > > send MIP signalling on the same channel as the > > traffic data). Now your implementation is > > on an ethernet, so I'm not sure which theory > > that confirms. > > Look at the simulation description > in http://geocities.com/kempf42/llanalysis.pdf. > The simulation was designed to work like a cellular link > (10 ms latency on the simulated radio channel). > > > In addition, the standard we follow is RFC2002, > > your implementation didn't follow that standard, > > so what do you disagree with when I say that > > the implementation is not correct ? > > Please clarify this to me. > > > > Again, you are misrepresenting the discussion that > Jon and Karim had on the mailing list. Our > code was based on Solaris MIPv4, which > implements RFC2002. How can you say > that our implementation doesn't follow > the standard when you've never looked at it? > > > > > > > > > If you want to prove these wrong, then I suggest > > > you implement Prereg and show results that > > > contradict the ones I presented. We are not talking about > > > extraterristrial abductions here. > > > > => I don't have to implement it to show you > > you've done something wrong, I can read > > text ! section 4.1.1 of your paper is only one > > example of the wrong implementation and there > > is more. > > > > No, but you have to implement something > to prove to the working group > that you've done something worth having > lots of people implement as a standard. IETF > is not an academic conference where people > publish theoretical papers then everybody > forgets about them. The work we do is > implemented and deployed by many companies > at great expense. It is incumbent upon us > to prove that what we promote as a standard > works as claimed. > > Now, Jon and I have done some implementation > work that shows Prereg doesn't work very > well for particular kinds of radio links. You > and Karim are the authors of Prereg. If you > think we are wrong, implement it yourselves > and prove us wrong! > > > => Separating the draft again is simply > > irrational and takes us back a year. > > If the WG decides on the next steps, we > > should abide of course, but I want to make > > it clear that we have the right foundations > > for othe decision. And that definitely (no offence) > > should not be based on the presentation in SLC, > > because anyone who reads the paper will realise > > where the errors are. > > > > Hesham, I've argued from the start that the > WG should select either one or another of > the techniques. The so-called "errors" in > the SLC presentation are your misrepresentations > of conversations between Jon and Karim on > the mailing list. You have not ever addressed > my specific question of Prereg's failure > when the MN is moving too fast to > complete the Prereg signaling on the > old FA. > > Until you address this, your arguments are > completely baseless. > > > jak > > From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 06:12: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 GAA05589 for ; Thu, 20 Dec 2001 06:12:19 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA21983; Thu, 20 Dec 2001 04:11:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29850; Thu, 20 Dec 2001 03:11:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKBAXZR023352 for ; Thu, 20 Dec 2001 03:10:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKBAXc6023351 for mobile-ip-dist; Thu, 20 Dec 2001 03:10:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKBAUZR023344 for ; Thu, 20 Dec 2001 03:10:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16278 for ; Thu, 20 Dec 2001 03:10:30 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11682 for ; Thu, 20 Dec 2001 04:10:29 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBKBASJ14193 for ; Thu, 20 Dec 2001 12:10:28 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Dec 20 12:10:13 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 12:10:27 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C162@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Thu, 20 Dec 2001 12:10:07 +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: > > > I agree with this as well. PFANE can perform optimization > > > now, and is > > > particularly important for protocols such as 802.11 > in which the > > > MN controls movement. The only reason it is being held up > > > is that the > > > security > > > issues of full route optimization are much more complex > > > than the simple > > > FA/FA security > > > required for PFANE. Therefore, I think it needs to be > moved into a > > > separate > > > draft. > > > > => I'm stunned by this discussion, I thought we were > > all aware of the existence of PFANE when we did > > the lowlatency draft ! > > Well, maybe we missed it => WE didn't miss it, YOU obviously did. because it was bundled > into the route optimization draft. I don't think > there is any harm in admiting that a simple existing > technique which we know works is preferable > to something that is not yet well understood, > for the short term. => I can't explain this any better and as a co-author of the draft you shouldn't need me to explain it to you. If you don't understand that PFANE is not an alternative to PREREG then I suggest you read both, the low latency and route opt drafts. > > The _entire_ purpose of the draft was to show > > that the handover speed can be reduced due to > > anticipation of the handover, so how can you > > possibly claim that PFANE is an alternative ? > > > > The simulation results we did showed that a technique > similar to PFANE worked about as well as Prereg. > The paper is at > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-ha ndover-00.tx => Did you simulate it or implement it ????????? t Of course, we will have to do simulations for PFANE itself to be sure. => So how can you make the claims above if you didn't simulate both on the exact same environment ?????? Please be consistent with your claims. Hesham jak From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 06:17: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 GAA05644 for ; Thu, 20 Dec 2001 06:17:10 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA24177; Thu, 20 Dec 2001 04:15:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16983; Thu, 20 Dec 2001 03:15:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKBFIZR023467 for ; Thu, 20 Dec 2001 03:15:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKBFIoI023466 for mobile-ip-dist; Thu, 20 Dec 2001 03:15:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKBFFZR023459 for ; Thu, 20 Dec 2001 03:15:15 -0800 (PST) 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 DAA16892 for ; Thu, 20 Dec 2001 03:15:16 -0800 (PST) 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 DAA18204 for ; Thu, 20 Dec 2001 03:15:14 -0800 (PST) Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBKBFDJ19815 for ; Thu, 20 Dec 2001 12:15:13 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Dec 20 12:15:12 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 12:06:38 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C163@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Thu, 20 Dec 2001 12:14:52 +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: > > => Aha ! Thanks for the enlightenment, but you've missed > > my point. Your theoritical analysis was > > based on an implementation on a cellular link > > with certain characteristics (e.g. you had to > > send MIP signalling on the same channel as the > > traffic data). Now your implementation is > > on an ethernet, so I'm not sure which theory > > that confirms. > > Look at the simulation description > in http://geocities.com/kempf42/llanalysis.pdf. > The simulation was designed to work like a cellular link > (10 ms latency on the simulated radio channel). => Like a radio channel ???! You're assuming latency is the only charactersitic of a radio channel. So can you please tell us, did you simulate it or implement it ? Because previously you claimed to have implemented it. It's NOT the same thing btw. > > > In addition, the standard we follow is RFC2002, > > your implementation didn't follow that standard, > > so what do you disagree with when I say that > > the implementation is not correct ? > > Please clarify this to me. > > > > Again, you are misrepresenting the discussion that > Jon and Karim had on the mailing list. Our > code was based on Solaris MIPv4, which > implements RFC2002. How can you say > that our implementation doesn't follow > the standard when you've never looked at it? > => Have you been reading the emails ?? Jon explained how his implementation works and it was clearly wrong. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 06: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 GAA05746 for ; Thu, 20 Dec 2001 06:25:32 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA27991; Thu, 20 Dec 2001 04:24:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18010; Thu, 20 Dec 2001 03:24:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKBNbZR023574 for ; Thu, 20 Dec 2001 03:23:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKBNbIJ023573 for mobile-ip-dist; Thu, 20 Dec 2001 03:23:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKBNYZR023566 for ; Thu, 20 Dec 2001 03:23:34 -0800 (PST) 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 DAA01212 for ; Thu, 20 Dec 2001 03:23:34 -0800 (PST) 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 DAA21686 for ; Thu, 20 Dec 2001 03:23:33 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBKBNWJ29556 for ; Thu, 20 Dec 2001 12:23:32 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Dec 20 12:23:31 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 12:14:58 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C164@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Thu, 20 Dec 2001 12:23:11 +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: > Because he told me that both standard MIPv4 > and Prereg have this problem. And if you > look at the spec, you will see this is so. > > Karim...are you there? Did we not have > this conversation in SLC? => I just saw Karim's reply, I don't think I need to say anymore. > > So if you have this inflexible link layer, > > then use POST REG, this is the whole rationale > > of the draft. > > > > Then what is the point of even having Prereg? => Why don't you read the applicability statements again. And add to them one new point, POSTREG does not work for ETHERNET or any link layer that has MAC addresses ! PFANE does NOT have anticipation. I hope this is cleare. > > => Obviously you're not reading my messages. > > If I tell I've implemented IPv6 with 64 bit addresses, > > will you believe me ? Well if you think you have > > to implement to prove me wrong then ...... well > > it's strange to think that. > > > > So can you PLEASE answer my question on section 4.1.1 ? > > otherwise there is no point in this discussion. > > > > As I've said, you have misrepresented the discussion > between Jon and Karim on the mailing list. Jon implemented > our version of low latency in accordance with RFC 2002 > and draft-ietf-mobileip-lowlatency-handoffs.txt. => Why don't you answer my questions (technically) instead of claiming that I'm misrepresenting conversations ? Jon hasn't said that. If you're going to answer me let's start from section 4.4.1 and then go through the rest of your paper. If you're not going to respond to that, then as I said earlier, this discussion is not useful or constructive. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 07:17: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 HAA06226 for ; Thu, 20 Dec 2001 07:17:36 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA23713; Thu, 20 Dec 2001 04:16:32 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23651; Thu, 20 Dec 2001 04:16:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKCFVZR023802 for ; Thu, 20 Dec 2001 04:15:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKCFVgT023801 for mobile-ip-dist; Thu, 20 Dec 2001 04:15:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKCFSZR023794 for ; Thu, 20 Dec 2001 04:15:28 -0800 (PST) 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 EAA06650 for ; Thu, 20 Dec 2001 04:15:29 -0800 (PST) Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23968 for ; Thu, 20 Dec 2001 04:15:29 -0800 (PST) Received: from SWEETPEA (sweetpea.comet.columbia.edu [128.59.65.202]) by ponyexpress.ee.columbia.edu (8.11.3/8.11.3) with SMTP id fBKCFSQ29840; Thu, 20 Dec 2001 07:15:28 -0500 From: "Andrew T. Campbell" To: Cc: "Andrew Campbell \(E-mail\)" Subject: [mobile-ip] Comparison of IP micro-mobility protocols Date: Thu, 20 Dec 2001 07:12:14 -0500 Message-ID: <001501c1894f$903db770$ca413b80@SWEETPEA> 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 CWS, Build 9.0.2416 (9.0.2911.0) x-mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <8C92E23A3E87FB479988285F9E22BE465AB897@ftmail> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Folks: All this talk about simulation - L2 triggered me: Here is a paper on the performance comparison of Cellular IP, Hawaii and Hierarchical Mobile IP using the Columbia IP Micro-mobility Software (CIMS): http://comet.columbia.edu/micromobility/ CIMS includes the ns-2 extension for all three protocols for those interested in using it. The paper that goes with the code is as follows: A. T. Campbell, Gomez, J., Kim, S., Turanyi, Z., Wan, C-Y. and A, Valko "Comparison of IP Micro-Mobility Protocols", IEEE Wireless Communications Magazine, Vol. 9, No. 1, February 2002. You can get a copy from: http://comet.columbia.edu/~campbell/andrew/publications/papers/pcs2001.pdf \begin{abstract} We present a performance comparison of a number of key micro-mobility protocols that have been discussed in the IETF Mobile IP Working Group over the past several years. IP micro-mobility protocols complement Mobile IP by offering fast and seamless handoff control in limited geographical areas and IP paging in support of scalability and power conservation. We show that despite the apparent differences between IP micro-mobility protocols, the operational principles that govern them are largely similar. We use this observation to establish a generic micro-mobility model to better understand design and performance trade offs. A number of key design choices are identified within the context of the generic model related to handoff quality and route control messaging. We present simulation results for Cellular IP, Hawaii and Hierarchical Mobile IP and evaluate the handoff performance of these protocols. Simulation results presented in this paper are based on the Columbia IP Micro-mobility Software (CIMS), which is freely available from the Web (comet.columbia.edu/micromobility) for experimentation. \end{abstract} Regards, --- Andrew http://comet.columbia.edu/~campbell From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 08:09: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 IAA06846 for ; Thu, 20 Dec 2001 08:09:43 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA09158; Thu, 20 Dec 2001 05:08:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13251; Thu, 20 Dec 2001 05:08:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKD7vZR024027 for ; Thu, 20 Dec 2001 05:07:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKD7vHW024026 for mobile-ip-dist; Thu, 20 Dec 2001 05:07:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKD7sZR024019 for ; Thu, 20 Dec 2001 05:07:54 -0800 (PST) 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 FAA29313 for ; Thu, 20 Dec 2001 05:07:56 -0800 (PST) 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 FAA06990 for ; Thu, 20 Dec 2001 05:07:55 -0800 (PST) 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 fBKD7qJ28591 for ; Thu, 20 Dec 2001 14:07:52 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Dec 20 14:07:52 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 13:59:18 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C165@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested - differently asked Date: Thu, 20 Dec 2001 14:07:27 +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: > Is it possible to tell us which parts? => Why are you asking about this George ? Do you think this will help the discussion ? I don't want to go back another year and start a futile discussion about the comparison between the different mechanisms on the list. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 08:50: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 IAA07198 for ; Thu, 20 Dec 2001 08:50:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06024; Thu, 20 Dec 2001 06:49:01 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17910; Thu, 20 Dec 2001 05:49:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKDmYZR024178 for ; Thu, 20 Dec 2001 05:48:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKDmYes024177 for mobile-ip-dist; Thu, 20 Dec 2001 05:48:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKDmVZR024170 for ; Thu, 20 Dec 2001 05:48:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15418 for ; Thu, 20 Dec 2001 05:48:33 -0800 (PST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA07779 for ; Thu, 20 Dec 2001 06:49:18 -0700 (MST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 08:48:30 -0500 Message-ID: <8C92E23A3E87FB479988285F9E22BE465AB89F@ftmail> From: George Tsirtsis To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested - differently asked Date: Thu, 20 Dec 2001 08:48:26 -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: I am asking because the spec describes multiple, largely independend mechanisms. -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Thursday, December 20, 2001 1:07 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] WG Feedback Requested - differently asked > Is it possible to tell us which parts? => Why are you asking about this George ? Do you think this will help the discussion ? I don't want to go back another year and start a futile discussion about the comparison between the different mechanisms on the list. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 10:23:22 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08833 for ; Thu, 20 Dec 2001 10:23:22 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01847; Thu, 20 Dec 2001 07:21:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00059; Thu, 20 Dec 2001 07:21:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKFKWZR024414 for ; Thu, 20 Dec 2001 07:20:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKFKWmg024413 for mobile-ip-dist; Thu, 20 Dec 2001 07:20:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKFKTZR024406 for ; Thu, 20 Dec 2001 07:20:29 -0800 (PST) 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 HAA00723 for ; Thu, 20 Dec 2001 07:20:30 -0800 (PST) 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 HAA07569 for ; Thu, 20 Dec 2001 07:20:29 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id IAA14844 for ; Thu, 20 Dec 2001 08:20:24 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA24904 for ; Thu, 20 Dec 2001 08:20:24 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Thu, 20 Dec 2001 09:20:24 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested - differently asked Date: Thu, 20 Dec 2001 09:20:21 -0600 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: George, We will implement both post and pre registration. But initially we are concentrating on post registration. regards, ajoy -----Original Message----- From: George Tsirtsis [mailto:G.Tsirtsis@flarion.com] Sent: Thursday, December 20, 2001 4:29 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] WG Feedback Requested - differently asked Ajoy, Is it possible to tell us which parts? Thanks George -----Original Message----- From: Singh Ajoy-ASINGH1 [mailto:ASINGH1@motorola.com] Sent: Wednesday, December 19, 2001 10:23 PM To: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] WG Feedback Requested - differently asked Hello Phil, We are implementing low latency handoff draft. Probably we will have some results by March. regards, ajoy -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: Wednesday, December 19, 2001 2:25 PM To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] WG Feedback Requested - differently asked Looks like I asked the wrong question. So, here's the question I'd like an answer to: - how many people are planning on this list are planning to *use* the MIP v4 low latency draft? Please identify yourselves. Re: the other items. The exchanges back and forth on the claims made about the performance of what's in the low latency draft don't seem to be getting us anywhere. Could we have two things: 1) discussions about who said and who claimed what off the list 2) results and rebuttals written up in draft format. I know this takes longer, but it's a lot easier to point to that and read it than something that is thrown on the list. From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 11:34:55 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11708 for ; Thu, 20 Dec 2001 11:34:55 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05108; Thu, 20 Dec 2001 08:33:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11165; Thu, 20 Dec 2001 08:33:46 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGX1ZR024969 for ; Thu, 20 Dec 2001 08:33:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKGX1vM024968 for mobile-ip-dist; Thu, 20 Dec 2001 08:33:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGWwZR024961 for ; Thu, 20 Dec 2001 08:32:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12264 for ; Thu, 20 Dec 2001 08:32:59 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21700 for ; Thu, 20 Dec 2001 09:32:40 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBKGWw800338 for ; Thu, 20 Dec 2001 08:32:58 -0800 (PST) Message-ID: <002101c18973$c29036c0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <4DA6EA82906FD511BE2F00508BCF053801C4C15F@Esealnt861.al.sw.ericsson.se> <012201c188c6$bff79320$7e6015ac@T23KEMPF> <006201c18910$55a91170$446015ac@AlperVAIO> Subject: Re: [mobile-ip] WG Feedback Requested Date: Thu, 20 Dec 2001 08:31:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alper, > I think while PFANE is an improvement > over regular MIPv4 as far as low > latency is concerned, I don't think > it can be as fast as prereg. Exchanging > protocol signaling after the L2 handover would > be slower. > Please see http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx t. This contains measurments of a technique that is similar to PFANE. The performance is about the same as Prereg for high latency radio links. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 11:53: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 LAA12180 for ; Thu, 20 Dec 2001 11:53:04 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07413; Thu, 20 Dec 2001 09:51:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15496; Thu, 20 Dec 2001 08:52:00 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGp8ZR025085 for ; Thu, 20 Dec 2001 08:51:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKGp8W3025084 for mobile-ip-dist; Thu, 20 Dec 2001 08:51:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKGp4ZR025077 for ; Thu, 20 Dec 2001 08:51:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15300 for ; Thu, 20 Dec 2001 08:51:06 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21365 for ; Thu, 20 Dec 2001 09:51:52 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBKGp0800884 for ; Thu, 20 Dec 2001 08:51:00 -0800 (PST) Message-ID: <006b01c18976$477a2ce0$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <4DA6EA82906FD511BE2F00508BCF053801C4C162@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] WG Feedback Requested Date: Thu, 20 Dec 2001 08:49:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, > > The simulation results we did showed that a technique > > similar to PFANE worked about as well as Prereg. > > The paper is at > > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-ha > ndover-00.tx > > => Did you simulate it or implement it ????????? > > > t > Of course, we will have to do simulations for > PFANE itself to be sure. > > => So how can you make the claims above if you > didn't simulate both on the exact same environment ?????? > Please be consistent with your claims. > Read the paper. It contains a description of the experimental method, and if it isn't clear, then I'll be happy to clarify. If you have any implementation skills at all, it should be enough to allow you to duplicate the work and either verify or refute our results. That's what engineering and science are all about, not sniping on mailing lists at people who do real work in an attempt to find out whether something works or not. And, that's about all I've got to say on this topic. Happy holidays... jak From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 12:30: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 MAA13577 for ; Thu, 20 Dec 2001 12:30:46 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04922; Thu, 20 Dec 2001 09:29:02 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10985; Thu, 20 Dec 2001 09:28:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKHRgZR025338 for ; Thu, 20 Dec 2001 09:27:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKHRgoK025337 for mobile-ip-dist; Thu, 20 Dec 2001 09:27:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKHRcZR025330 for ; Thu, 20 Dec 2001 09:27:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10814 for ; Thu, 20 Dec 2001 09:27:40 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17877 for ; Thu, 20 Dec 2001 10:27:39 -0700 (MST) 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 fBKHRcJ28030 for ; Thu, 20 Dec 2001 18:27:38 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Dec 20 18:27:37 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 18:27:22 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C170@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "'Phil Roberts'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Thu, 20 Dec 2001 18:27:16 +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: I will obviously ignore replying to this stupidity on a public list. You've just shown your own implementation and conversational skills > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, December 20, 2001 11:49 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] WG Feedback Requested > > > Hesham, > > > > The simulation results we did showed that a technique > > > similar to PFANE worked about as well as Prereg. > > > The paper is at > > > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-ha > > ndover-00.tx > > > > => Did you simulate it or implement it ????????? > > > > > > t > > Of course, we will have to do simulations for > > PFANE itself to be sure. > > > > => So how can you make the claims above if you > > didn't simulate both on the exact same environment ?????? > > Please be consistent with your claims. > > > > Read the paper. It contains a description of the > experimental method, and if it isn't clear, > then I'll be happy to clarify. > If you have any implementation skills at > all, it should be enough to allow you to duplicate > the work and either verify or refute our results. > That's what engineering and science are all > about, not sniping on mailing lists at people who do real > work in an attempt to find out whether something > works or not. > > And, that's about all I've got to say on this > topic. Happy holidays... > > > jak > From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 12:47: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 MAA14357 for ; Thu, 20 Dec 2001 12:47:47 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24021; Thu, 20 Dec 2001 10:46:22 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17156; Thu, 20 Dec 2001 09:46:36 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKHjoZR025561 for ; Thu, 20 Dec 2001 09:45:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKHjnEi025560 for mobile-ip-dist; Thu, 20 Dec 2001 09:45:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKHjkZR025553 for ; Thu, 20 Dec 2001 09:45:46 -0800 (PST) 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 JAA26308 for ; Thu, 20 Dec 2001 09:45:49 -0800 (PST) Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05514 for ; Thu, 20 Dec 2001 09:45:47 -0800 (PST) Received: (qmail 16263 invoked from network); 20 Dec 2001 17:45:46 -0000 Received: from unknown (HELO dell) ([138.89.30.21]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Dec 2001 17:45:46 -0000 Message-ID: <004601c1897e$68663d60$6401a8c0@dell> From: "Jonathan Wood" To: References: <4DA6EA82906FD511BE2F00508BCF053801C4C164@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] WG Feedback Requested Date: Thu, 20 Dec 2001 12:44:50 -0500 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.2615.200 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 > > As I've said, you have misrepresented the discussion > > between Jon and Karim on the mailing list. Jon implemented > > our version of low latency in accordance with RFC 2002 > > and draft-ietf-mobileip-lowlatency-handoffs.txt. > > => Why don't you answer my questions (technically) > instead of claiming that I'm misrepresenting > conversations ? Jon hasn't said that. If I haven't said that because I was on a plane all day yesterday. I do believe you are misunderstanding the conversation Karim and I had. The discussion about when to reset the default route was a tangent; I broke it off because I though it wasn't important enough to continue spamming the list with it. The implementation worked as specified in the draft and RFC2002. More importantly, it did NOT affect the performance results we got. I'd be happy to discuss the details more, but let's take it offline for now. Jonathan From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 13:00: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 NAA14752 for ; Thu, 20 Dec 2001 13:00:21 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20242; Thu, 20 Dec 2001 09:59:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02818; Thu, 20 Dec 2001 09:59:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKHwNZR025728 for ; Thu, 20 Dec 2001 09:58:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKHwNDp025727 for mobile-ip-dist; Thu, 20 Dec 2001 09:58:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKHwKZR025720 for ; Thu, 20 Dec 2001 09:58:20 -0800 (PST) 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 JAA29630 for ; Thu, 20 Dec 2001 09:58:23 -0800 (PST) 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 JAA29409 for ; Thu, 20 Dec 2001 09:58:22 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBKHwLJ13354 for ; Thu, 20 Dec 2001 18:58:21 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Dec 20 18:58:05 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 18:58:05 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C172@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] WG Feedback Requested Date: Thu, 20 Dec 2001 18:58:04 +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: > > > > > As I've said, you have misrepresented the discussion > > > between Jon and Karim on the mailing list. Jon implemented > > > our version of low latency in accordance with RFC 2002 > > > and draft-ietf-mobileip-lowlatency-handoffs.txt. > > > > => Why don't you answer my questions (technically) > > instead of claiming that I'm misrepresenting > > conversations ? Jon hasn't said that. If > > I haven't said that because I was on a plane all day yesterday. > > I do believe you are misunderstanding the conversation Karim and I > had. The discussion about when to reset the default route > was a tangent; => Ok, well I don't think it's a tangent at all. The point here is that you can't change your default router based on advertisements, how do you know whether your traffic will be accepted and not dropped by the FA ? In fact you don't know if you've moved at all. A new FA might have simply appeared on the same link. Anyhow, Karim has already shown text from 2002 to explain this. There is nothing wrong with finding bugs in implementations, I don't know why it's been taken as an insult and brushed away. > > More importantly, it did NOT affect the performance results > we got. I'd be > happy to discuss the details more, but let's take it > offline for now. > => Assuming movement (and implicit registration and reply to the nFA) just because a new FA advertisement is received, will clearly have an impact on performance. This is the implication of resetting your default router based on new FA advertisements. That is one of my points against your paper, and honestly, after writing all these emails to your co-author, I'm looking forward to my holidays tomorrow so if you want to discuss more then let's do it next year :) Hesham > Jonathan > From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 13:39:18 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 NAA16010 for ; Thu, 20 Dec 2001 13:39:18 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09939; Thu, 20 Dec 2001 10:38:17 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15036; Thu, 20 Dec 2001 10:38:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIbKZR026006 for ; Thu, 20 Dec 2001 10:37:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKIbKkD026005 for mobile-ip-dist; Thu, 20 Dec 2001 10:37:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIbHZR025998 for ; Thu, 20 Dec 2001 10:37:17 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14810 for ; Thu, 20 Dec 2001 10:37:19 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13240 for ; Thu, 20 Dec 2001 11:37:18 -0700 (MST) Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBKIbHJ03532 for ; Thu, 20 Dec 2001 19:37:17 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Dec 20 19:37:17 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 19:28:43 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C178@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] HMIPv6 test Date: Thu, 20 Dec 2001 19:36:59 +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 all, Just a quick note to inform you that a small interop test was held before IETF in which HMIPv6 ver-4 was tested. There were implementations from Ericsson, Monash University, and test cases from conformance lab in Ericsson. Regards, Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 13:43: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 NAA16138 for ; Thu, 20 Dec 2001 13:43:19 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08169; Thu, 20 Dec 2001 11:42:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16234; Thu, 20 Dec 2001 10:42:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIfXZR026094 for ; Thu, 20 Dec 2001 10:41:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKIfXEn026093 for mobile-ip-dist; Thu, 20 Dec 2001 10:41:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIfTZR026083 for ; Thu, 20 Dec 2001 10:41:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12630 for ; Thu, 20 Dec 2001 10:41:32 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14541 for ; Thu, 20 Dec 2001 11:41:31 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA15355 for ; Thu, 20 Dec 2001 10:41:31 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBKIfUi17665 for ; Thu, 20 Dec 2001 10:41:30 -0800 X-mProtect: Thu, 20 Dec 2001 10:41:30 -0800 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 smtpd6HI8kh; Thu, 20 Dec 2001 10:41:29 PST Message-ID: <3C2230D9.5BA4B149@iprg.nokia.com> Date: Thu, 20 Dec 2001 10:41:29 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] list of things for MIPv6 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 everybody, heres an attempt to list all the issues that need to be resolved so that Mobile IPv6 can move ahead. and some suggestions follow them. ----------------------------------- 1. Mobile IPv6 use of Routing Header It has been identified that reflector attacks are possible with MIPv6 use of routing header. There is also a solution for this. If the host processing the routing header performs a simple rule of 'check if the destination address and the next address to be swapped in both belong to the same interface of the node', before processing the routing header, we eliminate this threat caused by MIPv6. 2. Mobile IPv6 use of Home Address Option The threat in this case is that some trivial source spoofing attacks are possible. The answer to source spoofing has always been smart ingress filtering. its the same in this case too. Using a tunneling approach does not it solve it either. So we have two options a. Document this threat in Mobile IPv6 security considerations and leave it. b. Solve it by mandating that home address option is not processed unless there is a corresponding binding cache entry (of course created securely). use reverse tuneling through the home agent when a binding cache entry does not exist. in my opinion, lets go with (a). (b) is a really bad idea. (b) is too drastic. I can live (a) becase the threat is very insignificant. Source spoofing attacks are possible currently (in the current internet). if the bottom line is 'do no harm' lets go with (a). 3. Protecting the BU. There are three options. pick one. a. new extension header b. Authentication Sub-Option only. c. Jari Arkko's draft, option 4 which shows how authentication suboption and AH can be used together with minimal changes. if we decide to go with (a), lets not go with UDP. instead we should use a new extension header. I personally prefer option (c). Implementing the auth suboption is very easy. I can provide the code if people think it is complicated to implement. 4. Piggybacking Phil described various options in his presentation at Salt Lake City. lets pick one. a. lets leave it as it is. it is a 'MAY'. b. leave it as it is, but recommend when it is good to use and when it is bad to use. 5. Key Distribution protocol between MN and CN a. Return routability vs CGA (Cryptographically Generated Addrs) b. Binding Security Association for (a), lets go with return routability unless somebody can prove that it is insecure. The added complexity of CGA or Diffie Helman operations is not worth it. no additional gain. so lets go with simple return routability. for (b), I am not sure. ------------------------------------ Lets try to address these issues one by one. And once we are done with an issue, we dont visit it again. It would be good if everybody woud reply to this mail and voice their opinions. Once we close an issue we dont want people coming back later on saying that they dont agree with the conclusions reached. Maybe the WG chairs can decide on the concensus. Regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 13:45: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 NAA16263 for ; Thu, 20 Dec 2001 13:45:53 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13054; Thu, 20 Dec 2001 10:44:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17010; Thu, 20 Dec 2001 10:44:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIhiZR026180 for ; Thu, 20 Dec 2001 10:43:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKIhiP8026179 for mobile-ip-dist; Thu, 20 Dec 2001 10:43:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKIhdZR026169 for ; Thu, 20 Dec 2001 10:43:39 -0800 (PST) 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 KAA00152 for ; Thu, 20 Dec 2001 10:43:42 -0800 (PST) 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 KAA20663 for ; Thu, 20 Dec 2001 10:43:41 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA15522 for ; Thu, 20 Dec 2001 10:43:41 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBKIhfs21391 for ; Thu, 20 Dec 2001 10:43:41 -0800 X-mProtect: Thu, 20 Dec 2001 10:43:41 -0800 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 smtpdSecMir; Thu, 20 Dec 2001 10:43:39 PST Message-ID: <3C22315B.8BADC0F8@iprg.nokia.com> Date: Thu, 20 Dec 2001 10:43:39 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] HMIPv6 test References: <4DA6EA82906FD511BE2F00508BCF053801C4C178@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit a quick question. Who are the contact persons for these implementations? Vijay "Hesham Soliman (ERA)" wrote: > > Hi all, > > Just a quick note to inform you that a small > interop test was held before IETF in which > HMIPv6 ver-4 was tested. > There were implementations from Ericsson, > Monash University, and test cases from > conformance lab in Ericsson. > > Regards, > Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 13:52: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 NAA16510 for ; Thu, 20 Dec 2001 13:52:20 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA15922; Thu, 20 Dec 2001 10:50:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18623; Thu, 20 Dec 2001 10:50:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKInGZR026399 for ; Thu, 20 Dec 2001 10:49:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKInGpE026398 for mobile-ip-dist; Thu, 20 Dec 2001 10:49:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKInCZR026391 for ; Thu, 20 Dec 2001 10:49:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01485 for ; Thu, 20 Dec 2001 10:49:15 -0800 (PST) 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 LAA27600 for ; Thu, 20 Dec 2001 11:50:03 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBKInDJ07816 for ; Thu, 20 Dec 2001 19:49:13 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Dec 20 19:48:57 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Dec 2001 19:48:57 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C17B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] HMIPv6 test Date: Thu, 20 Dec 2001 19:48:56 +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: For Ericsson, Mattias Pettersson. For Monash, Greg Daley. For conformance lab, I'll get back to you unless they can see this. Hesham > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Thursday, December 20, 2001 7:44 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] HMIPv6 test > > > a quick question. Who are the contact persons for these > implementations? > > Vijay > > "Hesham Soliman (ERA)" wrote: > > > > Hi all, > > > > Just a quick note to inform you that a small > > interop test was held before IETF in which > > HMIPv6 ver-4 was tested. > > There were implementations from Ericsson, > > Monash University, and test cases from > > conformance lab in Ericsson. > > > > Regards, > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 14:04: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 OAA16947 for ; Thu, 20 Dec 2001 14:04:28 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24757; Thu, 20 Dec 2001 12:03:04 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05271; Thu, 20 Dec 2001 11:03:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJ2UZR026557 for ; Thu, 20 Dec 2001 11:02:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKJ2UGk026556 for mobile-ip-dist; Thu, 20 Dec 2001 11:02:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJ2QZR026549 for ; Thu, 20 Dec 2001 11:02:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19012 for ; Thu, 20 Dec 2001 11:02:27 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22818 for ; Thu, 20 Dec 2001 12:02:26 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBKJ2Q806219 for ; Thu, 20 Dec 2001 11:02:26 -0800 (PST) Message-ID: <02be01c18988$a3af3250$7e6015ac@T23KEMPF> From: "James Kempf" To: References: <3C2230D9.5BA4B149@iprg.nokia.com> Subject: Re: [mobile-ip] list of things for MIPv6 Date: Thu, 20 Dec 2001 11:00:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay, > 5. Key Distribution protocol between MN and CN > a. Return routability vs CGA (Cryptographically > Generated Addrs) > b. Binding Security Association > > for (a), lets go with return routability unless > somebody can prove that it is insecure. The added > complexity of CGA or Diffie Helman operations is > not worth it. no additional gain. so lets go with > simple return routability. > It was not clear to me from the discussion in SLC that there is any additional decrease in complexity over CGA for return routability, if public keys were used to secure the RR messaging. Clearly, for symmetric keying, there would be, but that would require a trust relationship to be set up, which would require an initial public key exchange/operation to secure the key distribution. I believe Gab was going to generate some kind of analysis of the cost of return routability with Diffie-Helman compared to CGA? jak From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 14:07: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 OAA17053 for ; Thu, 20 Dec 2001 14:07:21 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27008; Thu, 20 Dec 2001 12:06:00 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06336; Thu, 20 Dec 2001 11:06:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJ5cZR026661 for ; Thu, 20 Dec 2001 11:05:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKJ5cwu026660 for mobile-ip-dist; Thu, 20 Dec 2001 11:05:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJ5ZZR026653 for ; Thu, 20 Dec 2001 11:05:35 -0800 (PST) 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 LAA20008 for ; Thu, 20 Dec 2001 11:05:36 -0800 (PST) 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 LAA01244 for ; Thu, 20 Dec 2001 11:05:35 -0800 (PST) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA10036 for ; Thu, 20 Dec 2001 13:05:35 -0600 (CST) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id fBKJ5Ym23641 for ; Thu, 20 Dec 2001 13:05:34 -0600 (CST) Message-ID: <3C22375A.3D3AF552@alcatel.com> Date: Thu, 20 Dec 2001 13:09:14 -0600 From: Behcet Sarikaya Organization: Alcatel USA X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] HMIPv6 test References: <4DA6EA82906FD511BE2F00508BCF053801C4C178@Esealnt861.al.sw.ericsson.se> <3C22315B.8BADC0F8@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, Can I see this as the beginning of a positive stance on HMIPv6 issue? It seems that the holiday spririt has already arrived (refering to your other mail on: list of things for MIPv6). Great news! Let's keep the good work. Regards, Vijay Devarapalli wrote: > a quick question. Who are the contact persons for these > implementations? > > Vijay > > "Hesham Soliman (ERA)" wrote: > > > > Hi all, > > > > Just a quick note to inform you that a small > > interop test was held before IETF in which > > HMIPv6 ver-4 was tested. > > There were implementations from Ericsson, > > Monash University, and test cases from > > conformance lab in Ericsson. > > > > Regards, > > Hesham -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 14:09: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 OAA17149 for ; Thu, 20 Dec 2001 14:09:17 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28305; Thu, 20 Dec 2001 12:07:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06886; Thu, 20 Dec 2001 11:08:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJ7cZR026735 for ; Thu, 20 Dec 2001 11:07:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKJ7b5D026734 for mobile-ip-dist; Thu, 20 Dec 2001 11:07:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJ7YZR026724 for ; Thu, 20 Dec 2001 11:07:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20598 for ; Thu, 20 Dec 2001 11:07:35 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27818 for ; Thu, 20 Dec 2001 12:07:16 -0700 (MST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBKJ7Y806442 for ; Thu, 20 Dec 2001 11:07:34 -0800 (PST) Message-ID: <02fc01c18989$5b41ac40$7e6015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] Apologies-Low Latency Discussion Date: Thu, 20 Dec 2001 11:05:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, I would like to publically apologize for the tone of my email today. It was out of line. You are correct that critically examining an implementation is important, and I am sure that Jon will be able to answer any questions you may have (he was on a plane yesterday and unable to respond). And, I'd like to encourage you and anybody else to work towards implementing low latency so that we can come to a better understand its characteristics prior to standardization. jak From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 14:21: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 OAA17591 for ; Thu, 20 Dec 2001 14:21:25 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00789; Thu, 20 Dec 2001 11:20:12 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10258; Thu, 20 Dec 2001 11:20:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJJNZR026956 for ; Thu, 20 Dec 2001 11:19:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKJJN0U026955 for mobile-ip-dist; Thu, 20 Dec 2001 11:19:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJJKZR026948 for ; Thu, 20 Dec 2001 11:19:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26148 for ; Thu, 20 Dec 2001 11:19:21 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13193 for ; Thu, 20 Dec 2001 12:20:06 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA18593 for ; Thu, 20 Dec 2001 11:19:18 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBKJJI819442 for ; Thu, 20 Dec 2001 11:19:18 -0800 X-mProtect: Thu, 20 Dec 2001 11:19:18 -0800 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 smtpdtuV1Ey; Thu, 20 Dec 2001 11:19:17 PST Message-ID: <3C2239B5.7B30A55C@iprg.nokia.com> Date: Thu, 20 Dec 2001 11:19:17 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 References: <3C2230D9.5BA4B149@iprg.nokia.com> <02be01c18988$a3af3250$7e6015ac@T23KEMPF> 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 Gabriel, James Kempf wrote: > > Vijay, > > > 5. Key Distribution protocol between MN and CN > > a. Return routability vs CGA (Cryptographically > > Generated Addrs) > > b. Binding Security Association > > > > for (a), lets go with return routability unless > > somebody can prove that it is insecure. The added > > complexity of CGA or Diffie Helman operations is > > not worth it. no additional gain. so lets go with > > simple return routability. > > > > It was not clear to me from the discussion in SLC that > there is any additional decrease in complexity > over CGA for return routability, if public keys were used > to secure the RR messaging. Clearly, for symmetric > keying, there would be, but that would require a > trust relationship to be set up, which would > require an initial public key exchange/operation > to secure the key distribution. > > I believe Gab was going to generate some kind > of analysis of the cost of return routability with > Diffie-Helman compared to CGA? If this is true, can you do this as soon as possible? if you are too busy, would you trust somebody else to do it? Vijay > > jak From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 14:23:34 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17651 for ; Thu, 20 Dec 2001 14:23:34 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01929; Thu, 20 Dec 2001 11:22:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10950; Thu, 20 Dec 2001 11:22:21 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJLiZR027012 for ; Thu, 20 Dec 2001 11:21:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKJLhEr027011 for mobile-ip-dist; Thu, 20 Dec 2001 11:21:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJLeZR027001 for ; Thu, 20 Dec 2001 11:21:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19572 for ; Thu, 20 Dec 2001 11:21:41 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08339 for ; Thu, 20 Dec 2001 12:21:22 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA18821 for ; Thu, 20 Dec 2001 11:21:40 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBKJLd224633 for ; Thu, 20 Dec 2001 11:21:39 -0800 X-mProtect: Thu, 20 Dec 2001 11:21:39 -0800 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 smtpdVAIa7w; Thu, 20 Dec 2001 11:21:38 PST Message-ID: <3C223A42.99D95767@iprg.nokia.com> Date: Thu, 20 Dec 2001 11:21:38 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] HMIPv6 test References: <4DA6EA82906FD511BE2F00508BCF053801C4C17B@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit for Conformance tests I know. It has to be Akos Cserveni. Met him at three interops. Vijay "Hesham Soliman (ERA)" wrote: > > For Ericsson, Mattias Pettersson. > For Monash, Greg Daley. > For conformance lab, I'll get > back to you unless they can see this. > > Hesham > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: Thursday, December 20, 2001 7:44 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] HMIPv6 test > > > > > > a quick question. Who are the contact persons for these > > implementations? > > > > Vijay > > > > "Hesham Soliman (ERA)" wrote: > > > > > > Hi all, > > > > > > Just a quick note to inform you that a small > > > interop test was held before IETF in which > > > HMIPv6 ver-4 was tested. > > > There were implementations from Ericsson, > > > Monash University, and test cases from > > > conformance lab in Ericsson. > > > > > > Regards, > > > Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 14:38:23 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18265 for ; Thu, 20 Dec 2001 14:38:23 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20092; Thu, 20 Dec 2001 12:37:01 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24447; Thu, 20 Dec 2001 11:37:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJaWZR027192 for ; Thu, 20 Dec 2001 11:36:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKJaWr4027191 for mobile-ip-dist; Thu, 20 Dec 2001 11:36:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKJaTZR027184 for ; Thu, 20 Dec 2001 11:36:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24205 for ; Thu, 20 Dec 2001 11:36:30 -0800 (PST) Received: from maredsous.cs.rice.edu (maredsous.cs.rice.edu [128.42.1.54]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03650 for ; Thu, 20 Dec 2001 12:36:30 -0700 (MST) Received: (from dbj@localhost) by maredsous.cs.rice.edu id fBKJfG966693; Thu, 20 Dec 2001 13:41:16 -0600 (CST) Date: Thu, 20 Dec 2001 13:41:16 -0600 From: Dave Johnson To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Extension for MobiHoc 2002 submissions Message-ID: <20011220134116.A66672@maredsous.cs.rice.edu> 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: We tried to send email yesterday to announce an extension on the deadline for paper submissions to MobiHoc 2002, but somehow that message has not yet shown up on the mailing list. I am thus resending a copy of the announcement. I apologize if some people did get the original and find this one a duplicate, but given the timing before the holidays, I wanted to be sure the word got out. Dave --------------------------------------------------------------------------- SUBMISSION DEADLINE EXTENSION MobiHoc 2002 The Third ACM International Symposium on Mobile Ad Hoc Networking and Computing Lausanne, Switzerland June 9-11, 2002 http://www.acm.org/sigmobile/mobihoc/2002/ Sponsored by ACM SIGMOBILE http://www.acm.org/sigmobile/ >>> New submission deadline: January 8, 2002 <<< >>> Authors must register their paper by January 2, 2002 <<< MobiHoc 2002 is the third of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 in Long Beach, California, and now in 2002 in Lausanne, Switzerland. Topics of interest include all areas of mobile and wireless ad hoc networking (above the physical layer), ad hoc computing, and sensor networks. Due to popular request, we have extended the submission due date for MobiHoc 2002 from January 2 until January 8, 2002. However, authors MUST register their paper by submitting the paper title, abstract, authors, and all other information except the paper itself by the original due date of January 2. Authors should use the normal submission procedure described on the MobiHoc web pages to register their paper in this way, and the paper can then be modified and finally submitted up through January 8. The new deadline of January 8 for paper submission is a firm deadline. The complete Call for Papers and detailed paper submission instructions for MobiHoc 2002 are available from the MobiHoc web site at http://www.acm.org/sigmobile/mobihoc/2002/ For any questions about the Call for Papers, please contact the Program Co-Chairs David B. Johnson (dbj@cs.rice.edu) and J.J. Garcia-Luna-Aceves (jj@cs.ucsc.edu). --------------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 15:25: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 PAA19378 for ; Thu, 20 Dec 2001 15:25:26 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA21214; Thu, 20 Dec 2001 13:23:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06446; Thu, 20 Dec 2001 12:23:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKKN7ZR027412 for ; Thu, 20 Dec 2001 12:23:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKKN7Ds027411 for mobile-ip-dist; Thu, 20 Dec 2001 12:23:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKKN4ZR027404 for ; Thu, 20 Dec 2001 12:23:04 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06288 for ; Thu, 20 Dec 2001 12:23:06 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08417 for ; Thu, 20 Dec 2001 13:23:05 -0700 (MST) Received: from DOCOMOALPER (dhcp98.docomo-usa.com [172.21.96.98]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fBKKN4809112 for ; Thu, 20 Dec 2001 12:23:04 -0800 (PST) Message-ID: <08c501c18994$3f500b20$626015ac@DOCOMOALPER> From: "Alper Yegin" To: References: <4DA6EA82906FD511BE2F00508BCF053801C4C15F@Esealnt861.al.sw.ericsson.se> <012201c188c6$bff79320$7e6015ac@T23KEMPF> <006201c18910$55a91170$446015ac@AlperVAIO> <002101c18973$c29036c0$7e6015ac@T23KEMPF> Subject: Re: [mobile-ip] WG Feedback Requested Date: Thu, 20 Dec 2001 12:23:55 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.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 James, > > I think while PFANE is an improvement > > over regular MIPv4 as far as low > > latency is concerned, I don't think > > it can be as fast as prereg. Exchanging > > protocol signaling after the L2 handover would > > be slower. > > > > Please see > http://geocities.com/kempf42/draft-kempf-mobileip-postmit-handover-00.tx > t. > This contains measurments of a technique that > is similar to PFANE. The performance is about the > same as Prereg for high latency radio links. Your method above is more like an optimized PFANE. My understanding is that, the route optim. draft puts this extension in the registration request (which can only happen after a router discovery [receive unsoliicted RA; or send RS and receive RA]). Your draft puts a similar extension in the RS, therefore faster than (and not same as) standard PFANE. alper From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 15:48: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 PAA20077 for ; Thu, 20 Dec 2001 15:48:02 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04816; Thu, 20 Dec 2001 13:46:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00630; Thu, 20 Dec 2001 12:46:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKKjDZR027566 for ; Thu, 20 Dec 2001 12:45:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKKjDxO027565 for mobile-ip-dist; Thu, 20 Dec 2001 12:45:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKKj5ZR027555 for ; Thu, 20 Dec 2001 12:45:06 -0800 (PST) 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 MAA10350 for ; Thu, 20 Dec 2001 12:44:32 -0800 (PST) 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 MAA14902 for ; Thu, 20 Dec 2001 12:44:31 -0800 (PST) Received: from piuha.net (ws4.piuha.net [195.165.196.4]) by ws2.piuha.net (Postfix) with ESMTP id 0D79F6A905; Thu, 20 Dec 2001 22:44:22 +0200 (EET) Message-ID: <3C21F8E7.7060108@piuha.net> Date: Thu, 20 Dec 2001 16:42:47 +0200 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Claude Castelluccia Cc: mobile-ip@sunroof.eng.sun.com, Erik Nordmark , mroe@microsoft.com, tuomaura@microsoft.com, gab@sun.com Subject: Re: [mobile-ip] Risks of not verifying the care-of address References: <3C12BA10.5030304@piuha.net> <3C14787C.C5C79043@inrialpes.fr> <3C149F8F.1030203@piuha.net> <3C14F65C.6020901@piuha.net> <3C15CAB4.20D8B8ED@inrialpes.fr> <3C1635A3.2070105@piuha.net> <3C173610.BEF73BD2@inrialpes.fr> 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 Claude writes: > So what someone could do is: > 1- establish a SA with a CN using SUCV/CAM, Bake.... > 2- Start some session with the CN using route optimization > 3- register X (the network or host target) as your CoA... > ..packets will be sent to X!! You are right. We seem to be in a need to prevent not just bombing attacks against the first CoA but also all future ones. As you point out, a combination of CGA and RR techniques could do the job, with RR being repeated for each new CoA. (It seems unnecessary to repeat HoA and CGA tests as you move around, though we might do that as well in order to simplify the protocol.) Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 17:06: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 RAA22230 for ; Thu, 20 Dec 2001 17:05:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA07339; Thu, 20 Dec 2001 14:04:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03316; Thu, 20 Dec 2001 14:04:47 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKM42ZR028019 for ; Thu, 20 Dec 2001 14:04:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKM42Dw028018 for mobile-ip-dist; Thu, 20 Dec 2001 14:04:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKM3xZR028011 for ; Thu, 20 Dec 2001 14:03:59 -0800 (PST) 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 OAA01953 for ; Thu, 20 Dec 2001 14:04:01 -0800 (PST) Received: from ALPHA6.CC.MONASH.EDU.AU (alpha6.cc.monash.edu.au [130.194.1.25]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14065 for ; Thu, 20 Dec 2001 14:04:00 -0800 (PST) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KC4HOVQR488WX4V8@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Fri, 21 Dec 2001 09:03:45 +1100 Received: from localhost (localhost [127.0.0.1]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 9FA2C20007; Fri, 21 Dec 2001 09:03:44 +1100 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.137.189]) by kapow.its.monash.edu.au (Postfix) with ESMTP id AA3A420006; Fri, 21 Dec 2001 09:03:43 +1100 (EST) Date: Fri, 21 Dec 2001 09:06:46 +1100 From: Greg Daley Subject: [mobile-ip] AT-CRC (Monash) HMIPv6 implementation (and test event) To: mobile-ip@sunroof.eng.sun.com, greg.daley@eng.monash.edu.au, nick.moore@eng.monash.edu.au Message-id: <3C2260F6.91FA41B7@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <4DA6EA82906FD511BE2F00508BCF053801C4C17B@Esealnt861.al.sw.ericsson.se> Sender: owner-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, Content-Transfer-Encoding: 7BIT Our implementation is being funded through a Co-operative research centre (Rather than the University). So I suppose they get naming rights. Nick Moore and I may be contacted regarding this implementation (But may not respond until 3 Jan 2002). Greg Daley: greg.daley@eng.monash.edu.au Nick Moore: nick.moore@eng.monash.edu.au The implementation is based off MIPL 0.9, and covers a lot of the Basic Mode of operation. Our LMM Advertising Agent (RADVD) has been modified to send MAP options, but currently only uses static configuration. Currently we are analysing and consolidating the results from the event, and will soon move to support draft 5 header formats. Thanks to all at Ericsson Hungary for their organisation and efforts in running the event. Special thanks to Lajos Zaccomer and Akos Cserveni for their assistance during the tests. Greg Daley "Hesham Soliman (ERA)" wrote: > > For Ericsson, Mattias Pettersson. > For Monash, Greg Daley. > For conformance lab, I'll get > back to you unless they can see this. > > Hesham > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: Thursday, December 20, 2001 7:44 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] HMIPv6 test > > > > > > a quick question. Who are the contact persons for these > > implementations? > > > > Vijay > > > > "Hesham Soliman (ERA)" wrote: > > > > > > Hi all, > > > > > > Just a quick note to inform you that a small > > > interop test was held before IETF in which > > > HMIPv6 ver-4 was tested. > > > There were implementations from Ericsson, > > > Monash University, and test cases from > > > conformance lab in Ericsson. > > > > > > Regards, > > > Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 17:28: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 RAA22931 for ; Thu, 20 Dec 2001 17:28:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16577; Thu, 20 Dec 2001 14:27:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08350; Thu, 20 Dec 2001 14:27:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMQMZR028213 for ; Thu, 20 Dec 2001 14:26:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKMQMG8028212 for mobile-ip-dist; Thu, 20 Dec 2001 14:26:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMQKZR028205 for ; Thu, 20 Dec 2001 14:26:20 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17391 for ; Thu, 20 Dec 2001 17:26:22 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA24626 for mobile-ip@sunroof.eng.sun.com; Thu, 20 Dec 2001 17:26:59 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJFtWZR014592 for ; Wed, 19 Dec 2001 07:55:32 -0800 (PST) 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 HAA18903 for ; Wed, 19 Dec 2001 07:55:34 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26668 for ; Wed, 19 Dec 2001 07:55:33 -0800 (PST) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id AAA15256 for ; Thu, 20 Dec 2001 00:56:21 +0900 To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] icmpv6 In-Reply-To: References: <200112190919.fBJ9JgD57186@givry.rennes.enst-bretagne.fr> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20011220005621V.yoshfuji@wide.ad.jp> Date: Thu, 20 Dec 2001 00:56:21 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Lines: 13 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit In article (at Wed, 19 Dec 2001 07:40:40 -0800), "Subrata Goswami" says: > 0x01:0xY:0xAAAAAAAA > > questions are: > 1. what is the value of Y ? > 2. If it is 2 then where and what padding do you > add ? It depends on the link-layer (XXX) you want to use. Refer "IPv6 over XXX" document such as RFC 2464. --yoshfuji From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 17:44: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 RAA23437 for ; Thu, 20 Dec 2001 17:44:08 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18536; Thu, 20 Dec 2001 15:42:44 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12179; Thu, 20 Dec 2001 14:42:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMgGZR028451 for ; Thu, 20 Dec 2001 14:42:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKMgGYo028450 for mobile-ip-dist; Thu, 20 Dec 2001 14:42:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKMgEZR028443 for ; Thu, 20 Dec 2001 14:42:15 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23850 for ; Thu, 20 Dec 2001 17:42:17 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id RAA24957 for mobile-ip@sunroof.eng.sun.com; Thu, 20 Dec 2001 17:42:54 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBJMk0ZR021405 for ; Wed, 19 Dec 2001 14:46:00 -0800 (PST) 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 OAA15524 for ; Wed, 19 Dec 2001 14:46:02 -0800 (PST) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05157 for ; Wed, 19 Dec 2001 14:45:58 -0800 (PST) Received: from blind (blind [128.111.49.140]) by letters.cs.ucsb.edu (8.10.2+Sun/8.9.3) with ESMTP id fBJMjvl25915; Wed, 19 Dec 2001 14:45:57 -0800 (PST) Date: Wed, 19 Dec 2001 14:45:57 -0800 (PST) From: MobiHoc 2002 X-Sender: mobihoc@blind To: mobile-ip@sunroof.eng.sun.com cc: MobiHoc 2002 Subject: [mobile-ip] MobiHoc 2002 Deadline Extension 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: --------------------------------------------------------------------------- SUBMISSION DEADLINE EXTENSION MobiHoc 2002 The Third ACM International Symposium on Mobile Ad Hoc Networking and Computing Lausanne, Switzerland June 9-11, 2002 http://www.acm.org/sigmobile/mobihoc/2002/ Sponsored by ACM SIGMOBILE http://www.acm.org/sigmobile/ >>> New submission deadline: January 8, 2002 <<< >>> Authors must register their paper by January 2, 2002 <<< MobiHoc 2002 is the third of a series of annual meetings sponsored by ACM SIGMOBILE, focusing on the latest research in the rapidly growing area of mobile ad hoc networking and computing. The first MobiHoc was held in 2000 in Boston, Massachusetts, as a workshop affiliated with the MobiCom conference also sponsored by SIGMOBILE. Since then, MobiHoc has become a separate symposium, held in 2001 in Long Beach, California, and now in 2002 in Lausanne, Switzerland. Topics of interest include all areas of mobile and wireless ad hoc networking (above the physical layer), ad hoc computing, and sensor networks. Due to popular request, we have extended the submission due date for MobiHoc 2002 from January 2 until January 8, 2002. However, authors MUST register their paper by submitting the paper title, abstract, authors, and all other information except the paper itself by the original due date of January 2. Authors should use the normal submission procedure described on the MobiHoc web pages to register their paper in this way, and the paper can then be modified and finally submitted up through January 8. The new deadline of January 8 for paper submission is a firm deadline. The complete Call for Papers and detailed paper submission instructions for MobiHoc 2002 are available from the MobiHoc web site at http://www.acm.org/sigmobile/mobihoc/2002/ For any questions about the Call for Papers, please contact the Program Co-Chairs David B. Johnson (dbj@cs.rice.edu) and J.J. Garcia-Luna-Aceves (jj@cs.ucsc.edu). --------------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 20 18:12: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 SAA24168 for ; Thu, 20 Dec 2001 18:12:33 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA03683; Thu, 20 Dec 2001 15:11:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18461; Thu, 20 Dec 2001 15:11:25 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKNAaZR028714 for ; Thu, 20 Dec 2001 15:10:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBKNAaRA028711 for mobile-ip-dist; Thu, 20 Dec 2001 15:10:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKNAVZR028703 for ; Thu, 20 Dec 2001 15:10:32 -0800 (PST) Received: from lillen (d-mpk17-86-237.Eng.Sun.COM [129.146.86.237]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBKNATq16382 for ; Fri, 21 Dec 2001 00:10:30 +0100 (MET) Date: Fri, 21 Dec 2001 00:08:27 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] WG Feedback Requested To: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <008601c188b8$f37c1580$7e6015ac@T23KEMPF> 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 it is as important to have running code as to have rough > concensus. The difficulty with this work is that it is making > a performance claim. IETF has difficulty with performance claims, > since typically all that is important to approve a protocol > for draft standard is that the code run and some degree of > interoperability be > demonstrated. Agreed that the IETF doesn't deal well with cases when there are multiple proposals that optimize the same type of thing which results in different performance benefits perhaps in different situations. The only tool we have for this is "does the community consider it useful" and the only way we have to measure this in the interest to implement a particular proposal. > For proposed standard, even that level of implementability > is not necessary, except for routing protocols. Arguably, MIP is > a routing protocol, but recently the IESG seems to be backing > away from treating it like one. The IESG always welcomes interoperable implementations before making something a proposed standard. I don't think we've had a formal discussion regarding RFC 1264 for any routing protocol while I've been on the IESG. > My own opinion is that the IESG ought to require a protocol > making a performance claim to demonstrate that claim, > and, in particular, demonstrate when the claim holds > and when it doesn't. If there are other, similar protocols > that can make an equivalent or better claim that is > more broadly applicable, obviously they are better > candidates for standardization. Charaterizing a protocol > with a performance claim is critical for implementation > and deployment. I think the IESG has enough to do already. So while I encourage folks to think quantitively about performance optimizations (analysis on paper, simulation, or actual tests) I don't think this will resolve the issue. Some folks might think implementing a 300 page RFC for a 3% performance gain is worth while, whereas others would like to see a 300% performance gain before they implement a 3 page RFC. This is fundamentally an engineering tradeoff that needs to take into account not only the complexity/performance tradeoff but also things like the environment, what type of applications will use this (and what assumptions will they make about packet drop behavior, delay etc), and the observation that the probability of interoperability is inversely related to the complexity of the spec. And the only "tool" we have for to determine this is whether two or more implementors find the protocol useful enough to do a complete implementation. > [...] > > However, I really think we need to uplevel the context > here a bit and look at the meta-issue. Phil's question at the meeting > about who was going to implement this work was not encouraging. > I had thought that 3GPP2 was an obvious customer, > but they already do something like Postreg for PPP. > If nobody is going to implement this work, or it > will just be implemented as a research project, then what > is the point of doing it? We should just make the whole > thing experimental and concentrate on getting FMIPv6 > right. I think upleveling in general is a resonable approach for optimizations in general so try to guage during the process of developping an idea whether folks think it is useful enough. But this requires work by the WG participants to make the determination whether they individually think it is worth while to implement a protocol and having performance data would presumably be helpful for the WG participants. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 04:30: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 EAA20591 for ; Fri, 21 Dec 2001 04:30:28 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA01742; Fri, 21 Dec 2001 01:29:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00602; Fri, 21 Dec 2001 01:29:09 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBL9SDZR029796 for ; Fri, 21 Dec 2001 01:28:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBL9SDP6029795 for mobile-ip-dist; Fri, 21 Dec 2001 01:28:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBL9S9ZR029788 for ; Fri, 21 Dec 2001 01:28:09 -0800 (PST) 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 BAA00531 for ; Fri, 21 Dec 2001 01:28:11 -0800 (PST) Received: from tml-gw.tml.hut.fi (tml.hut.fi [130.233.44.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28142 for ; Fri, 21 Dec 2001 01:28:10 -0800 (PST) Received: (from smap@localhost) by tml-gw.tml.hut.fi (8.8.7/8.8.7) id LAA14061 for ; Fri, 21 Dec 2001 11:28:08 +0200 Received: from mail.tml.hut.fi(130.233.45.70) by tml-gw.tml.hut.fi via smap (V2.0) id xma014059; Fri, 21 Dec 01 11:27:55 +0200 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 fBL9Rt804380 for ; Fri, 21 Dec 2001 11:27:55 +0200 (EET) Received: from localhost (lpetande@localhost) by morphine.tml.hut.fi (8.9.3+Sun/8.9.3) with ESMTP id LAA00946 for ; Fri, 21 Dec 2001 11:27:55 +0200 (EET) X-Authentication-Warning: morphine.tml.hut.fi: lpetande owned process doing -bs Date: Fri, 21 Dec 2001 11:27:55 +0200 (EET) From: Henrik Petander To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-Reply-To: <3C2230D9.5BA4B149@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, On Thu, 20 Dec 2001, Vijay Devarapalli wrote: > hi everybody, > > heres an attempt to list all the issues that need to be > resolved so that Mobile IPv6 can move ahead. and some > suggestions follow them. > > ----------------------------------- > > 1. Mobile IPv6 use of Routing Header > It has been identified that reflector attacks are > possible with MIPv6 use of routing header. There is > also a solution for this. If the host processing > the routing header performs a simple rule of > 'check if the destination address and the next address > to be swapped in both belong to the same interface > of the node', before processing the routing header, > we eliminate this threat caused by MIPv6. This requirement would make vertical handoffs impossible for mobile hosts. Wouldn't it be sufficient for the host to check that the next address belongs to it and that the scope of the next address is not smaller than that of the destination address? This would stop reflector attacks, and allow MN to perform vertical handoffs. Regards, Henrik ---------------------------------- 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 Dec 21 06:07: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 GAA21577 for ; Fri, 21 Dec 2001 06:07:24 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA00966; Fri, 21 Dec 2001 03:06:18 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA13421; Fri, 21 Dec 2001 03:06:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLB5YZR000083 for ; Fri, 21 Dec 2001 03:05:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLB5Y8T000082 for mobile-ip-dist; Fri, 21 Dec 2001 03:05:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLB5VZR000075 for ; Fri, 21 Dec 2001 03:05:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12563 for ; Fri, 21 Dec 2001 03:05:31 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22306 for ; Fri, 21 Dec 2001 04:05:30 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBLB5SZ24602 for ; Fri, 21 Dec 2001 13:05:28 +0200 Date: Fri, 21 Dec 2001 13:05:28 +0200 (EET) From: Pekka Savola To: Subject: Re: [mobile-ip] list of things for MIPv6 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 Fri, 21 Dec 2001, Henrik Petander wrote: > On Thu, 20 Dec 2001, Vijay Devarapalli wrote: > > > hi everybody, > > > > heres an attempt to list all the issues that need to be > > resolved so that Mobile IPv6 can move ahead. and some > > suggestions follow them. > > > > ----------------------------------- > > > > 1. Mobile IPv6 use of Routing Header > > It has been identified that reflector attacks are > > possible with MIPv6 use of routing header. There is > > also a solution for this. If the host processing > > the routing header performs a simple rule of > > 'check if the destination address and the next address > > to be swapped in both belong to the same interface > > of the node', before processing the routing header, > > we eliminate this threat caused by MIPv6. > > This requirement would make vertical handoffs impossible for mobile hosts. > Wouldn't it be sufficient for the host to check that the next address > belongs to it and that the scope of the next address is not smaller than > that of the destination address? This would stop reflector attacks, and > allow MN to perform vertical handoffs. An alternative mechanism here would be basically "check that the next address is a Home Address of the node". This depends more on the implementation though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 06:18:52 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21713 for ; Fri, 21 Dec 2001 06:18:52 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA05291; Fri, 21 Dec 2001 03:17:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14685; Fri, 21 Dec 2001 03:17:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBH3ZR000328 for ; Fri, 21 Dec 2001 03:17:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLBH23g000327 for mobile-ip-dist; Fri, 21 Dec 2001 03:17:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBGxZR000320 for ; Fri, 21 Dec 2001 03:16:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA14590 for ; Fri, 21 Dec 2001 03:16:59 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA17735 for ; Fri, 21 Dec 2001 04:16:40 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBLBGvO24709 for ; Fri, 21 Dec 2001 13:16:57 +0200 Date: Fri, 21 Dec 2001 13:16:57 +0200 (EET) From: Pekka Savola To: Subject: Re: [mobile-ip] list of things for MIPv6 (2) In-Reply-To: <3C2230D9.5BA4B149@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: On Thu, 20 Dec 2001, Vijay Devarapalli wrote: > 2. Mobile IPv6 use of Home Address Option > The threat in this case is that some trivial source > spoofing attacks are possible. The answer to source > spoofing has always been smart ingress filtering. > its the same in this case too. Using a tunneling > approach does not it solve it either. So we have > two options > a. Document this threat in Mobile IPv6 security > considerations and leave it. > b. Solve it by mandating that home address option > is not processed unless there is a corresponding > binding cache entry (of course created securely). > use reverse tuneling through the home agent when > a binding cache entry does not exist. > > in my opinion, lets go with (a). (b) is a really bad > idea. (b) is too drastic. I can live (a) becase the > threat is very insignificant. Source spoofing attacks > are possible currently (in the current internet). if > the bottom line is 'do no harm' lets go with (a). This is the "easy way out". Your argument about source spoofing does not apply; it's certainly possible currently, but there are scenarios (which, unfortunately, I appear to have forgot to add in my rh-ha-draft) you can protect against without it: host1 --- fwrtr1 - rtrISP - Internet - fwrtr2 ---host2 3ffe:ffff:1::/48 3ffe:ffff:2::/48 Let's assume fwrtr2 is protecting host2 by filtering out all packets the source address of which belongs to the local network, like: deny ip from 3ffe:ffff:1::/48 to any interface from_internet Now, the attacker host1 could attack: src = 3ffe:ffff:1::1 (or spoofed if no filtering in fwrtr1, as assumed) dst = 3ffe:ffff:2::1 hoa=3ffe:ffff:2::2 The firewall cannot block this, and packets from internal source address 3ffe:ffff:2::2 can end up in the host2's stack. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 06:30: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 GAA21890 for ; Fri, 21 Dec 2001 06:30:54 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA09473; Fri, 21 Dec 2001 03:29:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15593; Fri, 21 Dec 2001 03:29:51 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBTFZR000538 for ; Fri, 21 Dec 2001 03:29:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLBTE0a000537 for mobile-ip-dist; Fri, 21 Dec 2001 03:29:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLBTBZR000530 for ; Fri, 21 Dec 2001 03:29:11 -0800 (PST) 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 DAA26029 for ; Fri, 21 Dec 2001 03:29:12 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02945 for ; Fri, 21 Dec 2001 03:29:10 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBLBT9M24811 for ; Fri, 21 Dec 2001 13:29:09 +0200 Date: Fri, 21 Dec 2001 13:29:09 +0200 (EET) From: Pekka Savola To: Subject: Re: [mobile-ip] list of things for MIPv6 (2) 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 Fri, 21 Dec 2001, Pekka Savola wrote: > Let's assume fwrtr2 is protecting host2 by filtering out all packets the > source address of which belongs to the local network, like: > > deny ip from 3ffe:ffff:1::/48 to any interface from_internet ^ 3ffe:ffff:2::/48, of course! sorry.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 09:42: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 JAA24337 for ; Fri, 21 Dec 2001 09:42:09 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15017; Fri, 21 Dec 2001 06:40:35 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03242; Fri, 21 Dec 2001 06:40:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLEdjZR001324 for ; Fri, 21 Dec 2001 06:39:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLEdjP2001323 for mobile-ip-dist; Fri, 21 Dec 2001 06:39:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLEdfZR001316 for ; Fri, 21 Dec 2001 06:39:42 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29529 for ; Fri, 21 Dec 2001 06:39:43 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18628 for ; Fri, 21 Dec 2001 07:39:42 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBLEdeI12709 for ; Fri, 21 Dec 2001 15:39:41 +0100 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 PAA07649 for ; Fri, 21 Dec 2001 15:39:41 +0100 (MET) 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 fBLEdfD69151 for ; Fri, 21 Dec 2001 15:39:41 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112211439.fBLEdfD69151@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-reply-to: Your message of Thu, 20 Dec 2001 10:41:29 PST. <3C2230D9.5BA4B149@iprg.nokia.com> Date: Fri, 21 Dec 2001 15:39:41 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: 1. Mobile IPv6 use of Routing Header => the solution has to be written down in a draft and presented to the IPv6 WG ASAP as a part of the host requirement document. 2. Mobile IPv6 use of Home Address Option The threat in this case is that some trivial source spoofing attacks are possible. The answer to source spoofing has always been smart ingress filtering. => it seems I have to write the IPv6 ingress filtering document (it is in my TODO list, I'll check with my co-author when we can write it). its the same in this case too. Using a tunneling approach does not it solve it either. => tunneling has exactly the same problem (and solution): no miracle even next Tuesday (:-). So we have two options a. Document this threat in Mobile IPv6 security considerations and leave it. b. Solve it by mandating that home address option is not processed unless there is a corresponding binding cache entry (of course created securely). use reverse tuneling through the home agent when a binding cache entry does not exist. in my opinion, lets go with (a). (b) is a really bad idea. (b) is too drastic. I can live (a) because the => you already know I agree! threat is very insignificant. Source spoofing attacks are possible currently (in the current internet). if the bottom line is 'do no harm' lets go with (a). => I shan't use the argument. The threat is real and we have to give back the tools against it. The limits of these tools are simply not in our scope. 3. Protecting the BU. There are three options. pick one. a. new extension header b. Authentication Sub-Option only. c. Jari Arkko's draft, option 4 which shows how authentication suboption and AH can be used together with minimal changes. => argh! Which draft/section/etc? if we decide to go with (a), lets not go with UDP. instead we should use a new extension header. => I am in favor of (a) because it works without the need to check if there is some IPsec somewhere. As IPsec codes are a bit complex (:-) and have strange (:-) interactions with other parts of stacks, IMHO this is a strong argument. 4. Piggybacking Phil described various options in his presentation at Salt Lake City. lets pick one. => I presented a generalized version (the IPv6 payload header) of this at an IPv6 session at SLC. I had to specify that my purpose was to collect pros & cons, not to really defend the idea, in order to not be hung with the micro cord... I should release a new version of the I-D with a lot of cons soon (i.e. before next IETF). a. lets leave it as it is. it is a 'MAY'. b. leave it as it is, but recommend when it is good to use and when it is bad to use. => (b) with good to use == never and bad to use == always! 5. Key Distribution protocol between MN and CN a. Return routability vs CGA (Cryptographically Generated Addrs) b. Binding Security Association for (a), lets go with return routability unless somebody can prove that it is insecure. => very easy: put the attacker in the CN default router. The added complexity of CGA or Diffie Helman operations is not worth it. no additional gain. so lets go with simple return routability. => I am afraid that if we do that all CNs will simply reject BSA establishment attempts. Of course if BSA establishments are very expensive (a lot of crypto operations) we'll get the same result. Here we really need a miracle! for (b), I am not sure. => explain a bit more the (b) issue. It would be good if everybody woud reply to this mail and voice their opinions. Once we close an issue we dont want people coming back later on saying that they dont agree with the conclusions reached. => hum, perhaps this will work but IMHO this should take months! Maybe the WG chairs can decide on the concensus. => WG chair job is harder and harder (:-)... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 09:42: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 JAA24356 for ; Fri, 21 Dec 2001 09:42:41 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27916; Fri, 21 Dec 2001 07:39:59 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03201; Fri, 21 Dec 2001 06:40:15 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLEcsZR001312 for ; Fri, 21 Dec 2001 06:38:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLEcsrW001311 for mobile-ip-dist; Fri, 21 Dec 2001 06:38:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLEcpZR001304 for ; Fri, 21 Dec 2001 06:38:51 -0800 (PST) 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 GAA07168 for ; Fri, 21 Dec 2001 06:38:51 -0800 (PST) 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 GAA23023 for ; Fri, 21 Dec 2001 06:38:50 -0800 (PST) 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.11.0/WIREfire-1.3) with SMTP id fBLEcnK19573 for ; Fri, 21 Dec 2001 15:38:49 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Fri Dec 21 15:38:27 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 15:29:52 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C17C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Apologies-Low Latency Discussion Date: Fri, 21 Dec 2001 15:38:03 +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: James, Thank you very much. I appreciate it. I will look forward to continuing the discussion later with Jon or anyone else (including you :)). I also think simulations and implementations of proposals are very important, we were doing the same here but got disrupted unfortunately and we lost some time. Also it is important to understand what others are doing and how they did it, which is the reason I've been eagerly following this discussion. Thanks and enjoy your break ! Hesham > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Thursday, December 20, 2001 8:06 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Apologies-Low Latency Discussion > > > Hesham, > > I would like to publically apologize for the tone of > my email today. It was out of line. You are correct that critically > examining an implementation is important, and > I am sure that Jon will be able to answer any questions > you may have (he was on a plane yesterday and > unable to respond). And, I'd like to encourage > you and anybody else to work towards > implementing low latency so that we can > come to a better understand its characteristics > prior to standardization. > > jak > From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 09:50:20 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24408 for ; Fri, 21 Dec 2001 09:50:19 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03005; Fri, 21 Dec 2001 07:48:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04196; Fri, 21 Dec 2001 06:49:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLEmXZR001508 for ; Fri, 21 Dec 2001 06:48:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLEmWoK001507 for mobile-ip-dist; Fri, 21 Dec 2001 06:48:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLEmTZR001500 for ; Fri, 21 Dec 2001 06:48:29 -0800 (PST) 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 GAA07998 for ; Fri, 21 Dec 2001 06:48:32 -0800 (PST) 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 GAA02787 for ; Fri, 21 Dec 2001 06:48:31 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBLEmTI13986 for ; Fri, 21 Dec 2001 15:48:29 +0100 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 PAA07788 for ; Fri, 21 Dec 2001 15:48:29 +0100 (MET) 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 fBLEmTD69240 for ; Fri, 21 Dec 2001 15:48:29 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112211448.fBLEmTD69240@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-reply-to: Your message of Thu, 20 Dec 2001 11:00:49 PST. <02be01c18988$a3af3250$7e6015ac@T23KEMPF> Date: Fri, 21 Dec 2001 15:48:29 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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 believe Gab was going to generate some kind of analysis of the cost of return routability with Diffie-Helman compared to CGA? => it seems that a Diffie-Hellman and a public key operation have similar costs (too high according to Vijay). Regards Francis.Dupont@enst-bretagne.fr PS: my concern about CGAs is IPRs by Ericsson and Microsoft. From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 10:48: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 KAA25371 for ; Fri, 21 Dec 2001 10:48:44 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08473; Fri, 21 Dec 2001 08:46:40 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08679; Fri, 21 Dec 2001 07:46:55 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLFkCZR001847 for ; Fri, 21 Dec 2001 07:46:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLFkC1l001846 for mobile-ip-dist; Fri, 21 Dec 2001 07:46:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLFk9ZR001839 for ; Fri, 21 Dec 2001 07:46:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21958 for ; Fri, 21 Dec 2001 07:46:09 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06208 for ; Fri, 21 Dec 2001 08:46:09 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fBLFk8J15855 for ; Fri, 21 Dec 2001 16:46:08 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Dec 21 16:46:07 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 16:46:07 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C182@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] list of things for MIPv6 Date: Fri, 21 Dec 2001 16:45:46 +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 Vijay and all, Sorry, long email but there are lots of issues. > ----------------------------------- > > 1. Mobile IPv6 use of Routing Header > It has been identified that reflector attacks are > possible with MIPv6 use of routing header. There is > also a solution for this. If the host processing > the routing header performs a simple rule of > 'check if the destination address and the next address > to be swapped in both belong to the same interface > of the node', before processing the routing header, > we eliminate this threat caused by MIPv6. => I think the best way to solve this is to make sure a node, by default, doesn't forward to any addresses outside any of the node's interfaces. And that it MUST be possible to override this behaviour by manual configuration. Unfortunately though this is something that needs to be done in IPng to be generic for all IPv6 hosts, so I don't know how to go about that. Different flavours of this rule are mentioned in Erik's draft, Pekka's draft and the cellular host (manyfolks) draft in IPng. > > 2. Mobile IPv6 use of Home Address Option > The threat in this case is that some trivial source > spoofing attacks are possible. The answer to source > spoofing has always been smart ingress filtering. > its the same in this case too. Using a tunneling > approach does not it solve it either. So we have > two options > a. Document this threat in Mobile IPv6 security > considerations and leave it. > b. Solve it by mandating that home address option > is not processed unless there is a corresponding > binding cache entry (of course created securely). > use reverse tuneling through the home agent when > a binding cache entry does not exist. > > in my opinion, lets go with (a). (b) is a really bad > idea. (b) is too drastic. I can live (a) becase the > threat is very insignificant. Source spoofing attacks > are possible currently (in the current internet). if > the bottom line is 'do no harm' lets go with (a). > => I'm afraid I agree with Pekka here. The threat is definitely significant. We can't pretend it won't happen, so I'd have to go with b) (unfortunately). But think on the positive side, it's good to have a symmetrical bidirectional path, for QoS reasons :) > > 3. Protecting the BU. There are three options. pick one. > a. new extension header > b. Authentication Sub-Option only. > c. Jari Arkko's draft, option 4 which shows how > authentication suboption and AH can be used > together with minimal changes. > > if we decide to go with (a), lets not go with UDP. > instead we should use a new extension header. > I personally prefer option (c). Implementing the > auth suboption is very easy. I can provide the code > if people think it is complicated to implement. > => Definitely a) or alternatively a UDP port number. > > 4. Piggybacking > Phil described various options in his presentation > at Salt Lake City. lets pick one. > a. lets leave it as it is. it is a 'MAY'. > b. leave it as it is, but recommend when it is > good to use and when it is bad to use. => c). (which was discussed), say that it SHOULD NOT be done. I agree with Francis on this one. > > > 5. Key Distribution protocol between MN and CN > a. Return routability vs CGA (Cryptographically > Generated Addrs) > b. Binding Security Association > > for (a), lets go with return routability unless > somebody can prove that it is insecure. The added > complexity of CGA or Diffie Helman operations is > not worth it. no additional gain. so lets go with > simple return routability. => I can't see how we can do RR only and still maintain that our requirement is "Add no harm". Connection hijacking can be considered "new harm" and RR will not stop it. IMHO (and I'm not a security expert) the combination of CGAs and RR is an excellent idea and will give quite a strong security. If the processing power is a concern, some optimisations were proposed to off-load some of the operations onto the HA. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 12:39: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 MAA27493 for ; Fri, 21 Dec 2001 12:39:30 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01472; Fri, 21 Dec 2001 09:38:24 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10336; Fri, 21 Dec 2001 09:38:06 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHbNZR002428 for ; Fri, 21 Dec 2001 09:37:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLHbN9s002427 for mobile-ip-dist; Fri, 21 Dec 2001 09:37:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHbKZR002420 for ; Fri, 21 Dec 2001 09:37:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28084 for ; Fri, 21 Dec 2001 09:37:21 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24594 for ; Fri, 21 Dec 2001 10:37:03 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBLHbJn24872 for ; Fri, 21 Dec 2001 11:37:19 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 11:35:50 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01449EF9@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] list of things for MIPv6 Date: Fri, 21 Dec 2001 11:35:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18A45.EF19DA70" Sender: owner-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_01C18A45.EF19DA70 Content-Type: text/plain; charset="iso-8859-1" > ----------------------------------- > > 1. Mobile IPv6 use of Routing Header > It has been identified that reflector attacks are > possible with MIPv6 use of routing header. There is > also a solution for this. If the host processing > the routing header performs a simple rule of > 'check if the destination address and the next address > to be swapped in both belong to the same interface > of the node', before processing the routing header, > we eliminate this threat caused by MIPv6. I guess all application or transport layers, even UDP, are responsible for checking that the source address is valid to tunnel-in so to speak? I may be wrong but we might be ignoring some other - less publicized threats. > > 2. Mobile IPv6 use of Home Address Option > The threat in this case is that some trivial source > spoofing attacks are possible. The answer to source > spoofing has always been smart ingress filtering. > its the same in this case too. Using a tunneling > approach does not it solve it either. So we have > two options > a. Document this threat in Mobile IPv6 security > considerations and leave it. > b. Solve it by mandating that home address option > is not processed unless there is a corresponding > binding cache entry (of course created securely). > use reverse tuneling through the home agent when > a binding cache entry does not exist. > > in my opinion, lets go with (a). (b) is a really bad > idea. (b) is too drastic. I can live (a) becase the > threat is very insignificant. Source spoofing attacks > are possible currently (in the current internet). if > the bottom line is 'do no harm' lets go with (a). > My opinion is that the specs should be correct and devoid of holes. It is implementation specific choice of vendors of equipment and software to be compliant or not. I don't think we should trivialize the hole. We should just fix it and move on. I also do not think that plugging the hole will significantly increase the cost of devices. Ex. I don't see an IP-enabled light switch or toaster being accessed by millions of mobile nodes at the same time. > > 3. Protecting the BU. There are three options. pick one. > a. new extension header > b. Authentication Sub-Option only. > c. Jari Arkko's draft, option 4 which shows how > authentication suboption and AH can be used > together with minimal changes. > > if we decide to go with (a), lets not go with UDP. > instead we should use a new extension header. > I personally prefer option (c). Implementing the > auth suboption is very easy. I can provide the code > if people think it is complicated to implement. > I thought the group had already settled on b. Last time I checked there were even plans to upgrade various open-source implementations as well. > > 4. Piggybacking > Phil described various options in his presentation > at Salt Lake City. lets pick one. > a. lets leave it as it is. it is a 'MAY'. > b. leave it as it is, but recommend when it is > good to use and when it is bad to use. > Both are fine with me. The points made above about implementation conformance still apply, though. > > 5. Key Distribution protocol between MN and CN > a. Return routability vs CGA (Cryptographically > Generated Addrs) > b. Binding Security Association > > for (a), lets go with return routability unless > somebody can prove that it is insecure. The added > complexity of CGA or Diffie Helman operations is > not worth it. no additional gain. so lets go with > simple return routability. > > for (b), I am not sure. > While I am not apposed to the 3-way triangular handshake - bounce around the world solutions being devised and standardized. At some point, it might be fruitful to focus on finding solutions that don't require AAA, yet can accomplish the association establishment in fewer messages. This might be more appropriate for working with real-time media streams. It would also be faster for non-realtime streams. I don't really see that solution to this fast establishment problem should be restricted to just mobile ip, however. I would certainly understand if MIP-specific slower methods were standardized and implemented first, though. The main point here is that if the 3-way handshake is the implementation, the applicability of its use with other WG technologies may be deminished; therefore other SDOs can claim that because of this, they are not conformant with MIPv6 route optimization. Even if there were a MIP RO with AAA document that did show how it could be done with fewer messages, I suspect that the endpoints might need to know which way it is being done and this might affect the MIPv6 protocol, itself? If a solution with no AAA could be found and agreed upon, this might avoid all of this unpleasantness. Regards, Glenn ------_=_NextPart_001_01C18A45.EF19DA70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] list of things for MIPv6

> -----------------------------------
>
> 1. Mobile IPv6 use of Routing Header
>         = It has been identified that reflector attacks are
>         = possible with MIPv6 use of routing header. There is
>         = also a solution for this. If the host processing
>         = the routing header performs a simple rule of
>         = 'check if the destination address and the next address
>         = to be swapped in both belong to the same interface
>         = of the node', before processing the routing header,
>         = we eliminate this threat caused by MIPv6.

I guess all application or transport layers, even = UDP, are responsible for checking that the source address is valid to = tunnel-in so to speak? I may be wrong but we might be ignoring some = other - less publicized threats.

>
> 2. Mobile IPv6 use of Home Address = Option
>         = The threat in this case is that some trivial source
>         = spoofing attacks are possible. The answer to source
>         = spoofing has always been smart ingress filtering.
>         = its the same in this case too. Using a tunneling
>         = approach does not it solve it either. So we have
>         = two options
>         = a. Document this threat in Mobile IPv6 security
>          = ;  considerations and leave it.
>         = b. Solve it by mandating that home address option
>          = ;  is not processed unless there is a corresponding
>          = ;  binding cache entry (of course created securely).
>          = ;  use reverse tuneling through the home agent when
>          = ;  a binding cache entry does not exist.
>
>         = in my opinion, lets go with (a). (b) is a really bad
>         = idea. (b) is too drastic. I can live (a) becase the
>       threat is very = insignificant. Source spoofing attacks
>       are possible = currently (in the current internet). if
>       the bottom line = is 'do no harm' lets go with (a).
>

My opinion is that the specs should be correct and = devoid of holes. It is implementation specific choice of vendors of = equipment and software to be compliant or not. I don't think we should = trivialize the hole. We should just fix it and move on. I also do not = think that plugging the hole will significantly increase the cost of = devices. Ex. I don't see an IP-enabled light switch or toaster being = accessed by millions of mobile nodes at the same time.

         =
>
> 3. Protecting the BU. There are three options. = pick one.
>         = a. new extension header
>         = b. Authentication Sub-Option only.
>         = c. Jari Arkko's draft, option 4 which shows how
>          = ;  authentication suboption and AH can be used
>          = ;  together with minimal changes.
>
>         = if we decide to go with (a), lets not go with UDP.
>         = instead we should use a new extension header.
>         = I personally prefer option (c). Implementing the
>         = auth suboption is very easy. I can provide the code
>         = if people think it is complicated to implement.
>

I thought the group had already settled on b. Last = time I checked there were even plans to upgrade various open-source = implementations as well.

>
> 4. Piggybacking
>         = Phil described various options in his presentation
>       at Salt Lake = City. lets pick one.
>         = a. lets leave it as it is. it is a 'MAY'.
>         = b. leave it as it is, but recommend when it is
>          = ;  good to use and when it is bad to use.
>

Both are fine with me. The points made above about = implementation conformance still apply, though.

>
> 5. Key Distribution protocol between MN and = CN
>         = a. Return routability vs CGA (Cryptographically
>          = ;  Generated Addrs)
>         = b. Binding Security Association
>
>         = for (a), lets go with return routability unless
>       somebody can = prove that it is insecure. The added
>       complexity of = CGA or Diffie Helman operations is
>       not worth it. no = additional gain. so lets go with
>       simple return = routability.
>
>         = for (b), I am not sure.         =
>

While I am not apposed to the 3-way triangular = handshake - bounce around the world solutions being devised and = standardized. At some point, it might be fruitful to focus on finding = solutions that don't require AAA, yet can accomplish the association = establishment in fewer messages. This might be more appropriate for = working with real-time media streams. It would also be faster for = non-realtime streams.  I don't really see that solution to this = fast establishment problem should be restricted to just mobile ip, = however. I would certainly understand if MIP-specific slower methods = were standardized and implemented first, though.

The main point here is that if the 3-way handshake is = the implementation, the applicability of its use with other WG = technologies may be deminished; therefore other SDOs can claim that = because of this, they are not conformant with MIPv6 route = optimization.

Even if there were a MIP RO with AAA document that = did show how it could be done with fewer messages, I suspect that the = endpoints might need to know which way it is being done and this might = affect the MIPv6 protocol, itself? If a solution with no AAA could be = found and agreed upon, this might avoid all of this = unpleasantness.

Regards,

Glenn


------_=_NextPart_001_01C18A45.EF19DA70-- From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 12:45: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 MAA27657 for ; Fri, 21 Dec 2001 12:45:32 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28735; Fri, 21 Dec 2001 10:43:03 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11977; Fri, 21 Dec 2001 09:43:19 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHghZR002480 for ; Fri, 21 Dec 2001 09:42:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLHghlT002479 for mobile-ip-dist; Fri, 21 Dec 2001 09:42:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHgdZR002472 for ; Fri, 21 Dec 2001 09:42:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12936 for ; Fri, 21 Dec 2001 09:42:41 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12210 for ; Fri, 21 Dec 2001 10:42:40 -0700 (MST) 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 fBLHgdJ25376 for ; Fri, 21 Dec 2001 18:42:39 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri Dec 21 18:42:23 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 18:34:04 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C18C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] list of things for MIPv6 Date: Fri, 21 Dec 2001 18:42:23 +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: > a. new extension header > b. Authentication Sub-Option only. > c. Jari Arkko's draft, option 4 which shows how > authentication suboption and AH can be used > together with minimal changes. > > if we decide to go with (a), lets not go with UDP. > instead we should use a new extension header. > I personally prefer option (c). Implementing the > auth suboption is very easy. I can provide the code > if people think it is complicated to implement. > I thought the group had already settled on b. Last time I checked there were even plans to upgrade various open-source implementations as well. => That was optimistic thinking I think ! we never had a concensus call on this. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 12:49: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 MAA27751 for ; Fri, 21 Dec 2001 12:49:40 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02614; Fri, 21 Dec 2001 10:48:16 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13872; Fri, 21 Dec 2001 09:48:31 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHlkZR002598 for ; Fri, 21 Dec 2001 09:47:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLHlk0x002597 for mobile-ip-dist; Fri, 21 Dec 2001 09:47:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHlhZR002587 for ; Fri, 21 Dec 2001 09:47:43 -0800 (PST) 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 JAA13761 for ; Fri, 21 Dec 2001 09:47:40 -0800 (PST) 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 JAA14013 for ; Fri, 21 Dec 2001 09:47:40 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA13699 for ; Fri, 21 Dec 2001 09:47:39 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBLHlds13468 for ; Fri, 21 Dec 2001 09:47:39 -0800 X-mProtect: Fri, 21 Dec 2001 09:47:39 -0800 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 smtpdEqIhZb; Fri, 21 Dec 2001 09:47:36 PST Message-ID: <3C2375B8.A242C65D@iprg.nokia.com> Date: Fri, 21 Dec 2001 09:47:36 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 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 Henrik Petander wrote: > > Hi Vijay, > > On Thu, 20 Dec 2001, Vijay Devarapalli wrote: > > > hi everybody, > > > > heres an attempt to list all the issues that need to be > > resolved so that Mobile IPv6 can move ahead. and some > > suggestions follow them. > > > > ----------------------------------- > > > > 1. Mobile IPv6 use of Routing Header > > It has been identified that reflector attacks are > > possible with MIPv6 use of routing header. There is > > also a solution for this. If the host processing > > the routing header performs a simple rule of > > 'check if the destination address and the next address > > to be swapped in both belong to the same interface > > of the node', before processing the routing header, > > we eliminate this threat caused by MIPv6. > > This requirement would make vertical handoffs impossible for mobile hosts. > Wouldn't it be sufficient for the host to check that the next address > belongs to it and that the scope of the next address is not smaller than > that of the destination address? This would stop reflector attacks, and > allow MN to perform vertical handoffs. Fine with me.... Vijay > > Regards, > > Henrik > ---------------------------------- > 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 Dec 21 13:04: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 NAA28117 for ; Fri, 21 Dec 2001 13:04:40 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13589; Fri, 21 Dec 2001 11:03:08 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17966; Fri, 21 Dec 2001 10:03:22 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLI2jZR002857 for ; Fri, 21 Dec 2001 10:02:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLI2jA6002856 for mobile-ip-dist; Fri, 21 Dec 2001 10:02:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLI2hZR002849 for ; Fri, 21 Dec 2001 10:02:43 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29001 for ; Fri, 21 Dec 2001 13:02:41 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA17403 for mobile-ip@sunroof.eng.sun.com; Fri, 21 Dec 2001 13:03:18 -0500 (EST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLFlpZR001862 for ; Fri, 21 Dec 2001 07:47:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12394 for ; Fri, 21 Dec 2001 07:47:52 -0800 (PST) Received: from iptemplario.ipt.pt ([193.137.5.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08872 for ; Fri, 21 Dec 2001 08:47:07 -0700 (MST) Received: from LOLIVEIRA ([193.137.5.223]) by iptemplario.ipt.pt with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YJ4MQCG8; Fri, 21 Dec 2001 15:34:19 -0000 Message-ID: <003b01c18a79$cf157390$df0589c1@loliveira> From: =?iso-8859-1?Q?Lu=EDs_Miguel_Oliveira?= To: References: <4DA6EA82906FD511BE2F00508BCF053801C4C17B@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] HMIPv6 test Date: Fri, 21 Dec 2001 15:47:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, Anyone have some details about this tests? _________________________________ Luis Miguel L. de Oliveira loliveira@av.it.pt ; loliveira@ipt.pt IPT - Instituto Politécnico de Tomar Quinta do Contador - Estrada da Serra 2300 TOMAR Instituto de Telecomunicações Campus Universitário de Santiago 3810-193 AVEIRO - PORTUGAL _________________________________ ----- Original Message ----- From: "Hesham Soliman (ERA)" To: Sent: Thursday, December 20, 2001 10:48 AM Subject: RE: [mobile-ip] HMIPv6 test > For Ericsson, Mattias Pettersson. > For Monash, Greg Daley. > For conformance lab, I'll get > back to you unless they can see this. > > Hesham > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: Thursday, December 20, 2001 7:44 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] HMIPv6 test > > > > > > a quick question. Who are the contact persons for these > > implementations? > > > > Vijay > > > > "Hesham Soliman (ERA)" wrote: > > > > > > Hi all, > > > > > > Just a quick note to inform you that a small > > > interop test was held before IETF in which > > > HMIPv6 ver-4 was tested. > > > There were implementations from Ericsson, > > > Monash University, and test cases from > > > conformance lab in Ericsson. > > > > > > Regards, > > > Hesham > > > From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 13:10: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 NAA28251 for ; Fri, 21 Dec 2001 13:10:33 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17817; Fri, 21 Dec 2001 11:09:18 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19767; Fri, 21 Dec 2001 10:09:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLI91ZR003034 for ; Fri, 21 Dec 2001 10:09:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLI906o003033 for mobile-ip-dist; Fri, 21 Dec 2001 10:09:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLI8vZR003026 for ; Fri, 21 Dec 2001 10:08:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18703 for ; Fri, 21 Dec 2001 10:09:00 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA11153 for ; Fri, 21 Dec 2001 11:09:47 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA14801 for ; Fri, 21 Dec 2001 10:08:58 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBLI8v806529 for ; Fri, 21 Dec 2001 10:08:57 -0800 X-mProtect: Fri, 21 Dec 2001 10:08:57 -0800 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 smtpdfwerMG; Fri, 21 Dec 2001 10:08:56 PST Message-ID: <3C237AB8.F97ED12C@iprg.nokia.com> Date: Fri, 21 Dec 2001 10:08:56 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 References: <4DA6EA82906FD511BE2F00508BCF053801C4C182@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Hesham, "Hesham Soliman (ERA)" wrote: > > > 2. Mobile IPv6 use of Home Address Option > > The threat in this case is that some trivial source > > spoofing attacks are possible. The answer to source > > spoofing has always been smart ingress filtering. > > its the same in this case too. Using a tunneling > > approach does not it solve it either. So we have > > two options > > a. Document this threat in Mobile IPv6 security > > considerations and leave it. > > b. Solve it by mandating that home address option > > is not processed unless there is a corresponding > > binding cache entry (of course created securely). > > use reverse tuneling through the home agent when > > a binding cache entry does not exist. > > > > in my opinion, lets go with (a). (b) is a really bad > > idea. (b) is too drastic. I can live (a) becase the > > threat is very insignificant. Source spoofing attacks > > are possible currently (in the current internet). if > > the bottom line is 'do no harm' lets go with (a). > > > > => I'm afraid I agree with Pekka here. The threat > is definitely significant. We can't pretend it Well. I disagree that the threat is significant. and we are not pretending that it is not there. we document it and leave it to the implementations. > won't happen, so I'd have to go with b) (unfortunately). > But think on the positive side, it's good to have > a symmetrical bidirectional path, for QoS reasons :) > > > > > 3. Protecting the BU. There are three options. pick one. > > a. new extension header > > b. Authentication Sub-Option only. > > c. Jari Arkko's draft, option 4 which shows how > > authentication suboption and AH can be used > > together with minimal changes. > > > > if we decide to go with (a), lets not go with UDP. > > instead we should use a new extension header. > > I personally prefer option (c). Implementing the > > auth suboption is very easy. I can provide the code > > if people think it is complicated to implement. > > > > => Definitely a) or alternatively a UDP port number. never UDP. a lot of implementations dont have UDP in the kernel. Mobile IPv6 almost always exists in the kernel. IF we go with (a) lets use a new extension header. But before that, I think people should read Jari Arkko's draft again. draft-arkko-mipv6-bu-security-01.txt, section 6.4. With that approach we dont need a new extension header for the BU. and there will be minimal changes to the existing implementations. Before people say 'new extension header' please think about what it means. it means changing a lot of implementations. a new extension header not understood by intermediate routers and dropped. firewalls need to know about the new extension header.... > > > > > 4. Piggybacking > > Phil described various options in his presentation > > at Salt Lake City. lets pick one. > > a. lets leave it as it is. it is a 'MAY'. > > b. leave it as it is, but recommend when it is > > good to use and when it is bad to use. > > => c). (which was discussed), say that it SHOULD NOT > be done. I agree with Francis on this one. > > > > > > > 5. Key Distribution protocol between MN and CN > > a. Return routability vs CGA (Cryptographically > > Generated Addrs) > > b. Binding Security Association > > > > for (a), lets go with return routability unless > > somebody can prove that it is insecure. The added > > complexity of CGA or Diffie Helman operations is > > not worth it. no additional gain. so lets go with > > simple return routability. > > => I can't see how we can do RR only and still maintain > that our requirement is "Add no harm". Connection > hijacking can be considered "new harm" and RR will I guess you need to read BU3WAY again. It just uses return routability. and BU3WAY cannot be called insecure in any way. and your connection hijacking does not happen there. > not stop it. IMHO (and I'm not a security expert) > the combination of CGAs and RR is an excellent idea > and will give quite a strong security. > If the processing power is a concern, some optimisations > were proposed to off-load some of the operations > onto the HA. IMO, this is not a option. there is no protocol for that. and if you try to do that, its plain stupid (of course IMHO). Vijay > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 13:10: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 NAA28266 for ; Fri, 21 Dec 2001 13:10:53 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAB11492; Fri, 21 Dec 2001 10:03:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17213; Fri, 21 Dec 2001 10:00:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHxgZR002782 for ; Fri, 21 Dec 2001 09:59:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLHxg3W002781 for mobile-ip-dist; Fri, 21 Dec 2001 09:59:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLHxeZR002774 for ; Fri, 21 Dec 2001 09:59:41 -0800 (PST) Received: from onion.east.sun.com (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28471 for ; Fri, 21 Dec 2001 12:59:42 -0500 (EST) Received: (from glass@localhost) by onion.east.sun.com (8.9.3+Sun/8.9.3) id NAA17315 for mobile-ip@sunroof.eng.sun.com; Fri, 21 Dec 2001 13:00:19 -0500 (EST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBKNiPZR029046 for ; Thu, 20 Dec 2001 15:44:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18499 for ; Thu, 20 Dec 2001 15:44:26 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA22211 for ; Thu, 20 Dec 2001 16:45:12 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA04607 for ; Thu, 20 Dec 2001 15:44:25 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBKNiOR08460 for ; Thu, 20 Dec 2001 15:44:24 -0800 X-mProtect: Thu, 20 Dec 2001 15:44:24 -0800 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 smtpdpxk2QW; Thu, 20 Dec 2001 15:44:22 PST Message-ID: <3C2277D7.1FBAC696@iprg.nokia.com> Date: Thu, 20 Dec 2001 15:44:23 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [Fwd: Re: [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 here is an old mail from Jari Arkko. this is tells me that it is not too difficult making Authentication sub option work with IKE. and we have also proved that it is implementable and interoperable. regards Vijay -------- Original Message -------- Subject: Re: [mobile-ip] About authorization and security policies Date: Tue, 14 Aug 2001 09:39:04 +0300 From: Jari Arkko Reply-To: mobile-ip@sunroof.eng.sun.com Organization: None To: mobile-ip@sunroof.eng.sun.com References: <200108140252.f7E2qLn00537@dharkins@lounge.orgatty.lounge.org> 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 Fri Dec 21 13:13: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 NAA28333 for ; Fri, 21 Dec 2001 13:13:14 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19903; Fri, 21 Dec 2001 11:12:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20396; Fri, 21 Dec 2001 10:12:17 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIBTZR003092 for ; Fri, 21 Dec 2001 10:11:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLIBTAS003091 for mobile-ip-dist; Fri, 21 Dec 2001 10:11:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIBQZR003084 for ; Fri, 21 Dec 2001 10:11:26 -0800 (PST) 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 KAA19178 for ; Fri, 21 Dec 2001 10:11:28 -0800 (PST) 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 KAA09512 for ; Fri, 21 Dec 2001 10:11:27 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA15341; Fri, 21 Dec 2001 10:11:27 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBLIBQ311145; Fri, 21 Dec 2001 10:11:26 -0800 X-mProtect: Fri, 21 Dec 2001 10:11:26 -0800 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 smtpdaGZegm; Fri, 21 Dec 2001 10:11:25 PST Message-ID: <3C237B4D.205C2437@iprg.nokia.com> Date: Fri, 21 Dec 2001 10:11:25 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Morrow CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 References: <933FADF5E673D411B8A30002A5608A0E01449EF9@zrc2c012.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, Glenn Morrow wrote: > I guess all application or transport layers, even UDP, are responsible for > checking that the source address is valid to tunnel-in so to speak? I may be > wrong but we might be ignoring some other - less publicized threats. To my understanding, the routing header is not necessarily even visible to higher-level protocols. I don't think they should have anything to do with processing routing headers. On the other hand, I think that setting up intermediate nodes for routing headers is an application-level function, just as with routing protocols. >> 2. Mobile IPv6 use of Home Address Option >> The threat in this case is that some trivial source >> spoofing attacks are possible. The answer to source >> spoofing has always been smart ingress filtering. >> its the same in this case too. Using a tunneling >> approach does not it solve it either. So we have >> two options >> a. Document this threat in Mobile IPv6 security >> considerations and leave it. >> b. Solve it by mandating that home address option >> is not processed unless there is a corresponding >> binding cache entry (of course created securely). >> use reverse tuneling through the home agent when >> a binding cache entry does not exist. >> >> in my opinion, lets go with (a). (b) is a really bad >> idea. (b) is too drastic. I can live (a) becase the >> threat is very insignificant. Source spoofing attacks >> are possible currently (in the current internet). if >> the bottom line is 'do no harm' lets go with (a). >> > > My opinion is that the specs should be correct and devoid of holes. It is > implementation specific choice of vendors of equipment and software to be > compliant or not. I don't think we should trivialize the hole. We should just > fix it and move on. I also do not think that plugging the hole will > significantly increase the cost of devices. Ex. I don't see an IP-enabled > light switch or toaster being accessed by millions of mobile nodes at the same > time. I have to agree that the specification has to be correct! However, we always have to weigh the cost of the problem against the cost of the solution. If the problem is microscopic, and the solution so burdensome as to likely inhibit implementation, then the solution is not a solution after all, and we should just document the problem. Thus I agree very much with (a), because I think the threat is small. Plus, I think that ingress-filtering routers can be built to make the threat even smaller. Furthermore, there are rules that can be built into correspondent nodes to reduce the threat even more. >> 5. Key Distribution protocol between MN and CN >> a. Return routability vs CGA (Cryptographically >> Generated Addrs) >> b. Binding Security Association >> >> for (a), lets go with return routability unless >> somebody can prove that it is insecure. The added >> complexity of CGA or Diffie Helman operations is >> not worth it. no additional gain. so lets go with >> simple return routability. >> >> for (b), I am not sure. >> > > While I am not apposed to the 3-way triangular handshake - bounce around the > world solutions being devised and standardized. At some point, it might be > fruitful to focus on finding solutions that don't require AAA, yet can > accomplish the association establishment in fewer messages. This might be more > appropriate for working with real-time media streams. It would also be faster > for non-realtime streams. I don't really see that solution to this fast > establishment problem should be restricted to just mobile ip, however. I would > certainly understand if MIP-specific slower methods were standardized and > implemented first, though. If we were to make the three-way handshake part of the data stream, then it would boil down to no more messages, but of course a lot more data bytes in those messages. Even if we don't do that, I think that the return routability stuff isn't so bad, given that it would typically occur when the application starts up, so that it would not interfere with the actual data streaming. The thing about Mobile IP that suggests a specialized solution is exactly the possibility to rely on the return routability for additional protection against wide-area attacks. In fact, I reckon that this will make MIP-specific methods faster, not slower, as long as we don't go overboard with mandating a lot of heavy exponentiation as part of the solution. > The main point here is that if the 3-way handshake is the implementation, the > applicability of its use with other WG technologies may be deminished; > therefore other SDOs can claim that because of this, they are not conformant > with MIPv6 route optimization. I don't think this is a likely result. Furthermore, if another solution is found that meets the performance and security needs of Mobile IPv6, then it should be possible to use it. This is another good reason to keep the key establishment protocol separated from the Mobile IPv6 protocol. > Even if there were a MIP RO with AAA document that did show how it could be > done with fewer messages, I suspect that the endpoints might need to know > which way it is being done and this might affect the MIPv6 protocol, itself? > If a solution with no AAA could be found and agreed upon, this might avoid all > of this unpleasantness. What do you think about bu3way? It's bound to be a lot faster than AAA, and can be adorned with optional features for additional security for applications that need it. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 13:20: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 NAA28564 for ; Fri, 21 Dec 2001 13:20:14 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19023; Fri, 21 Dec 2001 10:19:01 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21413; Fri, 21 Dec 2001 10:18:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLII6ZR003273 for ; Fri, 21 Dec 2001 10:18:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLII6kb003272 for mobile-ip-dist; Fri, 21 Dec 2001 10:18:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLII2ZR003262 for ; Fri, 21 Dec 2001 10:18:02 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21779 for ; Fri, 21 Dec 2001 10:18:04 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24123 for ; Fri, 21 Dec 2001 11:18:04 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA15786 for ; Fri, 21 Dec 2001 10:18:04 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBLII3720958 for ; Fri, 21 Dec 2001 10:18:03 -0800 X-mProtect: Fri, 21 Dec 2001 10:18:03 -0800 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 smtpdUp9dCh; Fri, 21 Dec 2001 10:18:02 PST Message-ID: <3C237CD7.DAD049A2@iprg.nokia.com> Date: Fri, 21 Dec 2001 10:17:59 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 References: <200112211439.fBLEdfD69151@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, Francis Dupont wrote: > So we have two options > a. Document this threat in Mobile IPv6 security > considerations and leave it. > b. Solve it by mandating that home address option > is not processed unless there is a corresponding > binding cache entry (of course created securely). > use reverse tuneling through the home agent when > a binding cache entry does not exist. > > in my opinion, lets go with (a). (b) is a really bad > idea. (b) is too drastic. I can live (a) because the > > => you already know I agree! I wish everybody would. it would great if implementors are given more importance in this WG. then we could have our way. > > 3. Protecting the BU. There are three options. pick one. > a. new extension header > b. Authentication Sub-Option only. > c. Jari Arkko's draft, option 4 which shows how > authentication suboption and AH can be used > together with minimal changes. > > => argh! Which draft/section/etc? draft-arkko-mipv6-bu-security-01.txt, section 6.4. > for (b), I am not sure. > > => explain a bit more the (b) issue. the issue is with the creation of BSAs. do you need the key distribution protocol to create BSAs? for example both BU3WAY and BAKE use return routability. but BAKE creates a BSA, whereas BU3WAY does not. BU3WAY is run everytime the MN sends a BU to the CN. There are a few arguments for not creating a BSA in Erik Nordmark's draft. > => hum, perhaps this will work but IMHO this should take months! I am thinking of closing issues 1-4 in a matter of few weeks. agreed that 5 will take longer. but it should be doable by Minneapolis IETF. (being optimistic as always...) Vijay > > Maybe the WG chairs can decide on the concensus. > > => WG chair job is harder and harder (:-)... > > Regards > > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 13:21:43 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28610 for ; Fri, 21 Dec 2001 13:21:42 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26109; Fri, 21 Dec 2001 11:20:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22038; Fri, 21 Dec 2001 10:20:49 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIK8ZR003328 for ; Fri, 21 Dec 2001 10:20:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLIK8Lv003327 for mobile-ip-dist; Fri, 21 Dec 2001 10:20:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIK4ZR003310 for ; Fri, 21 Dec 2001 10:20:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09537 for ; Fri, 21 Dec 2001 10:20:06 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24715 for ; Fri, 21 Dec 2001 11:20:05 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA15878 for ; Fri, 21 Dec 2001 10:20:05 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBLIK4B22877 for ; Fri, 21 Dec 2001 10:20:04 -0800 X-mProtect: Fri, 21 Dec 2001 10:20:04 -0800 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 smtpdMQTYjS; Fri, 21 Dec 2001 10:20:03 PST Message-ID: <3C237D53.87E38F93@iprg.nokia.com> Date: Fri, 21 Dec 2001 10:20:03 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 References: <4DA6EA82906FD511BE2F00508BCF053801C4C182@Esealnt861.al.sw.ericsson.se> <3C237AB8.F97ED12C@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 Vijay Devarapalli wrote: > > not stop it. IMHO (and I'm not a security expert) > > the combination of CGAs and RR is an excellent idea > > and will give quite a strong security. > > If the processing power is a concern, some optimisations > > were proposed to off-load some of the operations > > onto the HA. > > IMO, this is not a option. there is no protocol for that. > and if you try to do that, its plain stupid (of course IMHO). here I was talking about off-loading the operations onto the Home Agent. Vijay > > Vijay > > > > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 13: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 NAA28785 for ; Fri, 21 Dec 2001 13:29:12 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01603; Fri, 21 Dec 2001 11:27:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24290; Fri, 21 Dec 2001 10:28:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIRNZR003541 for ; Fri, 21 Dec 2001 10:27:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLIRNRf003540 for mobile-ip-dist; Fri, 21 Dec 2001 10:27:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIRKZR003533 for ; Fri, 21 Dec 2001 10:27:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14796 for ; Fri, 21 Dec 2001 10:27:22 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA19517 for ; Fri, 21 Dec 2001 11:28:10 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fBLIR5H17045 for ; Fri, 21 Dec 2001 10:27:05 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO38857; Fri, 21 Dec 2001 10:26:45 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA06976; Fri, 21 Dec 2001 10:27:19 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15395.32518.925275.491480@thomasm-u1.cisco.com> Date: Fri, 21 Dec 2001 10:27:18 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-Reply-To: <3C237AB8.F97ED12C@iprg.nokia.com> References: <4DA6EA82906FD511BE2F00508BCF053801C4C182@Esealnt861.al.sw.ericsson.se> <3C237AB8.F97ED12C@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: > > > in my opinion, lets go with (a). (b) is a really bad > > > idea. (b) is too drastic. I can live (a) becase the > > > threat is very insignificant. Source spoofing attacks > > > are possible currently (in the current internet). if > > > the bottom line is 'do no harm' lets go with (a). > > > > > > > => I'm afraid I agree with Pekka here. The threat > > is definitely significant. We can't pretend it > > Well. I disagree that the threat is significant. and we are > not pretending that it is not there. we document it and leave > it to the implementations. One of the criteria that Jeff gave was "do no harm". There has *considerable* push to get RFC 2827 implemented widely. MIPv6 providing a new and pervasive source of source spoofing without a way to prevent that introduces considerable harm by any reasonable definition. I cannot see how this can be handwaved away. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 13:43: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 NAA29026 for ; Fri, 21 Dec 2001 13:43:40 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24753; Fri, 21 Dec 2001 10:33:35 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25201; Fri, 21 Dec 2001 10:31:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIV0ZR003638 for ; Fri, 21 Dec 2001 10:31:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLIV0Xx003637 for mobile-ip-dist; Fri, 21 Dec 2001 10:31:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIUuZR003630 for ; Fri, 21 Dec 2001 10:30:57 -0800 (PST) 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 KAA25054 for ; Fri, 21 Dec 2001 10:30:59 -0800 (PST) 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 KAA02071 for ; Fri, 21 Dec 2001 10:30:59 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA16581 for ; Fri, 21 Dec 2001 10:30:58 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBLIUwA10971 for ; Fri, 21 Dec 2001 10:30:58 -0800 X-mProtect: Fri, 21 Dec 2001 10:30:58 -0800 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 smtpdp2Idoa; Fri, 21 Dec 2001 10:30:56 PST Message-ID: <3C237FE1.D041D3BD@iprg.nokia.com> Date: Fri, 21 Dec 2001 10:30:57 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 References: <4DA6EA82906FD511BE2F00508BCF053801C4C18C@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit one small comment. "Hesham Soliman (ERA)" wrote: > > > a. new extension header > > b. Authentication Sub-Option only. > > c. Jari Arkko's draft, option 4 which shows how > > authentication suboption and AH can be used > > together with minimal changes. > > > > if we decide to go with (a), lets not go with UDP. > > instead we should use a new extension header. > > I personally prefer option (c). Implementing the > > auth suboption is very easy. I can provide the code > > if people think it is complicated to implement. > > > I thought the group had already settled on b. Last time I checked there were even plans to upgrade various open-source implementations as well. > > => That was optimistic thinking I think ! we never > had a concensus call on this. option (b) is very simple and works really well. all it needs is IKE supplying the keys. imagine this. 1. weak authentication can supply the key for the auth sub option 2. IKE can supply the key for the auth sub option 3. you dont have to worry about a new extension header for the BU. 4. you dont have to worry about IPSec and piggybacking. sigh(!) there are so many advantages... people just dont want to see it. also please take a look at the Jari Arkko's old mail that I forwarded to the mailing list yesterday. IKE can be used to create keys for the auth sub option. if the IPSec WG says they dont want to work on (2), then lets go with option (c). use both the sub option and AH. Vijay > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 13:56: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 NAA29395 for ; Fri, 21 Dec 2001 13:56:18 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA29581; Fri, 21 Dec 2001 10:43:48 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28006; Fri, 21 Dec 2001 10:43:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIgNZR003764 for ; Fri, 21 Dec 2001 10:42:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLIgNmX003763 for mobile-ip-dist; Fri, 21 Dec 2001 10:42:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLIgKZR003756 for ; Fri, 21 Dec 2001 10:42:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18028 for ; Fri, 21 Dec 2001 10:42:22 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26516 for ; Fri, 21 Dec 2001 11:43:10 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA17292; Fri, 21 Dec 2001 10:42:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBLIgKT28387; Fri, 21 Dec 2001 10:42:20 -0800 X-mProtect: Fri, 21 Dec 2001 10:42:20 -0800 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 smtpdLAq6HH; Fri, 21 Dec 2001 10:42:18 PST Message-ID: <3C23828A.4876D73E@iprg.nokia.com> Date: Fri, 21 Dec 2001 10:42:18 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 References: <200112211439.fBLEdfD69151@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: > > 1. Mobile IPv6 use of Routing Header > > => the solution has to be written down in a draft and presented > to the IPv6 WG ASAP as a part of the host requirement document. The solution depends on the application. For Mobile IPv6, the solution is trivial, as has been suggested many times by me and other people. I can imagine uses of the routing header that would be set up by security-conscious people who demand certain routability. I believe that the IPv6 working group CANNOT predict all the necessary policy mechanisms to check the correctness of such esoteric uses of the routing header. BTW, the current draft does NOT restrict such enhanced capabilities from the routing header. It just demands that any existing sequence of intermediate nodes should be kept as is except that the care-of address is to be inserted before the home address in the source route. > 2. Mobile IPv6 use of Home Address Option > The threat in this case is that some trivial source > spoofing attacks are possible. The answer to source > spoofing has always been smart ingress filtering. > > => it seems I have to write the IPv6 ingress filtering document > (it is in my TODO list, I'll check with my co-author when we > can write it). This sounds like a real piece of hard work. Can you give a preview of what you have in mind? Are you looking for co-masochists? > So we have two options > a. Document this threat in Mobile IPv6 security > considerations and leave it. > b. Solve it by mandating that home address option > is not processed unless there is a corresponding > binding cache entry (of course created securely). > use reverse tuneling through the home agent when > a binding cache entry does not exist. > > in my opinion, lets go with (a). (b) is a really bad > idea. (b) is too drastic. I can live (a) because the > > => you already know I agree! I wholeheartedly agree with this approach. I hope we can get consensus on it soon and move forward. > threat is very insignificant. Source spoofing attacks > are possible currently (in the current internet). if > the bottom line is 'do no harm' lets go with (a). > > => I shan't use the argument. The threat is real and we have > to give back the tools against it. The limits of these tools > are simply not in our scope. I agree that there is a real threat. I don't think it's huge, and I do think there are tools that we can build to protect against it. I also think that the threat posed by additional delay of Mobile IPv6 is larger than the threat posed by this source-spoofing attack. > > 3. Protecting the BU. There are three options. pick one. > a. new extension header > b. Authentication Sub-Option only. > c. Jari Arkko's draft, option 4 which shows how > authentication suboption and AH can be used > together with minimal changes. > > => argh! Which draft/section/etc? > > if we decide to go with (a), lets not go with UDP. > instead we should use a new extension header. > > => I am in favor of (a) because it works without the need > to check if there is some IPsec somewhere. As IPsec codes > are a bit complex (:-) and have strange (:-) interactions > with other parts of stacks, IMHO this is a strong argument. I'm not so enthusiastic about (a), because I know it's a pile of work to do it. On the other hand, in the abstract without consideration of wearing out my keyboard, I would be happy to support it in hopes of getting closure towards getting the draft through working-group Last Call. > 4. Piggybacking > Phil described various options in his presentation > at Salt Lake City. lets pick one. > > => I presented a generalized version (the IPv6 payload header) > of this at an IPv6 session at SLC. I had to specify that my purpose > was to collect pros & cons, not to really defend the idea, > in order to not be hung with the micro cord... I should release > a new version of the I-D with a lot of cons soon (i.e. before > next IETF). In previous e-mail, I have pointed out why arguments for the generalized IPv6 payload header are different than the arguments for including Binding Update as an option within a stream of data. Briefly, it has to do with the timeliness of the control messages and the naturalness of inclusion along with the data. > a. lets leave it as it is. it is a 'MAY'. > b. leave it as it is, but recommend when it is > good to use and when it is bad to use. > > => (b) with good to use == never and bad to use == always! This isn't right. It's almost always good to use, because it almost always offers a performance improvement. There are times when the performance improvement could make the difference in even the feasibility of smooth voice handovers, due to the decrease in jitter (as was pointed out in work from Cedric Westphal). There is practically zero downside for the receiver. The downside at the sender is that it takes more code. Arguments about channel sizing and dropping outsized packets apply only to systems with broken IPv6 implementations. Every IPv6 implementation is mandated to be able to deliver such packets. So I strongly suggest that we _allow_ platforms to be built that offer the better performance, without by any means mandating that such piggybacking MUST be done by the sender. > 5. Key Distribution protocol between MN and CN > a. Return routability vs CGA (Cryptographically > Generated Addrs) > b. Binding Security Association > > for (a), lets go with return routability unless > somebody can prove that it is insecure. > > => very easy: put the attacker in the CN default router. This is not "easy", and furthermore to prevent such an attack would take a LOT more mandated protocol than is likely to be promoted as part of any realistic solution. I reckon that compromising the default router is one of the worst things that could happen at any enterprise, and afterwards nobody will give a rat's patootie about what happened to Mobile IPv6. > The added > complexity of CGA or Diffie Helman operations is > not worth it. no additional gain. so lets go with > simple return routability. > > => I am afraid that if we do that all CNs will simply reject > BSA establishment attempts. Of course if BSA establishments > are very expensive (a lot of crypto operations) we'll get the > same result. Here we really need a miracle! No, but we could use less hysteria. I would suggest that we build and test some of the proposed approaches, and carry out some reasoned discussion after we have more experience. This whole argument is sounding to me about how insane it would be to use your credit card over the Internet. As it turns out, life is not so horrible after all. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 14:10: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 OAA29710 for ; Fri, 21 Dec 2001 14:10:28 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07966; Fri, 21 Dec 2001 11:03:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21130; Fri, 21 Dec 2001 11:03:38 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLJ2mZR003967 for ; Fri, 21 Dec 2001 11:02:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLJ2mVE003966 for mobile-ip-dist; Fri, 21 Dec 2001 11:02:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLJ2jZR003959 for ; Fri, 21 Dec 2001 11:02:45 -0800 (PST) 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 LAA24116 for ; Fri, 21 Dec 2001 11:02:45 -0800 (PST) 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 LAA14395 for ; Fri, 21 Dec 2001 11:02:45 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA18568; Fri, 21 Dec 2001 11:02:45 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBLJ2hf23255; Fri, 21 Dec 2001 11:02:43 -0800 X-mProtect: Fri, 21 Dec 2001 11:02:43 -0800 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 smtpdVtrkml; Fri, 21 Dec 2001 11:02:42 PST Message-ID: <3C238753.FF634071@iprg.nokia.com> Date: Fri, 21 Dec 2001 11:02:43 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (EPA)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 References: <4DA6EA82906FD511BE2F00508BCF053801C4C182@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, "Hesham Soliman (ERA)" wrote: > => I can't see how we can do RR only and still maintain > that our requirement is "Add no harm". Connection > hijacking can be considered "new harm" and RR will > not stop it. Can you be specific about the hijacking danger that you see? What I'm imagining is this: - Suppose Correspondent Node and Mobile Node (MN) are communicating - Bogus Mobile Node (BMN) sends a bu3way (e.g.) message to validate a Binding Update for a bogus care-of address. - BMN eventually gets CN to send packets to BMN. I agree that this could happen. But only when BMN resides in certain places (e.g., at Francis Dupont's default router). Thus, I don't think this qualifies as an additional threat. > IMHO (and I'm not a security expert) > the combination of CGAs and RR is an excellent idea > and will give quite a strong security. > If the processing power is a concern, some optimisations > were proposed to off-load some of the operations > onto the HA. CGA helps to establish ownership of an address. As has been pointed out, it doesn't solve all the problems with bombing arbitrary subnets. So I think it should be an optional feature, not mandated but recommended for situations where the extra security is valuable. Regards, Charlie (not a security expert either) P. From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 14:19: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 OAA29982 for ; Fri, 21 Dec 2001 14:19:43 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04997; Fri, 21 Dec 2001 12:18:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25144; Fri, 21 Dec 2001 11:18:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLJHsZR004114 for ; Fri, 21 Dec 2001 11:17:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLJHsmB004113 for mobile-ip-dist; Fri, 21 Dec 2001 11:17:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLJHoZR004106 for ; Fri, 21 Dec 2001 11:17:50 -0800 (PST) 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 LAA06239 for ; Fri, 21 Dec 2001 11:17:51 -0800 (PST) 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 LAA14486 for ; Fri, 21 Dec 2001 11:17:49 -0800 (PST) Received: from jariws1 ([62.248.153.66]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011221191748.LADF11987.fep01-app.kolumbus.fi@jariws1> for ; Fri, 21 Dec 2001 21:17:48 +0200 Message-ID: <003301c18a54$4b115e80$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: References: <3C2230D9.5BA4B149@iprg.nokia.com> Subject: Re: [mobile-ip] list of things for MIPv6 Date: Fri, 21 Dec 2001 21:18:38 +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.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 > 1. Mobile IPv6 use of Routing Header Agree that a rule is needed, and expect the rule to be sufficient. Need to work on exactly what the rule is, though. > 2. Mobile IPv6 use of Home Address Option > The threat in this case is that some trivial source > spoofing attacks are possible. The answer to source > spoofing has always been smart ingress filtering. > its the same in this case too. Using a tunneling > approach does not it solve it either. So we have > two options > a. Document this threat in Mobile IPv6 security > considerations and leave it. > b. Solve it by mandating that home address option > is not processed unless there is a corresponding > binding cache entry (of course created securely). > use reverse tuneling through the home agent when > a binding cache entry does not exist. > > in my opinion, lets go with (a). (b) is a really bad > idea. (b) is too drastic. I can live (a) becase the > threat is very insignificant. Source spoofing attacks > are possible currently (in the current internet). if > the bottom line is 'do no harm' lets go with (a). I believe there is a real difference in current spoofing attacks compared to the ones enabled by the home address option. Namely, ingress filtering or other techniques can prevent source address spoofing but I can't see how they could prevent HAO spoofing. However, regarding the exact strength of the attack opened through this whole I think the jury is still out. We had a discussion with Erik and Gabriel about trying to classify the threat in some sort of a 'Richter scale'. For instance, this attack seems to evade all known automatic tracing and detection techniques unlike e.g. typical TCP SYN attacks, but on the other hand it does not produce any packet amplification. Still, it could be used as a part of a DDoS to hide client locations. My preliminary answer here would be (b) unless we can think of something else, or a believable reason why the attack isn't serious enough. > 3. Protecting the BU. There are three options. pick one. > a. new extension header > b. Authentication Sub-Option only. > c. Jari Arkko's draft, option 4 which shows how > authentication suboption and AH can be used > together with minimal changes. I'd like to see this as two separate issues, actually. The first issue is whether PKI and RR/CGA-based authentication are *alternatives* of which exactly one is used for one packet, or whether they are complementary, possibly used together. On this first question I have lately come to the conclusion that I'd prefer them to be possibly used together. This is because the methods prove different things. CGA e.g. proves address ownership while PKI proves you belong to the group of good guys. You might want the other one too, even if you already did one. The second issue is which protocol actually protects the BUs. Here my preferences are options 6.2 or 6.4 from my draft. (I seem to recall that we had some consensus in SLC about using rather a new protocol or UDP than IPv6 DOs... if so, then 6.2 would be clearly possible as well). > 5. Key Distribution protocol between MN and CN > a. Return routability vs CGA (Cryptographically > Generated Addrs) > b. Binding Security Association First of all, I think the main alternatives are either pure RR without D-H or RR+D-H+CGA. The reason for this is that if you end up doing bignum math in D-H you might as well get the full protection with CGA at the same time. Secondly, for the performance concerns, I believe we can rule out effects to small mobiles, given that there exists crypto offload mechanisms (see CAM-DH) that can take care of this. Servers and HAs, on the other hand, may have more of an issue but there are otoh lots of crypto hardware accelerators available, if a server wants to do RO with a large number of clients. I believe Gab intended to post some performance information to the list. Thirdly, there seems to be some differences in the security strength of RR vs CGA. There even seems to be some differences in v4 security vs. MIPv6 + RR. Whether these are significant, needs to be discussed. I intend to write something about this to the list -- but after christmas. My personal preference is D-H+CGA, because it's the only solution that truly proves address ownership. Fourth, recent discussion in the list under the "Risks of not verifying the care-of address" seem to have concluded that in order to avoid the 3rd party bombing attacks, we need to verify CoA RR not just once, but on every movement. To me, this implies that if we use just RR, then we may not find BSAs very useful (and hence all the discussion IPsec vs. -14 is moot). On the other hand, if CGA is used then there's a clear advantage to BSAs still since the bignum math can be done just once, while RR and some symmetric crypto is still done on every movement. So, RR => no BSA, CGA => BSA. Fifth, we need also some further decisions, such as whether to do an RR test to CoA as well as the HoA (I think we do), and some DoS resistance tricks (e.g. puzzles vs. RR at the bottom of CGA, I believe RR is a better choice for this), and possibly some others. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 14:29: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 OAA00233 for ; Fri, 21 Dec 2001 14:29:28 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17209; Fri, 21 Dec 2001 11:28:06 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27334; Fri, 21 Dec 2001 11:28:01 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLJRGZR004234 for ; Fri, 21 Dec 2001 11:27:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLJRFh6004233 for mobile-ip-dist; Fri, 21 Dec 2001 11:27:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLJRCZR004220 for ; Fri, 21 Dec 2001 11:27:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27104 for ; Fri, 21 Dec 2001 11:27:12 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15684 for ; Fri, 21 Dec 2001 12:27:59 -0700 (MST) Received: from zrchb200.us.nortel.com (zrchb200.us.nortel.com [47.103.121.45]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id fBLJR9n04989 for ; Fri, 21 Dec 2001 13:27:09 -0600 (CST) Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 21 Dec 2001 13:25:40 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E01449FF0@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] list of things for MIPv6 Date: Fri, 21 Dec 2001 13:25:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C18A55.46520C40" Sender: owner-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_01C18A55.46520C40 Content-Type: text/plain; charset="iso-8859-1" Charlie, I think I may not have made myself clear on some of the points. I'll try to rephrase them either via contributions or in a later posting. Happy Holidays to all, Glenn > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, December 21, 2001 12:11 PM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] list of things for MIPv6 > > > Hello Glenn, > > Glenn Morrow wrote: > > > I guess all application or transport layers, even UDP, are > responsible for > > checking that the source address is valid to tunnel-in so > to speak? I may be > > wrong but we might be ignoring some other - less publicized threats. > > To my understanding, the routing header is not necessarily even > visible to higher-level protocols. I don't think they should have > anything to do with processing routing headers. > > On the other hand, I think that setting up intermediate nodes for > routing headers is an application-level function, just as with > routing protocols. > > >> 2. Mobile IPv6 use of Home Address Option > >> The threat in this case is that some trivial source > >> spoofing attacks are possible. The answer to source > >> spoofing has always been smart ingress filtering. > >> its the same in this case too. Using a tunneling > >> approach does not it solve it either. So we have > >> two options > >> a. Document this threat in Mobile IPv6 security > >> considerations and leave it. > >> b. Solve it by mandating that home address option > >> is not processed unless there is a corresponding > >> binding cache entry (of course created securely). > >> use reverse tuneling through the home agent when > >> a binding cache entry does not exist. > >> > >> in my opinion, lets go with (a). (b) is a really bad > >> idea. (b) is too drastic. I can live (a) becase the > >> threat is very insignificant. Source spoofing attacks > >> are possible currently (in the current internet). if > >> the bottom line is 'do no harm' lets go with (a). > >> > > > > My opinion is that the specs should be correct and devoid > of holes. It is > > implementation specific choice of vendors of equipment and > software to be > > compliant or not. I don't think we should trivialize the > hole. We should just > > fix it and move on. I also do not think that plugging the hole will > > significantly increase the cost of devices. Ex. I don't see > an IP-enabled > > light switch or toaster being accessed by millions of > mobile nodes at the same > > time. > > I have to agree that the specification has to be correct! However, we > always have to weigh the cost of the problem against the cost of the > solution. If the problem is microscopic, and the solution so > burdensome > as to likely inhibit implementation, then the solution is not > a solution > after all, and we should just document the problem. Thus I agree very > much with (a), because I think the threat is small. Plus, I > think that > ingress-filtering routers can be built to make the threat > even smaller. > Furthermore, there are rules that can be built into > correspondent nodes > to reduce the threat even more. > > > >> 5. Key Distribution protocol between MN and CN > >> a. Return routability vs CGA (Cryptographically > >> Generated Addrs) > >> b. Binding Security Association > >> > >> for (a), lets go with return routability unless > >> somebody can prove that it is insecure. The added > >> complexity of CGA or Diffie Helman operations is > >> not worth it. no additional gain. so lets go with > >> simple return routability. > >> > >> for (b), I am not sure. > >> > > > > While I am not apposed to the 3-way triangular handshake - > bounce around the > > world solutions being devised and standardized. At some > point, it might be > > fruitful to focus on finding solutions that don't require > AAA, yet can > > accomplish the association establishment in fewer messages. > This might be more > > appropriate for working with real-time media streams. It > would also be faster > > for non-realtime streams. I don't really see that solution > to this fast > > establishment problem should be restricted to just mobile > ip, however. I would > > certainly understand if MIP-specific slower methods were > standardized and > > implemented first, though. > > If we were to make the three-way handshake part of the data > stream, then it > would boil down to no more messages, but of course a lot more > data bytes in > those messages. Even if we don't do that, I think that the > return routability > stuff isn't so bad, given that it would typically occur when > the application > starts up, so that it would not interfere with the actual > data streaming. > > The thing about Mobile IP that suggests a specialized > solution is exactly > the possibility to rely on the return routability for > additional protection > against wide-area attacks. In fact, I reckon that this will > make MIP-specific > methods faster, not slower, as long as we don't go overboard > with mandating > a lot of heavy exponentiation as part of the solution. > > > The main point here is that if the 3-way handshake is the > implementation, the > > applicability of its use with other WG technologies may be > deminished; > > therefore other SDOs can claim that because of this, they > are not conformant > > with MIPv6 route optimization. > > I don't think this is a likely result. Furthermore, if > another solution > is found that meets the performance and security needs of > Mobile IPv6, then > it should be possible to use it. This is another good reason > to keep the > key establishment protocol separated from the Mobile IPv6 protocol. > > > Even if there were a MIP RO with AAA document that did show > how it could be > > done with fewer messages, I suspect that the endpoints > might need to know > > which way it is being done and this might affect the MIPv6 > protocol, itself? > > If a solution with no AAA could be found and agreed upon, > this might avoid all > > of this unpleasantness. > > What do you think about bu3way? It's bound to be a lot > faster than AAA, and > can be adorned with optional features for additional security > for applications > that need it. > > Regards, > Charlie P. > ------_=_NextPart_001_01C18A55.46520C40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] list of things for MIPv6

Charlie,

I think I may not have made myself clear on some of = the points. I'll try to rephrase them either via contributions or in a = later posting. 

Happy Holidays to all,

Glenn

> -----Original Message-----
> From: Charles E. Perkins [mailto:charliep@iprg.nokia.com]
> Sent: Friday, December 21, 2001 12:11 PM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: mobile-ip@sunroof.eng.sun.com
> Subject: Re: [mobile-ip] list of things for = MIPv6
>
>
> Hello Glenn,
>
> Glenn Morrow wrote:
>
> > I guess all application or transport = layers, even UDP, are
> responsible for
> > checking that the source address is valid = to tunnel-in so
> to speak? I may be
> > wrong but we might be ignoring some other = - less publicized threats.
>
> To my understanding, the routing header is not = necessarily even
> visible to higher-level protocols.  I = don't think they should have
> anything to do with processing routing = headers.
>
> On the other hand, I think that setting up = intermediate nodes for
> routing headers is an application-level = function, just as with
> routing protocols.
>
> >> 2. Mobile IPv6 use of Home Address = Option
> = >>         The threat in = this case is that some trivial source
> = >>         spoofing = attacks are possible. The answer to source
> = >>         spoofing has = always been smart ingress filtering.
> = >>         its the same = in this case too. Using a tunneling
> = >>         approach does = not it solve it either. So we have
> = >>         two = options
> = >>         a. Document = this threat in Mobile IPv6 security
> = >>          &nbs= p; considerations and leave it.
> = >>         b. Solve it by = mandating that home address option
> = >>          &nbs= p; is not processed unless there is a corresponding
> = >>          &nbs= p; binding cache entry (of course created securely).
> = >>          &nbs= p; use reverse tuneling through the home agent when
> = >>          &nbs= p; a binding cache entry does not exist.
> >>
> = >>         in my opinion, = lets go with (a). (b) is a really bad
> = >>         idea. (b) is = too drastic. I can live (a) becase the
> >>       = threat is very insignificant. Source spoofing attacks
> >>       = are possible currently (in the current internet). if
> >>       = the bottom line is 'do no harm' lets go with (a).
> >>
> >
> > My opinion is that the specs should be = correct and devoid
> of holes. It is
> > implementation specific choice of vendors = of equipment and
> software to be
> > compliant or not. I don't think we should = trivialize the
> hole. We should just
> > fix it and move on. I also do not think = that plugging the hole will
> > significantly increase the cost of = devices. Ex. I don't see
> an IP-enabled
> > light switch or toaster being accessed by = millions of
> mobile nodes at the same
> > time.
>
> I have to agree that the specification has to = be correct!  However, we
> always have to weigh the cost of the problem = against the cost of the
> solution.  If the problem is microscopic, = and the solution so
> burdensome
> as to likely inhibit implementation, then the = solution is not
> a solution
> after all, and we should just document the = problem.  Thus I agree very
> much with (a), because I think the threat is = small.  Plus, I
> think that
> ingress-filtering routers can be built to make = the threat
> even smaller.
> Furthermore, there are rules that can be built = into
> correspondent nodes
> to reduce the threat even more.
>
>
> >> 5. Key Distribution protocol between = MN and CN
> = >>         a. Return = routability vs CGA (Cryptographically
> = >>          &nbs= p; Generated Addrs)
> = >>         b. Binding = Security Association
> >>
> = >>         for (a), lets = go with return routability unless
> >>       = somebody can prove that it is insecure. The added
> >>       = complexity of CGA or Diffie Helman operations is
> >>       = not worth it. no additional gain. so lets go with
> >>       = simple return routability.
> >>
> = >>         for (b), I am = not sure.
> >>
> >
> > While I am not apposed to the 3-way = triangular handshake -
> bounce around the
> > world solutions being devised and = standardized. At some
> point, it might be
> > fruitful to focus on finding solutions = that don't require
> AAA, yet can
> > accomplish the association establishment = in fewer messages.
> This might be more
> > appropriate for working with real-time = media streams. It
> would also be faster
> > for non-realtime streams.  I don't = really see that solution
> to this fast
> > establishment problem should be restricted = to just mobile
> ip, however. I would
> > certainly understand if MIP-specific = slower methods were
> standardized and
> > implemented first, though.
>
> If we were to make the three-way handshake part = of the data
> stream, then it
> would boil down to no more messages, but of = course a lot more
> data bytes in
> those messages.  Even if we don't do that, = I think that the
> return routability
> stuff isn't so bad, given that it would = typically occur when
> the application
> starts up, so that it would not interfere with = the actual
> data streaming.
>
> The thing about Mobile IP that suggests a = specialized
> solution is exactly
> the possibility to rely on the return = routability for
> additional protection
> against wide-area attacks.  In fact, I = reckon that this will
> make MIP-specific
> methods faster, not slower, as long as we don't = go overboard
> with mandating
> a lot of heavy exponentiation as part of the = solution.
>
> > The main point here is that if the 3-way = handshake is the
> implementation, the
> > applicability of its use with other WG = technologies may be
> deminished;
> > therefore other SDOs can claim that = because of this, they
> are not conformant
> > with MIPv6 route optimization.
>
> I don't think this is a likely result.  = Furthermore, if
> another solution
> is found that meets the performance and = security needs of
> Mobile IPv6, then
> it should be possible to use it.  This is = another good reason
> to keep the
> key establishment protocol separated from the = Mobile IPv6 protocol.
>
> > Even if there were a MIP RO with AAA = document that did show
> how it could be
> > done with fewer messages, I suspect that = the endpoints
> might need to know
> > which way it is being done and this might = affect the MIPv6
> protocol, itself?
> > If a solution with no AAA could be found = and agreed upon,
> this might avoid all
> > of this unpleasantness.
>
> What do you think about bu3way?  It's = bound to be a lot
> faster than AAA, and
> can be adorned with optional features for = additional security
> for applications
> that need it.
>
> Regards,
> Charlie P.
>

------_=_NextPart_001_01C18A55.46520C40-- From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 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 OAA00680 for ; Fri, 21 Dec 2001 14:48:50 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA16703; Fri, 21 Dec 2001 11:27:19 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26972; Fri, 21 Dec 2001 11:26:34 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLJPvZR004205 for ; Fri, 21 Dec 2001 11:25:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLJPv3w004204 for mobile-ip-dist; Fri, 21 Dec 2001 11:25:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLJPrZR004197 for ; Fri, 21 Dec 2001 11:25:53 -0800 (PST) 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 LAA08143 for ; Fri, 21 Dec 2001 11:25:54 -0800 (PST) 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 LAA18555 for ; Fri, 21 Dec 2001 11:25:48 -0800 (PST) Received: from jariws1 ([62.248.153.66]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011221192547.LBOX11987.fep01-app.kolumbus.fi@jariws1>; Fri, 21 Dec 2001 21:25:47 +0200 Message-ID: <003f01c18a55$68947ea0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Vijay Devarapalli" Cc: References: <4DA6EA82906FD511BE2F00508BCF053801C4C182@Esealnt861.al.sw.ericsson.se> <3C237AB8.F97ED12C@iprg.nokia.com> Subject: Re: [mobile-ip] list of things for MIPv6 Date: Fri, 21 Dec 2001 21:26:37 +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.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 > > not stop it. IMHO (and I'm not a security expert) > > the combination of CGAs and RR is an excellent idea > > and will give quite a strong security. > > If the processing power is a concern, some optimisations > > were proposed to off-load some of the operations > > onto the HA. > > IMO, this is not a option. there is no protocol for that. > and if you try to do that, its plain stupid (of course IMHO). Well... I'm not going discuss the latter claim, but there *is* a protocol. See http://www.ietf.org/internet-drafts/draft-roe-mobileip-updateauth-01.txt under 3.2 and Optimisations. (In any case, the feeling in SLC seemed to be roughly the following: "Nice to know we can optimise for small MNs/CNs, but thank's, we don't think it will be necessary at the beginning. We could do it as an optional protocol later.") Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 14:56:06 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00802 for ; Fri, 21 Dec 2001 14:56:05 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28727; Fri, 21 Dec 2001 12:54:51 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03808; Fri, 21 Dec 2001 11:55:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLJsLZR004600 for ; Fri, 21 Dec 2001 11:54:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLJsLm8004599 for mobile-ip-dist; Fri, 21 Dec 2001 11:54:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLJsIZR004592 for ; Fri, 21 Dec 2001 11:54:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14310 for ; Fri, 21 Dec 2001 11:54:19 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA28705 for ; Fri, 21 Dec 2001 12:55:07 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBLJsGg28628 for ; Fri, 21 Dec 2001 21:54:16 +0200 Date: Fri, 21 Dec 2001 21:54:15 +0200 (EET) From: Pekka Savola To: Subject: Re: [mobile-ip] list of things for MIPv6 In-Reply-To: <15395.32518.925275.491480@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: On Fri, 21 Dec 2001, Michael Thomas wrote: > Vijay Devarapalli writes: > > > > in my opinion, lets go with (a). (b) is a really bad > > > > idea. (b) is too drastic. I can live (a) becase the > > > > threat is very insignificant. Source spoofing attacks > > > > are possible currently (in the current internet). if > > > > the bottom line is 'do no harm' lets go with (a). > > > > > > > > > > => I'm afraid I agree with Pekka here. The threat > > > is definitely significant. We can't pretend it > > > > Well. I disagree that the threat is significant. and we are > > not pretending that it is not there. we document it and leave > > it to the implementations. > > One of the criteria that Jeff gave was "do no > harm". There has *considerable* push to get RFC > 2827 implemented widely. MIPv6 providing a new and > pervasive source of source spoofing without a way > to prevent that introduces considerable harm by > any reasonable definition. I cannot see how this > can be handwaved away. Completely agree. I fear the issue cannot be settled properly. Everyone who thinks the threat isn't real should read: Date: Fri, 21 Dec 2001 13:16:57 +0200 (EET) From: Pekka Savola Reply-To: mobile-ip@sunroof.eng.sun.com To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 (2) This clarifies one issue that may not have come up strongly enough before. Practically destination site's filtering which you _can_ rely on these days is nullfied. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 15:50: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 PAA01754 for ; Fri, 21 Dec 2001 15:50:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00073; Fri, 21 Dec 2001 13:48:57 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19399; Fri, 21 Dec 2001 12:49:12 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLKmNZR005037 for ; Fri, 21 Dec 2001 12:48:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLKmNOn005036 for mobile-ip-dist; Fri, 21 Dec 2001 12:48:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLKmKZR005029 for ; Fri, 21 Dec 2001 12:48:20 -0800 (PST) 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 MAA24090 for ; Fri, 21 Dec 2001 12:48:21 -0800 (PST) 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 MAA00691 for ; Fri, 21 Dec 2001 12:48:21 -0800 (PST) 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 fBLKmKx24378 for ; Fri, 21 Dec 2001 12:48:20 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO43047; Fri, 21 Dec 2001 12:47:46 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA06992; Fri, 21 Dec 2001 12:48:19 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15395.40979.707959.184945@thomasm-u1.cisco.com> Date: Fri, 21 Dec 2001 12:48:19 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-Reply-To: <3C237FE1.D041D3BD@iprg.nokia.com> References: <4DA6EA82906FD511BE2F00508BCF053801C4C18C@Esealnt861.al.sw.ericsson.se> <3C237FE1.D041D3BD@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: > option (b) is very simple and works really well. > all it needs is IKE supplying the keys. This is *far* more complicated than you are making it out to be. Anybody who claims that changing IKE -- and IKE is *not* the only consideration -- would do well to find out what is going on in the IPsec working group. Making tweaks for MIP is not even *vaguely* on their radar screen, nor is it clear that the WG would ever take it up. Changing MIP to fit IPsec is a *far* easier path, and one that MIP WG is completely in control of their own destiny. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 16:08: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 QAA02162 for ; Fri, 21 Dec 2001 16:08:37 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10819; Fri, 21 Dec 2001 14:07:24 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23035; Fri, 21 Dec 2001 13:07:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLL6bZR005176 for ; Fri, 21 Dec 2001 13:06:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLL6awl005175 for mobile-ip-dist; Fri, 21 Dec 2001 13:06:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLL6XZR005168 for ; Fri, 21 Dec 2001 13:06:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27141 for ; Fri, 21 Dec 2001 13:06:35 -0800 (PST) Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13537 for ; Fri, 21 Dec 2001 14:06:35 -0700 (MST) Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100]) by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id fBLL6XW29834 for ; Fri, 21 Dec 2001 16:06:33 -0500 (EST) Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA13512; Fri, 21 Dec 2001 16:06:31 -0500 (EST) Received: from lucent.com by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA13506; Fri, 21 Dec 2001 16:06:30 -0500 (EST) Message-ID: <3C23A443.3905E18B@lucent.com> Date: Fri, 21 Dec 2001 16:06:11 -0500 From: Uri Blumenthal Organization: Lucent Technologies X-Mailer: Mozilla 4.76 [en]C-CCK-MCD EMS-1.5 (Windows NT 5.0; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 References: <4DA6EA82906FD511BE2F00508BCF053801C4C18C@Esealnt861.al.sw.ericsson.se> <3C237FE1.D041D3BD@iprg.nokia.com> <15395.40979.707959.184945@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: > > option (b) is very simple and works really well. > > all it needs is IKE supplying the keys. > > This is *far* more complicated than you are > making it out to be. Anybody who claims that > changing IKE -- and IKE is *not* the only > consideration -- would do well to find out > what is going on in the IPsec working group. It has been that IKE is "cast in stone". Luckily however, IKE is in the process of being changed, as we speak. IPSec working group is working on a successor of IKE, and now is the time to submit any specific requirements for IKEv2. -- Regards, Uri. -=-=-<>-=-=- From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 16:13: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 QAA02244 for ; Fri, 21 Dec 2001 16:13:34 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26129; Fri, 21 Dec 2001 13:12:28 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23894; Fri, 21 Dec 2001 13:12:24 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLLBoZR005295 for ; Fri, 21 Dec 2001 13:11:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLLBoF4005293 for mobile-ip-dist; Fri, 21 Dec 2001 13:11:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLLBlZR005286 for ; Fri, 21 Dec 2001 13:11:47 -0800 (PST) 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 NAA23802 for ; Fri, 21 Dec 2001 13:11:49 -0800 (PST) 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 NAA00050 for ; Fri, 21 Dec 2001 13:11:49 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA25760; Fri, 21 Dec 2001 13:11:48 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBLLBlA03465; Fri, 21 Dec 2001 13:11:47 -0800 X-mProtect: Fri, 21 Dec 2001 13:11:47 -0800 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 smtpdnvAz5g; Fri, 21 Dec 2001 13:11:46 PST Message-ID: <3C23A592.ED7C9403@iprg.nokia.com> Date: Fri, 21 Dec 2001 13:11:46 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 References: <3C2230D9.5BA4B149@iprg.nokia.com> <003301c18a54$4b115e80$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > I believe there is a real difference in current spoofing > attacks compared to the ones enabled by the home > address option. Namely, ingress filtering or other techniques > can prevent source address spoofing but I can't see how > they could prevent HAO spoofing. Ingress filtering could put some restriction on this. For instance, it could be enforced that only one home address could be associated to a particular care-of address. This would eliminate most of the "fun" that would be associated with such spoofing. We could also say that a correspondent node has to do such filtering. After these two measures are taken, I think that no self-respecting bad guy would waste time on such a low-payoff exploit. >> b. Solve it by mandating that home address option >> is not processed unless there is a corresponding >> binding cache entry (of course created securely). >> use reverse tuneling through the home agent when >> a binding cache entry does not exist. .......... > My preliminary answer here would be (b) unless we > can think of something else, or a believable reason why > the attack isn't serious enough. (b) is a pretty heavy thing to mandate, especially if you agree with my comments above after the previously cited paragraph. Perhaps we could say "SHOULD" verify the feasibility of the Home Address Option by some means, possibly including existence of a Binding Security Association (BSA). And then busily make such a protocol for establilshing BSAs viable (work which I reckon is currently going on). At least in this way we could make progress without handicapping all future implementations. >> 3. Protecting the BU. There are three options. pick one. >> a. new extension header >> b. Authentication Sub-Option only. >> c. Jari Arkko's draft, option 4 which shows how >> authentication suboption and AH can be used >> together with minimal changes. > > I'd like to see this as two separate issues, actually. The > first issue is whether PKI and RR/CGA-based authentication > are *alternatives* of which exactly one is used for one packet, > or whether they are complementary, possibly used together. > On this first question I have lately come to the conclusion > that I'd prefer them to be possibly used together. This is > because the methods prove different things. CGA e.g. > proves address ownership while PKI proves you belong to > the group of good guys. You might want the other one too, > even if you already did one. I agree that they do different things, and that they both do good things, but I can't see mandating CGA, for all of the reasons that have been mentioned elsewhere. > The second issue is which protocol actually protects the > BUs. Here my preferences are options 6.2 or 6.4 from my > draft. (I seem to recall that we had some consensus in > SLC about using rather a new protocol or UDP than IPv6 > DOs... if so, then 6.2 would be clearly possible as well). I don't recall that there was consensus gauged about anything, except _very briefly_ whether people would like to see a new header type for Mobile IPv6 messaging. I was a bit disconcerted that the call for consensus was taken without any discussion on the issues, but even so the results have to be taken into account. Supposing we had a new header type. Wouldn't it be appropriate to make the necessary signaling for protecting Binding Updates to also fit in the same container? I'll have to postpone discussion on your other points about CGA ==> BSA until later... Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 16:16: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 QAA02293 for ; Fri, 21 Dec 2001 16:16:20 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA27124; Fri, 21 Dec 2001 13:15:11 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24603; Fri, 21 Dec 2001 13:15:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLLEOZR005353 for ; Fri, 21 Dec 2001 13:14:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLLEOTi005352 for mobile-ip-dist; Fri, 21 Dec 2001 13:14:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLLELZR005345 for ; Fri, 21 Dec 2001 13:14:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18506 for ; Fri, 21 Dec 2001 13:14:23 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04348 for ; Fri, 21 Dec 2001 14:14:22 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA25840 for ; Fri, 21 Dec 2001 13:14:22 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBLLEL805530 for ; Fri, 21 Dec 2001 13:14:21 -0800 X-mProtect: Fri, 21 Dec 2001 13:14:21 -0800 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 smtpdYkuUkh; Fri, 21 Dec 2001 13:14:20 PST Message-ID: <3C23A62C.EA7CE397@iprg.nokia.com> Date: Fri, 21 Dec 2001 13:14:20 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 References: <4DA6EA82906FD511BE2F00508BCF053801C4C18C@Esealnt861.al.sw.ericsson.se> <3C237FE1.D041D3BD@iprg.nokia.com> <15395.40979.707959.184945@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: > > option (b) is very simple and works really well. > > all it needs is IKE supplying the keys. > > This is *far* more complicated than you are > making it out to be. Anybody who claims that > changing IKE -- and IKE is *not* the only > consideration -- would do well to find out > what is going on in the IPsec working group. actually I did that. IPSec WG is currently working on a requirements draft for son-of-IKE. I was surprised that SCTP folks were able to add a couple of requirements to make IKE work with SCTP. One of them I remember was that son-of-IKE now should support multiple addresses instead of a single address. I believe this was needed for SCTP to work. I was also talking to another person who is quite active in the IPSec WG. his personal opinion was that IPSec WG wouldnt be against taking on additional requirements. (also becuase they would really like to see IKE being implemented and deployed widely). I was thinking maybe could do something like this. So I mailed the IPSec WG chair Theodore T'so. I mailed a few other people too in the IPSec WG. havent heard from them yet. Vijay > Making tweaks for MIP is not even *vaguely* > on their radar screen, nor is it clear that > the WG would ever take it up. > > Changing MIP to fit IPsec is a *far* easier > path, and one that MIP WG is completely in > control of their own destiny. > > Mike From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 16:23: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 QAA02399 for ; Fri, 21 Dec 2001 16:23:39 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18624; Fri, 21 Dec 2001 14:22:26 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26092; Fri, 21 Dec 2001 13:22:41 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLLLgZR005528 for ; Fri, 21 Dec 2001 13:21:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLLLgda005527 for mobile-ip-dist; Fri, 21 Dec 2001 13:21:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLLLdZR005520 for ; Fri, 21 Dec 2001 13:21:39 -0800 (PST) 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 NAA29586 for ; Fri, 21 Dec 2001 13:21:41 -0800 (PST) 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 NAA16816 for ; Fri, 21 Dec 2001 13:21:40 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA26413 for ; Fri, 21 Dec 2001 13:21:40 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBLLLdv13826 for ; Fri, 21 Dec 2001 13:21:39 -0800 X-mProtect: Fri, 21 Dec 2001 13:21:39 -0800 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 smtpdIhxdWK; Fri, 21 Dec 2001 13:21:38 PST Message-ID: <3C23A7E2.9C97F9D1@iprg.nokia.com> Date: Fri, 21 Dec 2001 13:21:38 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 References: <4DA6EA82906FD511BE2F00508BCF053801C4C18C@Esealnt861.al.sw.ericsson.se> <3C237FE1.D041D3BD@iprg.nokia.com> <15395.40979.707959.184945@thomasm-u1.cisco.com> <3C23A443.3905E18B@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Uri Blumenthal wrote: > > Michael Thomas wrote: > > Vijay Devarapalli writes: > > > option (b) is very simple and works really well. > > > all it needs is IKE supplying the keys. > > > > This is *far* more complicated than you are > > making it out to be. Anybody who claims that > > changing IKE -- and IKE is *not* the only > > consideration -- would do well to find out > > what is going on in the IPsec working group. > > It has been that IKE is "cast in stone". Luckily however, > IKE is in the process of being changed, as we speak. > > IPSec working group is working on a successor of IKE, and > now is the time to submit any specific requirements for IKEv2. Exactly!! two options here. 1. Increase the selector granularity. Destination option type should also be a selector. 2. Add Authentication sub option to AH and ESP as protocols which need keying by IKE. Choosing 1 would be great. without it, IPSec is effectively killing the use of destination options becase they can never be protected specifically. It would good if the extension headers could be used more widely instead of always using a port number for selecting a particular SA. regards Vijay > -- > Regards, > Uri. > -=-=-<>-=-=- > From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 16:27: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 QAA02457 for ; Fri, 21 Dec 2001 16:27:34 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA20627; Fri, 21 Dec 2001 14:26:21 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26972; Fri, 21 Dec 2001 13:26:35 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLLQ0ZR005622 for ; Fri, 21 Dec 2001 13:26:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBLLQ0FQ005621 for mobile-ip-dist; Fri, 21 Dec 2001 13:26:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBLLPuZR005611 for ; Fri, 21 Dec 2001 13:25:56 -0800 (PST) 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 NAA00575 for ; Fri, 21 Dec 2001 13:25:58 -0800 (PST) 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 NAA18863 for ; Fri, 21 Dec 2001 13:25:56 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA26572 for ; Fri, 21 Dec 2001 13:25:56 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBLLPtq18484 for ; Fri, 21 Dec 2001 13:25:55 -0800 X-mProtect: Fri, 21 Dec 2001 13:25:55 -0800 Nokia Silicon Valley Messaging Protection Received: from jmalinen.iprg.nokia.com (205.226.2.98) by darkstar.iprg.nokia.com smtpdc2o4ct; Fri, 21 Dec 2001 13:25:54 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by jmalinen.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id NAA54213 for ; Fri, 21 Dec 2001 13:25:54 -0800 (PST) Message-ID: <3C23A8E2.8CD291D2@iprg.nokia.com> Date: Fri, 21 Dec 2001 13:25:54 -0800 From: "Jari T. Malinen" Organization: Nokia 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] list of things for MIPv6 References: <4DA6EA82906FD511BE2F00508BCF053801C4C18C@Esealnt861.al.sw.ericsson.se> <3C237FE1.D041D3BD@iprg.nokia.com> <15395.40979.707959.184945@thomasm-u1.cisco.com> <3C23A443.3905E18B@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Uri Blumenthal wrote: > > Michael Thomas wrote: > > Vijay Devarapalli writes: > > > option (b) is very simple and works really well. > > > all it needs is IKE supplying the keys. > > > > This is *far* more complicated than you are > > making it out to be. Anybody who claims that > > changing IKE -- and IKE is *not* the only > > consideration -- would do well to find out > > what is going on in the IPsec working group. > > It has been that IKE is "cast in stone". Luckily however, > IKE is in the process of being changed, as we speak. > > IPSec working group is working on a successor of IKE, and > now is the time to submit any specific requirements for IKEv2. > -- > Regards, > Uri. > -=-=-<>-=-=- > I was recently talking with someone involved in the work refered to above and he was surprised none of the requirements from here were known to them. In fact, the work is in an advanced stage so it won't necessarily take years before the revised APIs could be available. IPsec interfacing seems to me to be a manageable database API problem, its implementation is not rocket science, it has mainly been taken too much "given" that absolutely nothing can be changed there. BR, -Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Dec 21 19:17:15 2001 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05044 for ; Fri, 21 Dec 2001 19:17:14 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09246; Fri, 21 Dec 2001 17:15:58 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17000; Fri, 21 Dec 2001 16:16:13 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBM0FQZR006129 for ; Fri, 21 Dec 2001 16:15:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBM0FQTd006128 for mobile-ip-dist; Fri, 21 Dec 2001 16:15:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBM0FNZR006121 for ; Fri, 21 Dec 2001 16:15:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28312 for ; Fri, 21 Dec 2001 16:15:24 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08993 for ; Fri, 21 Dec 2001 17:15:05 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA05013 for ; Fri, 21 Dec 2001 16:15:23 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBM0FMj11360 for ; Fri, 21 Dec 2001 16:15:22 -0800 X-mProtect: Fri, 21 Dec 2001 16:15:22 -0800 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 smtpdZryO9G; Fri, 21 Dec 2001 16:15:21 PST Message-ID: <3C23D09A.34F6E597@iprg.nokia.com> Date: Fri, 21 Dec 2001 16:15:22 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group Subject: [mobile-ip] Last minute revisions to RFC2002bis --> RFC 3220 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, RFC2002bis made it to the RFC Editor's desk and was ready to be published as RFC 3220. However, the decision was taken to make one last minute revision, in order to resolve the problem that had been raised by Siva and Alper regarding the erroneous use of 0.0.0.0 as a destination address for the Registration Reply in case the mobile node send a Registration Request with source IP address indicated as 0.0.0.0. Since RFC 3220 was not published, it was possible to insert these changes. Essentially, the new draft mandates use of the mobile node's home address whenever that is possible, which is in almost every case. The case when it is not possible, is when the mobile node was asking to get a home address, and the Registration Reply indicates rejection for some reason. Along the way, I had been informed about a variety of minor editorial problems -- even, I must say, a spelling error. So I fixed those also. The only outstanding issue has to do with prohibiting retransmitted Registration Requests from using alternative NAIs. This "could" be considered "obvious", and so it was felt that there was no need to further perturb the contents of RFC 2002bis. Below, please find a complete list of all changes from RFC2002bis as it was at the conclusion of IETF Last Call, and what will be hopefully published very soon by the RFC Editor. If there is any objection to these changes, please let me know ASAP. Happy Holidays! Regards, Charlie P. PS. The "Changes" appendix materials probably will disappear... ================= Last-Minute Changes to RFC2002bis ==================== "<" == new ">" == old 639c639 < a) A "foreign agent care-of address" is a care-of address provided --- > - A "foreign agent care-of address" is a care-of address provided 649c649 < b) A "co-located care-of address" is a care-of address acquired --- > - A "co-located care-of address" is a care-of address acquired 712a713,744 > For example, the figure below illustrates the routing of datagrams > to and from a mobile node away from home, once the mobile node has > registered with its home agent. In the figure below, the mobile node > is using a foreign agent care-of address: 736,766d767 < For example, figure 1 illustrates the routing of datagrams to < and from a mobile node away from home, once the mobile node has < registered with its home agent. In figure 1, the mobile node is < using a foreign agent care-of address, not a co-located care-of < address. 774,775c775,776 < Router Discovery messages. Some extensions have been specified < to be encoded in the simple Type-Length-Value format described in > Router Discovery messages. Some extensions have been specified to be > encoded in the following simple Type-Length-Value format described in 872c872 < extension structure does not encourage the most efficient usage --- > extension structures does not encourage the most efficient usage 917c917 < 0 1 2 3 --- > 0 1 2 3 930,931c930,931 < Type is the type which describes a collection of extensions < which have a common data type. --- > Type is the type which describe a collection of extensions > which has a common data type. 982c982 < 0 1 2 3 --- > 0 1 2 3 992,993c992,993 < Type is the type which describes a collection of extensions < which have a common data type. --- > Type is the type which describe a collection of extensions > which has a common data type. 1240,1241c1240,1241 < 'F' bit is not also set. Furthermore, at least one of the 'F' bit < and the 'H' bit MUST be set in any Agent Advertisement message sent. --- > 'F' bit is not also set, and at least one of the 'F' bit and the 'H' > bit MUST be set in any Agent Advertisement message sent. 1343,1346c1343,1344 < Agent Solicitation. All mobility agents MUST join the Mobile-Agents < multicast group, at address 224.0.0.11. A mobile node MAY send an < Agent Solitication to 224.0.0.11. All mobility agents SHOULD respond < to Agent Solicitations. --- > Agent Solicitation. All mobility agents SHOULD respond to Agent > Solicitations. 1417,1419c1417,1419 < nodes can distinguish a reduction in the sequence number that occurs < after a reboot from a reduction that results in rollover of the < sequence number after it attains the value 0xffff. --- > nodes can distinguish reductions in sequence numbers that result from > reboots, from reductions that result in rollover of the sequence > number after it attains the value 0xffff. 2372,2373c2372,2373 < - Otherwise, if the mobile node does not have a home address, the < IP source address MUST be 0.0.0.0. --- > - If the mobile node does not have a home address, the IP source > address MUST be 0.0.0.0. 2389,2390c2389,2390 < as learned from the IP source address of the corresponding < Agent Advertisement MUST be used. This MAY be an address --- > as learned from the IP source address of the corresponding Agent > Advertisement MUST be used. In addition, when transmitting 2399,2400d2398 < which does not appear as an advertised care-of address in < the Agent Advertisement. In addition, when transmitting 2821c2821 < - the IP Destination Address (as specified in 3.6.1.1) --- > - the IP Destination Address (as specified in 3.6.2.3) 3014,3017c3014,3016 < If the Registration Reply (as received from the Home < Agent) contains a Home Address which is not 0.0.0.0, < then the IP Destination Address is copied from the Home < Address field of the Registration Reply. Otherwise, the --- > Copied from the IP Source Address of the Registration > Request. 3026,3027d3024 < IP Destination Address of the Registration Reply is set < to be 255.255.255.255. 3242,3243c3236,3237 < extension or verify that the authenticator value has been < checked by another agent with which it has a security --- > extension. or verify that the authenticator value has > been checked by another agent with which it has a security 3445c3438 < This section provides the specific rules by which home agents pick --- > This section provides the specific rules by which mobile nodes pick 3695c3683 < address associated with the mobile node's IP address. --- > address associated to the mobile node's IP address. 3734,3737c3721,3724 < of the encapsulated datagram MUST be the address sent to the mobile < node in the home agent field of the registration reply. That is, the < home agent cannot use the the address of some other network interface < as the source address. --- > of the encapsulated datagram MUST be the address that the mobile > node used in the home agent field of the registration request. That > is, the home agent cannot use the the address of some other network > interface as the source address. 3844c3833 < In order to receive multicasts, a mobile node MUST join the multicast --- > In order receive multicasts, a mobile node MUST join the multicast 3895,3900c3883,3888 < A mobile node can be a router that is responsible for the mobility of < one or more entire networks moving together, perhaps on an airplane, < a ship, a train, an automobile, a bicycle, or a kayak. The nodes < connected to a network served by the mobile router may themselves < be fixed nodes or mobile nodes or routers. In this document, such < networks are called "mobile networks". --- > A mobile node can be a router, which is responsible for the mobility > of one or more entire networks moving together, perhaps on an > airplane, a ship, a train, an automobile, a bicycle, or a kayak. > The nodes connected to a network served by the mobile router may > themselves be fixed nodes or mobile nodes or routers. In this > document, such networks are called "mobile networks". 4093c4082 < of its home agent. The ARP packet from the home agent MUST be --- > of its home agent. Th ARP packet from the home agent MUST be 4187,4193c4173,4187 < Address is set to the link-layer address of the mobile node. < If, instead, the home agent rejects the Registration Request, < the home agent MUST NOT make any change to the way it performs < ARP processing (gratuitous nor proxy) for the mobile node. In < this latter case, the home agent should operate as if the mobile < node has not returned home, and continue to perform proxy ARP on < behalf of the mobile node. --- > Address is set to the link-layer address of the mobile node. If, > instead, the home agent rejects the Registration Request, the > home agent MUST NOT make any change to the way it performs ARP > processing (gratuitous nor proxy) for the mobile node. In this > latter case, the HA should operate as if the MN has not returned > home, and continue to perform proxy ARP on behalf of the MN. 4628d4627 < - Ken Imboden (Candlestick Networks, Inc.) 4639d4637 < - Alper Yegin (NTT DoCoMo) 5050,5060c5050 < G.1. Recent Changes Subsequent to Revision 08 of RFC2002bis < < The following minor revisions had to be made, necessitating this new < revision for RFC2002bis: < < - Specification for Destination IP address of Registration < Reply transmitted from Foreign Agent, to avoid any possible < transmission to IP address 0.0.0.0. 5153,5156c5143,5145 < - In section 4.2.3, specification that multihomed home agents MUST < use the the address sent to the mobile node in the home agent < field of the registration reply as the source address in the < outer IP header of the encapsulated datagram. --- > - Specification that multihomed home agents MUST use the registered > care-of address as the source address in the outer IP header of > the encapsulated datagram. 5174,5176c5163,5165 < a multicast group at the router on the foreign network, the < mobile node MUST use its home address as the source IP address < for multicast packets, --- > multicast group at the router on the foreign network, the mobile > node MUST use its home address as the source IP address for > multicast packets, 5430,5433c5430,5433 < [3] J. Border, M. Kojo, J. Griner, G. Montenegro, and Z. Shelby. < Performance Enhancing Proxies Intended to Mitigate Link-Related < Degradations. Request for Comments (Proposed Standard) 3135, < Internet Engineering Task Force, June 2001. --- > [3] J. Border, M. Kojo, J. Griner, G. Montenegro, and > Z. Shelby. Performance Enhancing Proxies (work in > progress). Internet Draft, Internet Engineering Task Force. > draft-ietf-pilc-pep-07.txt, May 2001. 5458,5460c5458,5460 < End-to-end Performance Implications of Links with Errors. < Request for Comments (Proposed Standard) 3155, Internet < Engineering Task Force, August 2001. --- > Performance Implications of Link-Layer Characteristics: Links > with Errors. Internet Draft, Internet Engineering Task Force. > draft-ietf-pilc-error-08.txt, June 2001. 5478,5479c5478 < Extensions. Request for Comments (Proposed Standard) 3115, < Internet Engineering Task Force, April 2001. --- > Extensions, April 2001. 5591,5593c5591,5593 < [35] Charles E. Perkins and Pat R. Calhoun. AAA Registration Keys < for Mobile IP (work in progress). < draft-ietf-mobileip-aaa-key-05.txt, May 2001. --- > [35] C. Perkins and P. Calhoun. Generalized Key Distribution > Extensions for Mobile IP (work in progress). > draft-ietf-mobileip-gen-key-01.txt, July 2001. From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 06:53: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 GAA28663 for ; Sat, 22 Dec 2001 06:53:48 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA25560; Sat, 22 Dec 2001 03:52:49 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA06031; Sat, 22 Dec 2001 03:52:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMBq4ZR006753 for ; Sat, 22 Dec 2001 03:52:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMBq44V006752 for mobile-ip-dist; Sat, 22 Dec 2001 03:52:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMBq1ZR006745 for ; Sat, 22 Dec 2001 03:52:01 -0800 (PST) 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 DAA05996 for ; Sat, 22 Dec 2001 03:52:02 -0800 (PST) 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 DAA13698 for ; Sat, 22 Dec 2001 03:52:02 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id EAA02097 for ; Sat, 22 Dec 2001 04:52:01 -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 EAA21552 for ; Sat, 22 Dec 2001 04:52:01 -0700 (MST)] Received: from thorgal.crm.mot.com by m-il06-r1.mot.com with ESMTP; Sat, 22 Dec 2001 04:52:00 -0700 Received: from test9.crm.mot.com.crm.mot.com (zfr24-sr2-01.corp.mot.com [140.101.145.1]) by thorgal.crm.mot.com (Postfix) with ESMTP id D424A2EC83; Sat, 22 Dec 2001 12:50:17 +0100 (CET) To: mobile-ip@sunroof.eng.sun.com Cc: Francis Dupont , "Charles E. Perkins" Subject: Re: [mobile-ip] list of things for MIPv6 References: <200112211439.fBLEdfD69151@givry.rennes.enst-bretagne.fr> <3C23828A.4876D73E@iprg.nokia.com> From: Alexandru Petrescu Date: 22 Dec 2001 10:51:07 +0100 In-Reply-To: <3C23828A.4876D73E@iprg.nokia.com> Message-Id: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 10 Sender: owner-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: > No, but we could use less hysteria. I would suggest that we > build and test some of the proposed approaches, and carry out > some reasoned discussion after we have more experience. Anyone wishing to play today with a return routability implementation, please consider MIPL archives: there's a patch for 0.8.1 that establishes an MN-CN key with BAKE. Alex From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 10:05: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 KAA29700 for ; Sat, 22 Dec 2001 10:05:46 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16677; Sat, 22 Dec 2001 07:04:47 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16275; Sat, 22 Dec 2001 07:04:42 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMF3iZR006998 for ; Sat, 22 Dec 2001 07:03:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMF3iBI006997 for mobile-ip-dist; Sat, 22 Dec 2001 07:03:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMF3eZR006990 for ; Sat, 22 Dec 2001 07:03:41 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14979 for ; Sat, 22 Dec 2001 07:03:41 -0800 (PST) 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 IAA11429 for ; Sat, 22 Dec 2001 08:03:22 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBMF3Yb10419 for ; Sat, 22 Dec 2001 16:03:34 +0100 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 QAA15771 for ; Sat, 22 Dec 2001 16:03:35 +0100 (MET) 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 fBMF3YD87890 for ; Sat, 22 Dec 2001 16:03:34 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112221503.fBMF3YD87890@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 (2) In-reply-to: Your message of Fri, 21 Dec 2001 13:16:57 +0200. Date: Sat, 22 Dec 2001 16:03:34 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: Your argument about source spoofing does not apply; ... host1 --- fwrtr1 - rtrISP - Internet - fwrtr2 ---host2 3ffe:ffff:1::/48 3ffe:ffff:2::/48 Now, the attacker host1 could attack: src = 3ffe:ffff:1::1 (or spoofed if no filtering in fwrtr1, as assumed) => you say you have a source spoofing attack when the source firewall doesn't filter anything. I have not to read further in order to say you should be right and you add nothing to the debate... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 10:36: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 KAA00055 for ; Sat, 22 Dec 2001 10:36:19 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17127; Sat, 22 Dec 2001 08:35:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18644; Sat, 22 Dec 2001 07:35:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMFYWZR007149 for ; Sat, 22 Dec 2001 07:34:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMFYWXY007148 for mobile-ip-dist; Sat, 22 Dec 2001 07:34:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMFYTZR007141 for ; Sat, 22 Dec 2001 07:34:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16810 for ; Sat, 22 Dec 2001 07:34:30 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29284 for ; Sat, 22 Dec 2001 08:34:29 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBMFYRb11962 for ; Sat, 22 Dec 2001 16:34:27 +0100 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 QAA15918 for ; Sat, 22 Dec 2001 16:34:28 +0100 (MET) 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 fBMFYRD99899 for ; Sat, 22 Dec 2001 16:34:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112221534.fBMFYRD99899@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-reply-to: Your message of Fri, 21 Dec 2001 10:17:59 PST. <3C237CD7.DAD049A2@iprg.nokia.com> Date: Sat, 22 Dec 2001 16:34:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: > 3. Protecting the BU. There are three options. pick one. > a. new extension header > b. Authentication Sub-Option only. > c. Jari Arkko's draft, option 4 which shows how > authentication suboption and AH can be used > together with minimal changes. > > => argh! Which draft/section/etc? draft-arkko-mipv6-bu-security-01.txt, section 6.4. => I am still in favor of (a) because (a) really gives the choice between using Mobile IPv6 (aka application) specific stuff or plain IPsec. This is related to piggy-packing too (and I am strongly opposed to it). > for (b), I am not sure. > > => explain a bit more the (b) issue. the issue is with the creation of BSAs. do you need the key distribution protocol to create BSAs? for example both BU3WAY and BAKE use return routability. but BAKE creates a BSA, whereas BU3WAY does not. BU3WAY is run everytime the MN sends a BU to the CN. There are a few arguments for not creating a BSA in Erik Nordmark's draft. => first I believe that in some circumstances BAs have to be secured too. As I believe the return routability itself is not enough secure there is no advantage to have an ultra light weight scheme, i.e. to create a BSA should be paid off by possible reuse. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 11: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 LAA00322 for ; Sat, 22 Dec 2001 11:19:42 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26470; Sat, 22 Dec 2001 08:18:37 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03134; Sat, 22 Dec 2001 08:18:32 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMGHfZR007350 for ; Sat, 22 Dec 2001 08:17:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMGHfcT007349 for mobile-ip-dist; Sat, 22 Dec 2001 08:17:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMGHcZR007342 for ; Sat, 22 Dec 2001 08:17:38 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03057 for ; Sat, 22 Dec 2001 08:17:39 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06224 for ; Sat, 22 Dec 2001 09:17:34 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBMGHTb14189; Sat, 22 Dec 2001 17:17:29 +0100 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 RAA16049; Sat, 22 Dec 2001 17:17:29 +0100 (MET) 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 fBMGHTD00116; Sat, 22 Dec 2001 17:17:29 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112221617.fBMGHTD00116@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E. Perkins" cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-reply-to: Your message of Fri, 21 Dec 2001 10:42:18 PST. <3C23828A.4876D73E@iprg.nokia.com> Date: Sat, 22 Dec 2001 17:17:29 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: > 1. Mobile IPv6 use of Routing Header > > => the solution has to be written down in a draft and presented > to the IPv6 WG ASAP as a part of the host requirement document. The solution depends on the application. => I agree but today the general problem is known so we have to both fix the general case (even with drastic statements like by default hosts should drop packets with routing headers with segleft != 0) and specify the Mobile IPv6 solution. I can imagine uses of the routing header that would be set up by security-conscious people who demand certain routability. I believe that the IPv6 working group CANNOT predict all the necessary policy mechanisms to check the correctness of such esoteric uses of the routing header. => the specs should keep a open door for new usages but now the open door is for attacks and the priority is there. > => it seems I have to write the IPv6 ingress filtering document > (it is in my TODO list, I'll check with my co-author when we > can write it). This sounds like a real piece of hard work. Can you give a preview of what you have in mind? => explain DDoS and iDDoS threats, how ingress filtering is a reply to DDoS, how smart ingress filtering (ingress filtering + responsible usage of the network + access control extension) is a reply to iDDoS. Are you looking for co-masochists? => no, I should have written this document with Claude Castelluccia (the whole thing is not new for us) at the beginning of this year... > 3. Protecting the BU. There are three options. pick one. > a. new extension header > b. Authentication Sub-Option only. > c. Jari Arkko's draft, option 4 which shows how > authentication suboption and AH can be used > together with minimal changes. > > if we decide to go with (a), lets not go with UDP. > instead we should use a new extension header. > > => I am in favor of (a) because it works without the need > to check if there is some IPsec somewhere. As IPsec codes > are a bit complex (:-) and have strange (:-) interactions > with other parts of stacks, IMHO this is a strong argument. I'm not so enthusiastic about (a), because I know it's a pile of work to do it. => no, this is just a statement in the IANA section. >(piggy-backing) > a. lets leave it as it is. it is a 'MAY'. > b. leave it as it is, but recommend when it is > good to use and when it is bad to use. > > => (b) with good to use == never and bad to use == always! This isn't right. It's almost always good to use, because it almost always offers a performance improvement. There are times when the performance improvement could make the difference in even the feasibility of smooth voice handovers, due to the decrease in jitter (as was pointed out in work from Cedric Westphal). => all these arguments still apply if this is done by the link-layer. IMHO this is a typical case of mobility = wireless confusion. > 5. Key Distribution protocol between MN and CN > a. Return routability vs CGA (Cryptographically > Generated Addrs) > b. Binding Security Association > > for (a), lets go with return routability unless > somebody can prove that it is insecure. > > => very easy: put the attacker in the CN default router. This is not "easy" => I disagree: the formal proof (of insecurity) is easy. and furthermore to prevent such an attack would take a LOT more mandated protocol than is likely to be promoted as part of any realistic solution. I reckon that compromising the default router is one of the worst things that could happen at any enterprise, and afterwards nobody will give a rat's patootie about what happened to Mobile IPv6. => we are talking about formal proofs... at least, this is what I understood from Vijay's question. > The added > complexity of CGA or Diffie Helman operations is > not worth it. no additional gain. so lets go with > simple return routability. > > => I am afraid that if we do that all CNs will simply reject > BSA establishment attempts. Of course if BSA establishments > are very expensive (a lot of crypto operations) we'll get the > same result. Here we really need a miracle! No, but we could use less hysteria. => the real issue is we don't know what can be accepted by the market between cheap & not secure and expensive & very secure. Obviously there is a balance and to strike it seems to be hard. I would suggest that we build and test some of the proposed approaches, and carry out some reasoned discussion after we have more experience. => IPsec/IKE was built and tested, so we have already a point in one side of the spectrum (too far from the middle according to the IESG). This whole argument is sounding to me about how insane it would be to use your credit card over the Internet. => I agree this is more FUD than a real problem. But we have to take care of possible FUD against Mobile IPv6... unfortunately not since today. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 11:26: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 LAA00373 for ; Sat, 22 Dec 2001 11:26:26 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27507; Sat, 22 Dec 2001 08:25:29 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03919; Sat, 22 Dec 2001 08:25:26 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMGOtZR007475 for ; Sat, 22 Dec 2001 08:24:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMGOsjs007474 for mobile-ip-dist; Sat, 22 Dec 2001 08:24:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMGOpZR007467 for ; Sat, 22 Dec 2001 08:24:51 -0800 (PST) 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 IAA03872 for ; Sat, 22 Dec 2001 08:24:53 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03720 for ; Sat, 22 Dec 2001 08:24:48 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBMGOkb14594 for ; Sat, 22 Dec 2001 17:24:46 +0100 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 RAA16072 for ; Sat, 22 Dec 2001 17:24:46 +0100 (MET) 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 fBMGOkD00143 for ; Sat, 22 Dec 2001 17:24:46 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112221624.fBMGOkD00143@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-reply-to: Your message of Fri, 21 Dec 2001 10:30:57 PST. <3C237FE1.D041D3BD@iprg.nokia.com> Date: Sat, 22 Dec 2001 17:24:46 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: >about BU protection, (b) is Authentication Sub-Option only. option (b) is very simple and works really well. all it needs is IKE supplying the keys. => argh! I have two strong objections: - if piggy-backing is used ((a) new extension header simply makes piggy-backing impossible) you can get all the IPsec for another reason huge complexity. - IKE is Diffie-Hellman with strong authentication, as strong authentication mandates a global PKI (nobody knows how to do it without, specially in the IKE case) there is like a problem here... Regards Francis.Dupont@enst-bretagne.fr PS: IKE is a pig, left it to IPsec people. Even for the MN-HA security association(s) IKE should be replaced by better tools (like AAA as described in AAA for Mobile IPv6 drafts). From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 11:43: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 LAA00497 for ; Sat, 22 Dec 2001 11:43:34 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01406; Sat, 22 Dec 2001 09:42:15 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05038; Sat, 22 Dec 2001 08:42:30 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMGfmZR007599 for ; Sat, 22 Dec 2001 08:41:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMGfmax007598 for mobile-ip-dist; Sat, 22 Dec 2001 08:41:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMGfjZR007591 for ; Sat, 22 Dec 2001 08:41:45 -0800 (PST) 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 IAA23173 for ; Sat, 22 Dec 2001 08:41:47 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06881 for ; Sat, 22 Dec 2001 08:41:46 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBMGfhb15541 for ; Sat, 22 Dec 2001 17:41:43 +0100 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 RAA16136 for ; Sat, 22 Dec 2001 17:41:44 +0100 (MET) 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 fBMGfiD00225 for ; Sat, 22 Dec 2001 17:41:44 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112221641.fBMGfiD00225@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-reply-to: Your message of Fri, 21 Dec 2001 10:08:56 PST. <3C237AB8.F97ED12C@iprg.nokia.com> Date: Sat, 22 Dec 2001 17:41:44 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: > => Definitely a) or alternatively a UDP port number. never UDP. a lot of implementations dont have UDP in the kernel. Mobile IPv6 almost always exists in the kernel. IF we go with (a) lets use a new extension header. => Mobile IPv4 uses UDP and this doesn't seem to be a problem... As an implementor (of a mobile IPv6 in the user space :-) I can say the alternative is valid. But before that, I think people should read Jari Arkko's draft again. draft-arkko-mipv6-bu-security-01.txt, section 6.4. With that approach we dont need a new extension header for the BU. and there will be minimal changes to the existing implementations. => I already said why I don't believe in this approach. Before people say 'new extension header' please think about => note that "extension" is misleading, we are talking about a new terminal header type (a protocol in IPv4 terms). what it means. it means changing a lot of implementations. => these implementations have to be changed in any case... a new extension header not understood by intermediate routers and dropped. => NO, intermediate routers don't process terminal headers. firewalls need to know about the new extension header.... => this is true for any new protocols like SCTP. I guess you need to read BU3WAY again. It just uses return routability. and BU3WAY cannot be called insecure in any way. and your connection hijacking does not happen there. => don't joke: BU3WAY security is very low (perhaps too low). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 11:51: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 LAA00611 for ; Sat, 22 Dec 2001 11:51:13 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02993; Sat, 22 Dec 2001 09:50:01 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05644; Sat, 22 Dec 2001 08:50:16 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMGnjZR007709 for ; Sat, 22 Dec 2001 08:49:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMGnjkA007708 for mobile-ip-dist; Sat, 22 Dec 2001 08:49:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMGnfZR007701 for ; Sat, 22 Dec 2001 08:49:41 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21117 for ; Sat, 22 Dec 2001 08:49:43 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10883 for ; Sat, 22 Dec 2001 09:49:42 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBMGnfj03966 for ; Sat, 22 Dec 2001 18:49:41 +0200 Date: Sat, 22 Dec 2001 18:49:40 +0200 (EET) From: Pekka Savola To: Subject: Re: [mobile-ip] list of things for MIPv6 In-Reply-To: <200112221641.fBMGfiD00225@givry.rennes.enst-bretagne.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: On Sat, 22 Dec 2001, Francis Dupont wrote: > firewalls need to know about the new extension header.... > > => this is true for any new protocols like SCTP. SCTP is a valid analogy only if the considered extension header type is "terminal". So no TCP/UDP/whatever in that packet then .. that's what's under the discussion, right? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 11:54: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 LAA00665 for ; Sat, 22 Dec 2001 11:54:08 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03821; Sat, 22 Dec 2001 09:52:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05934; Sat, 22 Dec 2001 08:53:11 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMGqSZR007804 for ; Sat, 22 Dec 2001 08:52:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMGqSOp007803 for mobile-ip-dist; Sat, 22 Dec 2001 08:52:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMGqPZR007793 for ; Sat, 22 Dec 2001 08:52:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23740 for ; Sat, 22 Dec 2001 08:52:26 -0800 (PST) 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 JAA08814 for ; Sat, 22 Dec 2001 09:53:14 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBMGqNb16110 for ; Sat, 22 Dec 2001 17:52:23 +0100 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 RAA16179 for ; Sat, 22 Dec 2001 17:52:24 +0100 (MET) 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 fBMGqOD00309 for ; Sat, 22 Dec 2001 17:52:24 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112221652.fBMGqOD00309@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-reply-to: Your message of Fri, 21 Dec 2001 13:11:46 PST. <3C23A592.ED7C9403@iprg.nokia.com> Date: Sat, 22 Dec 2001 17:52:24 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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 don't recall that there was consensus gauged about anything, except _very briefly_ whether people would like to see a new header type for Mobile IPv6 messaging. I was a bit disconcerted that the call for consensus was taken without any discussion on the issues, but even so the results have to be taken into account. => it seems the only real consensus is we have none (:-). Supposing we had a new header type. Wouldn't it be appropriate to make the necessary signaling for protecting Binding Updates to also fit in the same container? => yes of course, same for binding acknowledgements. I don't know about binding requests but as this costs nothing (in fact this can remove some complexity) I am in favor to get a new terminal header type in order to put the whole Mobile IPv6 signaling, including dedicated security, in it. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 12:01: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 MAA00821 for ; Sat, 22 Dec 2001 12:01:49 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05503; Sat, 22 Dec 2001 10:00:36 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06547; Sat, 22 Dec 2001 09:00:52 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMH0KZR007931 for ; Sat, 22 Dec 2001 09:00:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMH0J31007930 for mobile-ip-dist; Sat, 22 Dec 2001 09:00:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMH0GZR007923 for ; Sat, 22 Dec 2001 09:00:16 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24060 for ; Sat, 22 Dec 2001 09:00:18 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12481 for ; Sat, 22 Dec 2001 10:00:17 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBMH0Fb16795 for ; Sat, 22 Dec 2001 18:00:15 +0100 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 SAA16206 for ; Sat, 22 Dec 2001 18:00:16 +0100 (MET) 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 fBMH0GD00341 for ; Sat, 22 Dec 2001 18:00:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112221700.fBMH0GD00341@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-reply-to: Your message of Fri, 21 Dec 2001 13:21:38 PST. <3C23A7E2.9C97F9D1@iprg.nokia.com> Date: Sat, 22 Dec 2001 18:00:16 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: It would good if the extension headers could be used more widely instead of always using a port number for selecting a particular SA. => the only advantage will be to give more control to applications in the use of IPsec (i.e. in place of hacking the SPD, an application can just use a "please-protect-me" destination option. But in the BU protection context, this will only raise again the piggy-backing issue (i.e. two different policies for the same packet for maximal confusion). Regards Francis.Dupont@enst-bretagne.fr PS: does this work well with the proposed IPsec implementation for Solaris (cf. very old mails about IPsec and piggy-backing)? From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 12:20: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 MAA01050 for ; Sat, 22 Dec 2001 12:20:13 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04216; Sat, 22 Dec 2001 09:19:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08722; Sat, 22 Dec 2001 09:19:10 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMHIRZR008154 for ; Sat, 22 Dec 2001 09:18:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMHIRwn008153 for mobile-ip-dist; Sat, 22 Dec 2001 09:18:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMHIOZR008146 for ; Sat, 22 Dec 2001 09:18:24 -0800 (PST) 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 JAA03217 for ; Sat, 22 Dec 2001 09:18:26 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14158 for ; Sat, 22 Dec 2001 09:18:25 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBMHINb21052 for ; Sat, 22 Dec 2001 18:18:23 +0100 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 SAA16251 for ; Sat, 22 Dec 2001 18:18:23 +0100 (MET) 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 fBMHIND00448 for ; Sat, 22 Dec 2001 18:18:23 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112221718.fBMHIND00448@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-reply-to: Your message of Sat, 22 Dec 2001 18:49:40 +0200. Date: Sat, 22 Dec 2001 18:18:23 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: On Sat, 22 Dec 2001, Francis Dupont wrote: > firewalls need to know about the new extension header.... > > => this is true for any new protocols like SCTP. SCTP is a valid analogy only if the considered extension header type is "terminal". So no TCP/UDP/whatever in that packet then .. that's what's under the discussion, right? => it should be terminal because a new not-terminal header type has no real advantage over the destination option header. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 13:13: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 NAA01562 for ; Sat, 22 Dec 2001 13:12:59 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19309; Sat, 22 Dec 2001 11:11:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16266; Sat, 22 Dec 2001 10:11:57 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMIBDZR008393 for ; Sat, 22 Dec 2001 10:11:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMIBDeA008392 for mobile-ip-dist; Sat, 22 Dec 2001 10:11:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMIBAZR008385 for ; Sat, 22 Dec 2001 10:11:10 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26363 for ; Sat, 22 Dec 2001 10:11:12 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22351 for ; Sat, 22 Dec 2001 11:11:12 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA03578; Sat, 22 Dec 2001 10:11:12 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fBMIBB917046; Sat, 22 Dec 2001 10:11:11 -0800 X-mProtect: Sat, 22 Dec 2001 10:11:11 -0800 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 smtpdUqH6fR; Sat, 22 Dec 2001 10:11:08 PST Message-ID: <3C24CB5D.CF3CE33F@iprg.nokia.com> Date: Sat, 22 Dec 2001 10:05:17 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 References: <200112221617.fBMGHTD00116@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, I reckon we're not too far from agreement. Comments below: Francis Dupont wrote: > > 3. Protecting the BU. There are three options. pick one. > > a. new extension header > ............. > I'm not so enthusiastic about (a), because I know it's a pile > of work to do it. > > => no, this is just a statement in the IANA section. I wish. No, I (as editor) would have to specify the exact placement, and interactions with possibly every other IPv6 header type. Plus who knows what other interactions will rear their ugly faces just at the last minute when we thought we had finally made it through Last Call...?! > >(piggy-backing) > > a. lets leave it as it is. it is a 'MAY'. > > b. leave it as it is, but recommend when it is > > good to use and when it is bad to use. > > > > => (b) with good to use == never and bad to use == always! > > This isn't right. It's almost always good to use, because it > almost always offers a performance improvement. There are times > when the performance improvement could make the difference in > even the feasibility of smooth voice handovers, due to the > decrease in jitter (as was pointed out in work from Cedric Westphal). > > => all these arguments still apply if this is done by the link-layer. > IMHO this is a typical case of mobility = wireless confusion. But it's not. The point of my statement about this, is that sending the control signal along with the data is very helpful as noted. The link-layer cannot distinguish between control and data. And we aren't supposed to be in the business of favoring those distinguished link-layers that know a lot about bundling packets. Furthermore, I will claim that I am usually pretty aware of the distinction between mobility and wireless, but hey nobody's perfect. > > 5. Key Distribution protocol between MN and CN > > a. Return routability vs CGA (Cryptographically > > Generated Addrs) > > b. Binding Security Association > > > > for (a), lets go with return routability unless > > somebody can prove that it is insecure. > > > > => very easy: put the attacker in the CN default router. > > This is not "easy" > => I disagree: the formal proof (of insecurity) is easy. An easy proof is not the same as a worrisome threat. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 13:14: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 NAA01600 for ; Sat, 22 Dec 2001 13:14:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19886; Sat, 22 Dec 2001 11:13:44 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07101; Sat, 22 Dec 2001 10:13:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMIDPZR008473 for ; Sat, 22 Dec 2001 10:13:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMIDPUk008472 for mobile-ip-dist; Sat, 22 Dec 2001 10:13:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMIDMZR008465 for ; Sat, 22 Dec 2001 10:13:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26606 for ; Sat, 22 Dec 2001 10:13:25 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26581 for ; Sat, 22 Dec 2001 11:14:12 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBMIDMQ04624 for ; Sat, 22 Dec 2001 20:13:22 +0200 Date: Sat, 22 Dec 2001 20:13:22 +0200 (EET) From: Pekka Savola To: Subject: Re: [mobile-ip] list of things for MIPv6 (2) In-Reply-To: <200112221503.fBMF3YD87890@givry.rennes.enst-bretagne.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: On Sat, 22 Dec 2001, Francis Dupont wrote: > Your argument about source spoofing does not apply; ... > > host1 --- fwrtr1 - rtrISP - Internet - fwrtr2 ---host2 > 3ffe:ffff:1::/48 3ffe:ffff:2::/48 > > Now, the attacker host1 could attack: > > src = 3ffe:ffff:1::1 (or spoofed if no filtering in fwrtr1, as assumed) > > => you say you have a source spoofing attack when the source firewall > doesn't filter anything. I have not to read further in order to say > you should be right and you add nothing to the debate... fwrtr1 is irrelevant in this scenario; it's all about what fwrtr2 can be trusted to do. Without HAO, destination site can still protect from the attackers spoofing the source as one of the destination site's internal addresses. With HAO this filtering, which you _can_ rely on, is nullified unless firewalls keep state of the bindings (or somehow know enough of them). A relevant threat, as those addresses could be viewed to be more trusted than most addresses in the internet. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 13:49: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 NAA01767 for ; Sat, 22 Dec 2001 13:49:06 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA15225; Sat, 22 Dec 2001 10:48:04 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12141; Sat, 22 Dec 2001 10:48:02 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMIlIZR008619 for ; Sat, 22 Dec 2001 10:47:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMIlIEm008618 for mobile-ip-dist; Sat, 22 Dec 2001 10:47:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMIlFZR008611 for ; Sat, 22 Dec 2001 10:47:15 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28536 for ; Sat, 22 Dec 2001 10:47:18 -0800 (PST) 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 LAA26420 for ; Sat, 22 Dec 2001 11:46:59 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBMIlDb29277; Sat, 22 Dec 2001 19:47:13 +0100 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 TAA16592; Sat, 22 Dec 2001 19:47:14 +0100 (MET) 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 fBMIlDD00976; Sat, 22 Dec 2001 19:47:13 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112221847.fBMIlDD00976@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charlie Perkins cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-reply-to: Your message of Sat, 22 Dec 2001 10:05:17 PST. <3C24CB5D.CF3CE33F@iprg.nokia.com> Date: Sat, 22 Dec 2001 19:47:13 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: >(about a new header for BUs) > => no, this is just a statement in the IANA section. I wish. => me too. No, I (as editor) would have to specify the exact placement, and interactions with possibly every other IPv6 header type. => terminal (simple, no interaction). Plus who knows what other interactions will rear their ugly faces just at the last minute when we thought we had finally made it through Last Call...?! => same answer. > >(piggy-backing) > > a. lets leave it as it is. it is a 'MAY'. > > b. leave it as it is, but recommend when it is > > good to use and when it is bad to use. > > > > => (b) with good to use == never and bad to use == always! > > This isn't right. It's almost always good to use, because it > almost always offers a performance improvement. There are times > when the performance improvement could make the difference in > even the feasibility of smooth voice handovers, due to the > decrease in jitter (as was pointed out in work from Cedric Westphal). > > => all these arguments still apply if this is done by the link-layer. > IMHO this is a typical case of mobility = wireless confusion. But it's not. The point of my statement about this, is that sending the control signal along with the data is very helpful as noted. => there are tons of reasons showing this is a bad idea. In general control and data need different policies for something (security (so IPsec issue), QoS, etc) and this is hard to apply two different policies to the same packet. Just put them in the same frame (-:)? The link-layer cannot distinguish between control and data. => make it more clever, i.e. recognize binding update in the "to be transmit" queue and put them in front of the "next to go" frame (but see the PostScriptum). And we aren't supposed to be in the business of favoring those distinguished link-layers that know a lot about bundling packets. => but very slow or very fast link-layers for different reasons can take benefit from a knowledge of what is in packets. I agree I don't want to open door to backones with routers look at inside my packets (they need the length only in order to aggregate packets into super-frames) but I am not against not-dumb first/last slow link-layers. Furthermore, I will claim that I am usually pretty aware of the distinction between mobility and wireless, but hey nobody's perfect. => you should recognize piggy-backing is less useful on an Ethernet or a 802.11b/802.11a. I consider piggy-backing as an over-optimization (as RSVP in fact) in most cases, i.e. this really makes sense with some link-layers which are very hard (i.e. too expensive) to improve (this is the case of mobile phone in Europe, nobody wants to buy a second license in some countries just to get more bandwidth :-). Regards Francis.Dupont@enst-bretagne.fr PS: the netcontrol class selector is still defined. If someone uses it in order to prioritize (?) BUs and if the link-layer knows class selectors, this will be better than piggy-backing: BUs will be delivered ASAP without waiting for the end of long frames. Aggressive link-layers can even cancel a long transmission in favor of a BU... (note I consider there is important to deliver BUs ASAP which is the case for home registration, piggy-backing is essentielly a slow down mechanism because it waits for something into piggy-back... My IPv6 payload header was smarter because it was designed in order to compress the "to be transmit" queue, i.e. it was always more efficient) From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 14:00: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 OAA01865 for ; Sat, 22 Dec 2001 14:00:16 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28813; Sat, 22 Dec 2001 11:58:58 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13499; Sat, 22 Dec 2001 10:59:14 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMIwWZR008975 for ; Sat, 22 Dec 2001 10:58:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMIwWlc008974 for mobile-ip-dist; Sat, 22 Dec 2001 10:58:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMIwTZR008967 for ; Sat, 22 Dec 2001 10:58:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01061 for ; Sat, 22 Dec 2001 10:58:30 -0800 (PST) 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 LAA06919 for ; Sat, 22 Dec 2001 11:59:20 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBMIwQb29537 for ; Sat, 22 Dec 2001 19:58:26 +0100 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 TAA16626 for ; Sat, 22 Dec 2001 19:58:27 +0100 (MET) 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 fBMIwRD01004 for ; Sat, 22 Dec 2001 19:58:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112221858.fBMIwRD01004@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 (2) In-reply-to: Your message of Sat, 22 Dec 2001 20:13:22 +0200. Date: Sat, 22 Dec 2001 19:58:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: On Sat, 22 Dec 2001, Francis Dupont wrote: > Your argument about source spoofing does not apply; ... > > host1 --- fwrtr1 - rtrISP - Internet - fwrtr2 ---host2 > 3ffe:ffff:1::/48 3ffe:ffff:2::/48 > > Now, the attacker host1 could attack: > > src = 3ffe:ffff:1::1 (or spoofed if no filtering in fwrtr1, as assumed) > > => you say you have a source spoofing attack when the source firewall > doesn't filter anything. I have not to read further in order to say > you should be right and you add nothing to the debate... fwrtr1 is irrelevant in this scenario; it's all about what fwrtr2 can be trusted to do. => fwrtr1 is the place where smart ingress filtering can be done. Without it, the job of fwrtr2 is far more difficult. And look at my conclusion. Without HAO, destination site can still protect from the attackers spoofing the source as one of the destination site's internal addresses. => this is trivial anti-spoofing. With HAO this filtering, which you _can_ rely on, is nullified unless firewalls keep state of the bindings (or somehow know enough of them). => I agree: the protection of the home domain needs to know the home registrations, by BU/BA spoofing and/or with HA collaboration. A relevant threat, as those addresses could be viewed to be more trusted than most addresses in the internet. => usually the potential home addresses are known so it is possible to give them less trust than for local addresses of fixed nodes. But I prefer to rely on smart ingress filtering because if you have no ingress filtering you have no good reply to ordinary DDos, i.e. this is a question of are you dead or more dead (:-)? Regards Francis.Dupont@enst-bretagne.fr PS: if we continue this discussion, can you put the whole scenario in order to be understable (not only boring :-) for others? From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 14:40: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 OAA02121 for ; Sat, 22 Dec 2001 14:40:43 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06113; Sat, 22 Dec 2001 12:39:28 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03325; Sat, 22 Dec 2001 11:39:43 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMJcpZR009447 for ; Sat, 22 Dec 2001 11:38:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMJcpaV009446 for mobile-ip-dist; Sat, 22 Dec 2001 11:38:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMJcmZR009439 for ; Sat, 22 Dec 2001 11:38:48 -0800 (PST) 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 LAA21686 for ; Sat, 22 Dec 2001 11:38:49 -0800 (PST) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09334 for ; Sat, 22 Dec 2001 11:38:48 -0800 (PST) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id 7E98A74403; Sat, 22 Dec 2001 21:38:40 +0200 (EET) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 71DABBA2D; Sat, 22 Dec 2001 21:38:39 +0200 (EET) Message-ID: <3C24E141.5020103@nomadiclab.com> Date: Sat, 22 Dec 2001 21:38:41 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Cc: Jari Arkko Subject: Re: [mobile-ip] list of things for MIPv6 References: <3C2230D9.5BA4B149@iprg.nokia.com> <003301c18a54$4b115e80$8a1b6e0a@arenanet.fi> <3C23A592.ED7C9403@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: >>I believe there is a real difference in current spoofing >>attacks compared to the ones enabled by the home >>address option. Namely, ingress filtering or other techniques >>can prevent source address spoofing but I can't see how >>they could prevent HAO spoofing. Charles E. Perkins wrote: > Ingress filtering could put some restriction on this. > For instance, it could be enforced that only one home > address could be associated to a particular care-of address. > This would eliminate most of the "fun" that would be > associated with such spoofing. We could also say that > a correspondent node has to do such filtering. After > these two measures are taken, I think that no self-respecting > bad guy would waste time on such a low-payoff exploit. Well, to me this seems to depend on how the CoAs are assigned. If the MN is allowed to use stateless autoconfiguration, it can generate a few thousand different CoAs for itself, and use each CoA separately to send different home addresses in the Home Address Option. Ingress filtering wouldn't notice this, each packet just would seem to originate from a different host. In an ethernet like network it is even possible to use a different MAC address each time. --Pekka Nikander From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 22 15: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 PAA02225 for ; Sat, 22 Dec 2001 15:01:56 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10289; Sat, 22 Dec 2001 13:00:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17539; Sat, 22 Dec 2001 12:00:58 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMK0HZR009720 for ; Sat, 22 Dec 2001 12:00:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBMK0HxD009719 for mobile-ip-dist; Sat, 22 Dec 2001 12:00:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBMK0EZR009712 for ; Sat, 22 Dec 2001 12:00:14 -0800 (PST) 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 MAA17427 for ; Sat, 22 Dec 2001 12:00:15 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24797 for ; Sat, 22 Dec 2001 12:00:14 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBMK0Dq05420 for ; Sat, 22 Dec 2001 22:00:13 +0200 Date: Sat, 22 Dec 2001 22:00:13 +0200 (EET) From: Pekka Savola To: Subject: Re: [mobile-ip] list of things for MIPv6 (2) In-Reply-To: <200112221858.fBMIwRD01004@givry.rennes.enst-bretagne.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: On Sat, 22 Dec 2001, Francis Dupont wrote: > On Sat, 22 Dec 2001, Francis Dupont wrote: > > Your argument about source spoofing does not apply; ... > > > > host1 --- fwrtr1 - rtrISP - Internet - fwrtr2 ---host2 > > 3ffe:ffff:1::/48 3ffe:ffff:2::/48 > > > > Now, the attacker host1 could attack: > > > > src = 3ffe:ffff:1::1 (or spoofed if no filtering in fwrtr1, as assumed) > > > > => you say you have a source spoofing attack when the source firewall > > doesn't filter anything. I have not to read further in order to say > > you should be right and you add nothing to the debate... > > fwrtr1 is irrelevant in this scenario; it's all about what fwrtr2 can be > trusted to do. > > => fwrtr1 is the place where smart ingress filtering can be done. > Without it, the job of fwrtr2 is far more difficult. And look at > my conclusion. fwrtr2 can only protect what it knows, that is, the local site not being spoofed. But as that is the only filtering you can _rely on_ (there might not be smart ingress filtering at fwrtr1!), it MUST NOT be compromised. > Without HAO, destination site can still protect from the attackers > spoofing the source as one of the destination site's internal addresses. > > => this is trivial anti-spoofing. It is trivial, but vital. > With HAO this filtering, which you _can_ rely on, is nullified unless > firewalls keep state of the bindings (or somehow know enough of them). > > => I agree: the protection of the home domain needs to know the home > registrations, by BU/BA spoofing and/or with HA collaboration. I disagree with your conclusion. I didn't say "it's ok to drop this issue and require the firewall know the registrations". I think I know my opinion about the subject already :-). And even if we did this, it would not help. The firewalls of sites where CN's are (perhaps not wanting _anything_ to do with MIPv6) would have to have these mappings as well, not just home domains. The reality might be that: 1) those that don't care or understand the problems pass this through 2) some (perhaps even most) home domains implement what you suggest 3) the rest of home domains and probably about all CN sites (people who care) drop all packets with HOA. > A relevant threat, as those addresses could be viewed to be more trusted > than most addresses in the internet. > > => usually the potential home addresses are known so it is possible to > give them less trust than for local addresses of fixed nodes. > > But I prefer to rely on smart ingress filtering because if you have > no ingress filtering you have no good reply to ordinary DDos, i.e. > this is a question of are you dead or more dead (:-)? Ingress filtering requires it is done at the source. This is not always done. Every site should implement egress filtering -- it's for their own safety even if they couldn't care for others'. > PS: if we continue this discussion, can you put the whole scenario > in order to be understable (not only boring :-) for others? I'm not sure how to make it clearer. I've added this to my draft: http://www.netcore.fi/pekkas/ietf/draft-savola-ipv6-rh-ha-security-01bis.txt The only changes are in section 3.1 "The Source Address Spoofing Problem" -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 23 21:14: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 VAA29837 for ; Sun, 23 Dec 2001 21:14:55 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA25290; Sun, 23 Dec 2001 19:13:38 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA24004; Sun, 23 Dec 2001 18:13:54 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBO2DGZR012543 for ; Sun, 23 Dec 2001 18:13:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBO2DGje012542 for mobile-ip-dist; Sun, 23 Dec 2001 18:13:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBO2DAZR012535 for ; Sun, 23 Dec 2001 18:13:11 -0800 (PST) Received: from lillen (hobo176.EBay.Sun.COM [129.150.99.73]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBO2D9312063; Mon, 24 Dec 2001 03:13:09 +0100 (MET) Date: Mon, 24 Dec 2001 00:37:31 +0100 (CET) From: Erik Nordmark Subject: Re: [mobile-ip] list of things for MIPv6 To: charliep@iprg.nokia.com Cc: Glenn Morrow , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C237B4D.205C2437@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: > I have to agree that the specification has to be correct! However, we > always have to weigh the cost of the problem against the cost of the > solution. If the problem is microscopic, and the solution so burdensome > as to likely inhibit implementation, then the solution is not a solution > after all, and we should just document the problem. Thus I agree very > much with (a), because I think the threat is small. Plus, I think that > ingress-filtering routers can be built to make the threat even smaller. > Furthermore, there are rules that can be built into correspondent nodes > to reduce the threat even more. Charlie, since I have no idea what rules could possibly be built into ingress-filtering routers and CNs that reduce the threat, could you please enlighten me? As far as I can tell, any scheme for verifying the relationship between the source address (CoA) and the Home Address, whether done by an ingress-filtering router or a CN, requires knowing the binding between those two addresses. Which ways to you see around this? Erik From owner-mobile-ip@sunroof.eng.sun.com Sun Dec 23 21:14: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 VAA29834 for ; Sun, 23 Dec 2001 21:14:54 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA13196; Sun, 23 Dec 2001 18:13:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23974; Sun, 23 Dec 2001 18:13:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBO2CrZR012533 for ; Sun, 23 Dec 2001 18:12:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBO2Crx1012532 for mobile-ip-dist; Sun, 23 Dec 2001 18:12:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBO2CnZR012525 for ; Sun, 23 Dec 2001 18:12:49 -0800 (PST) Received: from lillen (hobo176.EBay.Sun.COM [129.150.99.73]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fBO2Ck312047; Mon, 24 Dec 2001 03:12:47 +0100 (MET) Date: Mon, 24 Dec 2001 00:33:16 +0100 (CET) From: Erik Nordmark Subject: RE: [mobile-ip] list of things for MIPv6 To: hesham.soliman@era.ericsson.se Cc: "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <4DA6EA82906FD511BE2F00508BCF053801C4C182@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => I can't see how we can do RR only and still maintain > that our requirement is "Add no harm". Connection > hijacking can be considered "new harm" and RR will > not stop it. IMHO (and I'm not a security expert) > the combination of CGAs and RR is an excellent idea > and will give quite a strong security. Any node on the path between two communicating entities today can be MiTM for TCP connections and UDP "flows". If IPsec/TLS/etc is not used those MiTM can modify the content of the communication; otherwise they can just cause a DoS by dropping packets (or modifying them and having the receipient drop then due to authentication failure). Adding MIPv6 a BU protected by RR doesn't seem to make this any worse. What am I missing? Erik From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 24 09:41: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 JAA22757 for ; Mon, 24 Dec 2001 09:41:08 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29146; Mon, 24 Dec 2001 07:39:44 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16986; Mon, 24 Dec 2001 06:39:59 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOEciZR013465 for ; Mon, 24 Dec 2001 06:38:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOEcilv013464 for mobile-ip-dist; Mon, 24 Dec 2001 06:38:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOEceZR013457 for ; Mon, 24 Dec 2001 06:38:40 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07827 for ; Mon, 24 Dec 2001 06:38:43 -0800 (PST) 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 HAA00421 for ; Mon, 24 Dec 2001 07:39:30 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBOEcWb02718; Mon, 24 Dec 2001 15:38:32 +0100 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 PAA01569; Mon, 24 Dec 2001 15:38:32 +0100 (MET) 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 fBOEcWD04946; Mon, 24 Dec 2001 15:38:32 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112241438.fBOEcWD04946@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com cc: Jari Arkko Subject: Re: [mobile-ip] list of things for MIPv6 In-reply-to: Your message of Sat, 22 Dec 2001 21:38:41 +0200. <3C24E141.5020103@nomadiclab.com> Date: Mon, 24 Dec 2001 15:38:32 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: Well, to me this seems to depend on how the CoAs are assigned. If the MN is allowed to use stateless autoconfiguration, it can generate a few thousand different CoAs for itself, and use each CoA separately to send different home addresses in the Home Address Option. => this behavior is so different than standard MN's one that the ingress filtering should block it. Ingress filtering wouldn't notice this, each packet just would seem to originate from a different host. => I don't understand your argument. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 24 09:48: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 JAA22801 for ; Mon, 24 Dec 2001 09:48:07 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01084; Mon, 24 Dec 2001 07:46:52 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17538; Mon, 24 Dec 2001 06:47:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOEkWZR013589 for ; Mon, 24 Dec 2001 06:46:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBOEkWV5013588 for mobile-ip-dist; Mon, 24 Dec 2001 06:46:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBOEkTZR013581 for ; Mon, 24 Dec 2001 06:46:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25793 for ; Mon, 24 Dec 2001 06:46:32 -0800 (PST) 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 HAA02150 for ; Mon, 24 Dec 2001 07:47:24 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBOEkTb02960 for ; Mon, 24 Dec 2001 15:46:29 +0100 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 PAA01592 for ; Mon, 24 Dec 2001 15:46:29 +0100 (MET) 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 fBOEkTD04977 for ; Mon, 24 Dec 2001 15:46:29 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112241446.fBOEkTD04977@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 (2) In-reply-to: Your message of Sat, 22 Dec 2001 22:00:13 +0200. Date: Mon, 24 Dec 2001 15:46:29 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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: But as that is the only filtering you can _rely on_ (there might not be smart ingress filtering at fwrtr1!), it MUST NOT be compromised. => this is why there is something to do (next answer(s)). > With HAO this filtering, which you _can_ rely on, is nullified unless > firewalls keep state of the bindings (or somehow know enough of them). > > => I agree: the protection of the home domain needs to know the home > registrations, by BU/BA spoofing and/or with HA collaboration. I disagree with your conclusion. I didn't say "it's ok to drop this issue and require the firewall know the registrations". I think I know my opinion about the subject already :-). And even if we did this, it would not help. The firewalls of sites where CN's are (perhaps not wanting _anything_ to do with MIPv6) would have to have these mappings as well, not just home domains. => you are talking about spoofing of local addresses. For a CN which is not in the home or the visited domain, a HAO makes no difference. The reality might be that: 1) those that don't care or understand the problems pass this through 2) some (perhaps even most) home domains implement what you suggest 3) the rest of home domains and probably about all CN sites (people who care) drop all packets with HOA. => (3) is exactly what we don't want. > But I prefer to rely on smart ingress filtering because if you have > no ingress filtering you have no good reply to ordinary DDos, i.e. > this is a question of are you dead or more dead (:-)? Ingress filtering requires it is done at the source. This is not always done. => we can't enforce it but this is not our role too. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 24 19:05: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 TAA25843 for ; Mon, 24 Dec 2001 19:05:31 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA08948; Mon, 24 Dec 2001 16:04:43 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06728; Mon, 24 Dec 2001 16:04:39 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP03dZR015780 for ; Mon, 24 Dec 2001 16:03:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBP03cEN015778 for mobile-ip-dist; Mon, 24 Dec 2001 16:03:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP03ZZR015770 for ; Mon, 24 Dec 2001 16:03:35 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15048 for ; Mon, 24 Dec 2001 16:03:37 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07619 for ; Mon, 24 Dec 2001 17:03:36 -0700 (MST) 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 fBP03ax26387; Mon, 24 Dec 2001 16:03:36 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAO59363; Mon, 24 Dec 2001 16:03:02 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id QAA07845; Mon, 24 Dec 2001 16:03:35 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15399.49751.633230.919881@thomasm-u1.cisco.com> Date: Mon, 24 Dec 2001 16:03:35 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Cc: hesham.soliman@era.ericsson.se Subject: RE: [mobile-ip] list of things for MIPv6 In-Reply-To: References: <4DA6EA82906FD511BE2F00508BCF053801C4C182@Esealnt861.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 Erik Nordmark writes: > > => I can't see how we can do RR only and still maintain > > that our requirement is "Add no harm". Connection > > hijacking can be considered "new harm" and RR will > > not stop it. IMHO (and I'm not a security expert) > > the combination of CGAs and RR is an excellent idea > > and will give quite a strong security. > > Any node on the path between two communicating entities today can be > MiTM for TCP connections and UDP "flows". If IPsec/TLS/etc is not used those > MiTM can modify the content of the communication; otherwise they can > just cause a DoS by dropping packets (or modifying them and having the > receipient drop then due to authentication failure). > > Adding MIPv6 a BU protected by RR doesn't seem to make this any worse. > What am I missing? Right. It should be noted that the even the most widely deployed crypto/auth layer (TLS) is subject to trivial MITM wedging attacks (eg, insert a bogus-TLS good-TCP segment -- barf, die). For better or worse, we depend on there not being many evil routers. Literally. Mike From owner-mobile-ip@sunroof.eng.sun.com Mon Dec 24 19:05: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 TAA25854 for ; Mon, 24 Dec 2001 19:05:34 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA08867; Mon, 24 Dec 2001 16:04:30 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06701; Mon, 24 Dec 2001 16:04:28 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP03gZR015788 for ; Mon, 24 Dec 2001 16:03:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBP03gU2015787 for mobile-ip-dist; Mon, 24 Dec 2001 16:03:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBP03cZR015777 for ; Mon, 24 Dec 2001 16:03:38 -0800 (PST) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with SMTP id fBP03e3D430394 for ; Mon, 24 Dec 2001 16:03:40 -0800 (PST) Message-Id: <200112250003.fBP03e3D430394@jurassic.eng.sun.com> Date: Mon, 24 Dec 2001 16:05:32 -0800 (PST) From: Samita Chakrabarti Subject: [mobile-ip] Reminder: Connectathon Early bird registration : 12/31/01 To: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: PBaUHUIy4FOGFY5+SN0U5Q== 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: Folks who are interested in testing MIPv6/MIPv4 interoperability tests, please sign up for Connectathon by Dec31 st to get an early bird discount. Please check out http://www.connectathon.org or contact Audrey Van Belleghem at audrey@vanb.com or (408) 358-9598 Please note that the web-site will be updated with new test specifications on mobileip(V6/V4) in January. Please continue to send your suggestions on testing drafts that are not already listed in SLC presentation slides. We most probably will be adding FMIPV6 interoperability testing as two vendors expressed in testing FMIPV6. Thanks, -Samita samita.chakrabarti@Sun.com Solaris Networking Technology Sun Microsystems, Inc. (650)-786 5068. From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 26 13:26: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 NAA19512 for ; Wed, 26 Dec 2001 13:26:54 -0500 (EST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07110; Wed, 26 Dec 2001 11:25:50 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15352; Wed, 26 Dec 2001 10:26:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQIPJZR018585 for ; Wed, 26 Dec 2001 10:25:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQIPJN8018584 for mobile-ip-dist; Wed, 26 Dec 2001 10:25:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQIPGZR018577; Wed, 26 Dec 2001 10:25:16 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18292; Wed, 26 Dec 2001 10:25:19 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06438; Wed, 26 Dec 2001 11:25:18 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id fBQIPGb24738; Wed, 26 Dec 2001 19:25:16 +0100 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 TAA09919; Wed, 26 Dec 2001 19:25:16 +0100 (MET) 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 fBQIPGD14500; Wed, 26 Dec 2001 19:25:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200112261825.fBQIPGD14500@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] IPv6 ingress filtering early access Date: Wed, 26 Dec 2001 19:25:16 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at 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 have written a draft about IPv6 ingress filtering (with home address option considerations). It is not finished (some editing is needed) but I have put it for early access on (sorry for the long line): ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-ingress-filtering-00.txt I'll collect comment(s) in one week because me, the I-D editor and perhaps my co-author are on holidays. Happy new year! Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed Dec 26 14:40: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 OAA20224 for ; Wed, 26 Dec 2001 14:40:45 -0500 (EST) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15121; Wed, 26 Dec 2001 11:39:51 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14284; Wed, 26 Dec 2001 11:39:45 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJctZR018998 for ; Wed, 26 Dec 2001 11:38:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBQJctMl018997 for mobile-ip-dist; Wed, 26 Dec 2001 11:38:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBQJclZR018982; Wed, 26 Dec 2001 11:38:47 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14214; Wed, 26 Dec 2001 11:38:48 -0800 (PST) Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25628; Wed, 26 Dec 2001 12:38:29 -0700 (MST) Received: from jariws1 ([62.248.239.67]) by fep01-app.kolumbus.fi (InterMail vM.5.01.03.08 201-253-122-118-108-20010628) with SMTP id <20011226193846.YZJI11987.fep01-app.kolumbus.fi@jariws1>; Wed, 26 Dec 2001 21:38:46 +0200 Message-ID: <005e01c18e44$f38fea60$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Francis Dupont" , Cc: References: <200112261825.fBQIPGD14500@givry.rennes.enst-bretagne.fr> Subject: [mobile-ip] Re: IPv6 ingress filtering early access Date: Wed, 26 Dec 2001 21:38:53 +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.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 > ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-ingress-filtering-00.txt Nice draft, thanks for taking the time to write down the problems and their alternative solutions. Hope you still had time for Christmas ;-) I have a few comments. First, it seems that the main alternatives we have is (a) restrict MIPv6 functionality by removing intermediate alternatives between bidirectional tunneling and route optimisation, or (b) deploy AAA to help visited networks figure out what are legal home addresses. It is interesting to note the different actors in these two alternatives. In the first alternative, it is the CN who is taking the responsibility, and requiring no help whatsoever from the firewalls in between. In the second alternative, we put all the trust on the firewalls/routers of sites, and none of the CNs do any worrying over this anymore. Both solutions work if applied allover, and the second solution allows the current MIPv6 flexibility, being therefore the preferred solution if seen feasible. However, I'm concerned about the "applied allover" part. Specifically - while I'm very much fond of the AAA solutions - I'm concerned whether we can expect all parts of the Internet to have an infrastructure that really can figure out the home addresses. What if there's a coin-operated (or Visa-) airport WLAN? With no connection to a global roaming association of who owns what addresses. What kind of filtering should that do? Prohibit everything else expect bidirectional tunneling, or allow home addresses to be used? If latter, then the trusting CNs don't have a clue that they could be used as reflectors... Finally, I seem to remember there was a discussion a long time ago whether we could somehow provide automatic, mandatory, ingress filtering in IPv6. If such a feature were possible, it would really make setting up networks easier and denial of service attacks easier to trace. Do you think this would be feasible? If yes, perhaps it should also be discussed in the draft. Currently, we are headed towards the same situation as in IPv4 where ingress filtering is only partially applied, and we keep coming up with "patch" solutions such as I-trace to help the situation. Interestingly, these solutions typically need changes to a large fraction of the routers in the Internet which we already are doing anyway to move to IPv6... Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 27 03:03: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 DAA12354 for ; Thu, 27 Dec 2001 03:03:00 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA13231; Thu, 27 Dec 2001 00:01:42 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA16175; Thu, 27 Dec 2001 00:01:40 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR80wZR019908 for ; Thu, 27 Dec 2001 00:00:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBR80vZ6019907 for mobile-ip-dist; Thu, 27 Dec 2001 00:00:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBR80sZR019900 for ; Thu, 27 Dec 2001 00:00:54 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA08001 for ; Thu, 27 Dec 2001 00:00:55 -0800 (PST) Received: from muminmamman.lifix.fi ([195.238.204.197]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09581 for ; Thu, 27 Dec 2001 01:00:54 -0700 (MST) Received: from ban by muminmamman.lifix.fi with local (Exim 3.32 #1 (Debian)) id 16JVT6-000110-00; Thu, 27 Dec 2001 10:00:48 +0200 Date: Thu, 27 Dec 2001 10:00:48 +0200 From: Bjorn Andersson To: "Charles E. Perkins" Cc: Mobile IP Working Group Subject: Re: [mobile-ip] Last minute revisions to RFC2002bis --> RFC 3220 Message-ID: <20011227100048.A2970@lifix.fi> Mail-Followup-To: Bjorn Andersson , "Charles E. Perkins" , Mobile IP Working Group References: <3C23D09A.34F6E597@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C23D09A.34F6E597@iprg.nokia.com> User-Agent: Mutt/1.3.20i Sender: owner-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, in rfc2002-bis-08 there is still a typo in section 6.4 where there are overlapping ranges in the error codes. I sent a note about this some months ago. The current text is as follows: 0-8 Success Codes 9-63 No allocation guidelines currently exist 64-128 Error Codes from the Foreign Agent 128-192 Error Codes from the Home Agent 193-255 No allocation guidelines currently exist but should be: 0-8 Success Codes 9-63 No allocation guidelines currently exist 64-127 Error Codes from the Foreign Agent 128-192 Error Codes from the Home Agent 193-255 No allocation guidelines currently exist Section 6.3 mentions that the One-byte padding can be used in registration message. There is no reference to this, and the draft only motivates the need for the One-byte padding in advertisements. I think that the extension should be removed from the list of registration extensions mentioned in 6.3. Regards, Bjorn -- Bjorn Andersson +358 50 341 2556 Lifix Systems Oy PGP id 5AFC144B Yliopistonkatu 5, 3rd floor; FIN-00100 Helsinki From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 27 06:57:38 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 GAA16015 for ; Thu, 27 Dec 2001 06:57:37 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08858; Thu, 27 Dec 2001 04:56:32 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA00762; Thu, 27 Dec 2001 03:56:48 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRBu7ZR020474 for ; Thu, 27 Dec 2001 03:56:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRBu7bY020473 for mobile-ip-dist; Thu, 27 Dec 2001 03:56:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRBu4ZR020466 for ; Thu, 27 Dec 2001 03:56:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA11213 for ; Thu, 27 Dec 2001 03:56:05 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08657 for ; Thu, 27 Dec 2001 04:55:46 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBRBu1N21785 for ; Thu, 27 Dec 2001 13:56:01 +0200 Date: Thu, 27 Dec 2001 13:56:01 +0200 (EET) From: Pekka Savola To: Subject: Re: [mobile-ip] list of things for MIPv6 (2) In-Reply-To: <200112241446.fBOEkTD04977@givry.rennes.enst-bretagne.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: On Mon, 24 Dec 2001, Francis Dupont wrote: > > With HAO this filtering, which you _can_ rely on, is nullified unless > > firewalls keep state of the bindings (or somehow know enough of them). > > > > => I agree: the protection of the home domain needs to know the home > > registrations, by BU/BA spoofing and/or with HA collaboration. > > I disagree with your conclusion. I didn't say "it's ok to drop this issue > and require the firewall know the registrations". I think I know my > opinion about the subject already :-). > > And even if we did this, it would not help. The firewalls of sites where > CN's are (perhaps not wanting _anything_ to do with MIPv6) would have to > have these mappings as well, not just home domains. > > => you are talking about spoofing of local addresses. For a CN which > is not in the home or the visited domain, a HAO makes no difference. Good point. Nevertheless, picture a scenario where the site has only a couple of MIPv6 users: would it be okay to require AAA for their sake (for local firewall, and for interacting with remote AAA systems for ingress filtering)? > The reality might be that: > 1) those that don't care or understand the problems pass this through > 2) some (perhaps even most) home domains implement what you suggest > 3) the rest of home domains and probably about all CN sites (people who > care) drop all packets with HOA. > > => (3) is exactly what we don't want. Sure, but that's still what me might get.. Consider: whoever got the idea that ICMPv4 is harmful? For some odd reason it's being blocked in many firewalls (breaking all sorts of things). It appears these kind of blocks can be installed even for much smaller concerns than spoofability, or no reasons at all... -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 27 07:39: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 HAA16311 for ; Thu, 27 Dec 2001 07:39:55 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26997; Thu, 27 Dec 2001 04:39:13 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA14262; Thu, 27 Dec 2001 04:39:08 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCcHZR020753 for ; Thu, 27 Dec 2001 04:38:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRCcHVw020752 for mobile-ip-dist; Thu, 27 Dec 2001 04:38:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCcDZR020745; Thu, 27 Dec 2001 04:38:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03619; Thu, 27 Dec 2001 04:38:15 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18247; Thu, 27 Dec 2001 05:37:55 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fBRCcAw22086; Thu, 27 Dec 2001 14:38:10 +0200 Date: Thu, 27 Dec 2001 14:38:10 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: , Subject: [mobile-ip] Re: IPv6 ingress filtering early access In-Reply-To: <200112261825.fBQIPGD14500@givry.rennes.enst-bretagne.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: On Wed, 26 Dec 2001, Francis Dupont wrote: > I have written a draft about IPv6 ingress filtering (with home address > option considerations). It is not finished (some editing is needed) but > I have put it for early access on (sorry for the long line): > > ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ipv6-ingress-filtering-00.txt Looks rather good .. even though we may not agree on the AAA issues, this seems to bring them up rather nicely :-). About section 2 on Correspondent Nodes; could you elaborate in the document why exactly solution is too drastic? Note that BCE check is not the only way to ensure legitimity of HAO: if it's secured by AH, it's ok; if some SUCV/.. weak authentication method is used, it's probably also ok; the same might even apply to return routability. It's too early to crush CN solutions. (I think the solution for HAO should most likely consist of two separate, "strong-enough" layers, one mandated at CN, one possible at firewalls, but that's not the topic of this draft). Note: it seems every site, even if it had only a few MN's, will have to have AAA infrastructure, so that it could interact, certify etc. home address use for remote AAA systems when MN goes roaming and there's a need to punch a hole in ingress filtering of remote sites. (If this is the approach for security, it should be required in the main MIPv6 draft). Or have I missed something? This seems unnecessary in many environments, e.g. university campus area WLAN or company's internal network. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords From owner-mobile-ip@sunroof.eng.sun.com Thu Dec 27 07:54: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 HAA16447 for ; Thu, 27 Dec 2001 07:54:03 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA29314; Thu, 27 Dec 2001 04:53:21 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15405; Thu, 27 Dec 2001 04:53:18 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCqaZR020941 for ; Thu, 27 Dec 2001 04:52:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBRCqaIp020940 for mobile-ip-dist; Thu, 27 Dec 2001 04:52:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBRCqXZR020933 for ; Thu, 27 Dec 2001 04:52:33 -0800 (PST) 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 EAA26712 for ; Thu, 27 Dec 2001 04:52:35 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29463 for ; Thu, 27 Dec 2001 04:52:34 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA20990; Thu, 27 Dec 2001 14:52:32 +0200 Date: Thu, 27 Dec 2001 14:52:32 +0200 Message-Id: <200112271252.OAA20990@burp.tkv.asdf.org> From: Markku Savela To: mobile-ip@sunroof.eng.sun.com In-reply-to: (message from Pekka Savola on Thu, 27 Dec 2001 14:38:10 +0200 (EET)) Subject: [mobile-ip] Re: IPv6 ingress filtering early access References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk Reply-To: mobile-ip@sunroof.eng.sun.com List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I may have missed some discussion due to high volume on this topic, but I like to inject one scenario of Home Address option use... If MN and CN have IPSEC session between them, then I suppose HAO within such session is safe. (I leave it open for now, whether the session should be between care of addresses or home addresses of MN and CN, but either should work?). -- Markku Savela From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 29 16:08: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 QAA00399 for ; Sat, 29 Dec 2001 16:08:47 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20326; Sat, 29 Dec 2001 13:07:46 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25043; Sat, 29 Dec 2001 13:07:44 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTL6tZR023926 for ; Sat, 29 Dec 2001 13:06:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBTL6t29023925 for mobile-ip-dist; Sat, 29 Dec 2001 13:06:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTL6qZR023918 for ; Sat, 29 Dec 2001 13:06:52 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24952 for ; Sat, 29 Dec 2001 13:06:54 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29462 for ; Sat, 29 Dec 2001 14:07:50 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBTL6rq29079 for ; Sat, 29 Dec 2001 13:06:53 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP02105; Sat, 29 Dec 2001 13:06:19 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA09648; Sat, 29 Dec 2001 13:06:52 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15406.12396.322792.819012@thomasm-u1.cisco.com> Date: Sat, 29 Dec 2001 13:06:52 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] list of things for MIPv6 In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053801C4C18C@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053801C4C18C@Esealnt861.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: > > a. new extension header > > b. Authentication Sub-Option only. > > c. Jari Arkko's draft, option 4 which shows how > > authentication suboption and AH can be used > > together with minimal changes. > > > > if we decide to go with (a), lets not go with UDP. > > instead we should use a new extension header. > > I personally prefer option (c). Implementing the > > auth suboption is very easy. I can provide the code > > if people think it is complicated to implement. > > > I thought the group had already settled on b. Last time I checked there were even plans to upgrade various open-source implementations as well. > > => That was optimistic thinking I think ! we never > had a concensus call on this. Indeed. The next rev of the mip draft should have *all* of this pulled out until there is consensus. What is in there is *highly* misleading and was put in the draft without any consultation on the list, and came as a rather rude surprise to some of us who have been participating in this discussion. Mike From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 29 16:10: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 QAA00428 for ; Sat, 29 Dec 2001 16:10:07 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA20566; Sat, 29 Dec 2001 13:09:23 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25182; Sat, 29 Dec 2001 13:09:20 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTL8lZR023962 for ; Sat, 29 Dec 2001 13:08:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBTL8lff023960 for mobile-ip-dist; Sat, 29 Dec 2001 13:08:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTL8hZR023950 for ; Sat, 29 Dec 2001 13:08:43 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03458 for ; Sat, 29 Dec 2001 13:08:46 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17463 for ; Sat, 29 Dec 2001 14:08:45 -0700 (MST) 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 fBTL8jv23443 for ; Sat, 29 Dec 2001 13:08:45 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP02108; Sat, 29 Dec 2001 13:08:12 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA09651; Sat, 29 Dec 2001 13:08:44 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15406.12508.722799.698472@thomasm-u1.cisco.com> Date: Sat, 29 Dec 2001 13:08:44 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-Reply-To: <3C237AB8.F97ED12C@iprg.nokia.com> References: <4DA6EA82906FD511BE2F00508BCF053801C4C182@Esealnt861.al.sw.ericsson.se> <3C237AB8.F97ED12C@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: > > => I'm afraid I agree with Pekka here. The threat > > is definitely significant. We can't pretend it > > Well. I disagree that the threat is significant. and we are > not pretending that it is not there. we document it and leave > it to the implementations. To do _what_ precisely? As in: what exactly can this implementation do to protect itself from source spoofing? Mike From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 29 16:23: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 QAA00548 for ; Sat, 29 Dec 2001 16:23:02 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24865; Sat, 29 Dec 2001 14:21:50 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25997; Sat, 29 Dec 2001 13:22:05 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTLLLZR024172 for ; Sat, 29 Dec 2001 13:21:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBTLLLuA024171 for mobile-ip-dist; Sat, 29 Dec 2001 13:21:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTLLIZR024164 for ; Sat, 29 Dec 2001 13:21:18 -0800 (PST) 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 NAA23705 for ; Sat, 29 Dec 2001 13:21:21 -0800 (PST) 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 NAA15930 for ; Sat, 29 Dec 2001 13:21:21 -0800 (PST) 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 fBTLLLv25274 for ; Sat, 29 Dec 2001 13:21:21 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP02125; Sat, 29 Dec 2001 13:20:47 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA09654; Sat, 29 Dec 2001 13:21:20 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15406.13263.904189.337520@thomasm-u1.cisco.com> Date: Sat, 29 Dec 2001 13:21:19 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-Reply-To: <3C237CD7.DAD049A2@iprg.nokia.com> References: <200112211439.fBLEdfD69151@givry.rennes.enst-bretagne.fr> <3C237CD7.DAD049A2@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: > I wish everybody would. it would great if implementors are > given more importance in this WG. then we could have our way. You know, it would be great if the number of obviously inflammatory remarks were kept to a minimum. If it weren't for IESG interference here, we'd likely have a looming WEP-esque disaster caused primarily by impatient developers spurred on by impatient PHB's. Mike From owner-mobile-ip@sunroof.eng.sun.com Sat Dec 29 16:30:59 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 QAA00696 for ; Sat, 29 Dec 2001 16:30:59 -0500 (EST) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA22270; Sat, 29 Dec 2001 13:30:09 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26697; Sat, 29 Dec 2001 13:30:07 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTLTVZR024293 for ; Sat, 29 Dec 2001 13:29:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3/Submit) id fBTLTVGB024292 for mobile-ip-dist; Sat, 29 Dec 2001 13:29:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta3+Sun/8.12.2.Beta3) with ESMTP id fBTLTSZR024285 for ; Sat, 29 Dec 2001 13:29:28 -0800 (PST) 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 NAA05055 for ; Sat, 29 Dec 2001 13:29:26 -0800 (PST) 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 NAA16563 for ; Sat, 29 Dec 2001 13:29:26 -0800 (PST) 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 fBTLTPv26307 for ; Sat, 29 Dec 2001 13:29:26 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAP02136; Sat, 29 Dec 2001 13:28:52 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA09658; Sat, 29 Dec 2001 13:29:25 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15406.13749.73299.458198@thomasm-u1.cisco.com> Date: Sat, 29 Dec 2001 13:29:25 -0800 (PST) To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] list of things for MIPv6 In-Reply-To: <3C23A443.3905E18B@lucent.com> References: <4DA6EA82906FD511BE2F00508BCF053801C4C18C@Esealnt861.al.sw.ericsson.se> <3C237FE1.D041D3BD@iprg.nokia.com> <15395.40979.707959.184945@thomasm-u1.cisco.com> <3C23A443.3905E18B@lucent.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 Uri Blumenthal writes: > Michael Thomas wrote: > > Vijay Devarapalli writes: > > > option (b) is very simple and works really well. > > > all it needs is IKE supplying the keys. > > > > This is *far* more complicated than you are > > making it out to be. Anybody who claims that > > changing IKE -- and IKE is *not* the only > > consideration -- would do well to find out > > what is going on in the IPsec working group. > > It has been that IKE is "cast in stone". Luckily however, > IKE is in the process of being changed, as we speak. > > IPSec working group is working on a successor of IKE, and > now is the time to submit any specific requirements for IKEv2. IKE is not the only way to key IPsec SA's. Mike