From owner-mobile-ip@sunroof.eng.sun.com Wed May 1 01:16:38 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22292 for ; Wed, 1 May 2002 01:16:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03154; Tue, 30 Apr 2002 23:15:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA19966; Tue, 30 Apr 2002 22:15:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g415EVrP008171 for ; Tue, 30 Apr 2002 22:14:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g415EVpW008170 for mobile-ip-dist; Tue, 30 Apr 2002 22:14:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g415ERrP008156 for ; Tue, 30 Apr 2002 22:14:27 -0700 (PDT) Received: from kathmandu.sun.com ([129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA19705 for ; Tue, 30 Apr 2002 22:14:29 -0700 (PDT) Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA02749 for ; Tue, 30 Apr 2002 23:14:28 -0600 (MDT) Received: from unknown (HELO EmadQ) (emadaq@217.144.4.131 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 1 May 2002 05:14:24 -0000 Reply-To: From: "Emad Qaddoura" To: , , , Subject: RE: [mobile-ip] Last Call: Regional Tunneling input Date: Wed, 1 May 2002 08:13:55 +0200 Message-ID: <000101c1f0d7$644fa2a0$830490d9@EmadQ> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C1F0E8.27D872A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0002_01C1F0E8.27D872A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Authors, Since I have not heard back from Annika on Q1 below, I would like to repost and get clarification from any of the co-authors/group. Personally, reading the draft and all the if/then cases like, get the impression that MIP will have added delay. Working for several years to improve MIP's real-time aspects, makes me concerned about the ultimate impact without seeing from the detailed analysis of this feature's impact (positive/negative). I am re-stating Q2 to the authors/service providers/content providers for their views, as location based services may require the finer granularity of the MN's where about. Thx. EQ ------------------------------------------------------------------------ -------------------------- 1) From Section 5.0, 4th paragraph, "If the advertised GFA is not the same as the one the mobile node has registered as its care-of address, and if the mobile node is still within the same domain as it was when it registered that care-of address, the mobile node MAY try to perform a regional registration with its registered GFA. If the foreign agent cannot support regional registration to a GFA, other than advertised, the foreign agent denies the regional registration with code UNKNOWN_GFA (see section 9.3). In this case the MN has to do a new home registration via the new GFA." As you see, there is extra registration step here,( if the current GFA used by the MN is not supported by the FA), adding possible delays to traffic, would it be reasonable to expect all FAs in the same domain to handle the regional registration to the different GFAs. Or do I misunderstand the above paragraph? With the route optimization draft being optional extensions, we should be concerned about any additional delays to traffic destined to the MN. 2) If the coverage area is large, and the home network does provide personalized content services based on the mobile node's location (location based services) requiring a finer location, would you expect this feature to be turned off most of the time? ------=_NextPart_000_0002_01C1F0E8.27D872A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors,

        = ;   

        = ;    Since I have not heard back from Annika on Q1 below, I would like to repost = and get clarification from any of the co-authors/group. Personally, reading the = draft and all the if/then cases like, get the impression that MIP will have = added delay. Working for several years to improve MIP’s real-time = aspects, makes me concerned about the ultimate impact without seeing from the = detailed analysis of this feature’s impact = (positive/negative).

 

        = ;    I am re-stating Q2 to the authors/service providers/content providers for = their views, as location based services may require the finer granularity of = the MN’s where about.

 

Thx.

EQ

------------------------------------------------------= --------------------------------------------

=

 

1) From Section 5.0, 4th paragraph,

"If the advertised GFA is not the same as the one the mobile node = has

   registered as its care-of address, and if the mobile node is = still

   within the same domain as it was when it registered that = care-of

   address, the mobile node MAY try to perform a regional = registration

   with its registered GFA. If the foreign agent cannot = support

   regional registration to a GFA, other than advertised, the = foreign

   agent denies the regional registration with code UNKNOWN_GFA = (see

   section 9.3).  In this case the MN = has to do a new home registration

   via the new GFA."

 

As you see, there is extra registration step here,( if = the current GFA used by the MN is not supported by the FA), adding possible delays = to traffic, would it be reasonable to expect all FAs in the same domain to handle the regional registration to the different = GFAs. Or do I misunderstand the above = paragraph?

 

With the route optimization draft being optional extensions, we should be = concerned about any additional delays to traffic destined to the = MN.

 

2) If the coverage area is large, and the home network does provide personalized = content services based on the mobile node's location (location based services) requiring a finer location, would you expect this feature to be turned = off most of the time?

 

 

------=_NextPart_000_0002_01C1F0E8.27D872A0-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 1 01:17:46 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22330 for ; Wed, 1 May 2002 01:17:45 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16892; Tue, 30 Apr 2002 22:15:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA19873; Tue, 30 Apr 2002 22:15:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g415EYrP008174 for ; Tue, 30 Apr 2002 22:14:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g415EXIr008173 for mobile-ip-dist; Tue, 30 Apr 2002 22:14:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g415ETrP008163 for ; Tue, 30 Apr 2002 22:14:29 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA19711 for ; Tue, 30 Apr 2002 22:14:31 -0700 (PDT) Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA20223 for ; Tue, 30 Apr 2002 23:14:31 -0600 (MDT) Received: from unknown (HELO EmadQ) (emadaq@217.144.4.131 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 1 May 2002 05:14:29 -0000 Reply-To: From: "Emad Qaddoura" To: "'Singh Ajoy-ASINGH1'" , Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt Date: Wed, 1 May 2002 08:13:55 +0200 Message-ID: <000601c1f0d7$67333a90$830490d9@EmadQ> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Singh Ajoy, Do you all have comparative data that you can publish? Thx. EQ > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] On Behalf Of Singh Ajoy-ASINGH1 > Sent: Wednesday, May 01, 2002 12:11 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-lowlatency- > handoffs-v4-03.txt > > Phil/Raj, > We have implemented low latency handoff draft. Our observation > is that fast handoff performs far better than standard > Mobile/IP. I do see value in publishing this > document as RFC. Probably it is okay to publish this as > experimental RFC if not standard track. > regards, > ajoy > > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: Tuesday, April 30, 2002 3:39 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Status of > draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt > > > In going through the last call comments on regional registrations there > were > some posts about the status of this draft and to what extent it had been > discussed in the working group. > > Raj and I had talked about it and I'd proposed that we not advance this > document > based on the perceived lack of interest in it in terms of real > implementation, in > fact to remove it completely from the WG's agenda. Since some work has > been > done > on it, perhaps the correct thing to do would be to keep it and publish it > as > an experimental RFC. I can't say that I'm in favor of the latter but > tentatively > agree to do so. When the WG started the effort there was tremendous > interest in it > but that interest has dropped nearly to zilch. If starting today it's not > clear > there is enough constituency to add it as a working group item. Hence my > preference to drop it altogether. Neither of us thought that taking it > onto > the standards track as proposed was appropriate. > > We should have kept the WG up-to-date on our thinking and appreciate > hearing > feedback on this. > > Phil From owner-mobile-ip@sunroof.eng.sun.com Wed May 1 04:41:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08572 for ; Wed, 1 May 2002 04:41:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15448; Wed, 1 May 2002 02:41:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04750; Wed, 1 May 2002 01:40:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g418e8rP008514 for ; Wed, 1 May 2002 01:40:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g418e8sm008513 for mobile-ip-dist; Wed, 1 May 2002 01:40:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g418e5rP008506 for ; Wed, 1 May 2002 01:40:05 -0700 (PDT) Received: from pheriche.sun.com ([129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA10697 for ; Wed, 1 May 2002 01:40:05 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20545 for ; Wed, 1 May 2002 02:40:05 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g418dAB09818; Wed, 1 May 2002 10:39:10 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA03892; Wed, 1 May 2002 10:39:10 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g418d5T03779; Wed, 1 May 2002 10:39:05 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205010839.g418d5T03779@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: =?ISO-8859-1?Q?Hans_Sj=F6strand?= cc: Sami Vaarala , Henrik Levkowetz , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security In-reply-to: Your message of Tue, 30 Apr 2002 15:18:29 +0200. <3CCE99A5.80808@ipunplugged.com> Date: Wed, 01 May 2002 10:39:05 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: What the attacker acheives is an eavesdrop in one direction for the duration of the registration. Because the redirect is only valid for the traffic going from the HA to the MN, the traffic from HA to MN is unaffected. => I don't understand at all... For this he has to actively change the source address of the RRQ in an intermediate node to an address which most probably is topologically incorrect and risk to have the packets dropped. => to rely on ingress filtering is a bit dangerous here. This instead of just passively listening from the position he has, in the path, and get both directions. => there are two parts to the threat: - get traffic: mobility doesn't make a major difference (see previous messages about this point) and the counter-measure is to use IPsec (efficient both with and without mobility). - redirect traffic to a victim: this is new and there is no proposed defense against it, just some ideas to limit the effect. given this and the fact that it's a given and well known fact that mobile ip doens't supply you with integrety I think that it will rather confuse than enlight people to start recommending ipsec becuase of these extensions. => I disagree: to recommend IPsec as a way to improve security is IMHO a typical "security consideration". Only valid objections should be in the wording. It will just raise new issues adn new questions. Is it the control messages that should be ipseced ? what ipsec, AH? Is it related to port 443 ? => IPsec can't help to protect the CoA because the CoA is changed en route. But this is a NAT traversal issue, the UDP tunneling by itself can be made as secure as we'd like (so it should when security is needed). So yes, inform people of the new threats but I don't think we should recomend ipsec as some kind of saviour. => IPsec is the proper answer to the fist part of the threat. Because it's not. => I disagree: we have only to explain IPsec can't help for the second part of the threat. He could eavesdrop before and he could do it now. => as I've explained with mobility the possibilities of eavesdropping are a bit different and we can't say today if these differences are really minor or not. So we should explain the first part of the threat even it is not very new. So ipsec is equally applicable to pure mobile ip and has very little to do with nat traversal extensions. => I disagree and don't forget this is for the "security considerations". And the dos case ipsec doesn't help at all. => unfortunately you are 100% right about this point. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Wed May 1 11:05:32 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02166 for ; Wed, 1 May 2002 11:05:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08212; Wed, 1 May 2002 09:04:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08784; Wed, 1 May 2002 08:04:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41F3XrP008921 for ; Wed, 1 May 2002 08:03:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41F3XCl008920 for mobile-ip-dist; Wed, 1 May 2002 08:03:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41F3UrP008913 for ; Wed, 1 May 2002 08:03:30 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08682 for ; Wed, 1 May 2002 08:03:30 -0700 (PDT) Received: from amber.ccs.neu.edu (amber.ccs.neu.edu [129.10.116.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24486 for ; Wed, 1 May 2002 09:03:29 -0600 (MDT) Received: from CASABLANCA.ccs.neu.edu (casablanca.ccs.neu.edu [129.10.118.188]) by amber.ccs.neu.edu (Postfix) with ESMTP id BA3681AB0D; Wed, 1 May 2002 11:03:26 -0400 (EDT) Message-Id: <5.0.2.1.0.20020501105430.03111fa8@mail.ccs.neu.edu> X-Sender: noubir@mail.ccs.neu.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 01 May 2002 10:54:45 -0400 To: mobile-ip@sunroof.eng.sun.com From: "G. Noubir" Subject: [mobile-ip] CFP: Workshop on Wireless Security (in conjunction with MobiCom 2002) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: ----------------------------------------------------------------------- Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP ----------------------------------------------------------------------- Call for Papers Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom 2002 September 28, 2002 Atlanta, Georgia, U.S.A. http://www.crhc.uiuc.edu/~nhv/wise Sponsored by SIGMOBILE (pending) A workshop on Wireless Security will be held in conjunction with ACM MobiCom 2002. The objective of this workshop is to bring together researchers from research communities in wireless networking, security, and dependability, with the goal of fostering interaction among them. With the increasing reliance on wireless networks, issues related to secure and dependable operation of such networks are gaining importance. Topics of interest include, but are not limited to: * Key management in wireless/mobile environments * Intrusion detection * Secure MAC protocols * Secure routing * Denial of service * Privacy and anonymity * Prevention of traffic analysis * Dependable wireless networking * Monitoring and surveillance * Disaster response Paper submission instructions: Submission of papers based on work-in-progress is encouraged. Submitted papers must not be previously published elsewhere or currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. Papers must meet the following restrictions: No longer than 10 pages (single or double column); in font no smaller than 11 points; must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Instructions for electronic submission of papers will be posted at http://www.crhc.uiuc.edu/~nhv/wise/submission.html. Important dates: Paper submissions due: May 20, 2002 Notification of acceptance: July 5, 2002 Camera-ready papers due: July 31, 2002 Workshop date: September 28, 2002 Workshop Co-Chairs: * Douglas Maughan, Defense Advanced Research Projects Agency (dmaughan@darpa.mil) * Nitin Vaidya, University of Illinois at Urbana-Champaign (nhv@uiuc.edu) Program Committee: Yair Amir, Johns Hopkins University Pete Dinsmore, NAI Chip Elliott, BBN Technologies Zygmunt Haas, Cornell University Jean-Pierre Hubaux, EPFL-Lausanne David B. Johnson, Rice University Douglas Maughan, Defense Advanced Research Projects Agency (co-chair) Brian Noble, University of Michigan Ranga Ramanujan, Architecture Technology Corporation Frank Stajano, University of Cambridge Brian Van Leeuwen, Sandia National Laboratories Nitin Vaidya, University of Illinois at Urbana-Champaign (co-chair) Wei Zhao, Texas A&M University Taieb Znati, National Science Foundation, and University of Pittsburgh Publicity Co-Chairs: Mohsen Guizani, University of West Florida Guevara Noubir, Northeastern University Publication Chair: Saad Biaz, Auburn University Registration Chair: Robin Kravets, University of Illinois at Urbana-Champaign From owner-mobile-ip@sunroof.eng.sun.com Wed May 1 11:17:24 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02594 for ; Wed, 1 May 2002 11:17:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27815; Wed, 1 May 2002 09:16:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12063; Wed, 1 May 2002 08:16:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41FEhrP008977 for ; Wed, 1 May 2002 08:14:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41FEgH4008976 for mobile-ip-dist; Wed, 1 May 2002 08:14:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41FEbrP008969 for ; Wed, 1 May 2002 08:14:39 -0700 (PDT) Received: from lukla.Sun.COM ([129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09779 for ; Wed, 1 May 2002 08:14:38 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA02093 for ; Wed, 1 May 2002 09:14:36 -0600 (MDT) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA24837 for ; Wed, 1 May 2002 08:13:29 -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 IAA10182 for ; Wed, 1 May 2002 08:13:29 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id <2NG92MP9>; Wed, 1 May 2002 10:13:29 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'emadaq@yahoo.com'" , Singh Ajoy-ASINGH1 , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-ldowlatency-handoff s-v4-03.txt Date: Wed, 1 May 2002 10:13:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Emad, Yes, we have presented comparative data at IPCN conference. regards, ajoy -----Original Message----- From: Emad Qaddoura [mailto:emadaq@yahoo.com] Sent: Wednesday, May 01, 2002 1:14 AM To: 'Singh Ajoy-ASINGH1'; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt Singh Ajoy, Do you all have comparative data that you can publish? Thx. EQ > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] On Behalf Of Singh Ajoy-ASINGH1 > Sent: Wednesday, May 01, 2002 12:11 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-lowlatency- > handoffs-v4-03.txt > > Phil/Raj, > We have implemented low latency handoff draft. Our observation > is that fast handoff performs far better than standard > Mobile/IP. I do see value in publishing this > document as RFC. Probably it is okay to publish this as > experimental RFC if not standard track. > regards, > ajoy > > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: Tuesday, April 30, 2002 3:39 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Status of > draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt > > > In going through the last call comments on regional registrations there > were > some posts about the status of this draft and to what extent it had been > discussed in the working group. > > Raj and I had talked about it and I'd proposed that we not advance this > document > based on the perceived lack of interest in it in terms of real > implementation, in > fact to remove it completely from the WG's agenda. Since some work has > been > done > on it, perhaps the correct thing to do would be to keep it and publish it > as > an experimental RFC. I can't say that I'm in favor of the latter but > tentatively > agree to do so. When the WG started the effort there was tremendous > interest in it > but that interest has dropped nearly to zilch. If starting today it's not > clear > there is enough constituency to add it as a working group item. Hence my > preference to drop it altogether. Neither of us thought that taking it > onto > the standards track as proposed was appropriate. > > We should have kept the WG up-to-date on our thinking and appreciate > hearing > feedback on this. > > Phil From owner-mobile-ip@sunroof.eng.sun.com Wed May 1 11:42:19 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04053 for ; Wed, 1 May 2002 11:42:18 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15382; Wed, 1 May 2002 09:41:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19924; Wed, 1 May 2002 08:41:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41FeYrP009123 for ; Wed, 1 May 2002 08:40:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41FeYPN009122 for mobile-ip-dist; Wed, 1 May 2002 08:40:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41FeUrP009115 for ; Wed, 1 May 2002 08:40:31 -0700 (PDT) Received: from pheriche.sun.com ([129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19998 for ; Wed, 1 May 2002 08:40:31 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12272 for ; Wed, 1 May 2002 09:40:31 -0600 (MDT) Message-ID: <003c01c1f126$49a5d2e0$7e6015ac@T23KEMPF> From: "James Kempf" To: , "'Singh Ajoy-ASINGH1'" , References: <000601c1f0d7$67333a90$830490d9@EmadQ> Subject: Re: [mobile-ip] Status of draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt Date: Wed, 1 May 2002 08:38:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit EQ, We have a good deal of comparative data, and are attempting to get more so we can do statistics on the data to statistically verify the comparison. We had a preliminary presentation at the IPCN conference in Paris last week, and we will be looking for a good archival journal as a venue for the final report. jak ----- Original Message ----- From: "Emad Qaddoura" To: "'Singh Ajoy-ASINGH1'" ; Sent: Tuesday, April 30, 2002 11:13 PM Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt > Singh Ajoy, > > Do you all have comparative data that you can publish? > > Thx. > EQ > > > -----Original Message----- > > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > > ip@sunroof.eng.sun.com] On Behalf Of Singh Ajoy-ASINGH1 > > Sent: Wednesday, May 01, 2002 12:11 AM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: RE: [mobile-ip] Status of draft-ietf-mobileip-lowlatency- > > handoffs-v4-03.txt > > > > Phil/Raj, > > We have implemented low latency handoff draft. Our observation > > is that fast handoff performs far better than standard > > Mobile/IP. I do see value in publishing this > > document as RFC. Probably it is okay to publish this as > > experimental RFC if not standard track. > > regards, > > ajoy > > > > -----Original Message----- > > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > > Sent: Tuesday, April 30, 2002 3:39 PM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] Status of > > draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt > > > > > > In going through the last call comments on regional registrations > there > > were > > some posts about the status of this draft and to what extent it had > been > > discussed in the working group. > > > > Raj and I had talked about it and I'd proposed that we not advance > this > > document > > based on the perceived lack of interest in it in terms of real > > implementation, in > > fact to remove it completely from the WG's agenda. Since some work > has > > been > > done > > on it, perhaps the correct thing to do would be to keep it and publish > it > > as > > an experimental RFC. I can't say that I'm in favor of the latter but > > tentatively > > agree to do so. When the WG started the effort there was tremendous > > interest in it > > but that interest has dropped nearly to zilch. If starting today it's > not > > clear > > there is enough constituency to add it as a working group item. Hence > my > > preference to drop it altogether. Neither of us thought that taking > it > > onto > > the standards track as proposed was appropriate. > > > > We should have kept the WG up-to-date on our thinking and appreciate > > hearing > > feedback on this. > > > > Phil > > From owner-mobile-ip@sunroof.eng.sun.com Wed May 1 13:00:34 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08533 for ; Wed, 1 May 2002 13:00:33 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27569; Wed, 1 May 2002 10:59:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20231; Wed, 1 May 2002 09:59:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41GwOrP009314 for ; Wed, 1 May 2002 09:58:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41GwOxP009313 for mobile-ip-dist; Wed, 1 May 2002 09:58:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41GwMrP009306 for ; Wed, 1 May 2002 09:58:22 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25890 for ; Wed, 1 May 2002 12:58:23 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g41GwLqp005186 for ; Wed, 1 May 2002 12:58:21 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g41GwLvQ005185 for mobile-ip@sunroof.eng.sun.com; Wed, 1 May 2002 12:58:21 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g412dCrP007963 for ; Tue, 30 Apr 2002 19:39:12 -0700 (PDT) Received: from patan.sun.com ([129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA13473 for ; Tue, 30 Apr 2002 19:39:14 -0700 (PDT) Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA09287 for ; Tue, 30 Apr 2002 20:39:13 -0600 (MDT) Received: from CONVERSION-DAEMON by firewall.wcom.com (PMDF V5.2-33 #42260) id <0GVE00101VDCO4@firewall.wcom.com> for mobile-ip@sunroof.eng.sun.com; Wed, 1 May 2002 02:39:12 +0000 (GMT) Received: from dgismtp01.wcomnet.com ([166.38.58.141]) by firewall.wcom.com (PMDF V5.2-33 #42260) with ESMTP id <0GVE00MH3VDB14@firewall.wcom.com>; Wed, 01 May 2002 02:39:12 +0000 (GMT) Received: from dgismtp01.wcomnet.com by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0GVE00601VD9CM@dgismtp01.wcomnet.com>; Wed, 01 May 2002 02:39:11 +0000 (GMT) Received: from hsinnreich2 ([153.39.76.99]) by dgismtp01.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id <0GVE0047GVD2XY@dgismtp01.wcomnet.com>; Wed, 01 May 2002 02:39:03 +0000 (GMT) Date: Tue, 30 Apr 2002 21:39:04 -0500 From: Henry Sinnreich Subject: [mobile-ip] RE: [Sipping] SIP-AAA Requirements (fwd) In-reply-to: To: "'Rohan Mahy'" , sipping@ietf.org, mobile-ip@sunroof.eng.sun.com Cc: john.loughney@nokia.com, Gonzalo Camarillo , Pat Calhoun , Charles Perkins , "'C. de Laat'" , jrv@merit.edu Message-id: <000001c1f0b9$5cc7f9b0$634c2799@hsinnreich2> Organization: WorldCom, Inc. MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit As 3GPP, 3GPP2 and 802.11 wireless networks are poised to use both SIP and Mobile IP, one cannot help notice there seems to be a lot commonality between: 1-SIP AAA requirements http://www-nrc.nokia.com/sua/draft-loughney-sip-aaa-req-00.txt 2-3GPP Requirements on SIP http://ietf.org/internet-drafts/draft-garcia-sipping-3gpp-reqs-03.txt 3-and most of all, Mobile IP AAA Requirements, RFC 2977 ftp://ftp.isi.edu/in-notes/rfc2977.txt The mobile IP WG http://ietf.org/html.charters/mobileip-charter.html has actually covered a lot of groundwork, where it may make sense to avoid duplication, such as for example for AAA Registration Keys http://ietf.org/internet-drafts/draft-ietf-mobileip-aaa-key-09.txt Here are some striking analogies: Mobile IP SIP ================ MN-----------UA FA-----------Visited SIP Registrar AAAL/H-------SIP AAA AAAB---------Clearinghouse See the AAAarch web page http://iridal.phys.uu.nl/~aaaarch/doc10/home.html and also http://ietf.org/internet-drafts/draft-johnston-sip-osp-token-02.txt One more item that the Mobile IP WG has successfully solved is the separation of specific AAA solutions such as RADIUS, DIAMETER or XML web services from the mobile IP protocol itself. It is not for the SIPPING WG to pick winners and losers in AAA solutions and promote one or another, as has been discussed. We should try to avoid coming up with several different/incompatible infrastructures, multiple logons and general annoyance from duplication of work. Or have the IESG step in to make order. I believe the SIPPING Mobile IP and AAAarch IP folks should talk to each other during the WG discussions or maybe possibly at a Bar BOF. I have taken therefore the liberty to copy the Mobile IP and AAAarch lists. >John will also be leading discussion on this topic at the interim meeting next week. The interested Mobile IP and AAAarch people cannot attend at such short notice. Thanks, Henry Henry Sinnreich WorldCom 400 International Parkway Richardson, Texas 75081 USA > -----Original Message----- > From: sipping-admin@ietf.org [mailto:sipping-admin@ietf.org] > On Behalf Of Rohan Mahy > Sent: Tuesday, April 30, 2002 1:13 PM > To: sipping@ietf.org > Cc: john.loughney@nokia.com > Subject: [Sipping] SIP-AAA Requirements (fwd) > > > Hi, > > John Loughney has just submitted a first draft rewrite of the > SIP AAA requirements. Until it appears in the archive, you > can download it from: > http://www-nrc.nokia.com/sua/draft-loughney-sip-aaa-req-00.txt Comments are solicited on the SIPPING list only. John will also be leading discussion on this topic at the interim meeting next week. thanks, -rohan _______________________________________________ Sipping mailing list https://www1.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@cs.columbia.edu for questions on current sip Use sip@ietf.org for new developments of core SIP From owner-mobile-ip@sunroof.eng.sun.com Wed May 1 18:59:15 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16390 for ; Wed, 1 May 2002 18:59:14 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA07511; Wed, 1 May 2002 16:58:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11830; Wed, 1 May 2002 15:58:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41MvGrP010741 for ; Wed, 1 May 2002 15:57:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41MvGrH010740 for mobile-ip-dist; Wed, 1 May 2002 15:57:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41MvCrP010733 for ; Wed, 1 May 2002 15:57:12 -0700 (PDT) Received: from kathmandu.sun.com ([129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11567 for ; Wed, 1 May 2002 15:57:13 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA06916 for ; Wed, 1 May 2002 16:57:12 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 941F26A901 for ; Thu, 2 May 2002 01:57:06 +0300 (EEST) Message-ID: <3CD072F4.9090508@piuha.net> Date: Thu, 02 May 2002 01:57:56 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #18: Prefix advertisement acknowledgement Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit (Originally brought up by Robert Chalmers.) Background: A mechanisms exists in Draft 16 to distribute home network prefixes to mobile nodes. These prefixes are sent along ICMP Mobile Prefix Advertisement messages. This message can be either solicited through the ICMP Mobile Prefix Solicitation message, or it can be unsolicited when the prefixes change. Section 9.9.3 says the following: The advertisement MUST include a Binding Request destination option if this is the first advertisement for a home registration, or if there was a change in prefix information since the last acknowledged advertisement was sent to the mobile node for the home registration. The Binding Request destination option MUST include a Unique Identifier Sub-Option (Section 5.5), with the unique identifier in the sub-option data set to a value different than that in any other Binding Request sent recently by this home agent. On the receiving side of this unsolicited advertisement, Section 10.19 "Receiving Mobile Prefix Advertisements" requires the following: If the advertisement contains a Binding Request option, the mobile node SHOULD return a Binding Update, which will be viewed by the home agent as an acknowledgement of the corresponding Mobile Prefix Advertisement, which it can cease transmitting. The problem with this is that the ICMP messages and BRs used to be carried in the same packet. If the MH no longer carries extra payloads, the delivery of the ICMP and the BR packets happens in different packets. This poses a problem for relying on the BR/BA as a way to acknowledge the receipt of the ICMP. Question: Is it necessary to have a reliable prefix delivery mechanism even in the unsolicited case? How can we ensure the delivery? Which of the mechanisms below should be used: (1) Ignore reliability for the unsolicited prefix advertisements. (2) Use any BU as a signal to stop sending the unsolicited advert. The lifetime limit (as discussed above) will force the BCE within the appropriate lifetime of existing prefixes. If the prefix has expired, a particular error code could indicate the problem which would cause the MN to solicit and advert and possibly form a new HoA. (3) Rely on the acknowledgment via BR/BA, even if these are carried in a different packet than that for the prefix advertisement. (4) Require the mobile node to make a solicited prefix query as a form of acknowledgement. (5) Add a separate ICMP message type for acknowledgement. (6) Add a separate Mobility Option to the BA message to acknowledge the receipt of a prefix advertisement. This may also require adding an identifier to the advertisement to be able to match advertisements and acknowledgements. (7) Use a non-final MH for the BR message so that the ICMP can also be carried in the same packet. (8) Convert ICMP messages to MH messages. Then, the Mobile Prefix Advert could contain a Unique ID parameter. The BU would act as an ack. Proposal: No proposal yet. From owner-mobile-ip@sunroof.eng.sun.com Wed May 1 19:00:58 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16693 for ; Wed, 1 May 2002 19:00:57 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12274; Wed, 1 May 2002 15:58:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11833; Wed, 1 May 2002 15:58:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41Mv5rP010731 for ; Wed, 1 May 2002 15:57:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g41Mv5vg010730 for mobile-ip-dist; Wed, 1 May 2002 15:57:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g41Mv2rP010723 for ; Wed, 1 May 2002 15:57:02 -0700 (PDT) Received: from pheriche.sun.com ([129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27935 for ; Wed, 1 May 2002 15:57:03 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA28352 for ; Wed, 1 May 2002 16:57:01 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2EA676A901 for ; Thu, 2 May 2002 01:56:54 +0300 (EEST) Message-ID: <3CD072E8.3050000@piuha.net> Date: Thu, 02 May 2002 01:57:44 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #7: MH format Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Background: The new Mobility Header messages need to fullfil a number of requirements, including proper alignment, ability to be extended later, compact form to preserve bandwidth on constrained wireless links, and so on. Question: Are these formats good? Proposal: See formats below. Text: MH: (8n) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Payload Proto | Header Len | MH Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . Message Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BR: (8n) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HOTI: (8n) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ COTI: (8n) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HOT: (8n) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Nonce Index | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Home Cookie (128 bits) | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ COT: (8n) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Nonce Index | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mobile cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Care-of Cookie (128 bits) | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BU: (8n) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|S|D| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (This would typically have a Nonce Indices and an Authorization Data mobility options following it. Nonce Indices can go in right after home address since it is 2n. It is 6 bytes long, so the alignment after that is 8n+6, which enables us to fit in Authorization Data immediately (4n+2). It may or may not be necessary to add a Mobile cookie in this message. The alternative is to rely on Sequence #.) BA: (8n) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (This may or may not be followed by an authorization data mobility option, depending on resolution to issue #3. If it is necessary, then between the Refresh field and the option there would have to be 2 bytes of padding. It may or may not be necessary to add a Mobile cookie in this message. The alternative is to rely on Sequence #.) BM: (8n) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (The status field can be used to tell if there's a missing binding or an unrecognized MH Type field - ICMP Parameter Problem pointers to packet contents are typically not used for actual behaviour.) Mobility option: (-) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Option Type | Option Len | Option Data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Pad1: (-) 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+ PadN: (-) 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 1 | Option Len | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Unique Identifier: (2n) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | 4 | Unique Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Alternate Care-of Address: (8n+6) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Alternate Care-of Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nonce indices: (2n) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Nonce Index | Care-of Nonce Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authorization Data: (4n+2) 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 5 | 18 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | Authenticator | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (The alignment is 4, not 8. Authenticator is 96 bits or 12 bytes.) From owner-mobile-ip@sunroof.eng.sun.com Wed May 1 22:29:29 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17223 for ; Wed, 1 May 2002 22:29:28 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA25245; Wed, 1 May 2002 20:29:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01653; Wed, 1 May 2002 19:28:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g422SFrP011177 for ; Wed, 1 May 2002 19:28:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g422SEGI011176 for mobile-ip-dist; Wed, 1 May 2002 19:28:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.85.105] (may be forged)) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g422SBrP011169 for ; Wed, 1 May 2002 19:28:11 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with SMTP id g422SCJe025111; Wed, 1 May 2002 19:28:12 -0700 (PDT) Message-Id: <200205020228.g422SCJe025111@jurassic.eng.sun.com> Date: Wed, 1 May 2002 19:30:33 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Unresolved issue #18: Prefix advertisement acknowledgement To: jari.arkko@piuha.net Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LP11+JJ8QC1CD5CqFAQltw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > The problem with this is that the ICMP messages and BRs used to be > carried in the same packet. If the MH no longer carries extra > payloads, the delivery of the ICMP and the BR packets happens in > different packets. This poses a problem for relying on the BR/BA as a > way to acknowledge the receipt of the ICMP. > > Question: Is it necessary to have a reliable prefix delivery mechanism > even in the unsolicited case? How can we ensure the delivery? Which of > the mechanisms below should be used: > > (1) Ignore reliability for the unsolicited prefix advertisements. > (2) Use any BU as a signal to stop sending the unsolicited advert. The > lifetime limit (as discussed above) will force the BCE within the > appropriate lifetime of existing prefixes. If the prefix has > expired, a particular error code could indicate the problem which > would cause the MN to solicit and advert and possibly form a new > HoA. I am not sure I understand the sequence of events in this case. Does it mean: 1. MN receives unsolicited prefix adv. 2. MN sends a BU anyway to stop further prefix adv (uses existing HOA ?) if the prefix information changes (renumbering), MN configures new HOA, continues communication until the valid prefix lifetime, after that it solicits prefix adv and subsequently sends BU with new HOA after receiving adv. If there is no prefix change, MN just updates the prefix lifetime information. Should the HA expect a BU at this point ? If HA expects BU as ACK only when prefix changes, then we can avoid extra signalling most of the time. I am not sure which error code is being mentioned here - is it something locally generated at MN ? Can we make security association mandatory for unsolicited unicast prefix advertisement for reliability ? choice (2), does not require BR/BU sequence for prefix delivery. I wonder whether we need unique identifier parameter at all then ? > (3) Rely on the acknowledgment via BR/BA, even if these are carried > in a different packet than that for the prefix advertisement. This option seems ok too, but somehow MN needs to match up the last prefix adv with the BR. It seems choice (2) is simpler. > (4) Require the mobile node to make a solicited prefix query > as a form of acknowledgement. > (5) Add a separate ICMP message type for acknowledgement. > (6) Add a separate Mobility Option to the BA message to acknowledge > the receipt of a prefix advertisement. This may also require > adding an identifier to the advertisement to be able to match > advertisements and acknowledgements. > (7) Use a non-final MH for the BR message so that the ICMP > can also be carried in the same packet. > (8) Convert ICMP messages to MH messages. Then, the Mobile Prefix Advert > could contain a Unique ID parameter. The BU would act as an ack. > > Proposal: No proposal yet. > -Samita From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 00:19:03 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01171 for ; Thu, 2 May 2002 00:19:02 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA08421; Wed, 1 May 2002 22:18:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03712; Wed, 1 May 2002 21:18:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g424HOrP011364 for ; Wed, 1 May 2002 21:17:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g424HNpq011363 for mobile-ip-dist; Wed, 1 May 2002 21:17:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g424HKrP011356 for ; Wed, 1 May 2002 21:17:20 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03498 for ; Wed, 1 May 2002 21:17:20 -0700 (PDT) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA23282 for ; Wed, 1 May 2002 21:17:19 -0700 (PDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g424HbF13011 for ; Thu, 2 May 2002 07:17:37 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 2 May 2002 07:17:18 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 2 May 2002 07:17:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] RE: [Sipping] SIP-AAA Requirements (fwd) Date: Thu, 2 May 2002 07:17:16 +0300 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38DD5@esebe004.NOE.Nokia.com> Thread-Topic: [Sipping] SIP-AAA Requirements (fwd) Thread-Index: AcHwutb8c20+wH4YQAC1a+CCCxoVMgA1GLZA To: , , , Cc: , , , , X-OriginalArrivalTime: 02 May 2002 04:17:17.0967 (UTC) FILETIME=[3F1F11F0:01C1F190] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g424HLrP011357 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Henry, > As 3GPP, 3GPP2 and 802.11 wireless networks are poised to use both SIP > and Mobile IP, one cannot help notice there seems to be a lot > commonality between: > > 1-SIP AAA requirements > http://www-nrc.nokia.com/sua/draft-loughney-sip-aaa-req-00.txt > > 2-3GPP Requirements on SIP > http://ietf.org/internet-drafts/draft-garcia-sipping-3gpp-reqs-03.txt > > 3-and most of all, Mobile IP AAA Requirements, RFC 2977 > ftp://ftp.isi.edu/in-notes/rfc2977.txt > > The mobile IP WG > http://ietf.org/html.charters/mobileip-charter.html has > actually covered a lot of groundwork, where it may make sense to avoid > duplication, such as for example for AAA Registration Keys > http://ietf.org/internet-drafts/draft-ietf-mobileip-aaa-key-09.txt My comment would be that perhaps there are not many ways to skin a cat. > One more item that the Mobile IP WG has successfully solved is the > separation of specific AAA solutions such as RADIUS, DIAMETER or XML web > services from the mobile IP protocol itself. It is not for the SIPPING > WG to pick winners and losers in AAA solutions and promote one or > another, as has been discussed. Yes, that is why I was asked to work on the requirements, coming from the AAA WG. What is needed from SIPPING is to see what needs SIP has, and I would appreciate feedback related to this. From the AAA WG view point (& IESG viewpoint, I believe) is that RADIUS is not sufficient and there are well know deficiencies with RADIUS that make further deployment problematic. The ongoing Diameter work is attempting to make AAA work for the Internet, which SIP is part of. > We should try to avoid coming up with several different/incompatible > infrastructures, multiple logons and general annoyance from > duplication of work. Or have the IESG step in to make order. This is very important. This is part of the exersize with regards to SIP - we need to make sure the real requirements of SIP are covered. > I believe the SIPPING Mobile IP and AAAarch IP folks should talk to each > other during the WG discussions or maybe possibly at a Bar BOF. I have > taken therefore the liberty to copy the Mobile IP and AAAarch lists. I think that solutions for SIP-AAA need not overlap, but be re-used. If one solution can fufill 2 requirements, that solution seems quite ideal, IMO. Anyhow, I think the more immediate need would be to generate some discussion on the draft, and see what has been left out. thanks, John From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 02:20:38 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21902 for ; Thu, 2 May 2002 02:20:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08105; Thu, 2 May 2002 00:20:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA27511; Wed, 1 May 2002 23:19:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g426J5rP011498 for ; Wed, 1 May 2002 23:19:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g426J5om011497 for mobile-ip-dist; Wed, 1 May 2002 23:19:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g426J2rP011490 for ; Wed, 1 May 2002 23:19:02 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA26396 for ; Wed, 1 May 2002 23:19:00 -0700 (PDT) Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA09826 for ; Wed, 1 May 2002 23:18:59 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 2 May 2002 09:18:52 +0300 Message-ID: Thread-Topic: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security Thread-Index: AcHwSbQB9zBj+4ZiR5GSbz7UlXhKxwBVrM2Q From: "Sami Vaarala" To: =?iso-8859-1?Q?Hans_Sj=F6strand?= Cc: "Francis Dupont" , "Henrik Levkowetz" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g426J2rP011491 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hans, > [Hans wrote] >[snip] > So yes, inform people of the new threats but I don't > think we should recomend ipsec as some kind of saviour. > Because it's not. He could eavesdrop before and he > could do it now. So ipsec is > equally applicable to > pure mobile ip and has very little to do with nat > traversal extensions. And the dos case ipsec doesn't > help at all. This was exactly what I said (or what I was trying to say previously): the confidentiality problem is always there with Mobile IP. However, because the NAT traversal mechanism allows you to hijack a session *without* staying on the path permanently, the confidentiality problem thus manifests itself in more situations. IPsec may be used to address those new situations, but will be useful in general to protect confidentiality of user data traffic. Would something along these lines sound reasonable? -Sami From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 03:57:45 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29426 for ; Thu, 2 May 2002 03:57:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06388; Thu, 2 May 2002 01:57:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA26982; Thu, 2 May 2002 00:56:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g427trrP011657 for ; Thu, 2 May 2002 00:55:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g427trrH011656 for mobile-ip-dist; Thu, 2 May 2002 00:55:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g427torP011649 for ; Thu, 2 May 2002 00:55:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11194 for ; Thu, 2 May 2002 00:55:50 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05959 for ; Thu, 2 May 2002 01:55:50 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g427tns7005339 for ; Thu, 2 May 2002 09:55:49 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Thu May 02 09:55:22 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <22815D8D>; Thu, 2 May 2002 09:55:22 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: "'jari.arkko@piuha.net'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #7: MH format Date: Thu, 2 May 2002 09:50:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Jari, > Question: Are these formats good? > > Proposal: See formats below. > > Text: > > MH: (8n) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Payload Proto | Header Len | MH Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Checksum | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > | | > . . > . Message Data . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > BU: (8n) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A|H|S|D| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Home Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > (This would typically have a Nonce Indices and an Authorization > Data mobility options following it. Nonce Indices can go in > right after home address since it is 2n. It is 6 bytes long, so > the alignment after that is 8n+6, which enables us to fit in > Authorization Data immediately (4n+2). > > It may or may not be necessary to add a Mobile cookie in this > message. The alternative is to rely on Sequence #.) It is still not really clear to me why you need the HoA inside the BU ?! In BU's sent to HA protected by IPSEC, the HoA needs to be present in the HAO anyway, and then couldn't the IPSEC SA check authenticate the HoA ? In BU's sent to HA protected by some other means, e.g., some authentication data, couldn't the HoA still be placed in a HAO and then be authenticated via the BU validation ? The same goes for BU's sent to a CN as the result of an RR exchange couldn't the HoA be placed in the HAO and be authenticated via the BU validation ? Wrt the latter (RR BU's), I am not really up to date, if this is totally out of line with the RR mechs then please ignore. Karen From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 04:15:21 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00223 for ; Thu, 2 May 2002 04:15:21 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08430; Thu, 2 May 2002 02:14:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA00817; Thu, 2 May 2002 01:14:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g428DJrP011758 for ; Thu, 2 May 2002 01:13:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g428DJTS011757 for mobile-ip-dist; Thu, 2 May 2002 01:13:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g428DGrP011750 for ; Thu, 2 May 2002 01:13:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14681 for ; Thu, 2 May 2002 01:13:17 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00484 for ; Thu, 2 May 2002 02:13:17 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g428CPB08090; Thu, 2 May 2002 10:12:25 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA12398; Thu, 2 May 2002 10:12:25 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g428COT06900; Thu, 2 May 2002 10:12:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205020812.g428COT06900@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #18: Prefix advertisement acknowledgement In-reply-to: Your message of Thu, 02 May 2002 01:57:56 +0300. <3CD072F4.9090508@piuha.net> Date: Thu, 02 May 2002 10:12:24 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I believe the prefix advertisement stuff which is complex, not yet useful, etc, should be moved to another document. The current I-D is already far too long! Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 04:19:56 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00494 for ; Thu, 2 May 2002 04:19:55 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19795; Thu, 2 May 2002 01:17:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01401; Thu, 2 May 2002 01:17:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g428GUrP011815 for ; Thu, 2 May 2002 01:16:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g428GU33011814 for mobile-ip-dist; Thu, 2 May 2002 01:16:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g428GRrP011807 for ; Thu, 2 May 2002 01:16:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01181 for ; Thu, 2 May 2002 01:16:28 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA09953 for ; Thu, 2 May 2002 02:16:23 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g428GJB09299; Thu, 2 May 2002 10:16:19 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA12502; Thu, 2 May 2002 10:16:19 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g428GIT06938; Thu, 2 May 2002 10:16:18 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205020816.g428GIT06938@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #7: MH format In-reply-to: Your message of Thu, 02 May 2002 01:57:44 +0300. <3CD072E8.3050000@piuha.net> Date: Thu, 02 May 2002 10:16:18 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Background: The new Mobility Header messages need to fullfil a number of requirements, including proper alignment, ability to be extended later, compact form to preserve bandwidth on constrained wireless links, and so on. Question: Are these formats good? => I don't know if the checksum (does it cover a pseudo-header ?) is useful because there is already an integrity protection (by the authorization data or another mechanism). This will make the common header 32 bit aligned... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 04:23:00 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00791 for ; Thu, 2 May 2002 04:22:59 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA20956; Thu, 2 May 2002 01:20:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02598; Thu, 2 May 2002 01:20:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g428KArP011880 for ; Thu, 2 May 2002 01:20:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g428K9Og011879 for mobile-ip-dist; Thu, 2 May 2002 01:20:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g428K6rP011872 for ; Thu, 2 May 2002 01:20:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23860 for ; Thu, 2 May 2002 01:20:07 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11439 for ; Thu, 2 May 2002 02:20:06 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g428JNB09863; Thu, 2 May 2002 10:19:27 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA12550; Thu, 2 May 2002 10:19:23 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g428JJT06956; Thu, 2 May 2002 10:19:19 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205020819.g428JJT06956@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Sami Vaarala" cc: =?iso-8859-1?Q?Hans_Sj=F6strand?= , "Henrik Levkowetz" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security In-reply-to: Your message of Thu, 02 May 2002 09:18:52 +0300. Date: Thu, 02 May 2002 10:19:19 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: This was exactly what I said (or what I was trying to say previously): the confidentiality problem is always there with Mobile IP. However, because the NAT traversal mechanism allows you to hijack a session *without* staying on the path permanently, the confidentiality problem thus manifests itself in more situations. IPsec may be used to address those new situations, but will be useful in general to protect confidentiality of user data traffic. Would something along these lines sound reasonable? => we seems to be near perfectly in phase... Can someone propose a statement to add in the security considerations? Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 04:32:27 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01368 for ; Thu, 2 May 2002 04:32:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24500; Thu, 2 May 2002 01:30:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03981; Thu, 2 May 2002 01:30:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g428TLrP011964 for ; Thu, 2 May 2002 01:29:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g428TLr2011963 for mobile-ip-dist; Thu, 2 May 2002 01:29:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g428TIrP011956 for ; Thu, 2 May 2002 01:29:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA25775 for ; Thu, 2 May 2002 01:29:19 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13327 for ; Thu, 2 May 2002 01:29:18 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g428TEB11800; Thu, 2 May 2002 10:29:14 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA12761; Thu, 2 May 2002 10:29:14 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g428TET07026; Thu, 2 May 2002 10:29:14 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205020829.g428TET07026@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Karen E Nielsen (TED)" cc: "'jari.arkko@piuha.net'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #7: MH format In-reply-to: Your message of Thu, 02 May 2002 09:50:44 +0200. Date: Thu, 02 May 2002 10:29:14 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: It is still not really clear to me why you need the HoA inside the BU ?! => in order to protect it in any case. In BU's sent to HA protected by IPSEC, the HoA needs to be present in the HAO anyway, and then couldn't the IPSEC SA check authenticate the HoA ? => this is *not* true: if the IPsec transform is not AH, the HAO is not covered by the integrity check and it is authenticated only by the SA lookup (i.e. not by the crypto, only by (reusing Mike Thomas' words) an access-list mechanism). In BU's sent to HA protected by some other means, e.g., some authentication data, couldn't the HoA still be placed in a HAO and then be authenticated via the BU validation ? [...] => same answer: to put the HA in the BU just makes things simpler (and security things must be simple in order to be secure). Another argument is to make the BU self-sufficient ables non-standard way to transport the BU (piggy-backing into an AAA AVP for instance). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 04:42:46 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01962 for ; Thu, 2 May 2002 04:42:45 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22997; Thu, 2 May 2002 02:42:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA28630; Thu, 2 May 2002 01:42:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g428fSrP012034 for ; Thu, 2 May 2002 01:41:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g428fSoT012033 for mobile-ip-dist; Thu, 2 May 2002 01:41:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g428fPrP012026 for ; Thu, 2 May 2002 01:41:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19366 for ; Thu, 2 May 2002 01:41:26 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10977 for ; Thu, 2 May 2002 02:41:26 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g428fOs7002645 for ; Thu, 2 May 2002 10:41:24 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu May 02 10:41:23 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 10:41:23 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: "'Francis Dupont'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #7: MH format Date: Thu, 2 May 2002 10:36:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Francis, > In your previous mail you wrote: > > It is still not really clear to me why you need the HoA > inside the BU ?! > > => in order to protect it in any case. > > In BU's sent to HA protected by IPSEC, the HoA needs to be present > in the HAO anyway, and then couldn't the IPSEC SA check > authenticate > the HoA ? > > => this is *not* true: if the IPsec transform is not AH, the > HAO is not > covered by the integrity check and it is authenticated only by the SA > lookup (i.e. not by the crypto, only by (reusing Mike Thomas' words) > an access-list mechanism). > An why is it that this (SA lookup) isn't good enough ? If the HoA in HAO has been changed, the packet will not match the SA lookup and will be discarded and we're happy - or ?? > In BU's sent to HA protected by some other means, e.g., some > authentication data, couldn't the HoA still be placed in a HAO and > then be authenticated via the BU validation ? > [...] > > => same answer: to put the HA in the BU just makes things simpler > (and security things must be simple in order to be secure). > Another argument is to make the BU self-sufficient ables non-standard > way to transport the BU (piggy-backing into an AAA AVP for instance). In such special cases (ala piggy-backing into an AAA AVP for instance). the HoA could be inserted as an option in the BU. This should not be the (only) argument for mandating its presence in ALL BU's - Or.. BR, Karen From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 05:14:57 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03250 for ; Thu, 2 May 2002 05:14:57 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA05080; Thu, 2 May 2002 03:14:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09817; Thu, 2 May 2002 02:14:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g429DMrP012146 for ; Thu, 2 May 2002 02:13:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g429DMQ4012145 for mobile-ip-dist; Thu, 2 May 2002 02:13:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g429DJrP012138 for ; Thu, 2 May 2002 02:13:19 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09788 for ; Thu, 2 May 2002 02:13:21 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01828 for ; Thu, 2 May 2002 02:13:20 -0700 (PDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id AC2B26A901; Thu, 2 May 2002 12:13:13 +0300 (EEST) Message-ID: <3CD1035B.7060908@piuha.net> Date: Thu, 02 May 2002 12:14:03 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #7: MH format References: <200205020816.g428GIT06938@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > => I don't know if the checksum (does it cover a pseudo-header ?) It does cover a pseudo-header as well. > is > useful because there is already an integrity protection (by the > authorization data or another mechanism). This will make the common > header 32 bit aligned... Yes, but not all MH messages are covered, at least directly, by the authorization data. For instance, Binding Missing is never covered, and [HC]oT{,I} are covered only indirecly after several messages have been exchanged. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 05:33:10 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04210 for ; Thu, 2 May 2002 05:33:10 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11357; Thu, 2 May 2002 03:32:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12301; Thu, 2 May 2002 02:32:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g429VhrP012240 for ; Thu, 2 May 2002 02:31:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g429VhMj012239 for mobile-ip-dist; Thu, 2 May 2002 02:31:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g429VerP012232 for ; Thu, 2 May 2002 02:31:40 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12181 for ; Thu, 2 May 2002 02:31:41 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07108 for ; Thu, 2 May 2002 03:31:40 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g429VZB23603; Thu, 2 May 2002 11:31:35 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA13780; Thu, 2 May 2002 11:31:35 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g429VZT07271; Thu, 2 May 2002 11:31:35 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205020931.g429VZT07271@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Karen E Nielsen (TED)" cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #7: MH format In-reply-to: Your message of Thu, 02 May 2002 10:36:46 +0200. Date: Thu, 02 May 2002 11:31:35 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => this is *not* true: if the IPsec transform is not AH, the > HAO is not > covered by the integrity check and it is authenticated only by the SA > lookup (i.e. not by the crypto, only by (reusing Mike Thomas' words) > an access-list mechanism). An why is it that this (SA lookup) isn't good enough ? => an access-list like check is far weaker than a crypto-based integrity and authentication check, and IMHO too weak (i.e. not good enough). If the HoA in HAO has been changed, the packet will not match the SA lookup and will be discarded and we're happy - or ?? => it is ridiculous to rely on this when a crypto-based check is available. IMHO to make the HoA optional is a poor design decision, and I am happy it is *not* optional. > => same answer: to put the HoA in the BU just makes things simpler > (and security things must be simple in order to be secure). > Another argument is to make the BU self-sufficient ables non-standard > way to transport the BU (piggy-backing into an AAA AVP for instance). In such special cases (ala piggy-backing into an AAA AVP for instance). the HoA could be inserted as an option in the BU. => I've already given my opinion about optional HoA. This should not be the (only) argument for mandating its presence in ALL BU's - Or.. => this is not the only argument, just a fine side-effect... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 05:36:42 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04480 for ; Thu, 2 May 2002 05:36:42 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02648; Thu, 2 May 2002 03:35:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12880; Thu, 2 May 2002 02:35:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g429YorP012290 for ; Thu, 2 May 2002 02:34:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g429Yo8t012289 for mobile-ip-dist; Thu, 2 May 2002 02:34:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g429YlrP012282 for ; Thu, 2 May 2002 02:34:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12800 for ; Thu, 2 May 2002 02:34:49 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09380 for ; Thu, 2 May 2002 03:34:48 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g429YkB24388; Thu, 2 May 2002 11:34:46 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA13825; Thu, 2 May 2002 11:34:46 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g429YjT07296; Thu, 2 May 2002 11:34:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205020934.g429YjT07296@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #7: MH format In-reply-to: Your message of Thu, 02 May 2002 12:14:03 +0300. <3CD1035B.7060908@piuha.net> Date: Thu, 02 May 2002 11:34:45 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => I don't know if the checksum (does it cover a pseudo-header ?) It does cover a pseudo-header as well. => don't forget to specify the pseudo-header details (source address, length field), including in the case the MH is not a terminal header. Yes, but not all MH messages are covered, at least directly, by the authorization data. For instance, Binding Missing is never covered, and [HC]oT{,I} are covered only indirecly after several messages have been exchanged. => so we should keep the checksum for simplicity... Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 05:39:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04673 for ; Thu, 2 May 2002 05:39:47 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03934; Thu, 2 May 2002 03:39:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13256; Thu, 2 May 2002 02:39:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g429cUrP012352 for ; Thu, 2 May 2002 02:38:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g429cTH4012351 for mobile-ip-dist; Thu, 2 May 2002 02:38:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g429cQrP012344 for ; Thu, 2 May 2002 02:38:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27056 for ; Thu, 2 May 2002 02:38:28 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03612 for ; Thu, 2 May 2002 03:38:29 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6D5516A901; Thu, 2 May 2002 12:38:21 +0300 (EEST) Message-ID: <3CD1093F.5000802@piuha.net> Date: Thu, 02 May 2002 12:39:11 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #7: MH format References: <200205020934.g429YjT07296@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > => so we should keep the checksum for simplicity... Ok. > => don't forget to specify the pseudo-header details (source address, > length field), including in the case the MH is not a terminal header. Here's the current text. Is this good enough or is something missing? TBD is MH's protocol number. Checksum 16-bit unsigned integer. This field contains the checksum of the Mobility Header. The checksum is the 16-bit one's complement of the one's complement sum of the entire Mobility Header starting with the Payload Proto field, prepended with a "pseudo-header" of IPv6 header fields, as specified in Section 8.1 of [rfc 2460]. The Next Header value used in the pseudo-header is TBD. For computing the checksum, the checksum field is set to zero. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 05:54:57 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05679 for ; Thu, 2 May 2002 05:54:57 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18850; Thu, 2 May 2002 02:52:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA15094; Thu, 2 May 2002 02:52:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g429pprP012398 for ; Thu, 2 May 2002 02:51:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g429ppm1012397 for mobile-ip-dist; Thu, 2 May 2002 02:51:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g429plrP012390 for ; Thu, 2 May 2002 02:51:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18016 for ; Thu, 2 May 2002 02:51:49 -0700 (PDT) Received: from chardonnay.levkowetz.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15732 for ; Thu, 2 May 2002 03:51:48 -0600 (MDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.02) id GVHA24-00015W-00; Thu, 02 May 2002 11:51:40 +0200 From: "Henrik Levkowetz" To: "Francis Dupont" , "Sami Vaarala" Cc: "Hans Sjöstrand" , Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security Date: Thu, 2 May 2002 11:51:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) In-Reply-To: <200205020819.g428JJT06956@givry.rennes.enst-bretagne.fr> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis, Sami and I are doing a rewrite of parts of the security considerations along these lines. We'll have a proposal for the list in a couple of days. Regards, Henrik Francis wrote: > > This was exactly what I said (or what I was trying to > say previously): the confidentiality problem is always > there with Mobile IP. However, because the NAT traversal > mechanism allows you to hijack a session *without* staying > on the path permanently, the confidentiality problem thus > manifests itself in more situations. > > IPsec may be used to address those new situations, but > will be useful in general to protect confidentiality of > user data traffic. > > Would something along these lines sound reasonable? > > => we seems to be near perfectly in phase... Can someone > propose a statement to add in the security considerations? > > Thanks > > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 06:00:12 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06043 for ; Thu, 2 May 2002 06:00:11 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20948; Thu, 2 May 2002 02:57:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16050; Thu, 2 May 2002 02:57:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g429vNrP012479 for ; Thu, 2 May 2002 02:57:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g429vMYC012478 for mobile-ip-dist; Thu, 2 May 2002 02:57:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g429vJrP012471 for ; Thu, 2 May 2002 02:57:19 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19516 for ; Thu, 2 May 2002 02:57:21 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20706 for ; Thu, 2 May 2002 02:57:21 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g429vIB27642; Thu, 2 May 2002 11:57:18 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA14136; Thu, 2 May 2002 11:57:18 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g429vIT07413; Thu, 2 May 2002 11:57:18 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205020957.g429vIT07413@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #7: MH format In-reply-to: Your message of Thu, 02 May 2002 12:39:11 +0300. <3CD1093F.5000802@piuha.net> Date: Thu, 02 May 2002 11:57:18 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => don't forget to specify the pseudo-header details (source address, > length field), including in the case the MH is not a terminal header. Here's the current text. Is this good enough or is something missing? TBD is MH's protocol number. Checksum 16-bit unsigned integer. This field contains the checksum of the Mobility Header. The checksum is the 16-bit one's complement of the one's complement sum of the entire Mobility Header starting with the Payload Proto field, prepended with a "pseudo-header" of IPv6 header fields, as specified in Section 8.1 of [rfc 2460]. The Next Header value used in the pseudo-header is TBD. For computing the checksum, the checksum field is set to zero. => you need in all cases a reference to section 10.1 for the addresses to use (no surprise but IMHO we should be as clear as possible here). For the non-terminal version of MH you have a problem with the protocol number (just do a choice) and (more interesting) with the payload length field. So I am afraid the current text is not yet enough... Of course, I suppose you'll include draft-ietf-mobileip-piggyback-00.txt in the new draft as most of the missing details are for the non-terminal version. Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 09:49:25 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25772 for ; Thu, 2 May 2002 09:49:24 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09539; Thu, 2 May 2002 07:47:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04644; Thu, 2 May 2002 06:47:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42DkRrP012867 for ; Thu, 2 May 2002 06:46:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42DkRqu012866 for mobile-ip-dist; Thu, 2 May 2002 06:46:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42DkOrP012859 for ; Thu, 2 May 2002 06:46:24 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10057 for ; Thu, 2 May 2002 06:46:19 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16122 for ; Thu, 2 May 2002 07:46:19 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g42Dk4p6021765; Thu, 2 May 2002 06:46:04 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABO79415; Thu, 2 May 2002 06:42:56 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA25532; Thu, 2 May 2002 06:46:03 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15569.17179.696024.574295@thomasm-u1.cisco.com> Date: Thu, 2 May 2002 06:46:03 -0700 (PDT) To: "Hesham Soliman (ERA)" Cc: "'James Kempf'" , "'Rajeev Koodli'" , "'Michael Thomas'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] some questions about draft-ietf-mobileip-fast-mip v6-04 In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6ACD1@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053802C6ACD1@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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) writes: > James, > > I rather favor some mechanism to inform the MN after > the move has occured. For example, sending the MN an > ICMP REDIRECT message after the access router has changed, > as Michael has suggested, would do the trick, > as it would avoid the problem of the signaling getting cut off > prematurely. > > => A side note, this is not the way redirects are used. > If there is an indication after the MN moves, then > we should keep it simple and stick to the original > MIPv6 design. However, I agree with Rajeev's analysis > and suggestions to use the indication before movement. > Also, in the MIPv4 draft, we did add a combined method > for failure modes where the oFA sends the indication > before the MN moves, and if no registration is received > till the MN disconnects, the traffic is forwarded to > the new FA. > This is clearly valid for the case where the network > (FA) is aware of the connection/disconnection state > of the MN. So, I agree with Hesham about the way that redirects actually work. However, back to the original issue: is there a reason that we can't have the mobile node pre-approve network based moves? That would keep with the spirit of the net (host is in charge), but allow the performance gains Jim is seeking. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 09:59:40 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26809 for ; Thu, 2 May 2002 09:59:40 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07854; Thu, 2 May 2002 06:57:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06443; Thu, 2 May 2002 06:56:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42DtOrP012938 for ; Thu, 2 May 2002 06:55:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42DtOTC012936 for mobile-ip-dist; Thu, 2 May 2002 06:55:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42DtLrP012929 for ; Thu, 2 May 2002 06:55:21 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23063 for ; Thu, 2 May 2002 06:55:21 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26605 for ; Thu, 2 May 2002 07:55:20 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g42DsjpY006185; Thu, 2 May 2002 06:54:48 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABO79523; Thu, 2 May 2002 06:51:36 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA25535; Thu, 2 May 2002 06:54:43 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15569.17699.425270.384860@thomasm-u1.cisco.com> Date: Thu, 2 May 2002 06:54:43 -0700 (PDT) To: Francis Dupont Cc: "Karen E Nielsen (TED)" , "'jari.arkko@piuha.net'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #7: MH format In-Reply-To: <200205020829.g428TET07026@givry.rennes.enst-bretagne.fr> References: <200205020829.g428TET07026@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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont writes: > It is still not really clear to me why you need the HoA inside the BU ?! > > => in order to protect it in any case. > > In BU's sent to HA protected by IPSEC, the HoA needs to be present > in the HAO anyway, and then couldn't the IPSEC SA check authenticate > the HoA ? > > => this is *not* true: if the IPsec transform is not AH, the HAO is not > covered by the integrity check and it is authenticated only by the SA > lookup (i.e. not by the crypto, only by (reusing Mike Thomas' words) > an access-list mechanism). Thanks for remembering that, Francis. I had forgot! > In BU's sent to HA protected by some other means, e.g., some > authentication data, couldn't the HoA still be placed in a HAO and > then be authenticated via the BU validation ? > [...] > > => same answer: to put the HA in the BU just makes things simpler > (and security things must be simple in order to be secure). > Another argument is to make the BU self-sufficient ables non-standard > way to transport the BU (piggy-backing into an AAA AVP for instance). Yes, that's what I was also thinking. Self-contained seems a lot cleaner. Also, maybe we can turn this around: if you put the home address in the BU, is there a reason to require a HAO at all? I'm not saying make *il*legal, but just not a requirement for a naked BU. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 10:03:15 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27255 for ; Thu, 2 May 2002 10:03:15 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01112; Thu, 2 May 2002 07:01:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08208; Thu, 2 May 2002 07:00:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42DxorP012999 for ; Thu, 2 May 2002 06:59:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42DxoRg012998 for mobile-ip-dist; Thu, 2 May 2002 06:59:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42DxlrP012991 for ; Thu, 2 May 2002 06:59:47 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24051 for ; Thu, 2 May 2002 06:59:48 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00250 for ; Thu, 2 May 2002 06:59:47 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g42DxKTZ016329; Thu, 2 May 2002 06:59:20 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABO79595; Thu, 2 May 2002 06:56:11 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id GAA25538; Thu, 2 May 2002 06:59:19 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15569.17975.41320.138267@thomasm-u1.cisco.com> Date: Thu, 2 May 2002 06:59:19 -0700 (PDT) To: "Karen E Nielsen (TED)" Cc: "'Francis Dupont'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #7: MH format In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Karen E Nielsen (TED) writes: > > => this is *not* true: if the IPsec transform is not AH, the > > HAO is not > > covered by the integrity check and it is authenticated only by the SA > > lookup (i.e. not by the crypto, only by (reusing Mike Thomas' words) > > an access-list mechanism). > > > > An why is it that this (SA lookup) isn't good enough ? Karen, SA's are not looked up by source IP addresses. They only consider the SPI with the sole exception of multicast where it's SPI/DstAddr. > > => same answer: to put the HA in the BU just makes things simpler > > (and security things must be simple in order to be secure). > > Another argument is to make the BU self-sufficient ables non-standard > > way to transport the BU (piggy-backing into an AAA AVP for instance). > > In such special cases (ala piggy-backing into an AAA AVP for instance). > the HoA could be inserted as an option in the BU. This should not be > the (only) argument for mandating its presence in ALL BU's - Or.. I assume that you're concerned about bandwidth? See my question about the possibility of eliding the HAO. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 10:25:10 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29599 for ; Thu, 2 May 2002 10:25:09 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02499; Thu, 2 May 2002 08:24:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00309; Thu, 2 May 2002 07:24:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42ENerP013195 for ; Thu, 2 May 2002 07:23:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42ENeuK013194 for mobile-ip-dist; Thu, 2 May 2002 07:23:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42ENarP013187 for ; Thu, 2 May 2002 07:23:36 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00149 for ; Thu, 2 May 2002 07:23:37 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13065 for ; Thu, 2 May 2002 08:23:36 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g42ENZs7018334 for ; Thu, 2 May 2002 16:23:35 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu May 02 16:22:42 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 16:20:07 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: "'Michael Thomas'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: FW: [mobile-ip] Unresolved issue #7: MH format Date: Thu, 2 May 2002 16:20:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Mike, (Sorry for duplicate, I forgot to cc mobileip list) > Karen, > > SA's are not looked up by source IP addresses. > They only consider the SPI with the sole exception > of multicast where it's SPI/DstAddr. I know. But the IPSEC processing should include matching the packet against the SA selectors. As long as the HoA appears in the SA selector this implicitly provides integrity protection of the HoA. > > > > => same answer: to put the HA in the BU just makes things simpler > > > (and security things must be simple in order to be secure). > > > Another argument is to make the BU self-sufficient ables > non-standard > > > way to transport the BU (piggy-backing into an AAA AVP > for instance). > > > > In such special cases (ala piggy-backing into an AAA AVP > for instance). > > the HoA could be inserted as an option in the BU. This > should not be > > the (only) argument for mandating its presence in ALL BU's - Or.. > > I assume that you're concerned about bandwidth? > See my question about the possibility of eliding > the HAO. Unless you want the IPSEC SA's (and SPD's) to be anchored on the CoA you would need the HoA to be in one of the SA selector fields, or am I missing something ? Karen From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 10:51:19 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02672 for ; Thu, 2 May 2002 10:51:19 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28250; Thu, 2 May 2002 07:48:54 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06887; Thu, 2 May 2002 07:48:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42Em3rP013263 for ; Thu, 2 May 2002 07:48:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42Em3H1013262 for mobile-ip-dist; Thu, 2 May 2002 07:48:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42Em0rP013255 for ; Thu, 2 May 2002 07:48:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00570 for ; Thu, 2 May 2002 07:48:01 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17185 for ; Thu, 2 May 2002 08:48:02 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g42Elwp6021949; Thu, 2 May 2002 07:47:58 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABO80222; Thu, 2 May 2002 07:44:50 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA25550; Thu, 2 May 2002 07:47:57 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15569.20893.414037.748382@thomasm-u1.cisco.com> Date: Thu, 2 May 2002 07:47:57 -0700 (PDT) To: "Karen E Nielsen (TED)" Cc: "'Michael Thomas'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: FW: [mobile-ip] Unresolved issue #7: MH format In-Reply-To: References: X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Karen E Nielsen (TED) writes: > Hi Mike, > > (Sorry for duplicate, I forgot to cc mobileip list) > > > Karen, > > > > SA's are not looked up by source IP addresses. > > They only consider the SPI with the sole exception > > of multicast where it's SPI/DstAddr. > > I know. But the IPSEC processing should include matching > the packet against the SA selectors. As long as the HoA appears in the > SA selector this implicitly provides integrity protection of the HoA. Let me ask a very leading question: do you think that IPsec security associations which are divorced from the current topology and their routing tags (eg, ip addresses) could be an interesting property for mobility? I sure do. I believe that all you need to do affect this is to wildcard the SA ipsrc selectors on the receiving end. > > I assume that you're concerned about bandwidth? > > See my question about the possibility of eliding > > the HAO. > > Unless you want the IPSEC SA's (and SPD's) to be anchored on the CoA you would > need the HoA to be in one of the SA selector fields, or am I missing something ? Maybe. If the access control element on the receiver is permissive (eg, a valid hash is sufficient to let the packet through), it won't be anchored *anywhere*. This seems like a very interesting property to me. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 11:52:01 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08372 for ; Thu, 2 May 2002 11:51:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15168; Thu, 2 May 2002 08:49:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24301; Thu, 2 May 2002 08:49:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42FmnrP013399 for ; Thu, 2 May 2002 08:48:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42FmnIu013398 for mobile-ip-dist; Thu, 2 May 2002 08:48:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42FmkrP013391 for ; Thu, 2 May 2002 08:48:46 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23889 for ; Thu, 2 May 2002 08:48:47 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05073 for ; Thu, 2 May 2002 09:48:47 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA28829; Thu, 2 May 2002 08:48:46 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g42Fmk732525; Thu, 2 May 2002 08:48:46 -0700 X-mProtect: <200205021548> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd148Ds8; Thu, 02 May 2002 08:48:43 PDT Message-ID: <3CD15FDB.26AF6468@iprg.nokia.com> Date: Thu, 02 May 2002 08:48:43 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #7: MH format References: <3CD072E8.3050000@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Jari, couple of comments Jari Arkko wrote: > > Background: The new Mobility Header messages need to fullfil a number of > requirements, including proper alignment, ability to be extended later, > compact form to preserve bandwidth on constrained wireless links, and so on. > > Question: Are these formats good? > > Proposal: See formats below. > > > BU: (8n) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A|H|S|D| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Home Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Can we move the Home Address to a Mobility Option? It is not always going to be there (esp if you use AH for BU protection). > Authorization Data: (4n+2) > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | 5 | 18 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | Authenticator | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > (The alignment is 4, not 8. Authenticator is 96 bits or 12 bytes.) What happened to the SPI field? I dont think there was concensus on removing the SPI field. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 12:48:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13296 for ; Thu, 2 May 2002 12:48:42 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00611; Thu, 2 May 2002 10:48:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15424; Thu, 2 May 2002 09:47:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42GkprP013546 for ; Thu, 2 May 2002 09:46:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42GkpPT013545 for mobile-ip-dist; Thu, 2 May 2002 09:46:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42GkmrP013538 for ; Thu, 2 May 2002 09:46:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19475 for ; Thu, 2 May 2002 09:46:50 -0700 (PDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20360 for ; Thu, 2 May 2002 09:46:50 -0700 (PDT) Received: from cs.ucsb.edu (vail [128.111.52.30]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g42GklO27628; Thu, 2 May 2002 09:46:47 -0700 (PDT) Message-ID: <3CD16D77.A5D63FE@cs.ucsb.edu> Date: Thu, 02 May 2002 09:46:47 -0700 From: Robert Chalmers Organization: UCSB Computer Science X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Unresolved issue #7: MH format References: <3CD072E8.3050000@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Background: The new Mobility Header messages need to fullfil a number of > requirements, including proper alignment, ability to be extended later, > compact form to preserve bandwidth on constrained wireless links, and so on. > > Question: Are these formats good? > > Proposal: See formats below. > > Text: (.snip.) > BU: (8n) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |A|H|S|D| Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence # | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Home Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > (This would typically have a Nonce Indices and an Authorization > Data mobility options following it. Nonce Indices can go in > right after home address since it is 2n. It is 6 bytes long, so > the alignment after that is 8n+6, which enables us to fit in > Authorization Data immediately (4n+2). > > It may or may not be necessary to add a Mobile cookie in this > message. The alternative is to rely on Sequence #.) > > BA: (8n) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status | Reserved | Sequence # | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Refresh | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > I would keep the sequence number in the same place as it is in the BU. Also, move the status to the first byte of the message: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Refresh | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (.snip.) > BM: (8n) > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Home Address + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Status | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . . > . Mobility Options . > . . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Here, I would move the status field to the first byte of the message, and elide the last 32-bits. This will allow the option to end on an 8n boundary: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (.snip.) -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 14:06:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20711 for ; Thu, 2 May 2002 14:06:01 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16532; Thu, 2 May 2002 12:05:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02802; Thu, 2 May 2002 11:05:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42I4PrP013750 for ; Thu, 2 May 2002 11:04:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42I4PsG013749 for mobile-ip-dist; Thu, 2 May 2002 11:04:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42I4MrP013742 for ; Thu, 2 May 2002 11:04:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27319 for ; Thu, 2 May 2002 11:04:22 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15741 for ; Thu, 2 May 2002 12:04:23 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 230D36A901; Thu, 2 May 2002 21:04:15 +0300 (EEST) Message-ID: <3CD17FD1.5060308@piuha.net> Date: Thu, 02 May 2002 21:05:05 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #7: MH format References: <3CD072E8.3050000@piuha.net> <3CD15FDB.26AF6468@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Can we move the Home Address to a Mobility Option? It is not always > going to be there (esp if you use AH for BU protection). Yes. Or more exactly, it is unnecessary if AH is used. But we have an open issue I believe on whether AH or ESP should be used. Could we decided that first, and then make a decision on the HoA place. If AH is used or either AH or ESP is used => make it an option. If only ESP is used => make it a part of the message. >> Authorization Data: (4n+2) >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | 5 | 18 | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + + >> | Authenticator | >> + + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> (The alignment is 4, not 8. Authenticator is 96 bits or 12 bytes.) > > What happened to the SPI field? I dont think there was concensus > on removing the SPI field. Yes. As I recall it, there wasn't any consensus whatsoever, not on keeping it either. Keep a 16 bit SPI field? ;-) Jari From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 14:30:00 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23561 for ; Thu, 2 May 2002 14:29:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13129; Thu, 2 May 2002 12:29:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11496; Thu, 2 May 2002 11:28:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42IS4rP013840 for ; Thu, 2 May 2002 11:28:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42IS4A1013839 for mobile-ip-dist; Thu, 2 May 2002 11:28:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42IS1rP013832 for ; Thu, 2 May 2002 11:28:01 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09497 for ; Thu, 2 May 2002 11:28:02 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28190 for ; Thu, 2 May 2002 12:28:01 -0600 (MDT) Message-ID: <014e01c1f206$caec64a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Michael Thomas" , "Hesham Soliman \(ERA\)" Cc: "'Rajeev Koodli'" , "'Michael Thomas'" , References: <4DA6EA82906FD511BE2F00508BCF053802C6ACD1@Esealnt861.al.sw.ericsson.se> <15569.17179.696024.574295@thomasm-u1.cisco.com> Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04 Date: Thu, 2 May 2002 11:25:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mike, > So, I agree with Hesham about the way that > redirects actually work. However, back to the > original issue: is there a reason that we can't > have the mobile node pre-approve network based > moves? That would keep with the spirit of the net > (host is in charge), but allow the performance > gains Jim is seeking. > The question is how far in advance of the handoff is OK? From the point of view of performance (based on the experiments we've done with IS-2000 RAN, WLAN, and simulation), the fastest handover performance is if the access router is informed by the link layer which access router the mobile will move to, and the access router takes care of rearranging the routing. The link layer is in the best position to determine which new access point gives the mobile the best reception because it has the power measurements, and allowing it to make that determination and move the mobile without requiring any interaction with the IP layer is by far the fastest. Making the decision on the access router is preferable because it eliminates any over the air signaling, which can get cut off if the mobile moves prematurely. Making the decision on the mobile is OK, but signaling at the IP layer prior to handover risks having the signaling get cut off if the link layer determines the mobile must be moved quickly to maintain reception. Thus, allowing the mobile to fix things up after the handover provides more reliable performance than signaling prior to the handover. Moving backward in time, the mobile could provide some pre-approval on the access router enough prior to the handover that the actual handover sequencing was not affected. Thus, the access router could send a list of candidate access routers for the next handover, and the mobile could say which of them it liked and which it didn't. When the time comes for an actual handover, the access router (if the access router is doing the choosing) would only select from those access routers on the mobile's pre-approved list. Or the mobile would choose if the mobile is doing the choosing. The difficulty with this is that if the link layer decides at the time of handover that power conditions are best for access points associated with access router X but access router X is not on the mobile's list, either the access router must negotiate with the mobile about the ones the mobile said it didn't want, risking losing the mobile if power conditions change too rapidly for the negotiation to conclude, or the mobile will simply be dropped. Similarly, if the mobile is doing the choosing and access router X is not on its list, the mobile either better change its mind quickly or risk losing IP service. Note that this method is particularly well suited to intertechnology handover, where the mobile must be involved in the handover decision regardless of the performance implications, because only the mobile knows which interfaces it currently has active or even installed (for PCMCIA cards). Moving backward in time yet further, the mobile could, upon entry to the wireless network, delegate selection of the next access router to the network, allowing the network to provide the best performance possible, or it could indicate that it wants to have a choice. This could be accomplished by an AAA mechanism in the user profile. For example, when you sign up for network service, there is a checkbox that allows you to delegate selection of your access router to the network in return for better preformance. If you don't check the box, then you get "best effort" mobile controlled handover, but you get to choose your next access router on every handoff. Comments? jak From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 14:39:12 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24540 for ; Thu, 2 May 2002 14:39:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19240; Thu, 2 May 2002 11:37:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02413; Thu, 2 May 2002 11:36:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42IaJrP013892 for ; Thu, 2 May 2002 11:36:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42IaInx013891 for mobile-ip-dist; Thu, 2 May 2002 11:36:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42IaFrP013884 for ; Thu, 2 May 2002 11:36:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13878 for ; Thu, 2 May 2002 11:36:16 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17239 for ; Thu, 2 May 2002 12:36:15 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B79E96A901; Thu, 2 May 2002 21:36:10 +0300 (EEST) Message-ID: <3CD1874C.5060803@piuha.net> Date: Thu, 02 May 2002 21:37:00 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Robert Chalmers Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Unresolved issue #7: MH format References: <3CD072E8.3050000@piuha.net> <3CD16D77.A5D63FE@cs.ucsb.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Robert Chalmers wrote: > BA > > I would keep the sequence number in the same place as it is in the BU. > Also, move the status to the first byte of the message: Yes. > >>BM: (8n) >> > Here, I would move the status field to the first byte of the message, > and elide the last 32-bits. This will allow the option to end on an 8n > boundary: Yes. Updated issue description and formats at http://www.piuha.net/~jarkko/publications/mipv6/issues/issue7.txt Jari From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 14:50:39 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25847 for ; Thu, 2 May 2002 14:50:34 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09942; Thu, 2 May 2002 12:50:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06971; Thu, 2 May 2002 11:49:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42In6rP013936 for ; Thu, 2 May 2002 11:49:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42In6W3013935 for mobile-ip-dist; Thu, 2 May 2002 11:49:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42In2rP013928 for ; Thu, 2 May 2002 11:49:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18055 for ; Thu, 2 May 2002 11:49:03 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09305 for ; Thu, 2 May 2002 12:49:03 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA09474; Thu, 2 May 2002 11:49:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g42In2d32029; Thu, 2 May 2002 11:49:02 -0700 X-mProtect: <200205021849> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvzBUSD; Thu, 02 May 2002 11:46:34 PDT Message-ID: <3CD1898A.C54A7E76@iprg.nokia.com> Date: Thu, 02 May 2002 11:46:34 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #7: MH format References: <3CD072E8.3050000@piuha.net> <3CD15FDB.26AF6468@iprg.nokia.com> <3CD17FD1.5060308@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Vijay Devarapalli wrote: > > > Can we move the Home Address to a Mobility Option? It is not always > > going to be there (esp if you use AH for BU protection). > > Yes. Or more exactly, it is unnecessary if AH is used. But we have > an open issue I believe on whether AH or ESP should be used. Could > we decided that first, and then make a decision on the HoA place. If > AH is used or either AH or ESP is used => make it an option. If only > ESP is used => make it a part of the message. Not just AH. Any future authentication mechanism which relies on a MAC field covering the HAO. So I prefer an option for the home address. > > >> Authorization Data: (4n+2) > >> > >> 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 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | 5 | 18 | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | | > >> + + > >> | Authenticator | > >> + + > >> | | > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> > >> (The alignment is 4, not 8. Authenticator is 96 bits or 12 bytes.) > > > > What happened to the SPI field? I dont think there was concensus > > on removing the SPI field. > > Yes. As I recall it, there wasn't any consensus whatsoever, not on keeping > it either. Keep a 16 bit SPI field? ;-) I think it has to be a 32 bit SPI field. And I guess the Authenticator field has no alignment requirements. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 15:03:37 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27175 for ; Thu, 2 May 2002 15:03:36 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02341; Thu, 2 May 2002 13:02:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12473; Thu, 2 May 2002 12:02:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42J24rP014017 for ; Thu, 2 May 2002 12:02:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42J24Qf014016 for mobile-ip-dist; Thu, 2 May 2002 12:02:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42J20rP014009 for ; Thu, 2 May 2002 12:02:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12082 for ; Thu, 2 May 2002 12:02:01 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA03889 for ; Thu, 2 May 2002 13:01:58 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g42J1vs7017750 for ; Thu, 2 May 2002 21:01:57 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu May 02 21:01:57 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <22815JVT>; Thu, 2 May 2002 21:01:56 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: "'Francis Dupont'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #7: MH format Date: Thu, 2 May 2002 20:59:27 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Francis, > In your previous mail you wrote: > > > => this is *not* true: if the IPsec transform is not AH, the > > HAO is not > > covered by the integrity check and it is authenticated > only by the SA > > lookup (i.e. not by the crypto, only by (reusing Mike > Thomas' words) > > an access-list mechanism). > > An why is it that this (SA lookup) isn't good enough ? > > => an access-list like check is far weaker than a > crypto-based integrity > and authentication check, and IMHO too weak (i.e. not good enough). > If you're saying that not all IPSEC implementations perform the (in 2401 mandated) SA selector matching and that such IPSEC implementations should be allowed, i.e. do not "stretch" IPSEC to much, then I agree that crypto is needed. However, the fact remains that if the SA selector contains the HoA (which I suppose it should unless you want the SA to be shared between the receiving node and a range of (or all) hosts from which it is accepting BU's) and if the SA selector match can be relied on to be performed, then the HoA IS integrity protected and crypto doesn't buy you any extras. BR, Karen From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 15:04:33 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27260 for ; Thu, 2 May 2002 15:04:28 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15166; Thu, 2 May 2002 12:02:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12226; Thu, 2 May 2002 12:02:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42J1GrP014000 for ; Thu, 2 May 2002 12:01:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42J1Gp7013999 for mobile-ip-dist; Thu, 2 May 2002 12:01:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42J1DrP013992 for ; Thu, 2 May 2002 12:01:13 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26176 for ; Thu, 2 May 2002 12:01:14 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01439 for ; Thu, 2 May 2002 13:01:13 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g42J1Ds7017679 for ; Thu, 2 May 2002 21:01:13 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu May 02 21:01:12 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 2 May 2002 20:58:38 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: "'Francis Dupont'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #7: MH format Date: Thu, 2 May 2002 20:58:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Francis, > In your previous mail you wrote: > > > => this is *not* true: if the IPsec transform is not AH, the > > HAO is not > > covered by the integrity check and it is authenticated > only by the SA > > lookup (i.e. not by the crypto, only by (reusing Mike > Thomas' words) > > an access-list mechanism). > > An why is it that this (SA lookup) isn't good enough ? > > => an access-list like check is far weaker than a > crypto-based integrity > and authentication check, and IMHO too weak (i.e. not good enough). > If you're saying that not all IPSEC implementations perform the (in 2401 mandated) SA selector matching and that such IPSEC implementations should be allowed, i.e. do not "stretch" IPSEC to much, then I agree that crypto is needed. However, the fact remains that if the SA selector contains the HoA (which I suppose it should unless you want the SA to be shared between the receiving node and a range of (or all) hosts from which it is accepting BU's) and if the SA selector match can be relied on to be performed, then the HoA IS integrity protected and crypto doesn't buy you any extras. BR, Karen From owner-mobile-ip@sunroof.eng.sun.com Thu May 2 18:34:03 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16771 for ; Thu, 2 May 2002 18:34:03 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03247; Thu, 2 May 2002 16:33:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06003; Thu, 2 May 2002 15:33:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42MWRrP014610 for ; Thu, 2 May 2002 15:32:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g42MWQYU014609 for mobile-ip-dist; Thu, 2 May 2002 15:32:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g42MWNrP014602 for ; Thu, 2 May 2002 15:32:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12452 for ; Thu, 2 May 2002 15:32:25 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA14934 for ; Thu, 2 May 2002 16:32:23 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2FD3F6A901; Fri, 3 May 2002 01:32:16 +0300 (EEST) Message-ID: <3CD1BEA2.40801@piuha.net> Date: Fri, 03 May 2002 01:33:06 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: More comments on Draft16 -CLARIFICATION References: <200204242225.g3OMPpJe027155@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks a lot for your commens Samita! I have taken them in account now. Some further discussion below. > 1. > In the draft, we must make sure to clearly specify that reverse tunnel > is mandatory now for mobile node and home agent. I am not sure, which > section this information should go to. Yes. > 2. > Also, we have had email discussion that only HOT message is sent in > ESP tunnel mode. For symmetry, we should mandate ESP tunnel mode for > both HOT/HOTI messages between MN-HA. Yes. This is especially important given the mobile-side cookies for weak CoT/HoT authentication (prevention of random nodes from the internet spoofing these). > Also, we need to clarify in the draft that ESP tunnel mode must(?) be used > over the MN-HA tunnel for binding update signalling HOTI/HOT traffic > only. The regular data traffic through the same MN-HA tunnel may not > necessarily be protected by ESP. Yes. > 3. > section 4.5.5 > > This section should clarify whether route optimazation through binding > update to a CN is a MUST or optional. Yes. There will be a new section under chapter 7, Requirements for All IPv6 Hosts and Routers that describes this. It currently reads SHOULD be able to participate in a return routability procedure etc. > Also, for better understanding and clarification of crypto handling, > it would be very helpful if this section offers several subsections, > for example: Yes. > Should talk about how Kcn should be generated. It should talk about > the size and data type of Kcn. Yes. 20 bytes. > Cookie update > --------------- > > Whether Kcn should be updated periodically. What is the default or > recommended update mechanism ? > When Kcn value is changed, then how long should one keep the old > Kcn around in order to accept a BU which is on flight while the > Kcn got changed. Yes. > Nonce generation procedure > ----------------------------- > > Nonce index is a 16 bit quantity. So what would be the default > recommendation for sequence of index values for which the cookie > would be valid ? Should it correspond to COOKIE_MIN_LIFETIME ? There is no default recommendation. The index values can't be used to infer anything. The mobile should expect to get a cookie that is valid at least COOKIE_MIN_LIFETIME seconds. I'll try to clarify this. > What is data type and size of Nj ? Yes. 16 bytes. > I understand that Nj == j is acceptable, because Nj is locally > known to CN, do we need to document that ? I believe this was already described in the explanation for the CoT message in the flow of 4.5.5. > A calculation or relationship between COOKIE LIFETIME and > nonce-index and nonce generation method would be useful for > implementors to maintain interoperability. Can you clarify what you would like to see? > Nonce update > ------------ > How j values and Nj values should be stored and updated in the > system ? Yes, will be clarified. > RR signaling procedure > ---------------------- > > The current 7 steps could be re-written in such a way which can > clearly specify the sequence and parallel steps and which of > them going via HA and which of them are not. BU messge does not > go via HA-right ? It should clarify that here. A diagram may be > useful. Yes. > Each HOTI/COTI/HOT/COT/BA/BU/BR messages should specify the source > and destination address of the packet. Whether it's tunneled or > not. If tunneled if there is any security protocol to be used. > It should also specify data type and size of K0, K1 and how they > should be formed in terms of implementation. Each item should > also refer to the Message Authentication section below. Yes. Will do... > Message Authentication > ---------------------- > This section should specify the HMAC-SHA1 and how it could be > used. It should specify how the output value of HMAC-SHA1 be > considered for K0 or K1 (96bit value). What is the input value > size of HMAC_SHA1 function here ? > > It's confusing whether MAC-Kcn is meant to use HMAC-SHA1 with key > Kcn, please clarify the notation. Yes it is. Will be clarified. > Hash Function > --------------- > Should talk about the recommended hash function to compute Kbu. Now it does. > section 5.1.8 BA messages > > I understand that Alt COA and Unique identifier parameters are > optional. Should not we have a BA status value when these parameters > are not supported ? > i,e > > 146 > > Parameter type not supported I believe their use is optional, not support? Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 3 03:54:55 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06679 for ; Fri, 3 May 2002 03:54:55 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18987; Fri, 3 May 2002 01:54:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA07361; Fri, 3 May 2002 00:54:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g437qvrP015293 for ; Fri, 3 May 2002 00:52:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g437qvh3015292 for mobile-ip-dist; Fri, 3 May 2002 00:52:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g437qrrP015285 for ; Fri, 3 May 2002 00:52:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA07261 for ; Fri, 3 May 2002 00:52:54 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02446 for ; Fri, 3 May 2002 01:52:52 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g437qhb16130; Fri, 3 May 2002 09:52:43 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA25256; Fri, 3 May 2002 09:52:43 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g437qhT10582; Fri, 3 May 2002 09:52:43 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205030752.g437qhT10582@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Karen E Nielsen (TED)" cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #7: MH format In-reply-to: Your message of Thu, 02 May 2002 20:58:51 +0200. Date: Fri, 03 May 2002 09:52:43 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => an access-list like check is far weaker than a > crypto-based integrity > and authentication check, and IMHO too weak (i.e. not good enough). > If you're saying that not all IPSEC implementations perform the (in 2401 mandated) SA selector matching => SADB (and SPD) selectors are not always addresses. and that such IPSEC implementations should be allowed, i.e. do not "stretch" IPSEC to much, then I agree that crypto is needed. => you have Mike Thomas' messages about this... However, the fact remains that if the SA selector contains the HoA (which I suppose it should unless you want the SA to be shared between the receiving node and a range of (or all) hosts from which it is accepting BU's) and if the SA selector match can be relied on to be performed, then the HoA IS integrity protected and crypto doesn't buy you any extras. => same answer... Your argument seems that firewalls and IPsec give the same level of security and I (and many others) disagree. AH will be deprecated in IPsec v3 (cf last IETF meeting), HAO is not always present, etc, so I believe to make the HoA optional is not a good choice (i.e. it is too soon for space optimization of mobility signaling). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri May 3 15:29:43 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25993 for ; Fri, 3 May 2002 15:29:38 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00117; Fri, 3 May 2002 12:27:21 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02401; Fri, 3 May 2002 12:27:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43JQNrP016505 for ; Fri, 3 May 2002 12:26:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g43JQNpO016504 for mobile-ip-dist; Fri, 3 May 2002 12:26:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43JQKrP016497 for ; Fri, 3 May 2002 12:26:20 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11839 for ; Fri, 3 May 2002 12:26:21 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09165 for ; Fri, 3 May 2002 13:26:20 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0BEE86A901 for ; Fri, 3 May 2002 22:26:14 +0300 (EEST) Message-ID: <3CD2E489.9060505@piuha.net> Date: Fri, 03 May 2002 22:27:05 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #4: BM authentication Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Background: The Binding Missing message is used in Mobile IPv6 to tell Content-Transfer-Encoding: 7bit the mobile node that the correspondent node does not have a binding. This message is sent when the mobile node sends route optimized traffic directly to the correspondent node and the correspondent node has e.g. rebooted recently. It is also the intention to use the Binding Missing message (we may have to rename it) to indicate that an unrecognized MH Type field was seen in a message. In the current specification, Binding Missing is not authenticated. Therefore, it can be sent by anyone in the Internet, in particular if the sender is not restricted by ingress filtering. The only requirement is that the attacker must know the care-of address the mobile node is currently at. Of course, if the mobile node implementation has some information from e.g. TCP layer that packets are getting through, it may choose to ignore bogus BM messages. But such information is not always available. Question: Does the BM message need authentication? Can we authenticate it? How? Given that the BM message is sent e.g. after a reboot of the correspondent node, it is impossible to use any previous RR-generated keying material to authenticate the BM. The other alternatives for authentication are as follows: 1) No authentication needed. 2) After receiving the BM, the mobile node would not believe this message until it has sent a new request to the correspondent node and gotten the same answer about the existence of the binding (or MH Type). This new request would be sent with a cookie, and the reply would have the same cookie. 3) Charlie's method: in the BM, return a hash of the offending packet. 4) A variant of 3 where the correspondent node MUST produce the hash, but the mobile node MAY (not MUST) use this information, if it happens to remember hashes of previous packets. Proposal: The problem with approach 2 is that one roundtrip is spent before the BM can be acted upon. The same roundtrip could be better spent by performing the return routability procedure. Approach 3 is a smart idea, and much better than approach 2 since no additional roundtrips are needed. But it does require the mobile node to keep a hashes of few recent packets (or start keeping hashes after one BM has been received). Essentially the question boils down to a requirement issue, how much do we care about random attackers in the Internet sending BMs to mobile nodes? Is it worth the trouble, given that the attacker still has to learn the care-of address? It also seems that nodes who really care about this problem could use cross-layer information as well. Other nodes will potentially suffer by having to revert back to bidirectional routing, unnecessarily. The recommendation is that BM messages be sent without any authentication. We're pretty neutral about the solution, however and comments are solicited. From owner-mobile-ip@sunroof.eng.sun.com Fri May 3 15:33:13 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26182 for ; Fri, 3 May 2002 15:33:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03289; Fri, 3 May 2002 12:31:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03482; Fri, 3 May 2002 12:30:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43JUBrP016573 for ; Fri, 3 May 2002 12:30:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g43JUAWv016572 for mobile-ip-dist; Fri, 3 May 2002 12:30:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43JU7rP016565 for ; Fri, 3 May 2002 12:30:07 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03327 for ; Fri, 3 May 2002 12:30:06 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10984 for ; Fri, 3 May 2002 13:30:06 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 55EC66A901 for ; Fri, 3 May 2002 22:30:05 +0300 (EEST) Message-ID: <3CD2E570.3080907@piuha.net> Date: Fri, 03 May 2002 22:30:56 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #4: BM authentication References: <3CD2E489.9060505@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Uh, some missing text in the beginning. Here's a retry: Background: The Binding Missing message is used in Mobile IPv6 to tell the mobile node that the correspondent node does not have a binding. This message is sent when the mobile node sends route optimized traffic directly to the correspondent node and the correspondent node has e.g. rebooted recently. It is also the intention to use the Binding Missing message (we may have to rename it) to indicate that an unrecognized MH Type field was seen in a message. In the current specification, Binding Missing is not authenticated. Therefore, it can be sent by anyone in the Internet, in particular if the sender is not restricted by ingress filtering. The only requirement is that the attacker must know the care-of address the mobile node is currently at. Of course, if the mobile node implementation has some information from e.g. TCP layer that packets are getting through, it may choose to ignore bogus BM messages. But such information is not always available. Question: Does the BM message need authentication? Can we authenticate it? How? Given that the BM message is sent e.g. after a reboot of the correspondent node, it is impossible to use any previous RR-generated keying material to authenticate the BM. The other alternatives for authentication are as follows: 1) No authentication needed. 2) After receiving the BM, the mobile node would not believe this message until it has sent a new request to the correspondent node and gotten the same answer about the existence of the binding (or MH Type). This new request would be sent with a cookie, and the reply would have the same cookie. 3) Charlie's method: in the BM, return a hash of the offending packet. 4) A variant of 3 where the correspondent node MUST produce the hash, but the mobile node MAY (not MUST) use this information, if it happens to remember hashes of previous packets. Proposal: The problem with approach 2 is that one roundtrip is spent before the BM can be acted upon. The same roundtrip could be better spent by performing the return routability procedure. Approach 3 is a smart idea, and much better than approach 2 since no additional roundtrips are needed. But it does require the mobile node to keep a hashes of few recent packets (or start keeping hashes after one BM has been received). Essentially the question boils down to a requirement issue, how much do we care about random attackers in the Internet sending BMs to mobile nodes? Is it worth the trouble, given that the attacker still has to learn the care-of address? It also seems that nodes who really care about this problem could use cross-layer information as well. Other nodes will potentially suffer by having to revert back to bidirectional routing, unnecessarily. The recommendation is that BM messages be sent without any authentication. We're pretty neutral about the solution, however and comments are solicited. From owner-mobile-ip@sunroof.eng.sun.com Fri May 3 18:05:38 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01978 for ; Fri, 3 May 2002 18:05:37 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21093; Fri, 3 May 2002 15:03:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15317; Fri, 3 May 2002 15:03:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43M2SrP016759 for ; Fri, 3 May 2002 15:02:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g43M2R03016758 for mobile-ip-dist; Fri, 3 May 2002 15:02:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43M2OrP016751 for ; Fri, 3 May 2002 15:02:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14871 for ; Fri, 3 May 2002 15:02:25 -0700 (PDT) Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id QAA09934 for ; Fri, 3 May 2002 16:02:24 -0600 (MDT) Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 May 2002 22:02:23 -0000 Message-Id: <5.0.0.25.2.20020503180034.03c85c70@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 03 May 2002 18:03:47 -0400 To: jari.arkko@piuha.net, "'mobile-ip@sunroof.eng.sun.com'" From: Thomas Hardjono Subject: Re: [mobile-ip] Unresolved issue #4: BM authentication In-Reply-To: <3CD2E489.9060505@piuha.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Are public-key based digital-signatures completely out of the question? Is it optional? thomas ------ At 5/3/2002||10:27 PM, Jari Arkko wrote: >the mobile node that the correspondent node does not have a >binding. This message is sent when the mobile node sends route >optimized traffic directly to the correspondent node and the >correspondent node has e.g. rebooted recently. > >It is also the intention to use the Binding Missing message (we may >have to rename it) to indicate that an unrecognized MH Type field was >seen in a message. > >In the current specification, Binding Missing is not authenticated. >Therefore, it can be sent by anyone in the Internet, in particular if >the sender is not restricted by ingress filtering. The only >requirement is that the attacker must know the care-of address the >mobile node is currently at. Of course, if the mobile node >implementation has some information from e.g. TCP layer that packets >are getting through, it may choose to ignore bogus BM messages. But >such information is not always available. > >Question: Does the BM message need authentication? Can we authenticate >it? How? Given that the BM message is sent e.g. after a reboot of the >correspondent node, it is impossible to use any previous RR-generated >keying material to authenticate the BM. The other alternatives for >authentication are as follows: > >1) No authentication needed. > >2) After receiving the BM, the mobile node would not believe this > message until it has sent a new request to the correspondent node > and gotten the same answer about the existence of the binding (or > MH Type). This new request would be sent with a cookie, and the > reply would have the same cookie. > >3) Charlie's method: in the BM, return a hash of the offending > packet. > >4) A variant of 3 where the correspondent node MUST produce the > hash, but the mobile node MAY (not MUST) use this information, > if it happens to remember hashes of previous packets. > >Proposal: The problem with approach 2 is that one roundtrip is spent >before the BM can be acted upon. The same roundtrip could be better >spent by performing the return routability procedure. Approach 3 is a >smart idea, and much better than approach 2 since no additional >roundtrips are needed. But it does require the mobile node to keep a >hashes of few recent packets (or start keeping hashes after one BM has >been received). Essentially the question boils down to a requirement >issue, how much do we care about random attackers in the Internet >sending BMs to mobile nodes? Is it worth the trouble, given that the >attacker still has to learn the care-of address? It also seems that >nodes who really care about this problem could use cross-layer >information as well. Other nodes will potentially suffer by having to >revert back to bidirectional routing, unnecessarily. > >The recommendation is that BM messages be sent without any >authentication. We're pretty neutral about the solution, >however and comments are solicited. From owner-mobile-ip@sunroof.eng.sun.com Fri May 3 18:35:30 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02520 for ; Fri, 3 May 2002 18:35:29 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04593; Fri, 3 May 2002 15:33:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27919; Fri, 3 May 2002 15:33:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43MWVrP016848 for ; Fri, 3 May 2002 15:32:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g43MWVBA016847 for mobile-ip-dist; Fri, 3 May 2002 15:32:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g43MWRrP016840 for ; Fri, 3 May 2002 15:32:28 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27385 for ; Fri, 3 May 2002 15:32:27 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19481 for ; Fri, 3 May 2002 16:32:30 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 987136A90D; Sat, 4 May 2002 01:32:19 +0300 (EEST) Message-ID: <3CD31026.8010409@piuha.net> Date: Sat, 04 May 2002 01:33:10 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Thomas Hardjono Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #4: BM authentication References: <5.0.0.25.2.20020503180034.03c85c70@pop.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thomas Hardjono wrote: > > Are public-key based digital-signatures completely out of the question? > Is it optional? As in traditional strong authentication e.g. through IPsec, or as in Cryptographically Generated Addresses? Traditional strong authentication is not out of question. You could set a policy on *all* your IP packets to be authenticated with IPsec, if you had a shared secret with your CN or a trust infra. CGA addresses... no one to my knowledge has thought yet about the use of CGA for this particular purpose but let's think about it. ...Thinking... it seems that if the CN had a CGA address it could easily construct error messages with a proof of authenticity. Just sign the message with the private key associated with the CN's address. There's been a discussion elsewhere on potential Secure Neighbour Discovery mechanisms for IPv6, and this use reminds me of a potential CGA application in that space. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 3 20:12:55 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04201 for ; Fri, 3 May 2002 20:12:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17866; Fri, 3 May 2002 18:12:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29065; Fri, 3 May 2002 17:12:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g440BOrP016966 for ; Fri, 3 May 2002 17:11:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g440BNSm016965 for mobile-ip-dist; Fri, 3 May 2002 17:11:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g440BKrP016958 for ; Fri, 3 May 2002 17:11:20 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g440BKUF019743; Fri, 3 May 2002 17:11:21 -0700 (PDT) Message-Id: <200205040011.g440BKUF019743@jurassic.eng.sun.com> Date: Fri, 3 May 2002 17:13:42 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Re: More comments on Draft16 -CLARIFICATION To: jari.arkko@piuha.net Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KnyI/LdS/7z2VzeYY5hSsg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Jari, Thanks much for taking the comments into consideration. My response is in-line. > > > 3. > > section 4.5.5 > > > > This section should clarify whether route optimazation through binding > > update to a CN is a MUST or optional. > > > Yes. There will be a new section under chapter 7, > > Requirements for All IPv6 Hosts and Routers that > > describes this. It currently reads SHOULD be able to > participate in a return routability procedure etc. > IMHO, SHOULD is quite weak statement. The whole point of doing route optimization is to save round-trip time. Now that we are solving the security issues, I think route optimization is the feature that a CN (a CN could be a MN) must implement. But obviously there SHOULD be a knob on MN side to turn it off and on. Without RO, the roundtrip time now is even longer through the reverse tunnel. Route optimization should be "MUST" for CN, IMHO. > > > Should talk about how Kcn should be generated. It should talk about > > the size and data type of Kcn. > > > Yes. 20 bytes. > Ok. > > > > > Nonce generation procedure > > ----------------------------- > > > > Nonce index is a 16 bit quantity. So what would be the default > > recommendation for sequence of index values for which the cookie > > would be valid ? Should it correspond to COOKIE_MIN_LIFETIME ? > > > There is no default recommendation. The index values can't be > used to infer anything. The mobile should expect to get a cookie > that is valid at least COOKIE_MIN_LIFETIME seconds. I'll try > to clarify this. > Ok, thanks. But the nonce indices would have to be valid (in system) during the cookie-lifetime period. > > > What is data type and size of Nj ? > > > Yes. 16 bytes. > > > > I understand that Nj == j is acceptable, because Nj is locally > > known to CN, do we need to document that ? > > > I believe this was already described in the explanation for the > CoT message in the flow of 4.5.5. > Yes, it documents that Nj is only local value. > > > A calculation or relationship between COOKIE LIFETIME and > > nonce-index and nonce generation method would be useful for > > implementors to maintain interoperability. > > > Can you clarify what you would like to see? > Actually I am wondering as well how to clarify. May be an example would be: if cookie_lifetime is n sec, then how long does the Nj need to be valid ? And during the n sec period, how many j or Nj should be around in the sliding window so that we consider loss of BUs or arrival of bogus BUs during MAX_COOKIE_LIFETIME. Also, I am not quite clear on how we handle MIN_COOKIE_LIFETIME and MAX_COOKIE_LIFETIME. Why exactly do we need MIN_COOKIE_LIFETIME ? Is it more for implementors not to set cookie lifetime lower than MIN_COOKIE_LIFETIME ? So, if cookie Ko is set to MIN_COOKIE_LIFETIME, does that mean the BU beyond MIN_COOKIE_LIFETIME, will not be accepted ? Or should it still be accepted till MAX_COOKIE_LIFETIME, although it's set to MIN_COOKIE_LIFETIME ? So, anyway we need to keep the cookie, nonce, nonce-index around up to MAX_COOKIE_LIFETIME, so why do we need a MIN value ? I mean to say whether just one value, COOKIE_LIFETIME is enough ? > > > section 5.1.8 BA messages > > > > I understand that Alt COA and Unique identifier parameters are > > optional. Should not we have a BA status value when these parameters > > are not supported ? > > i,e > > > > 146 > > > > Parameter type not supported > > I believe their use is optional, not support? > Yes, their use is optional. So, if a CN receives a message with alt COA (for example) and if it does not know how to process it, should not it send BA with status that this parameter type is not supported ? If we don't have such a status, what should CN send to MN in this case ? -Samita From owner-mobile-ip@sunroof.eng.sun.com Sat May 4 10:09:40 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24486 for ; Sat, 4 May 2002 10:09:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05229; Sat, 4 May 2002 08:09:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11464; Sat, 4 May 2002 07:08:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g44E79rP017723 for ; Sat, 4 May 2002 07:07:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g44E79KU017722 for mobile-ip-dist; Sat, 4 May 2002 07:07:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g44E76rP017715 for ; Sat, 4 May 2002 07:07:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11320 for ; Sat, 4 May 2002 07:07:06 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA16662 for ; Sat, 4 May 2002 08:07:00 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g44E6vb21420; Sat, 4 May 2002 16:06:57 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA07278; Sat, 4 May 2002 16:06:57 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g44E6vT26779; Sat, 4 May 2002 16:06:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205041406.g44E6vT26779@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #4: BM authentication In-reply-to: Your message of Fri, 03 May 2002 22:30:56 +0300. <3CD2E570.3080907@piuha.net> Date: Sat, 04 May 2002 16:06:57 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: It is also the intention to use the Binding Missing message (we may have to rename it) to indicate that an unrecognized MH Type field was seen in a message. => I have a concern with this second usage because the security requirement should not be the same. 1) No authentication needed. => fine for the main usage. 4) A variant of 3 where the correspondent node MUST produce the hash, but the mobile node MAY (not MUST) use this information, if it happens to remember hashes of previous packets. => fine for unrecognized MH Type field. The recommendation is that BM messages be sent without any authentication. We're pretty neutral about the solution, however and comments are solicited. => agree. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun May 5 04:09:56 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15388 for ; Sun, 5 May 2002 04:09:56 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15903; Sun, 5 May 2002 02:09:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17553; Sun, 5 May 2002 01:09:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4588BrP018486 for ; Sun, 5 May 2002 01:08:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4588Bdp018485 for mobile-ip-dist; Sun, 5 May 2002 01:08:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g45887rP018478 for ; Sun, 5 May 2002 01:08:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA10759 for ; Sun, 5 May 2002 01:08:09 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11798 for ; Sun, 5 May 2002 02:08:15 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 653C96A901; Sun, 5 May 2002 11:08:02 +0300 (EEST) Message-ID: <3CD4E896.5040405@piuha.net> Date: Sun, 05 May 2002 11:08:54 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: More comments on Draft16 -CLARIFICATION References: <200205040011.g440BKUF019743@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Samita Chakrabarti wrote: > IMHO, SHOULD is quite weak statement. The whole point of > doing route optimization is to save round-trip time. > Now that we are solving the security issues, I think > route optimization is the feature that a CN (a CN could be > a MN) must implement. But obviously there SHOULD be a knob > on MN side to turn it off and on. > > Without RO, the roundtrip time now is even longer through the > reverse tunnel. Route optimization should be "MUST" for CN, IMHO. This is a good argument. Why don't we create a separate issue for this... I'll do that. >>>A calculation or relationship between COOKIE LIFETIME and >>>nonce-index and nonce generation method would be useful for >>>implementors to maintain interoperability. > > Actually I am wondering as well how to clarify. > May be an example would be: > if cookie_lifetime is n sec, then how long does the Nj need to be > valid ? Cookies are valid exactly as long as both the nonces and Kcn used for creating them are valid. I'll try to clarify this. > And during the n sec period, how many j or Nj should be > around in the sliding window so that we consider loss of BUs > or arrival of bogus BUs during MAX_COOKIE_LIFETIME. > > Also, I am not quite clear on how we handle MIN_COOKIE_LIFETIME and > MAX_COOKIE_LIFETIME. Why exactly do we need MIN_COOKIE_LIFETIME ? > Is it more for implementors not to set cookie lifetime lower than > MIN_COOKIE_LIFETIME ? So, if cookie Ko is set to MIN_COOKIE_LIFETIME, > does that mean the BU beyond MIN_COOKIE_LIFETIME, will not be accepted ? > Or should it still be accepted till MAX_COOKIE_LIFETIME, although it's > set to MIN_COOKIE_LIFETIME ? So, anyway we need to keep the cookie, > nonce, nonce-index around up to MAX_COOKIE_LIFETIME, so why do we need > a MIN value ? I mean to say whether just one value, COOKIE_LIFETIME > is enough ? I've been wondering about this myself. I'll file a separate issue on this. >>> Parameter type not supported >>> >>I believe their use is optional, not support? > > Yes, their use is optional. So, if a CN receives a message with > alt COA (for example) and if it does not know how to process it, > should not it send BA with status that this parameter type is > not supported ? If we don't have such a status, what should CN > send to MN in this case ? I suppose there are four different possible cases: 1) A mandatory-to-support parameter in a legal position in some message. E.g. Alt-CoA in a BU. I don't think the CN should be allowed to complain about this. 2) A mandatory-to-support parameter in a bad position, e.g. Alt-CoA in a BA when the BU didn't contain any Alt-CoA. I'm not quite sure what we should do about this. 3) A parameter that isn't defined in the base standard but whose support is mandatory. I'm not sure we want to have these. 4) A parameter that isn't defined in the base standard and which is optional. No problem here. Jari From owner-mobile-ip@sunroof.eng.sun.com Sun May 5 05:40:31 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16053 for ; Sun, 5 May 2002 05:40:30 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12139; Sun, 5 May 2002 03:39:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA17458; Sun, 5 May 2002 02:39:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g459d0rP018575 for ; Sun, 5 May 2002 02:39:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g459d0ZR018574 for mobile-ip-dist; Sun, 5 May 2002 02:39:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g459cvrP018567 for ; Sun, 5 May 2002 02:38:57 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04236 for ; Sun, 5 May 2002 02:39:00 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13439 for ; Sun, 5 May 2002 02:38:59 -0700 (PDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 242C16A901 for ; Sun, 5 May 2002 12:38:58 +0300 (EEST) Message-ID: <3CD4FDE6.6010200@piuha.net> Date: Sun, 05 May 2002 12:39:50 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #21: MIN/MAX or one limit for lifetimes? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Background: As discussed in issue 6, having the cookies be valid for some amount of time makes it efficient to move around fast. Under issue 6, there was a discussion about the exact times necessary for this. The discussion centered around MAX_COOKIE_LIFE. However, there is a related constant MIN_COOKIE_LIFE. It is recommended that correspondent nodes try to keep these cookies acceptable at least MIN_COOKIE_LIFE seconds and SHOULD NOT allow them to be accepted beyond MAX_COOKIE_LIFE seconds. MAX_COOKIE_LIFE relates to the period of vulnerability. MIN_COOKIE_LIFE relates to the most certain period under which a mobile node can reasonably use a cookie -- after the MIN time there is much bigger likelihood that the correspondent node does not accept the cookie. (Note: while this discussion is about cookies, the cookies are simply cryptographic by-products, and the real issue is aging of the nonces used by the correspondent node. Invalidating a nonce will make the cookies generated based on it also invalid.) Question: When should the mobile node stop using a cookie, after the MIN or the MAX time? Are the times given for MIN and MAX in right relation to each other (e.g. 60/180 s)? Is the MIN time useful? Proposal: A mobile node which optimistically relies on a cookie between its MIN and MAX times is going to fail in this attempt, if the correspondent node is busy and has already invalidated the cookies. This will also happen if the correspondent node follows the standard too literally. However, most correspondent nodes that are not under a heavy load would likely have memory to keep the cookies alive long enough. Likewise, it will be impossible to guarantee lifetime even to MIN under all circumstances, such as reboots. An invalid cookie problem is also always acknowledged. If an acknowledgement was not required in the binding update, and the error acknowledgement is lost, some packets could be lost before the problem is noticed. In conclusion the specification should allow the cookies to be used until the MAX time, but require acknowledgements to be used for "reused" cookies. MIN time is not necessary. Correspondent nodes may still have to invalidate nonces and cookies, in particular under situations where BCE entries are rapidly being deleted and there is not enough memory to store both the deleted entries and the new ones. Draft 17 will contain text that recommends the oldest cookies to be invalidated first. If this happens, some Binding Updates sent by fast moving mobiles may fail. However, we expect this to be a rare enough event with correctly dimensioned correspondent nodes that we can deal with it in an optimistic manner. From owner-mobile-ip@sunroof.eng.sun.com Sun May 5 05:43:40 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16096 for ; Sun, 5 May 2002 05:43:39 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14680; Sun, 5 May 2002 02:41:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA17672; Sun, 5 May 2002 02:41:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g459eirP018613 for ; Sun, 5 May 2002 02:40:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g459eiFV018612 for mobile-ip-dist; Sun, 5 May 2002 02:40:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g459efrP018602 for ; Sun, 5 May 2002 02:40:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA17643 for ; Sun, 5 May 2002 02:40:44 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14186 for ; Sun, 5 May 2002 02:40:43 -0700 (PDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 4993B6A901 for ; Sun, 5 May 2002 12:40:42 +0300 (EEST) Message-ID: <3CD4FE4E.2030104@piuha.net> Date: Sun, 05 May 2002 12:41:34 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #22: SHOULD or MUST for CN RO? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit (List of issues at http://www.piuha.net/~jarkko/publications/mipv6/MIPv6-Issues.html - please submit your issues to the list, I can put them in the directory) Background: Draft 17 will have a section that describes the requirements for correspondent nodes. The initial attempt at this text is the following: Since any IPv6 node may at any time be a correspondent node of a mobile node, either sending a packet to a mobile node or receiving a packet from a mobile node, the following requirements apply to ALL IPv6 nodes (whether host or router, whether mobile or stationary): - Every IPv6 node MUST be able to process a Home Address option received in any IPv6 packet. - Every IPv6 node SHOULD be able to participate in a return routability procedure, process Binding Update messages, and to return a Binding Acknowledgement option if the Acknowledge (A) bit is set in the received Binding Update. - Every IPv6 node SHOULD be able to maintain a Binding Cache of the bindings received in accepted Binding Updates. Samita Chakrabarti comments on this: "IMHO, SHOULD is quite weak statement. The whole point of doing route optimization is to save round-trip time. Now that we are solving the security issues, I think route optimization is the feature that a CN (a CN could be a MN) must implement. But obviously there SHOULD be a knob on MN side to turn it off and on. Without RO, the roundtrip time now is even longer through the reverse tunnel. Route optimization should be "MUST" for CN, IMHO." Question: Is the text right? Should the keywords be MUST? From owner-mobile-ip@sunroof.eng.sun.com Sun May 5 11:22:29 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20027 for ; Sun, 5 May 2002 11:22:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11062; Sun, 5 May 2002 08:20:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19902; Sun, 5 May 2002 08:19:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g45FIOrP018952 for ; Sun, 5 May 2002 08:18:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g45FIOFD018951 for mobile-ip-dist; Sun, 5 May 2002 08:18:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g45FILrP018944 for ; Sun, 5 May 2002 08:18:21 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19827 for ; Sun, 5 May 2002 08:18:22 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14264 for ; Sun, 5 May 2002 09:18:21 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EDFCA6A901; Sun, 5 May 2002 18:18:19 +0300 (EEST) Message-ID: <3CD54D70.3040900@piuha.net> Date: Sun, 05 May 2002 18:19:12 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Unresolved issue #18: Prefix advertisement acknowledgement References: <200205020228.g422SCJe025111@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Samita Chakrabarti wrote: >>(2) Use any BU as a signal to stop sending the unsolicited advert. The >> lifetime limit (as discussed above) will force the BCE within the >> appropriate lifetime of existing prefixes. If the prefix has >> expired, a particular error code could indicate the problem which >> would cause the MN to solicit and advert and possibly form a new >> HoA. > > I am not sure I understand the sequence of events in this case. > > Does it mean: > 1. MN receives unsolicited prefix adv. Yes. > 2. MN sends a BU anyway to stop further prefix adv (uses existing HOA ?) > if the prefix information changes (renumbering), MN configures new HOA, Yes. So, either the old or the new HoA is used but a BU is sent anyway. > If there is no prefix change, MN just updates the prefix lifetime > information. > Should the HA expect a BU at this point ? If HA expects BU as ACK > only when prefix changes, then we can avoid extra signalling most > of the time. Good question. There are though rules that dictate when such unsolicited prefix advs are to be sent. But if you do send one, how do you know what the mobile node thinks the prefix is? Would the home agent be able to decide that for this particular MN we don't need to wait for a BU, because it already knew the prefix? > I am not sure which error code is being mentioned here - is it something > locally generated at MN ? A new error code in BA. > Can we make security association mandatory for unsolicited unicast prefix > advertisement for reliability ? The IPsec SA that is talked about in the text? I believe that doesn't help with the reliability part. > choice (2), does not require BR/BU sequence for prefix delivery. > > I wonder whether we need unique identifier parameter at all then ? You are right, we don't need that in this alternative. Jari From owner-mobile-ip@sunroof.eng.sun.com Sun May 5 15:52:02 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22863 for ; Sun, 5 May 2002 15:52:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28797; Sun, 5 May 2002 12:49:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10119; Sun, 5 May 2002 12:49:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g45JmjrP019323 for ; Sun, 5 May 2002 12:48:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g45Jmjp2019322 for mobile-ip-dist; Sun, 5 May 2002 12:48:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g45JmfrP019315 for ; Sun, 5 May 2002 12:48:41 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10066 for ; Sun, 5 May 2002 12:48:43 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06183 for ; Sun, 5 May 2002 12:48:43 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g45JmPpY028069; Sun, 5 May 2002 12:48:25 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABP26079; Sun, 5 May 2002 12:45:21 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA26822; Sun, 5 May 2002 12:48:28 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15573.35980.590363.501142@thomasm-u1.cisco.com> Date: Sun, 5 May 2002 12:48:28 -0700 (PDT) To: "James Kempf" Cc: "Michael Thomas" , "Hesham Soliman \(ERA\)" , "'Rajeev Koodli'" , Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04 In-Reply-To: <014e01c1f206$caec64a0$7e6015ac@T23KEMPF> References: <4DA6EA82906FD511BE2F00508BCF053802C6ACD1@Esealnt861.al.sw.ericsson.se> <15569.17179.696024.574295@thomasm-u1.cisco.com> <014e01c1f206$caec64a0$7e6015ac@T23KEMPF> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jim, I think you're missing one really important ingredient here: the mobile node wants to be able to have some say in what the next AR might be too. In particular, I really, really, want to have my mobile node be able to, say, tell the cellular router to create a tunnel to a COA on my home 802.11. In that case, the cellular router knows nothing at all about my 802.11; it's the MN that figures this out somehow. In that case, I don't want it moving me at all as I'm probably transitioning off their system (or visa versa). If we factor this scenario in, I think we're largely in agreement. Mike James Kempf writes: > Mike, > > > So, I agree with Hesham about the way that > > redirects actually work. However, back to the > > original issue: is there a reason that we can't > > have the mobile node pre-approve network based > > moves? That would keep with the spirit of the net > > (host is in charge), but allow the performance > > gains Jim is seeking. > > > > The question is how far in advance of the handoff is OK? > > >From the point of view of performance (based on the experiments we've > done with IS-2000 RAN, WLAN, and simulation), the fastest handover > performance is if the access router is informed by the link layer which > access router the mobile will move to, and the access router takes care > of rearranging the routing. The link layer is in the best position to > determine which new access point gives the mobile the best reception > because it has the power measurements, and allowing it to make that > determination and move the mobile without requiring any interaction with > the IP layer is by far the fastest. Making the decision on the access > router is preferable because it eliminates any over the air signaling, > which can get cut off if the mobile moves prematurely. Making the > decision on the mobile is OK, but signaling at the IP layer prior to > handover risks having the signaling get cut off if the link layer > determines the mobile must be moved quickly to maintain reception. Thus, > allowing the mobile to fix things up after the handover provides more > reliable performance than signaling prior to the handover. > > Moving backward in time, the mobile could provide some pre-approval on > the access router enough prior to the handover that the actual handover > sequencing was not affected. Thus, the access router could send a list > of candidate access routers for the next handover, and the mobile could > say which of them it liked and which it didn't. When the time comes for > an actual handover, the access router (if the access router is doing the > choosing) would only select from those access routers on the mobile's > pre-approved list. Or the mobile would choose if the mobile is doing the > choosing. The difficulty with this is that if the link layer decides at > the time of handover that power conditions are best for access points > associated with access router X but access router X is not on the > mobile's list, either the access router must negotiate with the mobile > about the ones the mobile said it didn't want, risking losing the mobile > if power conditions change too rapidly for the negotiation to conclude, > or the mobile will simply be dropped. Similarly, if the mobile is doing > the choosing and access router X is not on its list, the mobile either > better change its mind quickly or risk losing IP service. > > Note that this method is particularly well suited to intertechnology > handover, where the mobile must be involved in the handover decision > regardless of the performance implications, because only the mobile > knows which interfaces it currently has active or even installed (for > PCMCIA cards). > > Moving backward in time yet further, the mobile could, upon entry to the > wireless network, delegate selection of the next access router to the > network, allowing the network to provide the best performance possible, > or it could indicate that it wants to have a choice. This could be > accomplished by an AAA mechanism in the user profile. For example, when > you sign up for network service, there is a checkbox that allows you to > delegate selection of your access router to the network in return for > better preformance. If you don't check the box, then you get "best > effort" mobile controlled handover, but you get to choose your next > access router on every handoff. > > Comments? > > jak > From owner-mobile-ip@sunroof.eng.sun.com Sun May 5 18:27:00 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24218 for ; Sun, 5 May 2002 18:27:00 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08975; Sun, 5 May 2002 16:26:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00275; Sun, 5 May 2002 15:26:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g45MPIrP019583 for ; Sun, 5 May 2002 15:25:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g45MPII3019582 for mobile-ip-dist; Sun, 5 May 2002 15:25:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g45MPFrP019575 for ; Sun, 5 May 2002 15:25:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24527 for ; Sun, 5 May 2002 15:25:17 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27904 for ; Sun, 5 May 2002 16:25:16 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id DA0A96A901 for ; Mon, 6 May 2002 01:25:15 +0300 (EEST) Message-ID: <3CD5B17F.4060900@kolumbus.fi> Date: Mon, 06 May 2002 01:26:07 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Unresolved issue #12: State machine for MN? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit See issue description at http://www.piuha.net/~jarkko/publications/mipv6/issues/issue12.txt Comments appreciated. Jari From owner-mobile-ip@sunroof.eng.sun.com Sun May 5 19:31:58 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24701 for ; Sun, 5 May 2002 19:31:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09358; Sun, 5 May 2002 17:31:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12484; Sun, 5 May 2002 16:30:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g45NTLrP019656 for ; Sun, 5 May 2002 16:29:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g45NTLJt019655 for mobile-ip-dist; Sun, 5 May 2002 16:29:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g45NTIrP019648 for ; Sun, 5 May 2002 16:29:18 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05840 for ; Sun, 5 May 2002 16:29:20 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18950 for ; Sun, 5 May 2002 17:29:20 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6A0196A901; Mon, 6 May 2002 02:29:13 +0300 (EEST) Message-ID: <3CD5C07C.5050109@piuha.net> Date: Mon, 06 May 2002 02:30:04 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: Tuomas Aura , "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark , Gabriel Montenegro Subject: Re: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <007d01c1e2b0$f69eac80$8a1b6e0a@arenanet.fi> <3CB9AC18.20205@piuha.net> <3CBE04FF.DD0C2869@iprg.nokia.com> <3CBED045.8050901@piuha.net> <3CBFAE5B.5030901@piuha.net> <3CC04E6F.23E002F5@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'm trying to finish the discussion on the BA/BR authentication. Let me try to capture the opinions as I understood them. First the things we seem to agree on: * Binding Request doesn't need any authentication. Sending spoofed CN traffic to the mobile node's home address accomplishes the same thing, make it look like the CN does not have a BCE. * Some authentication is needed for the Binding Acknowledgement. Otherwise, it may be possible to get the MN traffic blackholed, or RO turned off too easily. * Original Kbu did not offer any authentication in the CN->MN direction, because someone could have spoofed HoT, CoT. Then the remaining differences: * Erik and Vijay think that a sequence number suffices for BA instead of a real cookie. Tuomas thinks that sequence numbers are too guessable. * Tuomas and Jari think that a cookie alone would be sufficient for BA authentication, and Kbu should not be used due to the complexity it brings for the analysis of the security of RR. They acknowledge however that Kbu authentication does bring an additional level of security, mainly against attackers on the CoA link (which may not matter if these attackers can perform other attacks anyway). Vijay thinks Kbu authentication is also needed. How should we move forward, then? I'd like to propose the following compromise: 1) Sequence numbers can be used, but their initialization will be required to be random. 2) We will not use Kbu for BAs. 3) No BR authentication. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 05:34:40 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10749 for ; Mon, 6 May 2002 05:34:40 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00700; Mon, 6 May 2002 03:34:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02639; Mon, 6 May 2002 02:33:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g469XHrP020211 for ; Mon, 6 May 2002 02:33:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g469XHGU020210 for mobile-ip-dist; Mon, 6 May 2002 02:33:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g469XDrP020203 for ; Mon, 6 May 2002 02:33:13 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08291 for ; Mon, 6 May 2002 02:33:15 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA02735 for ; Mon, 6 May 2002 02:33:14 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g469XDs7018404 for ; Mon, 6 May 2002 11:33:14 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon May 06 11:32:41 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <22815T91>; Mon, 6 May 2002 11:30:17 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: "'jari.arkko@piuha.net'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #22: SHOULD or MUST for CN RO? Date: Mon, 6 May 2002 11:31:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Background: Draft 17 will have a section that describes the > requirements > for correspondent nodes. The initial attempt at this text is the > following: > > Since any IPv6 node may at any time be a correspondent node of a > mobile node, either sending a packet to a mobile node or > receiving a > packet from a mobile node, the following requirements apply to ALL > IPv6 nodes (whether host or router, whether mobile or stationary): > > - Every IPv6 node MUST be able to process a Home Address option > received in any IPv6 packet. > > - Every IPv6 node SHOULD be able to participate in a return > routability procedure, process Binding Update messages, and to > return a Binding Acknowledgement option if the Acknowledge (A) > bit is set in the received Binding Update. > > - Every IPv6 node SHOULD be able to maintain a Binding > Cache of the > bindings received in accepted Binding Updates. > > Samita Chakrabarti comments on this: "IMHO, SHOULD is quite weak > statement. The whole point of doing route optimization is to save > round-trip time. Now that we are solving the security issues, I think > route optimization is the feature that a CN (a CN could be a MN) must > implement. But obviously there SHOULD be a knob on MN side to turn it > off and on. > > Without RO, the roundtrip time now is even longer through the > reverse tunnel. Route optimization should be "MUST" for CN, IMHO." > > Question: Is the text right? Should the keywords be MUST? > Does it really make sense to mandate (MUST) RO at CN's ? Without specifying a certain minimum BC size, a MUST will have no real effect, and do we have a good idea about what this minimum size "MUST" be ? SHOULD is the right keyword IMHO. CN's supporting RO will provide a better service to MN's, such CN's will be chosen above CN's not maintaining BC. Karen From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 06:48:04 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12113 for ; Mon, 6 May 2002 06:48:04 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03955; Mon, 6 May 2002 03:45:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA20059; Mon, 6 May 2002 03:45:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46AiUrP020347 for ; Mon, 6 May 2002 03:44:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46AiUYN020346 for mobile-ip-dist; Mon, 6 May 2002 03:44:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46AiRrP020339 for ; Mon, 6 May 2002 03:44:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12837 for ; Mon, 6 May 2002 03:44:27 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA19489 for ; Mon, 6 May 2002 04:44:22 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g46AiH0E018818 for ; Mon, 6 May 2002 12:44:17 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon May 06 12:41:34 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <228154LC>; Mon, 6 May 2002 12:39:10 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: "'Michael Thomas'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #7: MH format Date: Mon, 6 May 2002 12:40:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Mike, > Let me ask a very leading question: do you think > that IPsec security associations which are > divorced from the current topology and their > routing tags (eg, ip addresses) could be an > interesting property for mobility? I sure do. > > I believe that all you need to do affect this is > to wildcard the SA ipsrc selectors on the > receiving end. > > > > I assume that you're concerned about bandwidth? > > > See my question about the possibility of eliding > > > the HAO. > > > > Unless you want the IPSEC SA's (and SPD's) to be anchored > on the CoA you would > > need the HoA to be in one of the SA selector fields, or am > I missing something ? > > Maybe. If the access control element on the > receiver is permissive (eg, a valid hash is > sufficient to let the packet through), it won't be > anchored *anywhere*. This seems like a very > interesting property to me. Thanks a lot for explaining. I agree that this is an interesting property. However, with the current IPSEC architecture wouldn't this mean that - ONE : Policies can now only be anchored on the payload, which in this case is the MH. Hence all inbound packets with a MH must be protected in the same manner wrt. Security Protocol, algorithm, key lengths etc. Of course, if you can differentiate the MH type (as a payload port number) this only goes for MH of specific type. TWO - more important : The SA processing will only check that the correct payload was in the packet. Hence, unless you have some way to verify the association between the SPI and the HoA, then when A has a SA with its HA for the protection of MH of a certain type, i.e. BU's, A can use this SA (and SPI) to send bogus BU's for all other MN's that the HA serves. - ?? - Karen From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 07:01:03 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12329 for ; Mon, 6 May 2002 07:01:02 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13148; Mon, 6 May 2002 05:00:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21872; Mon, 6 May 2002 04:00:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46AxRrP020406 for ; Mon, 6 May 2002 03:59:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46AxRPZ020405 for mobile-ip-dist; Mon, 6 May 2002 03:59:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46AxOrP020398 for ; Mon, 6 May 2002 03:59:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23968 for ; Mon, 6 May 2002 03:59:24 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26042 for ; Mon, 6 May 2002 04:59:22 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g46AxJ0E027139 for ; Mon, 6 May 2002 12:59:19 +0200 (MEST) Received: FROM esealnt746.al.sw.ericsson.se BY esealnt461 ; Mon May 06 12:58:49 2002 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 12:58:49 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: "'Francis Dupont'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #7: MH format Date: Mon, 6 May 2002 12:58:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > However, the fact remains that if the SA selector contains the HoA > (which I suppose it should unless you want the > SA to be shared between the receiving node and a range of > (or all) hosts from which it is accepting BU's) > and if the SA selector match can be relied on to be performed, > then the HoA IS integrity protected and crypto doesn't buy > you any extras. > > => same answer... Your argument seems that firewalls and > IPsec give the > same level of security and I (and many others) disagree. > AH will be deprecated in IPsec v3 (cf last IETF meeting), HAO is not > always present, etc, so I believe to make the HoA optional is not > a good choice (i.e. it is too soon for space optimization of mobility > signaling). > I am saying that the SA selector check integrity protects all non-wildcard SA selector items. If you "and many others" have the experience that this is to weak, (for what ever reason I have still to understand, but so be it) then I suppose that the HoA must be included in the BU, if the BU (and the HoA) is to be authenticated by IPSEC ESP. Whether this is sufficient to mandate the presence of the Hoax in the BU, is up to others to decide. BR, Karen From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 07:26:30 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13060 for ; Mon, 6 May 2002 07:26:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04629; Mon, 6 May 2002 05:26:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24602; Mon, 6 May 2002 04:25:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46BPCrP020474 for ; Mon, 6 May 2002 04:25:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46BPCl3020473 for mobile-ip-dist; Mon, 6 May 2002 04:25:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46BP8rP020466 for ; Mon, 6 May 2002 04:25:08 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24507 for ; Mon, 6 May 2002 04:25:09 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA15545 for ; Mon, 6 May 2002 04:25:08 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12791; Mon, 6 May 2002 07:25:00 -0400 (EDT) Message-Id: <200205061125.HAA12791@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-rfc3012bis-02.txt Date: Mon, 06 May 2002 07:24:59 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobile IPv4 Challenge/Response Extensions Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-rfc3012bis-02.txt Pages : 19 Date : 03-May-02 Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-rfc3012bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-rfc3012bis-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: <20020503121836.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc3012bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc3012bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020503121836.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 11:02:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22451 for ; Mon, 6 May 2002 11:02:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19682; Mon, 6 May 2002 09:02:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20057; Mon, 6 May 2002 08:01:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46F1FrP020856 for ; Mon, 6 May 2002 08:01:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46F1FJF020855 for mobile-ip-dist; Mon, 6 May 2002 08:01:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46F1CrP020848 for ; Mon, 6 May 2002 08:01:12 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24312 for ; Mon, 6 May 2002 08:01:13 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08977 for ; Mon, 6 May 2002 08:01:12 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g46F1B0E010315 for ; Mon, 6 May 2002 17:01:11 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon May 06 17:01:01 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 6 May 2002 16:50:15 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AD20@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Michael Thomas'" , James Kempf Cc: "Hesham Soliman (ERA)" , "'Rajeev Koodli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] some questions about draft-ietf-mobileip-fast-mip v6-04 Date: Mon, 6 May 2002 17:01:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I think you're missing one really important > ingredient here: the mobile node wants to be able > to have some say in what the next AR might be > too. In particular, I really, really, want to have > my mobile node be able to, say, tell the cellular > router to create a tunnel to a COA on my home > 802.11. In that case, the cellular router knows > nothing at all about my 802.11; it's the MN that > figures this out somehow. => Exactly. Abstracting it even more, if we want to have a truely L2 independant solution, the MN MUST be involved in deciding where it's going. The AR can accept/reject that decision, but the MN has to be involved. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 12:14:43 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25204 for ; Mon, 6 May 2002 12:14:43 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02490; Mon, 6 May 2002 10:13:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16072; Mon, 6 May 2002 09:12:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46GC0rP020964 for ; Mon, 6 May 2002 09:12:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46GC0LL020963 for mobile-ip-dist; Mon, 6 May 2002 09:12:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46GBurP020956 for ; Mon, 6 May 2002 09:11:56 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15619 for ; Mon, 6 May 2002 09:11:58 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04325 for ; Mon, 6 May 2002 10:11:57 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA29224; Mon, 6 May 2002 07:04:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g46E4Lu03947; Mon, 6 May 2002 07:04:21 -0700 X-mProtect: <200205061404> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdePhHqu; Mon, 06 May 2002 07:04:19 PDT Message-ID: <3CD68D58.D1BD70F6@iprg.nokia.com> Date: Mon, 06 May 2002 07:04:09 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Karen E Nielsen (TED)" CC: "'jari.arkko@piuha.net'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #22: SHOULD or MUST for CN RO? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, "Karen E Nielsen (TED)" wrote: > >Does it really make sense to mandate (MUST) RO at CN's ? Yes, it makes a lot of sense, because eventually the dominant part of the Internet will be mobile. > Without specifying a certain minimum BC size, a MUST will have no real effect, and do we > have a good idea about what this minimum size "MUST" be ? This is not true. If it were true, then analogously you would be able to say that routing protocols could have no real effect because they do not specify a minimum route table size. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 12:45:29 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26471 for ; Mon, 6 May 2002 12:45:29 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21501; Mon, 6 May 2002 10:42:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00367; Mon, 6 May 2002 09:42:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46GfSrP021086 for ; Mon, 6 May 2002 09:41:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46GfSID021085 for mobile-ip-dist; Mon, 6 May 2002 09:41:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46GfPrP021078 for ; Mon, 6 May 2002 09:41:25 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29895 for ; Mon, 6 May 2002 09:41:26 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19223 for ; Mon, 6 May 2002 10:41:35 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g46GfOs7011235 for ; Mon, 6 May 2002 18:41:24 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon May 06 18:41:24 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4A829>; Mon, 6 May 2002 18:41:24 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0594@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'jari.arkko@piuha.net'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Unresolved issue #22: SHOULD or MUST for CN RO? Date: Mon, 6 May 2002 18:41:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Late reply. Since any IPv6 node may at any time be a correspondent node of a > mobile node, either sending a packet to a mobile node > or receiving a > packet from a mobile node, the following requirements > apply to ALL > IPv6 nodes (whether host or router, whether mobile or > stationary): > > - Every IPv6 node MUST be able to process a Home > Address option > received in any IPv6 packet. > > - Every IPv6 node SHOULD be able to participate in a return > routability procedure, process Binding Update > messages, and to > return a Binding Acknowledgement option if the > Acknowledge (A) > bit is set in the received Binding Update. > > - Every IPv6 node SHOULD be able to maintain a > Binding Cache of the > bindings received in accepted Binding Updates. > > Samita Chakrabarti comments on this: "IMHO, SHOULD is quite weak > statement. The whole point of doing route optimization is to save > round-trip time. Now that we are solving the security > issues, I think > route optimization is the feature that a CN (a CN could be > a MN) must > implement. But obviously there SHOULD be a knob on MN side > to turn it > off and on. > > Without RO, the roundtrip time now is even longer through the > reverse tunnel. Route optimization should be "MUST" for CN, IMHO." => I was going to ask, why is this coming up now and was ok as a SHOULD before, then I saw the last line. IMHO, this is not a justification for mandating RO. Yes reverse tunnelling through the HA would cause additional RTT for CNs outside the MN's home network, but does it really make a difference when compared to triangular routing. At least for most communication scenarios today I can't see any benefits (in terms of delays) for asymmetric triangular routing, compared to symmetric rectangular routing. Would love to hear some explanation from someone for why there is a significant difference. RO for all sounds nice, but I don't see why it is more important now than before. > Question: Is the text right? Should the keywords be MUST? => If it should be a MUST then I don't think it should be done based on the text above, it would be good to know if there is anything new that would give a significant reason for making it a MUST. Of course the WG can also just have a change of heart and thing that RO is important anyway and should have always been a MUST. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 12:51:34 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26696 for ; Mon, 6 May 2002 12:51:34 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25308; Mon, 6 May 2002 10:51:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05018; Mon, 6 May 2002 09:50:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46GoGrP021147 for ; Mon, 6 May 2002 09:50:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46GoGDw021146 for mobile-ip-dist; Mon, 6 May 2002 09:50:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46GoDrP021139 for ; Mon, 6 May 2002 09:50:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04783 for ; Mon, 6 May 2002 09:50:14 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24797 for ; Mon, 6 May 2002 10:50:23 -0600 (MDT) Message-ID: <011601c1f51d$cf2a09e0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "'Michael Thomas'" Cc: "Hesham Soliman \(ERA\)" , "'Rajeev Koodli'" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AD20@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] some questions about draft-ietf-mobileip-fast-mipv6-04 Date: Mon, 6 May 2002 09:48:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham/Michael, > > > I think you're missing one really important > > ingredient here: the mobile node wants to be able > > to have some say in what the next AR might be > > too. In particular, I really, really, want to have > > my mobile node be able to, say, tell the cellular > > router to create a tunnel to a COA on my home > > 802.11. In that case, the cellular router knows > > nothing at all about my 802.11; it's the MN that > > figures this out somehow. > In my note, I said this about intertechnology handover: Note that this method is particularly well suited to intertechnology handover, where the mobile must be involved in the handover decision regardless of the performance implications, because only the mobile knows which interfaces it currently has active or even installed (for PCMCIA cards). So I agree that there needs to be mobile involvement when there is intertechnology handover, such as between cellular and 802.11. > => Exactly. Abstracting it even more, if we want > to have a truely L2 independant solution, the > MN MUST be involved in deciding where it's > going. The AR can accept/reject that decision, > but the MN has to be involved. > The purpose of the L2 triggers draft (draft-manyfolks-l2-mobile-req-04.txt is to define an abstraction of the information needed by IP from the link layer for fast handover. The intent is to allow the specification of the handover protocol to be independent of specific Layer 2 technologies. So I do agree about the need for a technology independent specification of the fast handover protocol. However, for intra-technology handover, eliminating signaling to and from the mobile immediately prior to handover when radio conditions are deteriorating is crucial for consistent, reliable handover performance if the wireless protocol provides the access router with the proper handover sequencing information, as defined in the L2 triggers draft. On IS-2000 RAN (the only radio protocol where we could implement both mobile-controlled and network controlled handover to compare them), network-controlled handover consistently loses about 1-2 packets whereas mobile-controlled loses 11-20 or more, sometimes over 25 if the handover signaling between the mobile node and the access router fails because the mobile moves too quickly. As I mentioned in my note, this does not preclude the mobile being involved at an earlier stage, considerably prior to the handover itself, or afterwards when radio conditions and the mobile's movement pattern make the Layer 3 connection more reliable, but it does argue, and quite strongly in my opinion, for limiting the mobile's involvement immediately prior to the handover, if the radio protocol makes this possible. jak From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 13:52:02 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29555 for ; Mon, 6 May 2002 13:52:01 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22602; Mon, 6 May 2002 10:49:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21382; Mon, 6 May 2002 10:49:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46HmlrP021213 for ; Mon, 6 May 2002 10:48:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46HmkBe021212 for mobile-ip-dist; Mon, 6 May 2002 10:48:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46HmjrP021205 for ; Mon, 6 May 2002 10:48:45 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16500 for ; Mon, 6 May 2002 13:48:45 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g46Hmjqp009827 for ; Mon, 6 May 2002 13:48:45 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g46HmiXV009826 for mobile-ip@sunroof.eng.sun.com; Mon, 6 May 2002 13:48:44 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g45K7vrP019387; Sun, 5 May 2002 13:07:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12045; Sun, 5 May 2002 13:08:00 -0700 (PDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02065; Sun, 5 May 2002 13:08:00 -0700 (PDT) Received: from yahoo.com ([64.173.9.201]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0GVN00AFIM9Z4M@mta5.snfc21.pbi.net>; Sun, 05 May 2002 13:07:55 -0700 (PDT) Date: Sun, 05 May 2002 13:05:56 -0700 From: Chair of 3G02/Globecom03/VTC03 Subject: [mobile-ip] 3Gwireless'2002 & 4G Mobile Forum Kickoff Message-id: <3CD590A4.F6D7B70@yahoo.com> MIME-version: 1.0 X-Mailer: Mozilla 4.78 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear colleagues: The important 3Gwireless'2002 and 4Gmobile Forum kickoff are just weeks to go. To get involved in the intensive technical discussions and strategies on 3G/4G, please reserve your seat right now at: http://wirelesscongress.com or http://delson.org/wc. Welcome on board and secure your leadership in this emerging wireless communication. Thank you. Office of Chairman 3G02/WWC02 http://wirelesscongress.com PS: Limited number of conference records are freely available to government agencies, public library and wireless authorities. Contact the conference for details. [Sorry for multiple copies of this message. This is only one-time transmission for technical info only. Complete removal is automatic. Thanks for your support for the promotion of education and research.] From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 13:52:47 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29575 for ; Mon, 6 May 2002 13:52:47 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23250; Mon, 6 May 2002 10:50:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21902; Mon, 6 May 2002 10:50:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46HncrP021233 for ; Mon, 6 May 2002 10:49:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46HnbNL021232 for mobile-ip-dist; Mon, 6 May 2002 10:49:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46HnZrP021224 for ; Mon, 6 May 2002 10:49:36 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16807 for ; Mon, 6 May 2002 13:49:35 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g46HnZqp009833 for ; Mon, 6 May 2002 13:49:35 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g46HnZ5f009832 for mobile-ip@sunroof.eng.sun.com; Mon, 6 May 2002 13:49:35 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46C85rP020544 for ; Mon, 6 May 2002 05:08:05 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06786 for ; Mon, 6 May 2002 05:08:06 -0700 (PDT) Received: from mx1.iat.cnr.it (mx1.iat.cnr.it [146.48.65.88]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20132 for ; Mon, 6 May 2002 05:08:05 -0700 (PDT) Received: from CONVERSION.MAIL.IAT.CNR.IT by mail.iat.cnr.it (PMDF V6.1-1 #40166) id <01KHERXLVSPS96W2CE@mail.iat.cnr.it> for mobile-ip@sunroof.eng.sun.com; Mon, 06 May 2002 14:07:37 +0200 (MET DST) Received: from [146.48.82.104] (diana.cnuce.cnr.it [146.48.82.104]) by mail.iat.cnr.it (PMDF V6.1-1 #40166) with ESMTP id <01KHERXLHO4K96W3N8@mail.iat.cnr.it>; Mon, 06 May 2002 14:07:37 +0200 (MET DST) Date: Mon, 06 May 2002 14:07:35 +0200 From: info_net2002 Subject: [mobile-ip] Networking2002 - registration deadline MAY 10th X-Sender: net2002@pop.cnuce.cnr.it To: conf@colmar.uha.fr, cfp@mmlab.snu.ac.kr, Conferencesa@comsoc.org, info-confs@comsoc.org, mobile-ip@sunroof.eng.sun.com Message-id: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: CALL FOR PARTICIPATION NETWORKING 2002 The Second IFIP-TC6 Networking Conference http://www.cnuce.pi.cnr.it/Networking2002 May 19-24 2002, Pisa - Italy Networking is the biennial Conference on Networking of the IFIP Technical Committee on Communication Systems (TC6). Networking 2002 is the second conference of this series --the first event was held in Paris, May 2000 Networking 2002 is organized into three tracks: i) Networking Technologies, Services and Protocols ii) Performance of Computer and Communication Networks iii) Mobile and Wireless Communications Systems. This year the conference received 314 submissions coming from 42 countries from all five continents: Africa (4), Asia (84), America (63), Europe (158) and Oceania (5). From the 314 submissions, we finally selected 82 full papers for the presentation in the conference technical sessions. In addition, we selected 31 short papers for presentation in the poster sessions. The technical program also includes a panel session, and three Invited Talks from worldwide leaders Imrich Chlamtac "Managing Optical Networks in the Optical Domain" Randy Katz "The Post-PC Era: It's All About Services" Gerald Maguire "Personal Computing and Communication". The panel session "Post 9-11 Networking Challenges" is organized by Andrew T. Campbell (Columbia University) Panelist: Randy Katz (University of California, Berkeley) Jonathan Liebenau (London School of Economics), Nicholas F. Maxemchuk (Columbia University), Karl Rauscher (Lucent, Founder Wireless Emergency Response Team). The panel discusses on how to cope with the communications systems' vulnerabilities revealed by the World Trade Center attack on September 11. The program of the conference is on five days and includes - two tutorial days, http://www.cnuce.pi.cnr.it/Networking2002/tutorial.html - the main conference, http://www.cnuce.pi.cnr.it/Networking2002/at-a-glance.html - one-day thematic workshops, http://www.cnuce.pi.cnr.it/Networking2002/workshops.html Advance program, registration information, and hotel information for NETWORKING 2002 are now available at http://www.cnuce.pi.cnr.it/Networking2002/info.html If you are unable to access the above web page, please send e-mail to: info_net2002 . CONFERENCE REGISTRATION: The deadline for late registration is MAY 10, 2002. HOTEL RESERVATION: Please book your hotel room as soon as possible. May is a high tourist season in Pisa. ----------------------------------------- NETWORKING 2002 The Second IFIP-TC6 Networking Conference May 19-24 2002, Pisa - Italy c/o CNUCE Institute - National Research Council CNR Research Area Via G. Moruzzi, 1 56124, Pisa, Italy fax.: +39 050 3138092/91 http://www.cnuce.pi.cnr.it/Networking2002 From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 15:43:47 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04301 for ; Mon, 6 May 2002 15:43:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29975; Mon, 6 May 2002 13:43:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01277; Mon, 6 May 2002 12:42:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46JfZrP021655 for ; Mon, 6 May 2002 12:41:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46JfYR3021654 for mobile-ip-dist; Mon, 6 May 2002 12:41:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46JfVrP021647 for ; Mon, 6 May 2002 12:41:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08451 for ; Mon, 6 May 2002 12:41:32 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10376 for ; Mon, 6 May 2002 13:41:42 -0600 (MDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g46Jf8tp003632 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 6 May 2002 12:41:08 -0700 (PDT) Received: from JEFFD.qualcomm.com (jeffd.qualcomm.com [129.46.209.167]) by crowley.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g46Jf5To002243; Mon, 6 May 2002 12:41:05 -0700 (PDT) Message-Id: <5.1.0.14.2.20020506122328.0c592420@mail1.qualcomm.com> X-Sender: jeffd@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 06 May 2002 12:44:15 -0700 To: mobile-ip@sunroof.eng.sun.com From: Jeff Dyck Subject: Re: [mobile-ip] Length field definitions - rfc3115 Cc: gdommety@cisco.com, kleung In-Reply-To: <3C717501.7874707F@attglobal.net> References: <3C6FE255.C2FA49C3@attglobal.net> <3C6FEB76.650DEF8E@cisco.com> <3C7013C8.95CF05D1@attglobal.net> <3C709D67.C14840A7@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Kent, I realize this is an old topic, however your comment below seems to miss the contradiction. I thought I'd point it out once again to make sure you are aware. The reserved field precedes the length field, i.e. this is not consistent with the general definition of the length field where length is equal to the # of following bytes. In the case of the [CN]VSE it is # of bytes following + 1 byte (reserved). However, since 3115 is already standards track, I don't think this should be changed. Jeff At 03:41 PM 2/18/2002 -0600, Sebastian Thalanany wrote: >Hello Kent, > Thanks for the confirmation. > >Regards, > Sebastian > >kleung wrote: > > > Sebastian Thalanany wrote: > > > > > Hello Kent, > > > Since rfc3115 is based on rfc2002, which was > > > obsoleted last month by rfc3220, it would perhaps be preferrable to > > > update rfc3115 with the general format specification for a skippable > > > extension(NVSE) as specified in rfc3220. If the intent of the > > > "Reserved" field is to extend the Type field, as indicated in section > > > 1.10 and 1.11 of rfc3220, or for some other purpose, then perhaps the > > > following definitions for a CVSE element and an NVSE element may avoid > > > ambiguities in interpretation: > > > > > > 1. CVSE > > > Length Length in bytes of the Value(data) field > > > within > > > this extension. It does NOT include the bytes associated with the > > > Type, Length and the Reserved fields. > > > > > > > > > 2. NVSE > > > Length Length in bytes of the Value(data) field within > > > this extension. It does NOT include the bytes associated with the > > > Type, Length and the Reserved fields. > > > > > > > Not this. > > > > > > > > or > > > > > > Length Length in bytes of the Value(data) field within > > > this extension. It does NOT include the bytes associated with the > > > Type, Length fields. The Length field MUST be set to 2 plus the length > > > > > > of the Value(data) field, where the additional two octets are required > > > > > > to include the length of the Reserved field. > > > > > > This one. Length is always what follows that field in the > extension. This is consistent with 1.9, 1.10 and 1.11. > > > > Thanks. > > > > Kent > > > > > > > > For the NVSE, please confirm one of the two proposed > > > definitions. > > > > > > Thanks. > > > > > > Regards, > > > Sebastian __________________________________________________ Jeffrey Dyck, Engineer QUALCOMM CDMA Technologies (858) 845-7548 jeffd@qualcomm.com From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 16:20:42 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05067 for ; Mon, 6 May 2002 16:20:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA21023; Mon, 6 May 2002 14:20:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18069; Mon, 6 May 2002 13:20:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46KJGrP021809 for ; Mon, 6 May 2002 13:19:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46KJGiB021808 for mobile-ip-dist; Mon, 6 May 2002 13:19:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46KJDrP021801 for ; Mon, 6 May 2002 13:19:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03081 for ; Mon, 6 May 2002 13:19:15 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01963 for ; Mon, 6 May 2002 14:19:24 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA19197; Mon, 6 May 2002 12:54:19 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g46JsI929735; Mon, 6 May 2002 12:54:18 -0700 X-mProtect: <200205061954> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGkLFYe; Mon, 06 May 2002 12:54:17 PDT Message-ID: <3CD6DF69.6FAFC0EB@iprg.nokia.com> Date: Mon, 06 May 2002 12:54:17 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #22: SHOULD or MUST for CN RO? References: <3CD4FE4E.2030104@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Without RO, the roundtrip time now is even longer through the > reverse tunnel. Route optimization should be "MUST" for CN, IMHO." > > Question: Is the text right? Should the keywords be MUST? Ofcourse 'MUST'. vijay From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 16:36:24 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05489 for ; Mon, 6 May 2002 16:36:23 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04144; Mon, 6 May 2002 13:34:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24635; Mon, 6 May 2002 13:34:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46KXDrP021881 for ; Mon, 6 May 2002 13:33:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46KXDpT021880 for mobile-ip-dist; Mon, 6 May 2002 13:33:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46KX5rP021873 for ; Mon, 6 May 2002 13:33:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07595 for ; Mon, 6 May 2002 13:33:07 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21323 for ; Mon, 6 May 2002 14:33:06 -0600 (MDT) Message-ID: <024101c1f53c$faabcad0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Vijay Devarapalli" , Cc: References: <3CD4FE4E.2030104@piuha.net> <3CD6DF69.6FAFC0EB@iprg.nokia.com> Subject: Re: [mobile-ip] Unresolved issue #22: SHOULD or MUST for CN RO? Date: Mon, 6 May 2002 13:31:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > Without RO, the roundtrip time now is even longer through the > > reverse tunnel. Route optimization should be "MUST" for CN, IMHO." > > > > Question: Is the text right? Should the keywords be MUST? > > Ofcourse 'MUST'. > Since the CN can be any node in the IPv6 Internet, doesn't this need to be passed by IPNG? jak From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 16:40:30 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05597 for ; Mon, 6 May 2002 16:40:30 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06554; Mon, 6 May 2002 13:38:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26680; Mon, 6 May 2002 13:38:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46KbUrP021933 for ; Mon, 6 May 2002 13:37:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46KbTPT021932 for mobile-ip-dist; Mon, 6 May 2002 13:37:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46KbPrP021925 for ; Mon, 6 May 2002 13:37:26 -0700 (PDT) Received: from lillen (vpn-129-156-96-75.EMEA.Sun.COM [129.156.96.75]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g46KbHg00968; Mon, 6 May 2002 22:37:18 +0200 (MEST) Date: Mon, 6 May 2002 22:36:36 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Unresolved issue #3: BA, BR authentication? To: jari.arkko@piuha.net Cc: Vijay Devarapalli , Tuomas Aura , "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark , Gabriel Montenegro In-Reply-To: "Your message with ID" <3CD5C07C.5050109@piuha.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Then the remaining differences: > > * Erik and Vijay think that a sequence number suffices for > BA instead of a real cookie. Tuomas thinks that sequence > numbers are too guessable. I think something stronger than a sequence number is fine as well. > 1) Sequence numbers can be used, but their initialization will > be required to be random. I personally think it would be better to have an explicitly random cookie and let the sequence numbers start at zero. > 2) We will not use Kbu for BAs. OK > 3) No BR authentication. OK Erik From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 16:51:30 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05969 for ; Mon, 6 May 2002 16:51:29 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22223; Mon, 6 May 2002 13:49:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01836; Mon, 6 May 2002 13:49:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46KlErP021977 for ; Mon, 6 May 2002 13:47:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46KlD87021976 for mobile-ip-dist; Mon, 6 May 2002 13:47:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46KlArP021969 for ; Mon, 6 May 2002 13:47:10 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13493 for ; Mon, 6 May 2002 13:47:10 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06881 for ; Mon, 6 May 2002 14:47:10 -0600 (MDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g46Kl8p6011378; Mon, 6 May 2002 13:47:08 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-56.cisco.com [128.107.163.56]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACV22346; Mon, 6 May 2002 13:47:07 -0700 (PDT) Message-ID: <3CD6EBCB.BC919C47@cisco.com> Date: Mon, 06 May 2002 13:47:07 -0700 From: kleung Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Dyck CC: mobile-ip@sunroof.eng.sun.com, gdommety@cisco.com Subject: Re: [mobile-ip] Length field definitions - rfc3115 References: <3C6FE255.C2FA49C3@attglobal.net> <3C6FEB76.650DEF8E@cisco.com> <3C7013C8.95CF05D1@attglobal.net> <3C709D67.C14840A7@cisco.com> <5.1.0.14.2.20020506122328.0c592420@mail1.qualcomm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The fields for CVSE and NVSE are different. So in summary... For CVSE Length Length in bytes of this extension, not including the Type, Length, and Reserved field bytes. For NVSE Length Length in bytes of this extension, not including the Type and Length field bytes. So consistency check remains ... > This one. Length is always what follows that field in the > extension. This is consistent with 1.9, 1.10 and 1.11. Kent Jeff Dyck wrote: > Hi Kent, > > I realize this is an old topic, however your comment below seems to miss > the contradiction. I thought I'd point it out once again to make sure you > are aware. > > The reserved field precedes the length field, i.e. this is not consistent > with the general definition of the length field where length is equal to > the # of following bytes. In the case of the [CN]VSE it is # of bytes > following + 1 byte (reserved). > > However, since 3115 is already standards track, I don't think this should > be changed. > > Jeff > > At 03:41 PM 2/18/2002 -0600, Sebastian Thalanany wrote: > >Hello Kent, > > Thanks for the confirmation. > > > >Regards, > > Sebastian > > > >kleung wrote: > > > > > Sebastian Thalanany wrote: > > > > > > > Hello Kent, > > > > Since rfc3115 is based on rfc2002, which was > > > > obsoleted last month by rfc3220, it would perhaps be preferrable to > > > > update rfc3115 with the general format specification for a skippable > > > > extension(NVSE) as specified in rfc3220. If the intent of the > > > > "Reserved" field is to extend the Type field, as indicated in section > > > > 1.10 and 1.11 of rfc3220, or for some other purpose, then perhaps the > > > > following definitions for a CVSE element and an NVSE element may avoid > > > > ambiguities in interpretation: > > > > > > > > 1. CVSE > > > > Length Length in bytes of the Value(data) field > > > > within > > > > this extension. It does NOT include the bytes associated with the > > > > Type, Length and the Reserved fields. > > > > > > > > > > > > 2. NVSE > > > > Length Length in bytes of the Value(data) field within > > > > this extension. It does NOT include the bytes associated with the > > > > Type, Length and the Reserved fields. > > > > > > > > > > Not this. > > > > > > > > > > > or > > > > > > > > Length Length in bytes of the Value(data) field within > > > > this extension. It does NOT include the bytes associated with the > > > > Type, Length fields. The Length field MUST be set to 2 plus the length > > > > > > > > of the Value(data) field, where the additional two octets are required > > > > > > > > to include the length of the Reserved field. > > > > > > > > > This one. Length is always what follows that field in the > > extension. This is consistent with 1.9, 1.10 and 1.11. > > > > > > Thanks. > > > > > > Kent > > > > > > > > > > > For the NVSE, please confirm one of the two proposed > > > > definitions. > > > > > > > > Thanks. > > > > > > > > Regards, > > > > Sebastian > > __________________________________________________ > Jeffrey Dyck, Engineer > QUALCOMM CDMA Technologies > (858) 845-7548 > jeffd@qualcomm.com -- | | Kent Leung :|: :|: IOS Development :|||: :|||: Voice: 408.526.5030 :|||||||: :|||||||: Email: kleung@cisco.com .:|||||||||:.:|||||||||:. URL : http://wwwin-mobileip:8000 c i s c o S y s t e m s "Enabling the mobile wireless age!" From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 17:26:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07496 for ; Mon, 6 May 2002 17:26:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10751; Mon, 6 May 2002 15:25:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18405; Mon, 6 May 2002 14:25:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46LJ4rP022056 for ; Mon, 6 May 2002 14:19:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46LJ2pZ022055 for mobile-ip-dist; Mon, 6 May 2002 14:19:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46LISrP022048 for ; Mon, 6 May 2002 14:18:28 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14416 for ; Mon, 6 May 2002 14:18:29 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02371 for ; Mon, 6 May 2002 15:18:25 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g46LI7U31248; Tue, 7 May 2002 00:18:08 +0300 Date: Tue, 7 May 2002 00:18:07 +0300 (EEST) From: Pekka Savola To: James Kempf cc: Vijay Devarapalli , , Subject: Re: [mobile-ip] Unresolved issue #22: SHOULD or MUST for CN RO? In-Reply-To: <024101c1f53c$faabcad0$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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Mon, 6 May 2002, James Kempf wrote: > > > Without RO, the roundtrip time now is even longer through the > > > reverse tunnel. Route optimization should be "MUST" for CN, IMHO." > > > > > > Question: Is the text right? Should the keywords be MUST? > > > > Ofcourse 'MUST'. > > > > Since the CN can be any node in the IPv6 Internet, doesn't this need to > be passed by IPNG? Definitely. (Or it will probably come back at the w.g. at IESG last call..) It's easy for MIPv6 implementors and advocates to say MUST, but some people, more skeptic about the deployment of mobility certainly disagree. -- 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 May 6 17:58:46 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08741 for ; Mon, 6 May 2002 17:58:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17067; Mon, 6 May 2002 15:58:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29030; Mon, 6 May 2002 14:58:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46LoDrP022119 for ; Mon, 6 May 2002 14:50:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46LoCWw022118 for mobile-ip-dist; Mon, 6 May 2002 14:50:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46LndrP022111 for ; Mon, 6 May 2002 14:49:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA25934 for ; Mon, 6 May 2002 14:49:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12652 for ; Mon, 6 May 2002 15:49:37 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA26154; Mon, 6 May 2002 14:49:35 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g46LnYi11379; Mon, 6 May 2002 14:49:34 -0700 X-mProtect: <200205062149> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdxUSvKz; Mon, 06 May 2002 14:49:32 PDT Message-ID: <3CD6FA6C.801B291@iprg.nokia.com> Date: Mon, 06 May 2002 14:49:32 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: Tuomas Aura , "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark , Gabriel Montenegro Subject: Re: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <007d01c1e2b0$f69eac80$8a1b6e0a@arenanet.fi> <3CB9AC18.20205@piuha.net> <3CBE04FF.DD0C2869@iprg.nokia.com> <3CBED045.8050901@piuha.net> <3CBFAE5B.5030901@piuha.net> <3CC04E6F.23E002F5@iprg.nokia.com> <3CD5C07C.5050109@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Jari, A few comments, Jari Arkko wrote: > > I'm trying to finish the discussion on the BA/BR authentication. > Let me try to capture the opinions as I understood them. First > the things we seem to agree on: > > * Binding Request doesn't need any authentication. Sending > spoofed CN traffic to the mobile node's home address > accomplishes the same thing, make it look like the CN > does not have a BCE. > > * Some authentication is needed for the Binding Acknowledgement. > Otherwise, it may be possible to get the MN traffic blackholed, > or RO turned off too easily. > > * Original Kbu did not offer any authentication in the CN->MN > direction, because someone could have spoofed HoT, CoT. > > Then the remaining differences: > > * Erik and Vijay think that a sequence number suffices for > BA instead of a real cookie. Tuomas thinks that sequence > numbers are too guessable. Thats why I said Kbu helps here. Even if the sequence number is guessable, the attacker cannot generate MAC_Kbu over the binding ack (unless he knows the Kbu). > * Tuomas and Jari think that a cookie alone would be sufficient > for BA authentication, and Kbu should not be used due to the > complexity it brings for the analysis of the security of RR. Sorry, I dont remember this. What additional complexity? Can you please elaborate? > They acknowledge however that Kbu authentication does bring > an additional level of security, mainly against attackers on > the CoA link (which may not matter if these attackers can > perform other attacks anyway). Vijay thinks Kbu authentication > is also needed. > > How should we move forward, then? I'd like to propose the > following compromise: > > 1) Sequence numbers can be used, but their initialization will > be required to be random. Fine with me. > 2) We will not use Kbu for BAs. Fine with me, if you tell me what the additional complexity is. I am all for simplification. > 3) No BR authentication. cool. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 19:14:05 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10744 for ; Mon, 6 May 2002 19:14:05 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02723; Mon, 6 May 2002 17:13:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09460; Mon, 6 May 2002 16:13:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46N7wrP022227 for ; Mon, 6 May 2002 16:07:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46N7wti022226 for mobile-ip-dist; Mon, 6 May 2002 16:07:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46N7trP022219 for ; Mon, 6 May 2002 16:07:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07695 for ; Mon, 6 May 2002 16:07:36 -0700 (PDT) Received: from letters.cs.ucsb.edu (letters.cs.ucsb.edu [128.111.41.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA00402 for ; Mon, 6 May 2002 17:07:35 -0600 (MDT) Received: from cs.ucsb.edu (vail [128.111.52.30]) by letters.cs.ucsb.edu (8.11.6+Sun/8.9.3) with ESMTP id g46N7ZO10861 for ; Mon, 6 May 2002 16:07:35 -0700 (PDT) Message-ID: <3CD70CB7.F3599E8C@cs.ucsb.edu> Date: Mon, 06 May 2002 16:07:35 -0700 From: Robert Chalmers Organization: UCSB Computer Science X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Unresolved issue #18: Prefix advertisement acknowledgement References: <3CD072F4.9090508@piuha.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Background: A mechanisms exists in Draft 16 to distribute home network > prefixes to mobile nodes. These prefixes are sent along ICMP Mobile > Prefix Advertisement messages. This message can be either solicited > through the ICMP Mobile Prefix Solicitation message, or it can be > unsolicited when the prefixes change. (.snip.) > Question: Is it necessary to have a reliable prefix delivery mechanism > even in the unsolicited case? How can we ensure the delivery? Which of > the mechanisms below should be used: > > (1) Ignore reliability for the unsolicited prefix advertisements. > (2) Use any BU as a signal to stop sending the unsolicited advert. The > lifetime limit (as discussed above) will force the BCE within the > appropriate lifetime of existing prefixes. If the prefix has > expired, a particular error code could indicate the problem which > would cause the MN to solicit and advert and possibly form a new > HoA. > (3) Rely on the acknowledgment via BR/BA, even if these are carried > in a different packet than that for the prefix advertisement. > (4) Require the mobile node to make a solicited prefix query > as a form of acknowledgement. > (5) Add a separate ICMP message type for acknowledgement. > (6) Add a separate Mobility Option to the BA message to acknowledge > the receipt of a prefix advertisement. This may also require > adding an identifier to the advertisement to be able to match > advertisements and acknowledgements. > (7) Use a non-final MH for the BR message so that the ICMP > can also be carried in the same packet. > (8) Convert ICMP messages to MH messages. Then, the Mobile Prefix Advert > could contain a Unique ID parameter. The BU would act as an ack. > I personally think that all of the ICMP messages should be converted into mobility messages (via MH). Since the MH is now a full-fledged protocol, and not just a collection of destination options, why should we maintain the separate set of ICMP messages? By making the Mobile Prefix Advert into a mobility message, the Unique ID parameter could be sent along. Then a matching BU could be used to reply. enjoy, Bob -- /**************************************************************** Robert Chalmers UCSB Computer Science Doctoral Candidate Network and Multimedia Systems Lab (NMSL) "My heart is in the code, but my soul lies in the process" | robertc@cs.ucsb.edu || http://www.cs.ucsb.edu/~robertc/ | *****************************************************************/ From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 19:17:20 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10829 for ; Mon, 6 May 2002 19:17:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA26611; Mon, 6 May 2002 17:16:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10407; Mon, 6 May 2002 16:16:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46NB2rP022240 for ; Mon, 6 May 2002 16:11:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g46NB2Tj022239 for mobile-ip-dist; Mon, 6 May 2002 16:11:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g46NAwrP022232 for ; Mon, 6 May 2002 16:10:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08702 for ; Mon, 6 May 2002 16:11:00 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA01829 for ; Mon, 6 May 2002 17:10:59 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A675C6A904; Tue, 7 May 2002 02:10:52 +0300 (EEST) Message-ID: <3CD70DB1.6070001@piuha.net> Date: Tue, 07 May 2002 02:11:45 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: Tuomas Aura , "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark , Gabriel Montenegro Subject: Re: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <007d01c1e2b0$f69eac80$8a1b6e0a@arenanet.fi> <3CB9AC18.20205@piuha.net> <3CBE04FF.DD0C2869@iprg.nokia.com> <3CBED045.8050901@piuha.net> <3CBFAE5B.5030901@piuha.net> <3CC04E6F.23E002F5@iprg.nokia.com> <3CD5C07C.5050109@piuha.net> <3CD6FA6C.801B291@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >>* Tuomas and Jari think that a cookie alone would be sufficient >> for BA authentication, and Kbu should not be used due to the >> complexity it brings for the analysis of the security of RR. >> > > Sorry, I dont remember this. What additional complexity? Can > you please elaborate? There isn't much additional implementation or specification complexity, just use the same Kbu in the ack, add a MAC... but the worry was about the ability to understand the RR protocol and its properties. A cookie/seqno returned in an ack is understandable to everyone, but figuring out exactly what does Kbu buy or not buy in the ack is not trivial. This would make it hard to analyze whether the protocol has surprising problems, or what the exact security level is. Also, engineers taking a quick look at the protocol might be fooled into believing there is more security than there really is. In any case, we seem to agree on what to do, so... Jari From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 21:06:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12717 for ; Mon, 6 May 2002 21:06:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14529; Mon, 6 May 2002 19:05:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12623; Mon, 6 May 2002 18:05:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4712urP022470 for ; Mon, 6 May 2002 18:02:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4712tiL022469 for mobile-ip-dist; Mon, 6 May 2002 18:02:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.86.38] (may be forged)) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4712mrP022462 for ; Mon, 6 May 2002 18:02:52 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4712nUF020692; Mon, 6 May 2002 18:02:49 -0700 (PDT) Message-Id: <200205070102.g4712nUF020692@jurassic.eng.sun.com> Date: Mon, 6 May 2002 18:05:12 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Unresolved issue #18: Prefix advertisement acknowledgement To: jari.arkko@piuha.net Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tgSFuNrwdR4EYk2OLkzv7Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > 2. MN sends a BU anyway to stop further prefix adv (uses existing HOA ?) > > if the prefix information changes (renumbering), MN configures new HOA, > > > Yes. So, either the old or the new HoA is used but a BU is sent anyway. > > Ok. If the new HOA is used and old HOA prefix is still valid for sometime, then the HA would have to somehow store the new HOA in the binding cache (as well as the old HoA) in order to continue the ongoing data transfer until the old HOA becomes invalid. But there is more to it, ie. HA needs to update it's security association with the new HoA etc. > > If there is no prefix change, MN just updates the prefix lifetime > > information. > > Should the HA expect a BU at this point ? If HA expects BU as ACK > > only when prefix changes, then we can avoid extra signalling most > > of the time. > > > Good question. There are though rules that dictate when such unsolicited > prefix advs are to be sent. But if you do send one, how do you know what > the mobile node thinks the prefix is? Would the home agent be able to decide > that for this particular MN we don't need to wait for a BU, because it already > knew the prefix? > Yes. If the prefix does not change (no renumbering), then there is no change in HoA, the prefix adv contains the validity life time information. At that point HA does not expect any BU back from the MN (unreliable, but saves signaling bandwidth). MN receives the prefix and updates it's HoA validity lifetime, if for some reason it does not receive prefix adv for a period of time and it's valid life time expires, MN should solicit an advertisement. When HA knows that the prefix has changed (i,e new HOA to be formed), then it expects BU from the MN as an acknowledgement to make sure MN receives the prefix change information. I'd expect this situation would be infrequent. > > choice (2), does not require BR/BU sequence for prefix delivery. > > > > I wonder whether we need unique identifier parameter at all then ? > > > You are right, we don't need that in this alternative. Getting rid of the unique identifier perhaps will simplify things a bit. Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Mon May 6 21:20:26 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12901 for ; Mon, 6 May 2002 21:20:25 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11367; Mon, 6 May 2002 19:20:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA15872; Mon, 6 May 2002 18:19:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g471INrP022533 for ; Mon, 6 May 2002 18:18:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g471INOE022532 for mobile-ip-dist; Mon, 6 May 2002 18:18:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g471IKrP022525 for ; Mon, 6 May 2002 18:18:20 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA25354 for ; Mon, 6 May 2002 18:18:20 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA10904 for ; Mon, 6 May 2002 19:18:19 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA06924; Mon, 6 May 2002 18:18:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g471IHn14632; Mon, 6 May 2002 18:18:17 -0700 X-mProtect: <200205070118> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfIWw4Z; Mon, 06 May 2002 18:18:15 PDT Message-ID: <3CD72B58.F915298E@iprg.nokia.com> Date: Mon, 06 May 2002 18:18:16 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net CC: Tuomas Aura , "'mobile-ip@sunroof.eng.sun.com'" , Erik Nordmark , Gabriel Montenegro Subject: Re: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: <007d01c1e2b0$f69eac80$8a1b6e0a@arenanet.fi> <3CB9AC18.20205@piuha.net> <3CBE04FF.DD0C2869@iprg.nokia.com> <3CBED045.8050901@piuha.net> <3CBFAE5B.5030901@piuha.net> <3CC04E6F.23E002F5@iprg.nokia.com> <3CD5C07C.5050109@piuha.net> <3CD6FA6C.801B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > Vijay Devarapalli wrote: > > >>* Tuomas and Jari think that a cookie alone would be sufficient > >> for BA authentication, and Kbu should not be used due to the > >> complexity it brings for the analysis of the security of RR. > >> > > > > Sorry, I dont remember this. What additional complexity? Can > > you please elaborate? > > There isn't much additional implementation or specification complexity, > just use the same Kbu in the ack, add a MAC... but the worry was about > the ability to understand the RR protocol and its properties. A cookie/seqno > returned in an ack is understandable to everyone, but figuring out exactly > what does Kbu buy or not buy in the ack is not trivial. This would make it hard to > analyze whether the protocol has surprising problems, or what the exact > security level is. Also, engineers taking a quick look at the protocol > might be fooled into believing there is more security than there really > is. Jari, I dont agree that engineers would be fooled as you describe. I think they are much smarter!!. Having the MAC_Kbu with the BA would eliminate the need for random initialization for the sequence number. It can be as it used to be. I would appreciate it, if the sequence number is left as it is now. regards Vijay > > In any case, we seem to agree on what to do, so... > > Jari From owner-mobile-ip@sunroof.eng.sun.com Tue May 7 03:27:49 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29357 for ; Tue, 7 May 2002 03:27:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18541; Tue, 7 May 2002 00:25:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20776; Tue, 7 May 2002 00:25:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g477OcrP023133 for ; Tue, 7 May 2002 00:24:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g477OcqD023132 for mobile-ip-dist; Tue, 7 May 2002 00:24:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g477OYrP023125 for ; Tue, 7 May 2002 00:24:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20642 for ; Tue, 7 May 2002 00:24:35 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10289 for ; Tue, 7 May 2002 01:24:45 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g477OX0E025927 for ; Tue, 7 May 2002 09:24:33 +0200 (MEST) Received: FROM esealnt747.al.sw.ericsson.se BY esealnt461 ; Tue May 07 09:24:27 2002 +0200 Received: by ESEALNT747.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id <22815XQH>; Tue, 7 May 2002 09:23:59 +0200 Message-ID: From: "Karen E Nielsen (TED)" To: "'Vijay Devarapalli'" Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] RE: Unresolved issue #22: SHOULD or MUST for CN RO? Date: Tue, 7 May 2002 09:23:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Vijay, > > hi Karen, > > hope you dont mind me saying this. > On the contrary, I really appreciate it - Thanks ! > "Karen E Nielsen (TED)" wrote: > > > > > Does it really make sense to mandate (MUST) RO at CN's ? > > Without specifying a certain minimum BC size, a MUST will > have no real effect, and do we > > have a good idea about what this minimum size "MUST" be ? > > This is a very unreasonable statement. > > Anyway, the MUST that is being discussed is for "MUST implement". > It does not mean that the CN has to do RO all the time. > > The minimum size would depend on what the CN is. If it is a mobile > node a few binding cache entries (for your satisfaction maybe 5). > If it is a Yahoo server, maybe 1 million? :( > > Specifying something like that is really a bad idea. Couldn't agree more, that is why I thought that a "SHOULD" was better. However, I understand from all you much more experienced people that "SHOULD" IS indeed a BAD idea. and that "the MUST implement" is very important. I was thinking that mandating RO is really a lot to ask from all other Ipv6 nodes and that unless they maintained a BC of a certain size we would not gain anything from it - but I now understand that we really gain a lot from imposing the functionality as a standard Ipv6 functionality even if a sufficient size of the BC is not always maintained. Karen (I am sending this to the list - hope that's OK) From owner-mobile-ip@sunroof.eng.sun.com Tue May 7 05:40:54 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00988 for ; Tue, 7 May 2002 05:40:54 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21977; Tue, 7 May 2002 02:38:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA12374; Tue, 7 May 2002 02:38:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g479bTrP023346 for ; Tue, 7 May 2002 02:37:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g479bTfR023345 for mobile-ip-dist; Tue, 7 May 2002 02:37:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g479bQrP023338 for ; Tue, 7 May 2002 02:37:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29608 for ; Tue, 7 May 2002 02:37:28 -0700 (PDT) Received: from www.elites.org ([140.112.41.190]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11670 for ; Tue, 7 May 2002 02:37:14 -0700 (PDT) Received: from kernel (c114.h061016033.is.net.tw [61.16.33.114]) (authenticated) by www.elites.org (8.11.4/8.11.4) with ESMTP id g479aci40812 for ; Tue, 7 May 2002 17:36:39 +0800 (CST) Message-ID: <005801c1f5aa$9dc08590$0ea8a8c0@kernel> From: "Wayne Ying-Jui Lee" To: Subject: [mobile-ip] about hierarchical foreign agents (reg-tunnel-06.txt) Date: Tue, 7 May 2002 17:36:06 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, I read "Mobile IPv4 Regional Registration" (reg-tunnel-06) In appendix B, it's mentioned multiple hierarchy levels of FAs beneath the GFA level. However, as described in that, the FA MUST support smooth handover (specifically, the Previous FA Notification extension). It seems the extension of Route Optimization is needed. So, I should need to modify original CN to support RO, and then suit multiple levels of FAs?? Is it possible I use multiple levels of FAs without Previous FA Notification extension? Or, any other solutions? Thank you. Sincerely, -- Wayne Ying-Jui Lee From owner-mobile-ip@sunroof.eng.sun.com Tue May 7 05:47:48 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01095 for ; Tue, 7 May 2002 05:47:47 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15234; Tue, 7 May 2002 02:45:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13654; Tue, 7 May 2002 02:45:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g479iYrP023408 for ; Tue, 7 May 2002 02:44:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g479iYTY023407 for mobile-ip-dist; Tue, 7 May 2002 02:44:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g479iUrP023400 for ; Tue, 7 May 2002 02:44:31 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13213 for ; Tue, 7 May 2002 02:44:33 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17624 for ; Tue, 7 May 2002 03:44:32 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g479i6b15434; Tue, 7 May 2002 11:44:06 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA14320; Tue, 7 May 2002 11:44:06 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g479i5T39104; Tue, 7 May 2002 11:44:05 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205070944.g479i5T39104@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" cc: "Vijay Devarapalli" , jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Unresolved issue #22: SHOULD or MUST for CN RO? In-reply-to: Your message of Mon, 06 May 2002 13:31:19 PDT. <024101c1f53c$faabcad0$7e6015ac@T23KEMPF> Date: Tue, 07 May 2002 11:44:05 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > > Without RO, the roundtrip time now is even longer through the > > reverse tunnel. Route optimization should be "MUST" for CN, IMHO." > > > > Question: Is the text right? Should the keywords be MUST? > > Ofcourse 'MUST'. > Since the CN can be any node in the IPv6 Internet, doesn't this need to be passed by IPNG? => this is exactly what I think, i.e. the question is out of the scope (and charter) of the MIP WG. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue May 7 11:40:00 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13134 for ; Tue, 7 May 2002 11:39:59 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13082; Tue, 7 May 2002 09:39:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10521; Tue, 7 May 2002 08:39:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g47FcNrP024037 for ; Tue, 7 May 2002 08:38:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g47FcMxj024036 for mobile-ip-dist; Tue, 7 May 2002 08:38:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g47FcJrP024029 for ; Tue, 7 May 2002 08:38:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09710 for ; Tue, 7 May 2002 08:38:21 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29391 for ; Tue, 7 May 2002 09:38:20 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA02458; Tue, 7 May 2002 08:38:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g47FcGk12113; Tue, 7 May 2002 08:38:16 -0700 X-mProtect: <200205071538> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpDYW9W; Tue, 07 May 2002 08:38:14 PDT Message-ID: <3CD7F4E6.4EA6F2C2@iprg.nokia.com> Date: Tue, 07 May 2002 08:38:14 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group CC: Jari Arkko , Dave Johnson Subject: [mobile-ip] draft-ietf-mobileip-ipv6-17.txt for "Mobility Support in IPv6" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, A new draft of MobileIPv6 has been submitted to the Internet Draft directories. I have also posted it at the following URL: http://people.nokia.net/~charliep/txt/mobilev6/mobilev6.txt I'll be away until May 18, but I hope the new draft answers most or all of the issues that were raised regarding draft-...-16.txt Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed May 8 01:09:57 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03957 for ; Wed, 8 May 2002 01:09:56 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28597; Tue, 7 May 2002 23:09:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA15668; Tue, 7 May 2002 22:09:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4858FrP025302 for ; Tue, 7 May 2002 22:08:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4858F6F025301 for mobile-ip-dist; Tue, 7 May 2002 22:08:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4858CrP025294 for ; Tue, 7 May 2002 22:08:12 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA09222 for ; Tue, 7 May 2002 22:08:14 -0700 (PDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20256 for ; Tue, 7 May 2002 22:08:01 -0700 (PDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g4857rtp015693 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 7 May 2002 22:07:53 -0700 (PDT) Received: from JEFFD.qualcomm.com (jeffd.qualcomm.com [129.46.209.167]) by crowley.qualcomm.com (8.12.3/8.12.1/1.0) with ESMTP id g4857oTo015813; Tue, 7 May 2002 22:07:51 -0700 (PDT) Message-Id: <5.1.0.14.2.20020507220954.032a66b8@mail1.qualcomm.com> X-Sender: jeffd@mail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 07 May 2002 22:11:14 -0700 To: kleung From: Jeff Dyck Subject: Re: [mobile-ip] Length field definitions - rfc3115 Cc: mobile-ip@sunroof.eng.sun.com, gdommety@cisco.com In-Reply-To: <3CD6EBCB.BC919C47@cisco.com> References: <3C6FE255.C2FA49C3@attglobal.net> <3C6FEB76.650DEF8E@cisco.com> <3C7013C8.95CF05D1@attglobal.net> <3C709D67.C14840A7@cisco.com> <5.1.0.14.2.20020506122328.0c592420@mail1.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Thanks for the clarification. Is there any plan to update the RFC and if so when might that happen? Jeff At 01:47 PM 5/6/2002 -0700, kleung wrote: >The fields for CVSE and NVSE are different. So in summary... > >For CVSE > Length Length in bytes of this extension, not including the Type, > Length, and Reserved field bytes. > >For NVSE > Length Length in bytes of this extension, not including the Type > and Length field bytes. > >So consistency check remains ... > > > This one. Length is always what follows that field in the > > extension. This is consistent with 1.9, 1.10 and 1.11. > >Kent > >Jeff Dyck wrote: > > > Hi Kent, > > > > I realize this is an old topic, however your comment below seems to miss > > the contradiction. I thought I'd point it out once again to make sure you > > are aware. > > > > The reserved field precedes the length field, i.e. this is not consistent > > with the general definition of the length field where length is equal to > > the # of following bytes. In the case of the [CN]VSE it is # of bytes > > following + 1 byte (reserved). > > > > However, since 3115 is already standards track, I don't think this should > > be changed. > > > > Jeff > > > > At 03:41 PM 2/18/2002 -0600, Sebastian Thalanany wrote: > > >Hello Kent, > > > Thanks for the confirmation. > > > > > >Regards, > > > Sebastian > > > > > >kleung wrote: > > > > > > > Sebastian Thalanany wrote: > > > > > > > > > Hello Kent, > > > > > Since rfc3115 is based on rfc2002, which was > > > > > obsoleted last month by rfc3220, it would perhaps be preferrable to > > > > > update rfc3115 with the general format specification for a skippable > > > > > extension(NVSE) as specified in rfc3220. If the intent of the > > > > > "Reserved" field is to extend the Type field, as indicated in section > > > > > 1.10 and 1.11 of rfc3220, or for some other purpose, then perhaps the > > > > > following definitions for a CVSE element and an NVSE element may > avoid > > > > > ambiguities in interpretation: > > > > > > > > > > 1. CVSE > > > > > Length Length in bytes of the Value(data) field > > > > > within > > > > > this extension. It does NOT include the bytes associated with the > > > > > Type, Length and the Reserved fields. > > > > > > > > > > > > > > > 2. NVSE > > > > > Length Length in bytes of the Value(data) field within > > > > > this extension. It does NOT include the bytes associated with the > > > > > Type, Length and the Reserved fields. > > > > > > > > > > > > > Not this. > > > > > > > > > > > > > > or > > > > > > > > > > Length Length in bytes of the Value(data) field within > > > > > this extension. It does NOT include the bytes associated with the > > > > > Type, Length fields. The Length field MUST be set to 2 plus the > length > > > > > > > > > > of the Value(data) field, where the additional two octets are > required > > > > > > > > > > to include the length of the Reserved field. > > > > > > > > > > > > This one. Length is always what follows that field in the > > > extension. This is consistent with 1.9, 1.10 and 1.11. > > > > > > > > Thanks. > > > > > > > > Kent > > > > > > > > > > > > > > For the NVSE, please confirm one of the two proposed > > > > > definitions. > > > > > > > > > > Thanks. > > > > > > > > > > Regards, > > > > > Sebastian > > > > __________________________________________________ > > Jeffrey Dyck, Engineer > > QUALCOMM CDMA Technologies > > (858) 845-7548 > > jeffd@qualcomm.com > >-- > | | Kent Leung > :|: :|: IOS Development > :|||: :|||: Voice: 408.526.5030 > :|||||||: :|||||||: Email: kleung@cisco.com >.:|||||||||:.:|||||||||:. URL : http://wwwin-mobileip:8000 > c i s c o S y s t e m s "Enabling the mobile wireless age!" __________________________________________________ Jeffrey Dyck, Engineer QUALCOMM CDMA Technologies (858) 845-7548 jeffd@qualcomm.com From owner-mobile-ip@sunroof.eng.sun.com Wed May 8 04:22:12 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28765 for ; Wed, 8 May 2002 04:22:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA04869; Wed, 8 May 2002 01:18:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA29661; Wed, 8 May 2002 01:18:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g488HfrP026667 for ; Wed, 8 May 2002 01:17:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g488Hfxn026666 for mobile-ip-dist; Wed, 8 May 2002 01:17:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g488HbrP026659 for ; Wed, 8 May 2002 01:17:37 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA10220 for ; Wed, 8 May 2002 01:17:38 -0700 (PDT) Received: from ora.sanfront.com.cn ([159.226.6.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA13406 for ; Wed, 8 May 2002 02:17:37 -0600 (MDT) Received: (qmail 19899 invoked from network); 8 May 2002 08:18:33 -0000 Received: from unknown (HELO peter) (210.72.13.221) by -v with SMTP; 8 May 2002 08:18:33 -0000 Message-ID: <015301c1f669$066de970$dd0d48d2@peter> From: "Feng Yanjun" To: Subject: [mobile-ip] A new Draft using MIPv6 Date: Wed, 8 May 2002 16:19:08 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0150_01C1F6AC.1481E730" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0150_01C1F6AC.1481E730 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBBbGwsDQoNCkkgc3VibWl0dGVkIGEgZHJhZnQgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQteWFuanVuLWxiYW0taXB2Ni0wMC50eHQsIA0Kd2hpY2ggbWFpbmx5 IHJldXNlIE1JUHY2IGFuZCBBbnljYXN0Lg0KQWxsIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZCB2 ZXJ5IG11Y2ghICAgOi0pDQoNCkFic3RyYWN0DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBh IG1ldGhvZCB1c2luZyBwc2V1ZG8tYW55Y2FzdCBhbmQgcHNldWRvLQ0KICAgbW9iaWxpdHkgYmFz ZWQgb24gTW9iaWxlIElQdjYsIHdoaWNoIGltcGxlbWVudCBsb2FkIGJhbGFuY2luZyBpbiANCiAg IHNlc3Npb24gbGV2ZWwgaW4gSXB2NiBuZXR3b3JrLCB3aXRob3V0IHRob3NlIHByb2JsZW1zIG9m IHRyYWRpdGlvbmFsIA0KICAgbG9hZCBiYWxhbmNpbmcgbWV0aG9kcyAoTG9hZCBiYWxhbmNpbmcg YnkgRE5TLCBOQVQpIHN1Y2ggYXMgDQogICB0cmlhbmdsZSByb3V0aW5nLCBsb25nIGxhdGVuY3kg dGltZSwgcG9vciBzY2FsYWJpbGl0eSwgZXRjLg0KIA0KICAgVGhlIHRocmVlIGVudGl0aWVzIGlu IExCQU0gKHNlcnZlciwgQWdlbnQsIENOKSBjb3JyZXNwb25kIHRvIE1OLCBIQSwgQ04gDQogICBp biBNSVB2Ni4gTEJBTSBuZWVkcyBsaXR0bGUgbW9kaWZpY2F0aW9uIG9mIE1JUHY2OiBhdCBTZXJ2 ZXIgc2lkZSwgb25seSANCiAgIG9uZSBuZXcgSGVhZGVyIFBhcmFtZXRlciBpcyBhZGRlZDthdCBB Z2VudCBzaWRlLCBvbmx5IGEgQ2FjaGUgdG8gbG9nIA0KICAgbG9hZCBiYWxhbmNpbmcgaGlzdG9y eSBmb3IgbG9hZCBiYWxhbmNpbmcgYWxnb3JpdGhtIGlzIGFkZGVkLiBFeGNlcHRzIA0KICAgdGhl IGJvdGggcG9pbnRzIGFib3ZlLCB0aGVyZSBpcyBub3QgYW55IG1vZGlmaWNhdGlvbiAgdG8gTUlQ djYuDQogDQogICBUaGUgcHJvY2VzcyBpcyBhcyBmb2xsb3dzOg0KICAgRmlyc3RseSwgd2hlbiB0 aGUgQ04gc2VuZHMgaW5pdGlhbCBJUCBwYWNrZXQgdG8gdGhlIExCQSBhZGRyZXNzIA0KICAgKHRo b3NlIHNlcnZlcnMnIEhvbWUgYWRkcmVzcyksIHRoZSBMQkFNIGFnZW50IHJlY2VpdmVzIHRoaXMg cGFja2V0IA0KICAgYW5kIHR1bm5lbHMgdGhpcyBwYWNrZXQgdG8gYSBzZXJ2ZXIgKHNheWluZyBz ZXJ2ZXItaSkgYnkgc29tZSBsb2FkIA0KICAgYWxnb3JpdGhtIHVzaW5nIElQdjYgZW5jYXBzdWxh dGlvbi4gVGhlbiwgd2hlbiB0aGUgU2VydmVyLWkgcmVjZWl2ZXMNCiAgIHRoaXMgdHVubmVsZWQg cGFja2V0LCBpdCB3aWxsIHNlbmQgQmluZGluZyBVcGRhdGUgbWVzc2FnZSB0byB0aGUgQ04uDQog ICBBZnRlciByZWNlaXZpbmcgQmluZGluZyBVcGRhdGUgIG1lc3NhZ2UsIENOIHdpbGwgY29tbXVu aWNhdGUgd2l0aCANCiAgIHNlcnZlci1pIGRpcmVjdGx5LCBieSB3aGljaCBsb2FkcyBhcmUgYmFs YW5jZWQuDQogDQpDaGVlcnMNCi0tIFlhbmp1biBGZW5nDQogIA0K ------=_NextPart_000_0150_01C1F6AC.1481E730 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC40NTIyLjE4MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+RGVhciBB bGwsPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+SSBzdWJtaXR0ZWQgYSBkcmFmdCA8L0ZPTlQ+PEEgDQpo cmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC15YW5qdW4tbGJh bS1pcHY2LTAwLnR4dCI+PEZPTlQgDQpmYWNlPcvOzOU+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQteWFuanVuLWxiYW0taXB2Ni0wMC50eHQ8L0ZPTlQ+PC9BPjxGT05U IA0KZmFjZT3LzszlPiwgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+d2hpY2gg bWFpbmx5IHJldXNlIE1JUHY2IGFuZCBBbnljYXN0LjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQg ZmFjZT3LzszlPkFsbCBjb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQgdmVyeSBtdWNoISAmbmJzcDsg DQo6LSk8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9y87M5T48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIGZhY2U9y87M5T5BYnN0cmFjdDxCUj4mbmJzcDsmbmJzcDsgVGhpcyBk b2N1bWVudCBkZXNjcmliZXMgYSBtZXRob2QgDQp1c2luZyBwc2V1ZG8tYW55Y2FzdCBhbmQgcHNl dWRvLTxCUj4mbmJzcDsmbmJzcDsgbW9iaWxpdHkgYmFzZWQgb24gTW9iaWxlIElQdjYsIA0Kd2hp Y2ggaW1wbGVtZW50IGxvYWQgYmFsYW5jaW5nIGluJm5ic3A7PEJSPiZuYnNwOyZuYnNwOyBzZXNz aW9uIGxldmVsIGluIElwdjYgDQpuZXR3b3JrLCB3aXRob3V0IHRob3NlIHByb2JsZW1zIG9mIHRy YWRpdGlvbmFsJm5ic3A7PEJSPiZuYnNwOyZuYnNwOyBsb2FkIA0KYmFsYW5jaW5nIG1ldGhvZHMg KExvYWQgYmFsYW5jaW5nIGJ5IEROUywgTkFUKSBzdWNoIGFzJm5ic3A7PEJSPiZuYnNwOyZuYnNw OyANCnRyaWFuZ2xlIHJvdXRpbmcsIGxvbmcgbGF0ZW5jeSB0aW1lLCBwb29yIHNjYWxhYmlsaXR5 LCANCmV0Yy48QlI+Jm5ic3A7PEJSPiZuYnNwOyZuYnNwOyBUaGUgdGhyZWUgZW50aXRpZXMgaW4g TEJBTSAoc2VydmVyLCBBZ2VudCwgQ04pIA0KY29ycmVzcG9uZCB0byZuYnNwO01OLCBIQSwgQ04g PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+Jm5ic3A7Jm5ic3A7IGluIE1JUHY2 LiBMQkFNIG5lZWRzIGxpdHRsZSZuYnNwOzwvRk9OVD48Rk9OVCANCmZhY2U9y87M5T5tb2RpZmlj YXRpb24gb2YgTUlQdjY6Jm5ic3A7YXQgU2VydmVyIHNpZGUsIG9ubHkgPC9GT05UPjwvRElWPg0K PERJVj48Rk9OVCBmYWNlPcvOzOU+Jm5ic3A7Jm5ic3A7IG9uZSBuZXcmbmJzcDtIZWFkZXIgUGFy YW1ldGVyJm5ic3A7aXMgDQphZGRlZDs8L0ZPTlQ+PEZPTlQgZmFjZT3LzszlPmF0Jm5ic3A7QWdl bnQgc2lkZSwmbmJzcDtvbmx5IGEgQ2FjaGUgdG8gbG9nIA0KPC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPcvOzOU+Jm5ic3A7Jm5ic3A7IGxvYWQgYmFsYW5jaW5nIGhpc3RvcnkmbmJzcDtm b3ImbmJzcDtsb2FkIA0KYmFsYW5jaW5nIGFsZ29yaXRobTwvRk9OVD48Rk9OVCBmYWNlPcvOzOU+ Jm5ic3A7aXMgYWRkZWQuIEV4Y2VwdHMgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvO zOU+Jm5ic3A7Jm5ic3A7IHRoZSBib3RoIHBvaW50cyBhYm92ZSwgdGhlcmUgaXMgbm90IGFueSAN Cm1vZGlmaWNhdGlvbiZuYnNwOyB0byBNSVB2Ni48QlI+Jm5ic3A7PEJSPiZuYnNwOyZuYnNwOyBU aGUgcHJvY2VzcyBpcyBhcyANCmZvbGxvd3M6PEJSPiZuYnNwOyZuYnNwOyBGaXJzdGx5LCB3aGVu IHRoZSBDTiBzZW5kcyBpbml0aWFsIElQIHBhY2tldCB0byB0aGUgTEJBIA0KYWRkcmVzcyZuYnNw OzxCUj4mbmJzcDsmbmJzcDsgKHRob3NlIHNlcnZlcnMnIEhvbWUgYWRkcmVzcyksIHRoZSBMQkFN IGFnZW50IA0KcmVjZWl2ZXMgdGhpcyBwYWNrZXQmbmJzcDs8QlI+Jm5ic3A7Jm5ic3A7IGFuZCB0 dW5uZWxzIHRoaXMgcGFja2V0IHRvIGEgc2VydmVyIA0KKHNheWluZyBzZXJ2ZXItaSkgYnkgc29t ZSZuYnNwO2xvYWQgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+Jm5ic3A7Jm5i c3A7IGFsZ29yaXRobSZuYnNwOzwvRk9OVD48Rk9OVCBmYWNlPcvOzOU+dXNpbmcgSVB2NiANCmVu Y2Fwc3VsYXRpb24uIFRoZW4sIHdoZW4gdGhlIFNlcnZlci1pIHJlY2VpdmVzPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+Jm5ic3A7ICZuYnNwO3RoaXMgdHVubmVsZWQmbmJzcDs8 L0ZPTlQ+PEZPTlQgZmFjZT3LzszlPnBhY2tldCwgDQppdCB3aWxsIHNlbmQmbmJzcDtCaW5kaW5n IFVwZGF0ZSBtZXNzYWdlIHRvIHRoZSBDTi48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 y87M5T4mbmJzcDsgJm5ic3A7QWZ0ZXIgcmVjZWl2aW5nJm5ic3A7PC9GT05UPjxGT05UIA0KZmFj ZT3LzszlPkJpbmRpbmcgVXBkYXRlJm5ic3A7IG1lc3NhZ2UsIENOIHdpbGwgY29tbXVuaWNhdGUg d2l0aCA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9y87M5T4mbmJzcDsmbmJzcDsgc2Vy dmVyLWkgZGlyZWN0bHksJm5ic3A7PC9GT05UPjxGT05UIGZhY2U9y87M5T5ieSANCndoaWNoIGxv YWRzIGFyZSBiYWxhbmNlZC48QlI+Jm5ic3A7PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNl PcvOzOU+Q2hlZXJzPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOU+LS0gWWFuanVu IEZlbmc8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9y87M5T4mbmJzcDsgPC9GT05UPjwv RElWPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= ------=_NextPart_000_0150_01C1F6AC.1481E730-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 8 07:29:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01195 for ; Wed, 8 May 2002 07:29:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07458; Wed, 8 May 2002 05:29:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05639; Wed, 8 May 2002 04:28:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48BS1rP026929 for ; Wed, 8 May 2002 04:28:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g48BS1Gx026928 for mobile-ip-dist; Wed, 8 May 2002 04:28:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48BRsrP026917 for ; Wed, 8 May 2002 04:27:54 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA11848 for ; Wed, 8 May 2002 04:27:55 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA22109 for ; Wed, 8 May 2002 05:27:54 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00814; Wed, 8 May 2002 07:27:46 -0400 (EDT) Message-Id: <200205081127.HAA00814@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-ipv6-17.txt Date: Wed, 08 May 2002 07:27:45 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : D. Johnson, C. Perkins, J. Arkko Filename : draft-ietf-mobileip-ipv6-17.txt Pages : 167 Date : 07-May-02 This document specifies the operation of mobile computers using IPv6. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, MUST support communications with mobile nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-17.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-ipv6-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-ipv6-17.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: <20020507124225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-ipv6-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-ipv6-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020507124225.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 8 07:54:51 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02035 for ; Wed, 8 May 2002 07:54:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15920; Wed, 8 May 2002 05:54:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18896; Wed, 8 May 2002 04:54:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48BrUrP026992 for ; Wed, 8 May 2002 04:53:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g48BrUj7026991 for mobile-ip-dist; Wed, 8 May 2002 04:53:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48BrQrP026984 for ; Wed, 8 May 2002 04:53:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18774 for ; Wed, 8 May 2002 04:53:28 -0700 (PDT) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA18021 for ; Wed, 8 May 2002 05:53:27 -0600 (MDT) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 8 May 2002 04:53:26 -0700 Received: from 157.54.6.150 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 08 May 2002 04:53:26 -0700 Received: from red-msg-09.redmond.corp.microsoft.com ([157.54.12.7]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 8 May 2002 04:53:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] Unresolved issue #3: BA, BR authentication? Date: Wed, 8 May 2002 04:53:25 -0700 Message-ID: Thread-Topic: [mobile-ip] Unresolved issue #3: BA, BR authentication? thread-index: AcH1ZRRtEg2uqUX7SoGiVITGBUNh2ABH3ZvA From: "Tuomas Aura" To: X-OriginalArrivalTime: 08 May 2002 11:53:26.0053 (UTC) FILETIME=[F6401550:01C1F686] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g48BrRrP026985 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > I dont agree that engineers would be fooled as you describe. I think > they are much smarter!!. Having the MAC_Kbu with the BA would eliminate > the need for random initialization for the sequence number. It can be > as it used to be. I would appreciate it, if the sequence number is left > as it is now. I'm not sure that we engineers are so smart. The fact that K_bu in the current protocol can be used for BA authentication was simply an accident. It did not happen by design. I was very much surprised when I realized that the cookie exchanges in CoT/CoTI/Hot/HoTI give K_bu this property. I do not want to use K_bu for BA authentication for two reasons: (1) As say before, it is difficult to understand how and why it works. (2) It is fragile. Any change to the way the protocol is used might break the BA authentication. For example, what happens if the cookies in CoT/CoTI or Hot/HoTI are reused or if the cookie in HoT/HoTI is replaced with a key established in some other way? (I could not answer this without taking another look.) I do believe that using K_bu for BA authentication in the current, full, and unchanged protocol does give small theoretical security advantage. (My colleague Ernie Cohen even verified this formally.) Nevertheless, for the two reasons listed above, I think using K_bu for BA authentication is a bad idea. Tuomas From owner-mobile-ip@sunroof.eng.sun.com Wed May 8 13:23:25 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17170 for ; Wed, 8 May 2002 13:23:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24344; Wed, 8 May 2002 10:21:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06899; Wed, 8 May 2002 10:21:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48HKIrP027348 for ; Wed, 8 May 2002 10:20:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g48HKIdV027347 for mobile-ip-dist; Wed, 8 May 2002 10:20:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48HKFrP027340 for ; Wed, 8 May 2002 10:20:15 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05418 for ; Wed, 8 May 2002 10:20:16 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25491 for ; Wed, 8 May 2002 11:20:15 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA07396; Wed, 8 May 2002 10:20:15 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g48HKED02419; Wed, 8 May 2002 10:20:14 -0700 X-mProtect: <200205081720> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpddpIuJP; Wed, 08 May 2002 10:20:12 PDT Message-ID: <3CD95E4D.DED4518E@iprg.nokia.com> Date: Wed, 08 May 2002 10:20:13 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Tuomas Aura CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Unresolved issue #3: BA, BR authentication? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Tuomas Aura wrote: > I'm not sure that we engineers are so smart. > The fact that K_bu in the current protocol can be used for > BA authentication was simply an accident. It did not happen > by design. I was very much surprised when I realized that > the cookie exchanges in CoT/CoTI/Hot/HoTI give K_bu this > property. > > I do not want to use K_bu for BA authentication for two > reasons: > (1) As say before, it is difficult to understand how > and why it works. Again, I have no clue why you say this. > (2) It is fragile. Any change to the way the protocol is > used might break the BA authentication. For example, > what happens if the cookies in CoT/CoTI or Hot/HoTI > are reused or if the cookie in HoT/HoTI is replaced with > a key established in some other way? > (I could not answer this without taking another look.) Tuomas, A key is needed for protecting the BU and BA. That is Kbu. Once we have the key, it is simple calculating MAC over the BU and the BA. Now, Lets see how Kbu is obtained. 1. A complete HoTI/HoT and CoTI/CoT exchange. 2. A reused home cookie and CoTI/CoT exchange. 3. A static key between the MN and a known CN. 4. Some other scheme. So, why is this fragile??? Do you realise that the CN and MN already have the Kbu, and they dont have to do anything extra for additional protection for the BA? > I do believe that using K_bu for BA authentication in the > current, full, and unchanged protocol does give small > theoretical security advantage. (My colleague Ernie Cohen even > verified this formally.) Nevertheless, for the two reasons > listed above, I think using K_bu for BA authentication is a > bad idea. Sorry, I dont buy your two reasons. A couple of points I guess we agree on. 1. The protection for BA is not as strong as protection for BU in the RR procedure. 2. The Kbu used on BA gives some additional protection (irrespective of how Kbu is obtained). Kbu by itself does not provide protection. It is in addition to the sequence number in the BA. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed May 8 17:58:43 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24940 for ; Wed, 8 May 2002 17:58:42 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19679; Wed, 8 May 2002 14:56:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20810; Wed, 8 May 2002 14:56:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48LtRrP027860 for ; Wed, 8 May 2002 14:55:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g48LtRFW027859 for mobile-ip-dist; Wed, 8 May 2002 14:55:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48LtOrP027852 for ; Wed, 8 May 2002 14:55:24 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20420 for ; Wed, 8 May 2002 14:55:20 -0700 (PDT) Received: from io.irean.vt.edu (io.irean.vt.edu [128.173.52.32]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24725 for ; Wed, 8 May 2002 14:55:20 -0700 (PDT) Received: (from wells@localhost) by io.irean.vt.edu (8.11.6/8.11.6) id g48LtJE26343; Wed, 8 May 2002 17:55:19 -0400 X-Authentication-Warning: io.irean.vt.edu: wells set sender to wells@ieee.org using -f Subject: [mobile-ip] Cisco mobile networks move detection question From: John Wells To: mobile-ip@sunroof.eng.sun.com Cc: monet@nal.motlabs.com Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 08 May 2002 17:55:19 -0400 Message-Id: <1020894919.8898.1473.camel@io.irean.vt.edu> Mime-Version: 1.0 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: (warning: cross-posted to MONET and MIP lists) Content-Transfer-Encoding: 7bit Hi all, I have a question on Cisco's v4 mobile network implementation's move detection algorithm. If a Cisco mobile router is registered with one foreign agent and hears an advertisement from another foreign agent, it automatically registers with the new foreign agent and uses the new address, as far as I can tell. This would seem to contradict the Mobile IP RFC, which provides for two move detection algorithms (RFC 2002, s 2.4.2): one based on router advertisement expirations, the other based on the prefix-length extension. Cisco routers do not broadcast prefix-length extensions, so the latter is not possible. It would seem that Cisco's algorithm might result in oscillation in the case of two foreign agents on the same subnet, for example in wireless scenarios. Any thoughts? Thanks, John -- John Wells, Virginia Tech Networking Lab (tel) +1 540 231-8347 (web) http://www.ee.vt.edu/~wells From owner-mobile-ip@sunroof.eng.sun.com Wed May 8 18:38:13 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25508 for ; Wed, 8 May 2002 18:38:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13843; Wed, 8 May 2002 15:36:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA07392; Wed, 8 May 2002 15:36:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48MZErP027936 for ; Wed, 8 May 2002 15:35:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g48MZEMu027935 for mobile-ip-dist; Wed, 8 May 2002 15:35:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48MZBrP027925 for ; Wed, 8 May 2002 15:35:11 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10854 for ; Wed, 8 May 2002 15:35:13 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12458 for ; Wed, 8 May 2002 16:35:12 -0600 (MDT) Message-ID: <01be01c1f6e0$6321ef00$7e6015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] Error DOS Attack? Date: Wed, 8 May 2002 15:33:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Section 6.1.1 of draft 17 specifies that an error is sent to the source if the MH type is not recognized (pg. 32). An attacker could pump packets at the CN or MN with erroneous MH type values, and the attacked node would have to continue replying, thus tying it up. None of the rest of the RR protocol seems to have any error returns, so this would be the only place that it could occur. Is this worth worrying about? jak From owner-mobile-ip@sunroof.eng.sun.com Wed May 8 19:14:43 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26005 for ; Wed, 8 May 2002 19:14:43 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA02256; Wed, 8 May 2002 17:14:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA22611; Wed, 8 May 2002 16:13:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48NCxrP028028 for ; Wed, 8 May 2002 16:12:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g48NCx5s028027 for mobile-ip-dist; Wed, 8 May 2002 16:12:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g48NCurP028020 for ; Wed, 8 May 2002 16:12:56 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23529 for ; Wed, 8 May 2002 16:12:58 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09600 for ; Wed, 8 May 2002 17:12:57 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA26851; Wed, 8 May 2002 16:12:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g48NCue26762; Wed, 8 May 2002 16:12:56 -0700 X-mProtect: <200205082312> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.164, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJQrCnY; Wed, 08 May 2002 16:12:53 PDT Message-ID: <3CD9B0DB.2060802@iprg.nokia.com> Date: Wed, 08 May 2002 16:12:27 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20020314 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Brian Haley CC: Charlie Perkins , mobile-ip@sunroof.eng.sun.com Subject: Re: [Fwd: [mobile-ip] S-bit and building a link-local address] References: <3CD7E4AB.617F8688@compaq.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Brian, sorry for the late reply. from 2462 Section 5.3 A link-local address is formed by prepending the well-known link- local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the interface identifier. If the interface identifier has a length of N bits, the interface identifier replaces the right-most N zero bits of the link-local prefix. If the interface identifier is more than 118 bits in length, autoconfiguration fails and manual configuration is required. Note that interface identifiers will typically be 64-bits long and based on EUI-64 identifiers as described in [ADDR-ARCH]. since the home agent knows the prefix length of the home link and thereby the interface id length of the MN's HoA, it can construct the link local address for the MN. if the mobile node knows that it uses a different interface id for the link local address and the home address, it should always set the 'S' bit to 1. Then the home agent would defend only the home address. regards Vijay Brian Haley wrote: > Hi Charlie and Vijay, > > On April 23rd I raised an issue about the S-bit in Binding Updates on > the mailing list that had only one response (Francis Dupont), hardly > consensus. Jari put it on the issues list for the draft, but wanted me to > get more input on it. Instead of re-posting to the list, I figured I'd > send mail to you two since Charlie's the co-author and I've talked to > Vijay about other draft things. > > If you want to post a reponse to the list, that's fine, I just wanted to > make sure other people hadn't missed it. Francis had the same > conclusion I did btw... > > Thanks, > > -Brian > > > ------------------------------------------------------------------------ > > Subject: > > [mobile-ip] S-bit and building a link-local address > From: > > Brian Haley > Date: > > Tue, 23 Apr 2002 17:55:27 -0400 > To: > > mobile ip > > > Hi, > > I have an issue with the use of the S-bit in Binding Updates. > > I'll start with a hard question: > > Where can I find the spec/RFC that defines how to build a link-local address > from a global unicast address? > > The BU only has the global address, and I think everyone's assuming /64 prefix > lengths, but according to the addressing architecture > (draft-ietf-ipngwg-addr-arch-v3-07.txt, soon to update RFC 2373), that's not > the case: > > Section 2.5.4 on Global Unicast Addresses > > "All global unicast addresses other than those that start with binary > 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as > described in section 2.5.1. Global unicast addresses that start with > binary 000 have no such constraint on the size or structure of the > interface ID field." > > I've been struggling with this one for a while, but it doesn't seem like we > can just mask-off the upper 64 bits, stuff an FE80 in there, and call it a > link-local address. This isn't even considering the IPv6-over-foo RFCs. > > So if that question can't be answered, I feel the S-bit must be removed > from the draft, unless someone is willing to write-up the method in > question, but since building link-local addresses has media type > implications, I wasn't going to go there. > > This also has ramifications with the D-bit since Section 9.1 of the > Mobile IPv6 spec says we must do DAD for the link-local address. > > Am I missing something here? > > -Brian > > From owner-mobile-ip@sunroof.eng.sun.com Wed May 8 20:16:20 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26961 for ; Wed, 8 May 2002 20:16:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06500; Wed, 8 May 2002 17:14:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22591; Wed, 8 May 2002 17:14:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g490DGrP028178 for ; Wed, 8 May 2002 17:13:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g490DGN0028177 for mobile-ip-dist; Wed, 8 May 2002 17:13:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g490DDrP028170 for ; Wed, 8 May 2002 17:13:13 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g490DG93326230; Wed, 8 May 2002 17:13:16 -0700 (PDT) Message-Id: <200205090013.g490DG93326230@jurassic.eng.sun.com> Date: Wed, 8 May 2002 17:15:39 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Re: More comments on Draft16 -CLARIFICATION To: jari.arkko@piuha.net Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7X+w220Dd/G3bn5COfJqpA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sorry, I am a bit behind the mails in the alias. > >>I believe their use is optional, not support? > > > > Yes, their use is optional. So, if a CN receives a message with > > alt COA (for example) and if it does not know how to process it, > > should not it send BA with status that this parameter type is > > not supported ? If we don't have such a status, what should CN > > send to MN in this case ? > > I suppose there are four different possible cases: > > 1) A mandatory-to-support parameter in a legal position in some message. E.g. > Alt-CoA in a BU. I don't think the CN should be allowed to complain about this. > Do you mean to say Alt-CoA in BU (ie. parameter type =3) could be mandatory to support ? > 2) A mandatory-to-support parameter in a bad position, e.g. Alt-CoA in a BA > when the BU didn't contain any Alt-CoA. I'm not quite sure what we should do > about this. > Drop the packet or optionally send "reason unspecified" ? But that is not very clear message. > 3) A parameter that isn't defined in the base standard but whose support is > mandatory. I'm not sure we want to have these. > Agree. > 4) A parameter that isn't defined in the base standard and which is optional. > No problem here. > So what do we do in this case ? This is the case I am concerned about. Shouldn't CN send a BA with a status error if acknowledgement is requested ? What that error should be ? Or do we send MH error header back in this case? One way is to drop the packet (if ACK is not requested), otherwise send BA with a "parameter type not supported" status error with the BA if ACK is requested. Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Wed May 8 22:15:00 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29710 for ; Wed, 8 May 2002 22:15:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21568; Wed, 8 May 2002 20:14:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA13104; Wed, 8 May 2002 19:14:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g492DQrP028281 for ; Wed, 8 May 2002 19:13:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g492DQVL028280 for mobile-ip-dist; Wed, 8 May 2002 19:13:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g492DNrP028273 for ; Wed, 8 May 2002 19:13:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12804 for ; Wed, 8 May 2002 19:13:25 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA00971 for ; Wed, 8 May 2002 20:13:24 -0600 (MDT) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 22:13:23 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C3737C@ftmail> From: "Alan O'Neill" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Regional MIP Drafts from Flarion Date: Wed, 8 May 2002 22:13:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Folks, I have submitted the following drafts as mentioned last week that relate to the regional tunneling issues that we have been discussing. I guess they won't be availabe for a couple of days yet so I will send out a link to the drafts on the Flarion web-site (www.flarion.com) as soon as they are available there. Nested MIP for Mobility Management Parallel MIP for Mobility Management Concatenated MIP for Mobility Management Regional Mobility Agent Signalling Proxy CCoA Tunneling for Mobile IP For those interested I have enclosed the abstracts in a separate e-mail but an overall summary is below. The recommended reading order is as shown above. The drafts aim to address a requirement that appears to be unaddressed by existing specs. Regional tunneling provides localisation of signalling but it does not provide aggregation of signalling when a MN has multiple HoAs. MIP signalling is presently HA/HoA specific and hence multiple HoAs leads to 'Parallel MIP' hand-off signalling (issues covered in Parallel draft) to the HA and the oFA, and also to any intermediate regional element. Multiple HoAs are required for concurrent local and remote access sessions, and also for third party content/application service provider networks. The architecture also aims to cleanly separate out the different operator control requirements for local and remote access traffic. Nested and Concatenated MIP are two alternative ways to address this requirement, both of which also address localisation (note that GFA type forwarding can also be supported with some constraints). They both use two layers of MIP signaling, the Local Access layer and the Remote Access layer to decouple intra operator from inter-operator concern. Nested MIP using encapsulation between the layers whilst Concatenated using switching between the two layers to address the requirements. The LA layer runs between the MN, FA and a Regional Mobility Agent that can be thought of as a local HA for now. The RMA allocates a Regional address (RoA)to the MN which it can use as a valid interface address for local access within the region of the RMA. The RoA is also used as the CCoA for a potential multitude of remote access MIP sessions in the RA layer (and can also be used for IPSRA or PPTP sessions). This then enables an MIP hand-off at the LA to also move all RA layer sessions at the same time. The RoA is valid within a region and therefore localisation is achieved for hand-offs within that region, until the RoA has to change. The clean separation of the two layers (local and remote) brings a wide range of benefits but there are of course costs as mentioned in the documents. For example, on the plus side, packets to the RoA are routed through the RMA rather than as a result of switching state and therefore the RMA regional element is more amenable to routing based recovery. On the downside, packets are encapsulated over the air-interface due to the use by the MN of a CCoA at the RA layer. This is addressed in a generic way for CCoAs by adding an MIP address mode called Proxy CCoAs where the tunnel management for the CCoA is left to the FA. Basic Nested MIP can be deployed with very little impact on existing MIP standards - a critical characteristic for Flarion. Enhanced features require signalling enhancements, and specifically we want to share the 'I' bit and HFAext/HFAIPext mechs from [RegTun],[RegTunmods] as the RMA can also support GFA and the mechanisms for the different forwarding modes are very similar. Concatenated mode and GFA mode are only available if the home registration is routed via the RMA. The RMA signalling draft is a very long document which overviews the detailed signalling mechanisms required to support Nested, Concat and GFA modes in an RMA through a number of evolution steps that support RMA hand-off between the modes. I think all required changes are fully backwards compatible although don't quote me yet. This draft also adds a number of features to the integrated model. There are many issues yet to be solved and I hope that if the wg appreciates the solution that a work programme can be defined. This will definitely require significant draft rewrites to break the work into manageable evolutionary chunks. When comparing RMA to the GFA from Reg Tun, the key differences are that the regional reg in GFA happens after the home reg whilst the opposite is true for RMA, the GFA is less amenable to routing based recovery, the GFA does not support signalling aggregation and the GFA has some additional issues with private / public address support. The GFA is however very efficient for a single RA or LA session per MN and the forwarding rules are obviously less complex under these conditions. As a final point I would recommend people take a bit of time to read and digest these docs before bringing detailed discussions to the list. There is a lot of information and the complete cost/benefit story takes a fair amount of processing. Regards, Alan O'Neill Flarion Technologies. From owner-mobile-ip@sunroof.eng.sun.com Wed May 8 22:19:20 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29802 for ; Wed, 8 May 2002 22:19:19 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA20777; Wed, 8 May 2002 20:18:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14744; Wed, 8 May 2002 19:18:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g492I4rP028333 for ; Wed, 8 May 2002 19:18:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g492I4ef028332 for mobile-ip-dist; Wed, 8 May 2002 19:18:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g492I1rP028325 for ; Wed, 8 May 2002 19:18:01 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17069 for ; Wed, 8 May 2002 19:18:03 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA28268 for ; Wed, 8 May 2002 19:18:03 -0700 (PDT) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 22:18:02 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C3737D@ftmail> From: "Alan O'Neill" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Regional abstracts Date: Wed, 8 May 2002 22:17:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Abstract as promised, Alan. ------------------------------------------------------------ Abstract (Nested) Regional Registration provides a mechanism for MIPv4 to localise registrations. The Mobile Node (MN) initially registers to the HA via the Gateway Foreign Agent (GFA) so that the HA can learn the GFA Care of Address (CoA). The MN can then subsequently use a Regional Registration to maintain the binding in the GFA as the MN moves and changes its Foreign Agent (FA) CoA or Collocated CoA (CCoA). It can continue to do so whilst a MN remains under the GFA through which the MN sent the Home Registration. The GFA performs CoA switching between the GFA CoA and that used by the MN (CCoA or FA CoA). Whilst the regional registration provides localisation, it does not at the same time provide registration aggregation for MNs employing multiple HoAs. The ability to concurrently support multiple MN addresses from arbitrary addressing domains is a 3GPP commercial and technical requirement and therefore of interest to operators seeking to move to an all-IP solution based on MIP. In addition, the GFA is a very stateful element in the core of the Internet that cannot be bypassed on failure through routing updates. This draft describes a complementary, less stateful model for localisation that in addition supports aggregation both for regional-like registration and hand-offs. The model re-uses as much as possible from the home registration signalling model of [RegTun] but requires a new form of aggregated regional registration. ----------------------------------------------------------- Abstract (Parallel) Nested MIP [NestMIP] provides a means to support both localization and aggregation of MIP signalling. It achieves this by providing two distinct layers of MIP signalling and forwarding; a local access layer that provides local mobility management and local access services, and a remote access layer that provides remote access back to a home subnet. Nested MIP and an associated proposal, Concatenated MIP [ConcatMIP] are necessary because existing MIP signalling is HA/HoA specific and therefore not easily amenable to aggregation for supporting multiple MIP sessions per MN. This document describes an alternative proposal for introducing aggregation that has significantly lower functionality but that is a smaller change from existing MIP standards and implementations. It is described here for completeness as part of the overall problem space. The solution uses a single HA/HoA specific MIP Registration as a master signal within which is carried an extension that defines an include/exclude list of the other HA/HoA pairs that should/should not be handed off. This extension can be carried in inter- FA hand-off signals and in regional registrations, and is also used within Nested/Concat MIP. ------------------------------------------------------------ Abstract (Concat) Nested MIP [NestMIP] provides a means to support both localization and aggregation of MIP signalling. It achieves this by providing two distinct layers of MIP signalling and forwarding; a local access layer that provides local mobility management and local access services, and a remote access layer that provides remote access back to a home subnet. The local access layer provides a regional address from a Regional Mobility Agent (a regional HA) that is then used as a CCoA for the remote access layer. Inter-FA movement and MIP signalling at the local access layer then automatically produces the hand-off of potentially multiple parallel remote access sessions. The consequences of this model are however reductions in bandwidth efficiency due to the additional layers of temporary and permanent encapsulation. This draft describes a complementary model for MIP forwarding, called Concatenated MIP that re-uses, and extends the localised and aggregated MIP signalling model from [NestMIP]. The enhanced forwarding model is intended to co-exist both with [NestMIP] and [RegTunMods] so that the appropriate trade- offs can be made on a per session basis between bandwidth efficiency and other features. Inter-RMA hand-offs between Nesting and Concatenating Regional Mobility Agents is also supported. ------------------------------------------------------------- Abstract (RMAsig) Nested MIP [NestMIP] and Concatenated MIP [ConcatMIP] provide means to support both localization and aggregation of MIP signalling. They achieve this by providing two distinct layers of MIP signalling and forwarding; a local access layer that provides local mobility management and local access services, and a remote access layer that provides remote access back to a home subnet. The local access layer provides a regional address from a Regional Mobility Agent (a regional HA) that is then used as a CCoA for the remote access layer. Inter-FA movement and MIP signalling at the local access layer then automatically supports the hand-off of potentially multiple parallel remote access sessions. Nested MIP achieves this through encapsulation whilst Concatenated MIP achieves it though various forms of CoA switching. This draft describes the localised and aggregated MIP signalling model for managing both the Local Access and Remote Access MIP layers. This includes inter-FA and Inter-RMA hand-offs within and between Nesting and Concatenating Regional Mobility Agents. This is necessary to support incremental, heterogeneous deployment that is required given that Nested MIP is deployable now whilst Concatenated MIP requires additional and significant standards and development work. ------------------------------------------------------------- Abstract (PCCoA) In MIPv4, when a Mobile Node (MN) registers with the 'D' bit, in the MIP Registration to a Home Agent (HA), then the MN wishes to use a Co-located Care-of address (CCoA) with a specific Home Address (HoA). Packets sent to the MN Home Address (HoA) will then be encapsulated in the CCoA by the HA and forwarded directly to the MN. Alternatively, a MN can obtain from the local Foreign Agent(FA) a shared FA CoA for inclusion in its MIP Registration to the FA/HA. In this case, the HA encapsulates to the FA CoA, and the Foreign Agent then decapsulates and delivers the HoA addressed packet unencapsulated to the MN. This draft adds to MIPv4 the ability for the MN to acquire a MN specific FA CoA that provides the MN with a topologically correct local address and whose tunnel encaps/decaps is provided by the FA. This address is called a proxy CCoA (PCCoA) and the associated processing in the MN and FA is called Proxy CCoA tunneling. This capability is applicable to any access technology but is especially useful for wireless systems where the access bandwidth is expensive and when point-to-point link-layer connectivity exists between the MN and the FA. This draft also describes reverse tunneling and smooth hand-off extensions based on the PCCoA that enables inter-FA forwarding even for CCoAs. From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 01:56:02 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03920 for ; Thu, 9 May 2002 01:56:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA24430; Wed, 8 May 2002 23:55:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA25625; Wed, 8 May 2002 22:55:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g495sQrP028603 for ; Wed, 8 May 2002 22:54:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g495sP8l028602 for mobile-ip-dist; Wed, 8 May 2002 22:54:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g495sMrP028595 for ; Wed, 8 May 2002 22:54:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA23063 for ; Wed, 8 May 2002 22:54:25 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04542 for ; Wed, 8 May 2002 22:54:24 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 3E9376A905; Thu, 9 May 2002 08:54:17 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BF8FD6A904; Thu, 9 May 2002 08:54:14 +0300 (EEST) Message-ID: <3CDA0F3C.8060409@piuha.net> Date: Thu, 09 May 2002 08:55:08 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Error DOS Attack? References: <01be01c1f6e0$6321ef00$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.1 required=5.0 tests=SUBJ_ENDS_IN_Q_MARK version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > Section 6.1.1 of draft 17 specifies that an error is sent to the source > if the MH type is not recognized (pg. 32). > > An attacker could pump packets at the CN or MN with erroneous MH type > values, and the attacked node would have to continue replying, thus > tying it up. None of the rest of the RR protocol seems to have any error > returns, so this would be the only place that it could occur. > > Is this worth worrying about? In a way this seems similar for any IP protocol, i.e. there aren't any new reflection-to-third-party or amplification concerns. For instance, even if the protocol didn't have MH type error return, you could send UDP with dst port = random, and an ICMP would be returned... one difference however appears that ICMPs are typically rate-limited. We should propably do the same for MH Type errors... checking... no we don't do this yet. Should add this to the document. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 09:32:21 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20563 for ; Thu, 9 May 2002 09:32:20 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA12058; Thu, 9 May 2002 07:31:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14751; Thu, 9 May 2002 06:31:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49DTvrP029148 for ; Thu, 9 May 2002 06:29:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49DTvD7029147 for mobile-ip-dist; Thu, 9 May 2002 06:29:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49DTsrP029140 for ; Thu, 9 May 2002 06:29:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14247 for ; Thu, 9 May 2002 06:29:56 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16210 for ; Thu, 9 May 2002 07:30:11 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 09:26:42 -0400 Message-ID: From: Phil Roberts To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional MIP Drafts from Flarion Date: Thu, 9 May 2002 09:26:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I haven't read any of these yet, Alan. Could you let us know whether you see these as additions to the regional registration draft or replacements? When you tentatively assert backwards compatibility is that with regional registrations or with RFC 3220 or both? Thanks, Phil > -----Original Message----- > From: Alan O'Neill [mailto:A.ONeill@flarion.com] > Sent: Wednesday, May 08, 2002 10:13 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Regional MIP Drafts from Flarion > > > Folks, > > I have submitted the following drafts as mentioned last week > that relate to the regional tunneling issues that we have > been discussing. I guess they won't be availabe for a couple > of days yet so I will send out a link to the drafts on the > Flarion web-site (www.flarion.com) as soon as they are > available there. > > Nested MIP for Mobility Management > > Parallel MIP for Mobility Management > > Concatenated MIP for Mobility Management > > Regional Mobility Agent Signalling > > Proxy CCoA Tunneling for Mobile IP > > > > For those interested I have enclosed the abstracts in a > separate e-mail but an overall summary is below. The > recommended reading order is as shown above. > > The drafts aim to address a requirement that appears to be > unaddressed by existing specs. Regional tunneling provides > localisation of signalling but it does not provide > aggregation of signalling when a MN has multiple HoAs. MIP > signalling is presently HA/HoA specific and hence multiple > HoAs leads to 'Parallel MIP' hand-off signalling (issues > covered in Parallel draft) to the HA and the oFA, and also to > any intermediate regional element. Multiple HoAs are required > for concurrent local and remote access sessions, and also for > third party content/application service provider networks. > The architecture also aims to cleanly separate out the > different operator control requirements for local and remote > access traffic. > > Nested and Concatenated MIP are two alternative ways to > address this requirement, both of which also address > localisation (note that GFA type forwarding can also be > supported with some constraints). They both use two layers of > MIP signaling, the Local Access layer and the Remote Access > layer to decouple intra operator from inter-operator concern. > Nested MIP using encapsulation between the layers whilst > Concatenated using switching between the two layers to > address the requirements. The LA layer runs between the MN, > FA and a Regional Mobility Agent that can be thought of as a > local HA for now. The RMA allocates a Regional address > (RoA)to the MN which it can use as a valid interface address > for local access within the region of the RMA. The RoA is > also used as the CCoA for a potential multitude of remote > access MIP sessions in the RA layer (and can also be used for > IPSRA or PPTP sessions). This then enables an MIP hand-off at > the LA to also move all RA layer sessions at the same time. > The RoA is valid within a region and therefore localisation > is achieved for hand-offs within that region, until the RoA > has to change. The clean separation of the two layers (local and > remote) brings a wide range of benefits but there are of > course costs as mentioned in the documents. For example, on > the plus side, packets to the RoA are routed through the RMA > rather than as a result of switching state and therefore the > RMA regional element is more amenable to routing based > recovery. On the downside, packets are encapsulated over the > air-interface due to the use by the MN of a CCoA at the RA > layer. This is addressed in a generic way for CCoAs by adding > an MIP address mode called Proxy CCoAs where the tunnel > management for the CCoA is left to the FA. > > Basic Nested MIP can be deployed with very little impact on > existing MIP standards - a critical characteristic for > Flarion. Enhanced features require signalling enhancements, > and specifically we want to share the 'I' bit and > HFAext/HFAIPext mechs from [RegTun],[RegTunmods] as the RMA > can also support GFA and the mechanisms for the different > forwarding modes are very similar. Concatenated mode and GFA > mode are only available if the home registration is routed > via the RMA. > > The RMA signalling draft is a very long document which > overviews the detailed signalling mechanisms required to > support Nested, Concat and GFA modes in an RMA through a > number of evolution steps that support RMA hand-off between > the modes. I think all required changes are fully backwards > compatible although don't quote me yet. This draft also adds > a number of features to the integrated model. There are many > issues yet to be solved and I hope that if the wg appreciates > the solution that a work programme can be defined. This will > definitely require significant draft rewrites to break the > work into manageable evolutionary chunks. > > When comparing RMA to the GFA from Reg Tun, the key > differences are that the regional reg in GFA happens after > the home reg whilst the opposite is true for RMA, the GFA is > less amenable to routing based recovery, the GFA does not > support signalling aggregation and the GFA has some > additional issues with private / public address support. The > GFA is however very efficient for a single RA or LA session > per MN and the forwarding rules are obviously less complex > under these conditions. > > As a final point I would recommend people take a bit of time > to read and digest these docs before bringing detailed > discussions to the list. There is a lot of information and > the complete cost/benefit story takes a fair amount of processing. > > Regards, Alan O'Neill > Flarion Technologies. > From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 09:35:14 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20775 for ; Thu, 9 May 2002 09:35:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01189; Thu, 9 May 2002 07:34:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15352; Thu, 9 May 2002 06:34:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49DXmrP029194 for ; Thu, 9 May 2002 06:33:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49DXlBu029193 for mobile-ip-dist; Thu, 9 May 2002 06:33:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49DXirP029183 for ; Thu, 9 May 2002 06:33:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23747 for ; Thu, 9 May 2002 06:33:47 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11262 for ; Thu, 9 May 2002 06:33:46 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 09:30:33 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Proposed Resolutions to Last Call Comments on Regional Tunneling Draft Date: Thu, 9 May 2002 09:30:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi folks, WG last call has completed for draft-ietf-mobileip-reg-tunnel-06.txt. There are a lot of comments on this draft. I've summarized them into 4 categories and propose we deal with resolutions of each of these categories of comments separately. To that end, in the next few days Annika or I will start a thread on each that attempts to close the issues where possible and identify areas of remaining disagreement. Please use the following format in your response to the list on each of the proposed resolutions. Respond as to whether you AGREE, DISAGREE, or CAN LIVE WITH the recommendation. And on the response put in the subject line, CLARIFICATION if you have a clarification to recommend, or ISSUE if you have an issue to raise. 1. There were objections to whether this document is needed as a standard at all and to what extent it is clear when and where this standard is to be implemented, or more accurately NOT implemented. 2. Issues with backwards compatibility 3. Other specific technical issues 4. How deployment of regional registration agents raise issues with the general Internet architecture. Phil From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 10:50:47 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24653 for ; Thu, 9 May 2002 10:50:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19600; Thu, 9 May 2002 07:48:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01748; Thu, 9 May 2002 07:48:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49EirrP029286 for ; Thu, 9 May 2002 07:44:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49EirPx029285 for mobile-ip-dist; Thu, 9 May 2002 07:44:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49EiorP029278 for ; Thu, 9 May 2002 07:44:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01050 for ; Thu, 9 May 2002 07:44:51 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15898 for ; Thu, 9 May 2002 08:44:48 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 10:41:34 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Date: Thu, 9 May 2002 10:41:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: There were a few comments questioning whether or not this draft should be published as a proposed standard at all, specifically whether it provides useful functionality, or functionality that is not otherwise available, or is described in a way that makes it clear to what extent it is optional to implement. A separate thread will address the issue of whether this draft should be published because it raises issue with fundamental architectural principles in the Internet. The document clearly states what it is attempting to do - reduce registration messaging traffic across the Internet, and reduce the handover latency when Home Agents are far from the Mobile Nodes which they serve. There has been expressed interest in the working group for pursuing this and there continues to be interest in doing so. There were suggestions that these requirements might better be served by the low latency draft (draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt). The techniques can be deployed in a complementary fashion. Low latency discusses how the drafts can be used together (see Appendix A). Given that the only plans for advancing lowlatency now are in an experimental status, offering to replace this with that doesn't necessarily advance the interests of the community. Another issue was raised as to what extent it is optional to implement the functionality described here. Given that it can be made clear that this is optional to implement, there is interest across the working group in doing so, and the proposed alternate is only experimental, these objections are not sufficient to stop the advance of this document to Proposed Standard. Attached below is modified text for the abstract and the introduction, Annika's words based on input from Madhavi. Phil "Abstract Using Mobile IP, a mobile node registers with its home agent each time it changes care-of address. If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. This document describes a new kind of "regional" registration, i.e., registration local to the visited domain. The regional signaling is performed via a new network entity called a Gateway Foreign Agent and introduces a layer of hierarchy in the foreign domain. Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another, within the same visited domain. This document is an optional extension to the Mobile IP protocol." "Introduction This document is an optional extension to the Mobile IP protocol, and proposes a means for mobile nodes to register locally within a visited domain. By registering locally, the number of signaling messages to the home network are keept to a minimum, and the signaling delay is reduced. In Mobile IP, as specified in RFC 3220 [9], a mobile node registers with its home agent each time it changes care-of address. If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. We propose a solution for performing registrations locally in the visited domain: regional registrations. The regional registration design introduces new Mobile IP messages - Regional Registrations, new Mobile IP extensions to convey information between the mobile node, foreign agent, and home agent, and a new network entity - Gateway Foreign Agent (GFA). Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another, within the same visited domain. This will both decrease the load on the home network, and speed up the process of handover within the visited domain. The introduction of a GFA also makes it possible to have different addressing realms in the home and in the visited networks." The last three paragraphs of the Introduction are unmodified. From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 11:07:12 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25163 for ; Thu, 9 May 2002 11:07:07 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22107; Thu, 9 May 2002 09:06:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07476; Thu, 9 May 2002 08:06:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49F5IrP029346 for ; Thu, 9 May 2002 08:05:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49F5Iau029345 for mobile-ip-dist; Thu, 9 May 2002 08:05:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49F5FrP029338 for ; Thu, 9 May 2002 08:05:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09513 for ; Thu, 9 May 2002 08:05:15 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21175 for ; Thu, 9 May 2002 09:05:15 -0600 (MDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g49F4vuF004589; Thu, 9 May 2002 08:04:57 -0700 (PDT) Received: from cisco.com (sjc-vpn3-232.cisco.com [10.21.64.232]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ACV88511; Thu, 9 May 2002 08:05:00 -0700 (PDT) Message-ID: <3CDA901B.1BF056D@cisco.com> Date: Thu, 09 May 2002 08:05:00 -0700 From: kleung Organization: Cisco Systems X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: John Wells CC: mobile-ip@sunroof.eng.sun.com, monet@nal.motlabs.com Subject: Re: [mobile-ip] Cisco mobile networks move detection question References: <1020894919.8898.1473.camel@io.irean.vt.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi John. John Wells wrote: > Hi all, > > I have a question on Cisco's v4 mobile network implementation's move > detection algorithm. If a Cisco mobile router is registered with one > foreign agent and hears an advertisement from another foreign agent, it > automatically registers with the new foreign agent and uses the new > address, as far as I can tell. This would seem to contradict the Mobile > IP RFC, which provides for two move detection algorithms (RFC 2002, s > 2.4.2): one based on router advertisement expirations, the other based > on the prefix-length extension. Cisco routers do not broadcast > prefix-length extensions, so the latter is not possible. > Cisco routers can append prefix-length extension to agent advertisements. It is enabled on the interface by "ip mobile prefix-length" command. > > It would seem that Cisco's algorithm might result in oscillation in the > case of two foreign agents on the same subnet, for example in wireless > scenarios. Any thoughts? The mobile router will not oscillate between 2 FAs on same subnet. Kent From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 11:14:21 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25344 for ; Thu, 9 May 2002 11:14:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12286; Thu, 9 May 2002 09:14:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09995; Thu, 9 May 2002 08:13:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49FBurP029475 for ; Thu, 9 May 2002 08:11:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49FBusF029474 for mobile-ip-dist; Thu, 9 May 2002 08:11:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49FBprP029454 for ; Thu, 9 May 2002 08:11:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26226 for ; Thu, 9 May 2002 08:11:53 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29573 for ; Thu, 9 May 2002 09:11:51 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g49FBmP18805; Thu, 9 May 2002 10:11:48 -0500 (CDT) Message-ID: <3CDA91CA.9070109@alcatel.com> Date: Thu, 09 May 2002 10:12:10 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Phil Roberts CC: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #1 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Phil, Can I suggest adding This document is an optional extension to the Mobile IP protocol. to every paragraph? ... just a joke. More seriously, is Mobile IP required to be implemented by every single networked computer in the world? If yes (apart from where does it say so?) then which one, mipv4 or mipv6? If mipv4 then it should not be mipv6, or vice versa? If no, the obvious conclusion? Regards, Phil Roberts wrote: >There were a few comments questioning whether or not this draft should be >published as a proposed standard at all, specifically whether it provides >useful functionality, or functionality that is not otherwise available, or >is described in a way that makes it clear to what extent it is optional to >implement. A separate thread will address the issue of whether this draft >should be published because it raises issue with fundamental architectural >principles in the Internet. > >The document clearly states what it is attempting to do - reduce >registration messaging traffic across the Internet, and reduce the handover >latency when Home Agents are far from the Mobile Nodes which they serve. >There has been expressed interest in the working group for pursuing this and >there continues to be interest in doing so. > >There were suggestions that these requirements might better be served by the >low latency draft (draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt). The >techniques can be deployed in a >complementary fashion. Low latency discusses how the drafts can be used >together (see Appendix A). Given that the only plans for advancing >lowlatency now are in an experimental status, offering to replace this with >that doesn't necessarily advance the interests of the community. > >Another issue was raised as to what extent it is optional to implement the >functionality described here. >Given that it can be made clear that this is optional to implement, there is >interest across the working group in doing so, and the proposed alternate is >only experimental, these objections are not sufficient to stop the advance >of this document to Proposed Standard. > >Attached below is modified text for the abstract and the introduction, >Annika's words based on input >from Madhavi. > >Phil > >"Abstract > >Using Mobile IP, a mobile node registers with its home agent each time it >changes care-of address. If the distance between the visited network and >the home network of the mobile node is large, the signaling delay for these >registrations may be long. This document describes a new kind of "regional" >registration, i.e., registration local to the visited domain. The regional >signaling is performed via a new network entity called a Gateway Foreign >Agent and introduces a layer of hierarchy in the foreign domain. Regional >registrations reduce the number of signaling messages to the home network, >and reduce the signaling delay when a mobile node moves from one foreign >agent to another, within the same visited domain. This document is an >optional extension to the Mobile IP protocol." > > >"Introduction > >This document is an optional extension to the Mobile IP protocol, and >proposes a means for mobile nodes to register locally within a visited >domain. By registering locally, the number of signaling messages to the >home network are keept to a minimum, and the signaling delay is reduced. > >In Mobile IP, as specified in RFC 3220 [9], a mobile node registers with >its home agent each time it changes care-of address. If the distance >between the visited network and the home network of the mobile node is >large, the signaling delay for these registrations may be long. We propose >a solution for performing registrations locally in the visited domain: >regional registrations. The regional registration design introduces new >Mobile IP messages - Regional Registrations, new Mobile IP extensions to >convey information between the mobile node, foreign agent, and home agent, >and a new network entity - Gateway Foreign Agent (GFA). Regional >registrations reduce the number of signaling messages to the home network, >and reduce the signaling delay when a mobile node moves from one foreign >agent to another, within the same visited domain. This will both decrease >the load on the home network, and speed up the process of handover within >the visited domain. The introduction of a GFA also makes it possible to >have different addressing realms in the home and in the visited networks." > > >The last three paragraphs of the Introduction are unmodified. > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 13:00:08 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00028 for ; Thu, 9 May 2002 13:00:08 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19629; Thu, 9 May 2002 10:59:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17093; Thu, 9 May 2002 09:59:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49GwBrP029680 for ; Thu, 9 May 2002 09:58:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49GwBeE029679 for mobile-ip-dist; Thu, 9 May 2002 09:58:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49Gw7rP029672 for ; Thu, 9 May 2002 09:58:08 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19976 for ; Thu, 9 May 2002 09:58:10 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07097 for ; Thu, 9 May 2002 10:58:09 -0600 (MDT) Message-ID: <00be01c1f77a$745e9170$7e6015ac@T23KEMPF> From: "James Kempf" To: "Phil Roberts" , References: Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Date: Thu, 9 May 2002 09:56:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit DISAGREE Speaking as a working group member, there is a working group draft on requirements for localized mobility management (draft-ietf-mobileip-lmm-requirements-01.txt) which was primarily intended for MIPv6, but could as well apply to MIPv4. If the WG really wants a standard for MIPv4 LMM, then I think these requirements should be regressed against the proposed solutions, including the low-latency solution and the new drafts by Alan O'Neill, and a standards-track solution chosen that best meets the requirements. That said, I recognize that the authors have put a lot of work into this design, and so I would support publishing it as experimental even if the requirements regression did not result it it being chosen. Finally, speaking as an IAB member, I have some concern about publishing a draft as an Internet standard when there are outstanding questions on its effect on the Internet architecture. I realize that was listed as a separate question, but I don't think it can be disentangled from how to publish this draft. jak ----- Original Message ----- From: "Phil Roberts" To: Sent: Thursday, May 09, 2002 7:41 AM Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #1 > There were a few comments questioning whether or not this draft should be > published as a proposed standard at all, specifically whether it provides > useful functionality, or functionality that is not otherwise available, or > is described in a way that makes it clear to what extent it is optional to > implement. A separate thread will address the issue of whether this draft > should be published because it raises issue with fundamental architectural > principles in the Internet. > > The document clearly states what it is attempting to do - reduce > registration messaging traffic across the Internet, and reduce the handover > latency when Home Agents are far from the Mobile Nodes which they serve. > There has been expressed interest in the working group for pursuing this and > there continues to be interest in doing so. > > There were suggestions that these requirements might better be served by the > low latency draft (draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt). The > techniques can be deployed in a > complementary fashion. Low latency discusses how the drafts can be used > together (see Appendix A). Given that the only plans for advancing > lowlatency now are in an experimental status, offering to replace this with > that doesn't necessarily advance the interests of the community. > > Another issue was raised as to what extent it is optional to implement the > functionality described here. > Given that it can be made clear that this is optional to implement, there is > interest across the working group in doing so, and the proposed alternate is > only experimental, these objections are not sufficient to stop the advance > of this document to Proposed Standard. > > Attached below is modified text for the abstract and the introduction, > Annika's words based on input > from Madhavi. > > Phil > > "Abstract > > Using Mobile IP, a mobile node registers with its home agent each time it > changes care-of address. If the distance between the visited network and > the home network of the mobile node is large, the signaling delay for these > registrations may be long. This document describes a new kind of "regional" > registration, i.e., registration local to the visited domain. The regional > signaling is performed via a new network entity called a Gateway Foreign > Agent and introduces a layer of hierarchy in the foreign domain. Regional > registrations reduce the number of signaling messages to the home network, > and reduce the signaling delay when a mobile node moves from one foreign > agent to another, within the same visited domain. This document is an > optional extension to the Mobile IP protocol." > > > "Introduction > > This document is an optional extension to the Mobile IP protocol, and > proposes a means for mobile nodes to register locally within a visited > domain. By registering locally, the number of signaling messages to the > home network are keept to a minimum, and the signaling delay is reduced. > > In Mobile IP, as specified in RFC 3220 [9], a mobile node registers with > its home agent each time it changes care-of address. If the distance > between the visited network and the home network of the mobile node is > large, the signaling delay for these registrations may be long. We propose > a solution for performing registrations locally in the visited domain: > regional registrations. The regional registration design introduces new > Mobile IP messages - Regional Registrations, new Mobile IP extensions to > convey information between the mobile node, foreign agent, and home agent, > and a new network entity - Gateway Foreign Agent (GFA). Regional > registrations reduce the number of signaling messages to the home network, > and reduce the signaling delay when a mobile node moves from one foreign > agent to another, within the same visited domain. This will both decrease > the load on the home network, and speed up the process of handover within > the visited domain. The introduction of a GFA also makes it possible to > have different addressing realms in the home and in the visited networks." > > > The last three paragraphs of the Introduction are unmodified. > From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 13:05:53 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00488 for ; Thu, 9 May 2002 13:05:53 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18021; Thu, 9 May 2002 11:05:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20602; Thu, 9 May 2002 10:04:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49H3vrP029739 for ; Thu, 9 May 2002 10:03:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49H3vGl029738 for mobile-ip-dist; Thu, 9 May 2002 10:03:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49H3srP029731 for ; Thu, 9 May 2002 10:03:54 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22496 for ; Thu, 9 May 2002 10:03:56 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10386 for ; Thu, 9 May 2002 11:03:56 -0600 (MDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g49H3skc027491; Thu, 9 May 2002 10:03:55 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA25868; Thu, 9 May 2002 13:03:54 -0400 (EDT) Date: Thu, 9 May 2002 13:03:54 -0400 From: "Madhavi W. Chandra" To: Phil Roberts Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Message-ID: <20020509130354.A25864@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from PRoberts@megisto.com on Thu, May 09, 2002 at 10:41:32AM -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Thu, May 09, 2002 at 10:41:32AM -0400, Phil Roberts wrote: > There were a few comments questioning whether or not this draft should be > published as a proposed standard at all, specifically whether it provides > useful functionality, or functionality that is not otherwise available, or > is described in a way that makes it clear to what extent it is optional to > implement. A separate thread will address the issue of whether this draft > should be published because it raises issue with fundamental architectural > principles in the Internet. > > The document clearly states what it is attempting to do - reduce > registration messaging traffic across the Internet, and reduce the handover > latency when Home Agents are far from the Mobile Nodes which they serve. > There has been expressed interest in the working group for pursuing this and > there continues to be interest in doing so. > > There were suggestions that these requirements might better be served by the > low latency draft (draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt). The > techniques can be deployed in a > complementary fashion. Low latency discusses how the drafts can be used > together (see Appendix A). Given that the only plans for advancing > lowlatency now are in an experimental status, offering to replace this with > that doesn't necessarily advance the interests of the community. > > Another issue was raised as to what extent it is optional to implement the > functionality described here. > Given that it can be made clear that this is optional to implement, there is > interest across the working group in doing so, and the proposed alternate is > only experimental, these objections are not sufficient to stop the advance > of this document to Proposed Standard. > > Attached below is modified text for the abstract and the introduction, > Annika's words based on input > from Madhavi. DISAGREE...as written below. As per the feedback we provided, it should be clearly stated in the Abstract and Introduction that this architecture is OPTIONAL and not required in typical Mobile IP deployments. Also, reference to the new Section that will describe scenarios that may benefit from this architecture should be included in the Introduction. The agreement to include the new Section is to alleviate the doubts for the necessity of this architecture. Hopefully, the new Section will highlight when the architecture is useful, and not when it is NOT. I have provided Annika with the suggested text. Please incorporate the above comments. Thanks, Madhavi > Phil > > "Abstract > > Using Mobile IP, a mobile node registers with its home agent each time it > changes care-of address. If the distance between the visited network and > the home network of the mobile node is large, the signaling delay for these > registrations may be long. This document describes a new kind of "regional" > registration, i.e., registration local to the visited domain. The regional > signaling is performed via a new network entity called a Gateway Foreign > Agent and introduces a layer of hierarchy in the foreign domain. Regional > registrations reduce the number of signaling messages to the home network, > and reduce the signaling delay when a mobile node moves from one foreign > agent to another, within the same visited domain. This document is an > optional extension to the Mobile IP protocol." > > > "Introduction > > This document is an optional extension to the Mobile IP protocol, and > proposes a means for mobile nodes to register locally within a visited > domain. By registering locally, the number of signaling messages to the > home network are keept to a minimum, and the signaling delay is reduced. > > In Mobile IP, as specified in RFC 3220 [9], a mobile node registers with > its home agent each time it changes care-of address. If the distance > between the visited network and the home network of the mobile node is > large, the signaling delay for these registrations may be long. We propose > a solution for performing registrations locally in the visited domain: > regional registrations. The regional registration design introduces new > Mobile IP messages - Regional Registrations, new Mobile IP extensions to > convey information between the mobile node, foreign agent, and home agent, > and a new network entity - Gateway Foreign Agent (GFA). Regional > registrations reduce the number of signaling messages to the home network, > and reduce the signaling delay when a mobile node moves from one foreign > agent to another, within the same visited domain. This will both decrease > the load on the home network, and speed up the process of handover within > the visited domain. The introduction of a GFA also makes it possible to > have different addressing realms in the home and in the visited networks." > > > The last three paragraphs of the Introduction are unmodified. From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 15:22:03 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05906 for ; Thu, 9 May 2002 15:22:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05460; Thu, 9 May 2002 13:21:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01114; Thu, 9 May 2002 12:21:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49JKTrP000009 for ; Thu, 9 May 2002 12:20:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49JKTaW000008 for mobile-ip-dist; Thu, 9 May 2002 12:20:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49JKQrP029997 for ; Thu, 9 May 2002 12:20:26 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21008 for ; Thu, 9 May 2002 12:20:28 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23983 for ; Thu, 9 May 2002 12:20:28 -0700 (PDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g49JKRHT005874 for ; Thu, 9 May 2002 12:20:27 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA26042 for mobile-ip@sunroof.eng.sun.com; Thu, 9 May 2002 15:20:27 -0400 (EDT) Date: Thu, 9 May 2002 15:20:27 -0400 From: "Madhavi W. Chandra" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Archives link incorrect Message-ID: <20020509152027.A26017@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: HI Steve, The archives link seems to be incorrect. Please provide the correct URL. Thanks, Madhavi From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 15:44:19 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06599 for ; Thu, 9 May 2002 15:44:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29487; Thu, 9 May 2002 12:42:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12152; Thu, 9 May 2002 12:42:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49JfCrP000119 for ; Thu, 9 May 2002 12:41:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49JfCL9000118 for mobile-ip-dist; Thu, 9 May 2002 12:41:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49Jf8rP000109 for ; Thu, 9 May 2002 12:41:09 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02819 for ; Thu, 9 May 2002 12:41:10 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06090 for ; Thu, 9 May 2002 12:41:10 -0700 (PDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g49Jf4402436; Thu, 9 May 2002 14:41:04 -0500 (CDT) Message-ID: <3CDAD0E5.30701@alcatel.com> Date: Thu, 09 May 2002 14:41:25 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf CC: Phil Roberts , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #1 References: <00be01c1f77a$745e9170$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Jim, James Kempf wrote: >DISAGREE > >Speaking as a working group member, there is a working group draft on >requirements for localized mobility management >(draft-ietf-mobileip-lmm-requirements-01.txt) which was primarily >intended for MIPv6, but could as well apply to MIPv4. If the WG really >wants a standard for MIPv4 LMM, then I think these requirements should >be regressed against the proposed solutions, including the low-latency >solution and the new drafts by Alan O'Neill, and a standards-track >solution chosen that best meets the requirements. > 1. We have not even seen Alan's drafts, how can we secondguess Alan? 2. Regarding LMM requirements draft, can you be specific on where it would contradict MIPv4 regreg? > >That said, I recognize that the authors have put a lot of work into this >design, and so I would support publishing it as experimental even if the >requirements regression did not result it it being chosen. > This somehow contradicts your previous paragraph. I am against having standards just because the authors worked hard. The history of telecom standards tells us the contrary. > >Finally, speaking as an IAB member, I have some concern about publishing >a draft as an Internet standard when there are outstanding questions on >its effect on the Internet architecture. I realize that was listed as a >separate question, but I don't think it can be disentangled from how to >publish this draft. > > jak > Sorry I missed this, what are the outstanding questions on the Internet architecture that MIPv4 regreg affects? > --behcet > From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 16:22:04 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07400 for ; Thu, 9 May 2002 16:22:04 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11026; Thu, 9 May 2002 14:21:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01603; Thu, 9 May 2002 13:21:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49KInrP000240 for ; Thu, 9 May 2002 13:18:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49KInqH000239 for mobile-ip-dist; Thu, 9 May 2002 13:18:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49KIjrP000230 for ; Thu, 9 May 2002 13:18:45 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16067 for ; Thu, 9 May 2002 13:18:47 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28776 for ; Thu, 9 May 2002 13:18:47 -0700 (PDT) Message-ID: <06fa01c1f796$74f4f450$7e6015ac@T23KEMPF> From: "James Kempf" To: "Behcet Sarikaya" Cc: "Phil Roberts" , References: <00be01c1f77a$745e9170$7e6015ac@T23KEMPF> <3CDAD0E5.30701@alcatel.com> Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Date: Thu, 9 May 2002 13:16:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > 1. We have not even seen Alan's drafts, how can we secondguess Alan? > 2. Regarding LMM requirements draft, can you be specific on where it > would contradict MIPv4 regreg? > It is up to the WG and the chairs to decide whether we should do this or not, and up to the chairs and AD to decide how it should be done, if we do it. > This somehow contradicts your previous paragraph. I am against having > standards just because the authors worked hard. The history of telecom > standards tells us the contrary. > An experimental designation is not a standard. It says that it is experimental. It could also be done as informational. > Sorry I missed this, what are the outstanding questions on the Internet > architecture that MIPv4 regreg affects? > When Phil posts this as a discussion item, I will respond. jak From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 16:23:47 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07458 for ; Thu, 9 May 2002 16:23:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00710; Thu, 9 May 2002 13:21:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01579; Thu, 9 May 2002 13:21:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49KIIrP000227 for ; Thu, 9 May 2002 13:18:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49KII0P000226 for mobile-ip-dist; Thu, 9 May 2002 13:18:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49KIBrP000218 for ; Thu, 9 May 2002 13:18:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA18374 for ; Thu, 9 May 2002 13:18:14 -0700 (PDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA17300 for ; Thu, 9 May 2002 14:18:30 -0600 (MDT) Received: from unknown (HELO EmadQ) (emadaq@194.165.132.116 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 9 May 2002 20:18:10 -0000 Reply-To: From: "Emad Qaddoura" To: "'James Kempf'" , "'Phil Roberts'" , Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Date: Thu, 9 May 2002 23:17:21 +0200 Message-ID: <000001c1f79e$eaf717c0$5701a8c0@EmadQ> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <00be01c1f77a$745e9170$7e6015ac@T23KEMPF> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James, Phil, I agree with James about the requirements aspect. " against the proposed solutions". I have asked the authors question(s) about the real-time impact to the MIP protocol? What is it really? Working with MIP protocol and mobility derivatives for many years, I get worried about the added options and messaging for the MIP signaling which ultimately impacts the data path. Until such view is fully clear, I CAN ONLY IMAGINE this draft being in the experimental stage and not on a standard track. Is the added complexity to the overall MIP architecture worth the few MS for a trip to the home network/the added signaling message to the home? Would such a delay/signal be tolerable as long as there is a mechanism that handles data forwarding to the new FA similar to the one in the low latency draft. Also, looking at from a services point view and a direction of how handheld devices with dual access (or more) would be used, I strongly believe (may be only me) that the granularity of the location to the home network/info-provider would of high importance for location based services. I don't want to know that my subscriber is visiting the North section of town, I need to have more information about the location so I can "push/send" more personalized data to him, i.e. his favorite pizza restaurant. Thx. Emad. > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] On Behalf Of James Kempf > Sent: Thursday, May 09, 2002 6:56 PM > To: Phil Roberts; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue > #1 > > DISAGREE > > Speaking as a working group member, there is a working group draft on > requirements for localized mobility management > (draft-ietf-mobileip-lmm-requirements-01.txt) which was primarily > intended for MIPv6, but could as well apply to MIPv4. If the WG really > wants a standard for MIPv4 LMM, then I think these requirements should > be regressed against the proposed solutions, including the low-latency > solution and the new drafts by Alan O'Neill, and a standards-track > solution chosen that best meets the requirements. > > That said, I recognize that the authors have put a lot of work into this > design, and so I would support publishing it as experimental even if the > requirements regression did not result it it being chosen. > > Finally, speaking as an IAB member, I have some concern about publishing > a draft as an Internet standard when there are outstanding questions on > its effect on the Internet architecture. I realize that was listed as a > separate question, but I don't think it can be disentangled from how to > publish this draft. > > jak > > ----- Original Message ----- > From: "Phil Roberts" > To: > Sent: Thursday, May 09, 2002 7:41 AM > Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #1 > > > > There were a few comments questioning whether or not this draft should > be > > published as a proposed standard at all, specifically whether it > provides > > useful functionality, or functionality that is not otherwise > available, or > > is described in a way that makes it clear to what extent it is > optional to > > implement. A separate thread will address the issue of whether this > draft > > should be published because it raises issue with fundamental > architectural > > principles in the Internet. > > > > The document clearly states what it is attempting to do - reduce > > registration messaging traffic across the Internet, and reduce the > handover > > latency when Home Agents are far from the Mobile Nodes which they > serve. > > There has been expressed interest in the working group for pursuing > this and > > there continues to be interest in doing so. > > > > There were suggestions that these requirements might better be served > by the > > low latency draft (draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt). > The > > techniques can be deployed in a > > complementary fashion. Low latency discusses how the drafts can be > used > > together (see Appendix A). Given that the only plans for advancing > > lowlatency now are in an experimental status, offering to replace this > with > > that doesn't necessarily advance the interests of the community. > > > > Another issue was raised as to what extent it is optional to implement > the > > functionality described here. > > Given that it can be made clear that this is optional to implement, > there is > > interest across the working group in doing so, and the proposed > alternate is > > only experimental, these objections are not sufficient to stop the > advance > > of this document to Proposed Standard. > > > > Attached below is modified text for the abstract and the introduction, > > Annika's words based on input > > from Madhavi. > > > > Phil > > > > "Abstract > > > > Using Mobile IP, a mobile node registers with its home agent each time > it > > changes care-of address. If the distance between the visited network > and > > the home network of the mobile node is large, the signaling delay for > these > > registrations may be long. This document describes a new kind of > "regional" > > registration, i.e., registration local to the visited domain. The > regional > > signaling is performed via a new network entity called a Gateway > Foreign > > Agent and introduces a layer of hierarchy in the foreign domain. > Regional > > registrations reduce the number of signaling messages to the home > network, > > and reduce the signaling delay when a mobile node moves from one > foreign > > agent to another, within the same visited domain. This document is an > > optional extension to the Mobile IP protocol." > > > > > > "Introduction > > > > This document is an optional extension to the Mobile IP protocol, and > > proposes a means for mobile nodes to register locally within a visited > > domain. By registering locally, the number of signaling messages to > the > > home network are keept to a minimum, and the signaling delay is > reduced. > > > > In Mobile IP, as specified in RFC 3220 [9], a mobile node registers > with > > its home agent each time it changes care-of address. If the distance > > between the visited network and the home network of the mobile node is > > large, the signaling delay for these registrations may be long. We > propose > > a solution for performing registrations locally in the visited domain: > > regional registrations. The regional registration design introduces > new > > Mobile IP messages - Regional Registrations, new Mobile IP extensions > to > > convey information between the mobile node, foreign agent, and home > agent, > > and a new network entity - Gateway Foreign Agent (GFA). Regional > > registrations reduce the number of signaling messages to the home > network, > > and reduce the signaling delay when a mobile node moves from one > foreign > > agent to another, within the same visited domain. This will both > decrease > > the load on the home network, and speed up the process of handover > within > > the visited domain. The introduction of a GFA also makes it possible > to > > have different addressing realms in the home and in the visited > networks." > > > > > > The last three paragraphs of the Introduction are unmodified. > > From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 17:12:29 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09400 for ; Thu, 9 May 2002 17:12:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23304; Thu, 9 May 2002 14:10:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08516; Thu, 9 May 2002 14:10:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49L9IrP000384 for ; Thu, 9 May 2002 14:09:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g49L9IZF000383 for mobile-ip-dist; Thu, 9 May 2002 14:09:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g49L9FrP000376 for ; Thu, 9 May 2002 14:09:15 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14470 for ; Thu, 9 May 2002 14:09:15 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08065 for ; Thu, 9 May 2002 15:09:15 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g49L94x10585; Thu, 9 May 2002 16:09:04 -0500 (CDT) Message-ID: <3CDAE584.5090206@alcatel.com> Date: Thu, 09 May 2002 16:09:24 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: emadaq@yahoo.com CC: "'James Kempf'" , "'Phil Roberts'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #1 References: <000001c1f79e$eaf717c0$5701a8c0@EmadQ> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit EQ, You claim to have worked many years on MIP but I am not sure if you understand the fact that MIP DOES not deal with geographic location changes such as being in the north section of town, etc. neither do we deal with personalized data. IETF has geopriv WG that works on geographic location issues and simple WG deals with instant messages. I believe your other concerns had been answered by Charlie who is in China this week (my guess). Thx. Emad Qaddoura wrote: >James, Phil, > > I agree with James about the requirements aspect. " against the >proposed solutions". > > I have asked the authors question(s) about the real-time impact >to the MIP protocol? What is it really? > > Working with MIP protocol and mobility derivatives for many >years, I get worried about the added options and messaging for the MIP >signaling which ultimately impacts the data path. Until such view is >fully clear, I CAN ONLY IMAGINE this draft being in the experimental >stage and not on a standard track. > > Is the added complexity to the overall MIP architecture worth >the few MS for a trip to the home network/the added signaling message to >the home? Would such a delay/signal be tolerable as long as there is a >mechanism that handles data forwarding to the new FA similar to the one >in the low latency draft. > > Also, looking at from a services point view and a direction of >how handheld devices with dual access (or more) would be used, I >strongly believe (may be only me) that the granularity of the location >to the home network/info-provider would of high importance for location >based services. I don't want to know that my subscriber is visiting the >North section of town, I need to have more information about the >location so I can "push/send" more personalized data to him, i.e. his >favorite pizza restaurant. > >Thx. >Emad. > --behcet From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 22:42:14 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22868 for ; Thu, 9 May 2002 22:42:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA17214; Thu, 9 May 2002 20:41:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12572; Thu, 9 May 2002 19:41:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4A2ekrP000870 for ; Thu, 9 May 2002 19:40:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4A2ekTa000869 for mobile-ip-dist; Thu, 9 May 2002 19:40:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4A2egrP000862 for ; Thu, 9 May 2002 19:40:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA17886 for ; Thu, 9 May 2002 19:40:45 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA00546 for ; Thu, 9 May 2002 20:40:44 -0600 (MDT) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 22:40:41 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46E21C6C@ftmail> From: "Alan O'Neill" To: Phil Roberts , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional MIP Drafts from Flarion Date: Thu, 9 May 2002 22:40:42 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: It is both although the documents cover a range of evolution steps and options in which specific decisions could render loss of backwards compatibility wrt RegTun but this would only be when specifically intended to do so (ie if GFA is not deployed).. -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: 09 May 2002 22:57 To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional MIP Drafts from Flarion I haven't read any of these yet, Alan. Could you let us know whether you see these as additions to the regional registration draft or replacements? When you tentatively assert backwards compatibility is that with regional registrations or with RFC 3220 or both? Thanks, Phil > -----Original Message----- > From: Alan O'Neill [mailto:A.ONeill@flarion.com] > Sent: Wednesday, May 08, 2002 10:13 PM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Regional MIP Drafts from Flarion > > > Folks, > > I have submitted the following drafts as mentioned last week > that relate to the regional tunneling issues that we have > been discussing. I guess they won't be availabe for a couple > of days yet so I will send out a link to the drafts on the > Flarion web-site (www.flarion.com) as soon as they are > available there. > > Nested MIP for Mobility Management > > Parallel MIP for Mobility Management > > Concatenated MIP for Mobility Management > > Regional Mobility Agent Signalling > > Proxy CCoA Tunneling for Mobile IP > > > > For those interested I have enclosed the abstracts in a > separate e-mail but an overall summary is below. The > recommended reading order is as shown above. > > The drafts aim to address a requirement that appears to be > unaddressed by existing specs. Regional tunneling provides > localisation of signalling but it does not provide > aggregation of signalling when a MN has multiple HoAs. MIP > signalling is presently HA/HoA specific and hence multiple > HoAs leads to 'Parallel MIP' hand-off signalling (issues > covered in Parallel draft) to the HA and the oFA, and also to > any intermediate regional element. Multiple HoAs are required > for concurrent local and remote access sessions, and also for > third party content/application service provider networks. > The architecture also aims to cleanly separate out the > different operator control requirements for local and remote > access traffic. > > Nested and Concatenated MIP are two alternative ways to > address this requirement, both of which also address > localisation (note that GFA type forwarding can also be > supported with some constraints). They both use two layers of > MIP signaling, the Local Access layer and the Remote Access > layer to decouple intra operator from inter-operator concern. > Nested MIP using encapsulation between the layers whilst > Concatenated using switching between the two layers to > address the requirements. The LA layer runs between the MN, > FA and a Regional Mobility Agent that can be thought of as a > local HA for now. The RMA allocates a Regional address > (RoA)to the MN which it can use as a valid interface address > for local access within the region of the RMA. The RoA is > also used as the CCoA for a potential multitude of remote > access MIP sessions in the RA layer (and can also be used for > IPSRA or PPTP sessions). This then enables an MIP hand-off at > the LA to also move all RA layer sessions at the same time. > The RoA is valid within a region and therefore localisation > is achieved for hand-offs within that region, until the RoA > has to change. The clean separation of the two layers (local and > remote) brings a wide range of benefits but there are of > course costs as mentioned in the documents. For example, on > the plus side, packets to the RoA are routed through the RMA > rather than as a result of switching state and therefore the > RMA regional element is more amenable to routing based > recovery. On the downside, packets are encapsulated over the > air-interface due to the use by the MN of a CCoA at the RA > layer. This is addressed in a generic way for CCoAs by adding > an MIP address mode called Proxy CCoAs where the tunnel > management for the CCoA is left to the FA. > > Basic Nested MIP can be deployed with very little impact on > existing MIP standards - a critical characteristic for > Flarion. Enhanced features require signalling enhancements, > and specifically we want to share the 'I' bit and > HFAext/HFAIPext mechs from [RegTun],[RegTunmods] as the RMA > can also support GFA and the mechanisms for the different > forwarding modes are very similar. Concatenated mode and GFA > mode are only available if the home registration is routed > via the RMA. > > The RMA signalling draft is a very long document which > overviews the detailed signalling mechanisms required to > support Nested, Concat and GFA modes in an RMA through a > number of evolution steps that support RMA hand-off between > the modes. I think all required changes are fully backwards > compatible although don't quote me yet. This draft also adds > a number of features to the integrated model. There are many > issues yet to be solved and I hope that if the wg appreciates > the solution that a work programme can be defined. This will > definitely require significant draft rewrites to break the > work into manageable evolutionary chunks. > > When comparing RMA to the GFA from Reg Tun, the key > differences are that the regional reg in GFA happens after > the home reg whilst the opposite is true for RMA, the GFA is > less amenable to routing based recovery, the GFA does not > support signalling aggregation and the GFA has some > additional issues with private / public address support. The > GFA is however very efficient for a single RA or LA session > per MN and the forwarding rules are obviously less complex > under these conditions. > > As a final point I would recommend people take a bit of time > to read and digest these docs before bringing detailed > discussions to the list. There is a lot of information and > the complete cost/benefit story takes a fair amount of processing. > > Regards, Alan O'Neill > Flarion Technologies. > From owner-mobile-ip@sunroof.eng.sun.com Thu May 9 22:42:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22910 for ; Thu, 9 May 2002 22:42:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA01181; Thu, 9 May 2002 20:42:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12799; Thu, 9 May 2002 19:42:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4A2fVrP000887 for ; Thu, 9 May 2002 19:41:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4A2fUMR000886 for mobile-ip-dist; Thu, 9 May 2002 19:41:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4A2fRrP000879 for ; Thu, 9 May 2002 19:41:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA01877 for ; Thu, 9 May 2002 19:41:29 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15276 for ; Thu, 9 May 2002 19:41:29 -0700 (PDT) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 22:41:27 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46E21C6E@ftmail> From: "Alan O'Neill" To: Phil Roberts , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Proposed Resolutions to Last Call Comments on Reg ional Tunneling Draft Date: Thu, 9 May 2002 22:41:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Phil, One of the specific requests from Flarion during last call was to separate the standardisation of the regional signalling plane (the ability to statically or dynamically route MIP via an intermediate (in this case regional) node, from what happens as a result of that signalling as communicated in the extensions and other standard MIP fields. Apart from the Flarion work that wants to re-use this signalling plane, I am sure we can all think of reasons that an operator might want tighter control over the content and hence routing of MIP messages in a domain for NAT / firewall / security / QoS / accounting etc, and thereby avoid pushing a lot of state out to the FAs. Some of these routings may only want to inspect the signalling plane and not affect forwarding at all which can clearly be achieved but my main focus is of course on Nested/Concat MIP. GFA is then one such forwarding mode. The alternative is having to redefine it all again in each case. So I wondered in which catagory this issue should be addressed. I guess I would also recommend that that debate doesn't happen until people have a little bit of time to think about Nested (at least) although the above broader examples might help with motivation here. This is a tricky one I know.. Regards, Alan. -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: 09 May 2002 23:00 To: 'mobile-ip@sunroof.eng.sun.com' Subject: [mobile-ip] Proposed Resolutions to Last Call Comments on Regional Tunneling Draft Hi folks, WG last call has completed for draft-ietf-mobileip-reg-tunnel-06.txt. There are a lot of comments on this draft. I've summarized them into 4 categories and propose we deal with resolutions of each of these categories of comments separately. To that end, in the next few days Annika or I will start a thread on each that attempts to close the issues where possible and identify areas of remaining disagreement. Please use the following format in your response to the list on each of the proposed resolutions. Respond as to whether you AGREE, DISAGREE, or CAN LIVE WITH the recommendation. And on the response put in the subject line, CLARIFICATION if you have a clarification to recommend, or ISSUE if you have an issue to raise. 1. There were objections to whether this document is needed as a standard at all and to what extent it is clear when and where this standard is to be implemented, or more accurately NOT implemented. 2. Issues with backwards compatibility 3. Other specific technical issues 4. How deployment of regional registration agents raise issues with the general Internet architecture. Phil From owner-mobile-ip@sunroof.eng.sun.com Fri May 10 04:20:08 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10516 for ; Fri, 10 May 2002 04:20:07 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA24563; Fri, 10 May 2002 02:19:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01714; Fri, 10 May 2002 01:19:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4A8IarP001450 for ; Fri, 10 May 2002 01:18:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4A8Iaeo001449 for mobile-ip-dist; Fri, 10 May 2002 01:18:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4A8IXrP001442 for ; Fri, 10 May 2002 01:18:33 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27175 for ; Fri, 10 May 2002 01:18:35 -0700 (PDT) Received: from smtp011.mail.yahoo.com (smtp011.mail.yahoo.com [216.136.173.31]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA24130 for ; Fri, 10 May 2002 02:18:34 -0600 (MDT) Received: from unknown (HELO EmadQ) (emadaq@194.165.157.43 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 May 2002 08:18:30 -0000 Reply-To: From: "Emad Qaddoura" To: "'Behcet Sarikaya'" Cc: "'James Kempf'" , "'Phil Roberts'" , Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Date: Fri, 10 May 2002 11:17:40 +0200 Message-ID: <000d01c1f803$8ce717b0$5701a8c0@EmadQ> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <3CDAE584.5090206@alcatel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Behcet, Well, I don't want to go into un-healthy debates of how much someone understands mobility and its impact on service delivery and services in general. I would say I AM SURE you have no idea about the ultimate benefit of MIP and its mobility information, and your statements below are VERY PRE-MATURE. Location information that is provided by MIP would be of great importance to any service delivery such as location based service which can be of personalized context and fully depend on the granularity of the location. How the mapping/translation happens, is not within this WG as you may know. I had some personal emails with Charlie and, yes I was promised with some info, but did not get it yet. However, SINCE YOU ARE SO confident about what was provided, why don't you point me to it, and IS IT good enough to understand the impact of regional tunneling on the MIP architecture? Thx Emad. > -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] > Sent: Thursday, May 09, 2002 11:09 PM > To: emadaq@yahoo.com > Cc: 'James Kempf'; 'Phil Roberts'; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue > #1 > > EQ, > You claim to have worked many years on MIP but I am not sure if you > understand the fact that MIP DOES not deal with geographic location > changes such as being in the north section of town, etc. neither do we > deal with personalized data. IETF has geopriv WG that works on > geographic location issues and simple WG deals with instant messages. > I believe your other concerns had been answered by Charlie who is in > China this week (my guess). > > Thx. > > Emad Qaddoura wrote: > > >James, Phil, > > > > I agree with James about the requirements aspect. " against the > >proposed solutions". > > > > I have asked the authors question(s) about the real-time impact > >to the MIP protocol? What is it really? > > > > Working with MIP protocol and mobility derivatives for many > >years, I get worried about the added options and messaging for the MIP > >signaling which ultimately impacts the data path. Until such view is > >fully clear, I CAN ONLY IMAGINE this draft being in the experimental > >stage and not on a standard track. > > > > Is the added complexity to the overall MIP architecture worth > >the few MS for a trip to the home network/the added signaling message to > >the home? Would such a delay/signal be tolerable as long as there is a > >mechanism that handles data forwarding to the new FA similar to the one > >in the low latency draft. > > > > Also, looking at from a services point view and a direction of > >how handheld devices with dual access (or more) would be used, I > >strongly believe (may be only me) that the granularity of the location > >to the home network/info-provider would of high importance for location > >based services. I don't want to know that my subscriber is visiting the > >North section of town, I need to have more information about the > >location so I can "push/send" more personalized data to him, i.e. his > >favorite pizza restaurant. > > > >Thx. > >Emad. > > > --behcet From owner-mobile-ip@sunroof.eng.sun.com Fri May 10 07:36:33 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15238 for ; Fri, 10 May 2002 07:36:33 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA24416; Fri, 10 May 2002 05:36:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09419; Fri, 10 May 2002 04:35:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ABYrrP001789 for ; Fri, 10 May 2002 04:34:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4ABYqEr001788 for mobile-ip-dist; Fri, 10 May 2002 04:34:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ABYmrP001781 for ; Fri, 10 May 2002 04:34:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA25996 for ; Fri, 10 May 2002 04:34:50 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA18789 for ; Fri, 10 May 2002 05:34:43 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14845; Fri, 10 May 2002 07:34:34 -0400 (EDT) Message-Id: <200205101134.HAA14845@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-vpn-problem-statement-00.txt Date: Fri, 10 May 2002 07:34:34 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Problem Statement for Mobile IPv4 Traversal Across VPN Gateways Author(s) : F. Adrangi, P. Iyer et al. Filename : draft-ietf-mobileip-vpn-problem-statement-00.txt Pages : 9 Date : 09-May-02 Mobile IP [1] agents are being deployed in enterprise networks, to enable mobile users with network mobility across wired and wireless LANs while roaming inside the enterprise firewall. With the growing deployment of multi-subnetted IEEE 802.11 networks (referred as hot spots) in public places such as hotels, airports, and convention centers, and wireless WAN data networks such as GPRS, the need for enabling mobile users to maintain their transport connections and constant reachability while connecting back to their target 'home' networks protected by VPNs is increasing. This draft identifies example usage scenarios for enterprise users roaming outside the firewall, and defines a problem statement based on the scenarios. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-vpn-problem-statement-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-vpn-problem-statement-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-vpn-problem-statement-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020509124017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-vpn-problem-statement-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-vpn-problem-statement-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020509124017.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 10 07:50:59 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16079 for ; Fri, 10 May 2002 07:50:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28958; Fri, 10 May 2002 05:50:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA11090; Fri, 10 May 2002 04:50:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ABnarP001857 for ; Fri, 10 May 2002 04:49:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4ABnaQX001856 for mobile-ip-dist; Fri, 10 May 2002 04:49:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ABnXrP001849 for ; Fri, 10 May 2002 04:49:33 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28022 for ; Fri, 10 May 2002 04:49:34 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28603 for ; Fri, 10 May 2002 05:49:34 -0600 (MDT) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 May 2002 07:49:33 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46E21C72@ftmail> From: "Alan O'Neill" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Regional MIP drafts URL Date: Fri, 10 May 2002 07:49:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The set of drafts can now be found at; http://www.radiorouter.com/technology/tech_ietf-drafts.html Alan. From owner-mobile-ip@sunroof.eng.sun.com Fri May 10 08:40:25 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18491 for ; Fri, 10 May 2002 08:40:24 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA28429; Fri, 10 May 2002 05:38:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17820; Fri, 10 May 2002 05:38:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ACbErP001931 for ; Fri, 10 May 2002 05:37:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4ACbEc3001930 for mobile-ip-dist; Fri, 10 May 2002 05:37:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ACbArP001923 for ; Fri, 10 May 2002 05:37:10 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06694 for ; Fri, 10 May 2002 05:37:12 -0700 (PDT) From: Internet-Drafts@ietf.org Received: from public.szptt.net.cn (mail2-smtp.szptt.net.cn [202.96.136.222]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA17654 for ; Fri, 10 May 2002 06:37:10 -0600 (MDT) Received: from public.szptt.net.cn([202.96.136.222]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jmd3cdbe1ec; Fri, 10 May 2002 12:36:46 -0000 Received: from loki.ietf.org([132.151.1.177]) by public.szptt.net.cn(JetMail 2.5.3.0) with SMTP id jm843cd978aa; Wed, 8 May 2002 12:35:43 -0000 Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id HAA00156 for ietf-123-outbound.01@ietf.org; Wed, 8 May 2002 07:55:00 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id HAA29837 for ; Wed, 8 May 2002 07:27:53 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00814; Wed, 8 May 2002 07:27:46 -0400 (EDT) Message-Id: <200205081127.HAA00814@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-ipv6-17.txt Date: Wed, 08 May 2002 07:27:45 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobility Support in IPv6 Author(s) : D. Johnson, C. Perkins, J. Arkko Filename : draft-ietf-mobileip-ipv6-17.txt Pages : 167 Date : 07-May-02 This document specifies the operation of mobile computers using IPv6. Each mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While situated away from its home, a mobile node is also associated with a care-of address, which provides information about the mobile node's current location. IPv6 packets addressed to a mobile node's home address are transparently routed to its care-of address. The protocol enables IPv6 nodes to cache the binding of a mobile node's home address with its care-of address, and to then send any packets destined for the mobile node directly to it at this care-of address. To support this operation, Mobile IPv6 defines a new IPv6 protocol and a new destination option. All IPv6 nodes, whether mobile or stationary, MUST support communications with mobile nodes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-17.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-ipv6-17.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-ipv6-17.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: <20020507124225.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-ipv6-17.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-ipv6-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020507124225.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 10 10:30:14 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25105 for ; Fri, 10 May 2002 10:30:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00648; Fri, 10 May 2002 08:29:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23176; Fri, 10 May 2002 07:29:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4AEScrP002119 for ; Fri, 10 May 2002 07:28:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4AEScmH002118 for mobile-ip-dist; Fri, 10 May 2002 07:28:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4AESZrP002111 for ; Fri, 10 May 2002 07:28:35 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28727 for ; Fri, 10 May 2002 07:28:36 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10237 for ; Fri, 10 May 2002 07:28:36 -0700 (PDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4AESPHT024006; Fri, 10 May 2002 07:28:25 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA27152; Fri, 10 May 2002 10:28:25 -0400 (EDT) Date: Fri, 10 May 2002 10:28:25 -0400 From: "Madhavi W. Chandra" To: mobile-ip@sunroof.eng.sun.com Cc: mobileip-ietf@cisco.com Subject: [mobile-ip] Feedback on NAT draft Message-ID: <20020510102825.E26141@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Henrik and Sami, We've gone through your NAT draft with much interest and have a few comments: 1) Is the F bit in the UDP Reg Request Extension needed? Probably can let HA make the decision of IP-in-UDP tunneling. If HA determines that the RRQ did not traverse a NAT box, it still MAY accept the IP-in-UDP tunneling request based on administrative policy on the HA. Don't see the need for the MN to mandate this with the 'F' bit, since the HA is in the better position to decide. 2) Sect. 1.2. Comparison of IP SRC address against (a) CoA, (b) Home address, or (c) 0.0.0.0. Is this only the case when MN is sending RRQ in Co-CoA case? Should be made precise, as this does not hold in FA case. 3) For FA case, HA detection of NAT traversal is suspect since CoA and source IP address (FA egress interface) need not be the same. We suggest: Can either append UDP Reg Request Ext with *IP address of FA* when FA relays the RRQ to HA. Then HA can compare the IP SRC against the IP address of FA in UDP ext. If mismatch, HA can determine that RRQ traversed a NAT box. Or, can mandate that the IP SRC used at FA (FA egress interface) is the same as the FA CoA. 4) The draft does not specifically state what the tunnel end point should be...it only states it precisely for the case that the 'R' bit and 'F' bit are set in the UDP request extension in Section 4.6. Moreover, it is not clear when the tunnel endpoint is decided...upon receipt of the initial RRQ or keepalive? Please clarify and add appropriate/precise text to the draft. 5) The draft says that periodic keepalive signaling SHOULD be in the form of an RRQ...this seems like heavy signaling to do every K seconds. I'm trying to dig through the nat-vpn archives to find the thread you mentioned previously. No luck so far. Do you have a writeup of your analysis that I may refer to? Perhaps the SHOULD should be relaxed. Thanks for your consideration. Regards, Madhavi From owner-mobile-ip@sunroof.eng.sun.com Fri May 10 12:04:16 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01011 for ; Fri, 10 May 2002 12:04:16 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26328; Fri, 10 May 2002 10:03:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27017; Fri, 10 May 2002 09:03:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4AG2SrP002269 for ; Fri, 10 May 2002 09:02:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4AG2S5B002268 for mobile-ip-dist; Fri, 10 May 2002 09:02:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4AG2PrP002261 for ; Fri, 10 May 2002 09:02:25 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24913 for ; Fri, 10 May 2002 09:02:27 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25589 for ; Fri, 10 May 2002 10:02:26 -0600 (MDT) Message-ID: <007e01c1f83b$cca4b5f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Alan O'Neill" , "Phil Roberts" , References: <8C92E23A3E87FB479988285F9E22BE46E21C6E@ftmail> Subject: Re: [mobile-ip] Proposed Resolutions to Last Call Comments on Regional Tunneling Draft Date: Fri, 10 May 2002 09:00:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alan, > Apart from the Flarion work that wants to re-use this signalling plane, I am > sure we can all think of reasons that an operator might want tighter control > over the content and hence routing of MIP messages in a domain for NAT / > firewall / security / QoS / accounting etc, and thereby avoid pushing a lot > of state out to the FAs. > There are plenty of other protocols that deal with these issues, why do you think MIP has a role to play here? For example, the protocols being defined in the MIDCOM working group are specifically to deal with controlling firewalls, etc. Perhaps the problem is that MIPv4 does AAA, leading one to believe that MIP is where other such services should reside? > So I wondered in which catagory this issue should be addressed. I guess I > would also recommend that that debate doesn't happen until people have a > little bit of time to think about Nested (at least) although the above > broader examples might help with motivation here. > I agree that it is premature to move forward with this draft and that additional debate is necessary. We now have two proposed alternatives. jak From owner-mobile-ip@sunroof.eng.sun.com Sat May 11 05:30:26 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23492 for ; Sat, 11 May 2002 05:30:25 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15056; Sat, 11 May 2002 02:28:21 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02531; Sat, 11 May 2002 02:28:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4B9RHrP003309 for ; Sat, 11 May 2002 02:27:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4B9RHWj003308 for mobile-ip-dist; Sat, 11 May 2002 02:27:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4B9RErP003301 for ; Sat, 11 May 2002 02:27:14 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10563 for ; Sat, 11 May 2002 02:27:16 -0700 (PDT) Received: from chardonnay.levkowetz.com (h224n1fls32o89.telia.com [213.66.61.224]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14812 for ; Sat, 11 May 2002 02:27:15 -0700 (PDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.02) id GVXWX7-00023K-00; Sat, 11 May 2002 11:27:07 +0200 From: "Henrik Levkowetz" To: "Madhavi W. Chandra" , Subject: RE: [mobile-ip] Feedback on NAT draft Date: Sat, 11 May 2002 11:27:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020510102825.E26141@cisco.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Madhavi, > > Hi Henrik and Sami, > > We've gone through your NAT draft with much interest > and have a few comments: > > 1) Is the F bit in the UDP Reg Request Extension needed? > Probably can let HA make the decision of IP-in-UDP tunneling. > If HA determines that the RRQ did not traverse a NAT box, > it still MAY accept the IP-in-UDP tunneling request based > on administrative policy on the HA. Don't see the need > for the MN to mandate this with the 'F' bit, since the HA > is in the better position to decide. The function of the F bit is to have a mechanism to Force UDP tunnelling to be used also when no NAT is detected. It seems some people find this desireable, and I agree, and it also turns out to have a function when handling the FA R-bit case. > > 2) Sect. 1.2. Comparison of IP SRC address against (a) CoA, > (b) Home address, or (c) 0.0.0.0. Is this only the case > when MN is sending RRQ in Co-CoA case? > Should be made precise, as this does not hold in FA case. Right. It should say e.g. "mobile node IP source address..." > > 3) For FA case, HA detection of NAT traversal is suspect since > CoA and source IP address (FA egress interface) need not be the same. Right, good point. > > We suggest: > > Can either append UDP Reg Request Ext with *IP address > of FA* when FA relays the RRQ to HA. Then HA can compare the IP > SRC against the IP address of FA in UDP ext. If mismatch, HA > can determine that RRQ traversed a NAT box. > > Or, can mandate that the IP SRC used at FA (FA egress interface) > is the same as the FA CoA. Right. The second solution is simpler, and I'd go for that unless others on the list feel otherwise. > > 4) The draft does not specifically state what the tunnel end > point should be...it only states it precisely for the case that the > 'R' bit and 'F' bit are set in the UDP request extension in Section 4.6. > Moreover, it is not clear when the tunnel endpoint is decided...upon > receipt of the initial RRQ or keepalive? Please clarify and add > appropriate/precise text to the draft. I gather you're not referring to the tunnel end points, really, as those are at the HA and FA/MN, exactly as for IP-IP tunnelling, but rather the apparent destination address the HA needs to use for the tunnel. Yes, we'll add a clarification of this. There's a typo in the relevant section in draft -02 which may have helped make this obscure, too :-) > > 5) The draft says that periodic keepalive signaling SHOULD be in the > form of an RRQ...this seems like heavy signaling to do every K > seconds. I'm trying to dig through the nat-vpn archives to find the > thread you mentioned previously. No luck so far. Do you have a > writeup of your analysis that I may refer to? Perhaps the SHOULD should > be relaxed. Ok, the bandwidth calculation. Let us assume: a low-bandwidth channel of 14400 bits per second, a keepalive every 20 seconds a registration request which is typically some 80 bytes, IP header included a registration reply of the same length a binding lifetime of 120 seconds In this case, the bandwidth consumed by using registration requests and replies are roughly 5*2*8*80 out of 14400*120, or 6400/1728000, or about 0.37 % of the channel. If we compare this with zero-data icmp echo requests/replies, we get 5*2*8*28/(14400*120), or 0.13% of the channel. Yes, this is less. But no, I can't see about 0.4 % of a 14400 bit/s channel as heavy signalling. So here we differ in opinion. I on my part hold that 1) registration request keepalives are not particularly heavy, and 2) there are benefits to using reg. requests as keepalives, which makes at least a SHOULD appropriate, while 3) for extremely! processor-challenged mobiles, it may be heavy work to calculate the HMAC-MD5, so we need to use a SHOULD rather than a MUST (I think this third point is weak) and finally 4) in the FA R-bit case, we *cannot* use reg. requests / replies as keepalives, so we must have an alternative. Best regards, Henrik From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 05:55:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01692 for ; Mon, 13 May 2002 05:55:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA06292; Mon, 13 May 2002 03:53:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07279; Mon, 13 May 2002 02:52:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4D9ptrP005896 for ; Mon, 13 May 2002 02:51:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4D9psYF005895 for mobile-ip-dist; Mon, 13 May 2002 02:51:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4D9pprP005888 for ; Mon, 13 May 2002 02:51:51 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06917 for ; Mon, 13 May 2002 02:51:53 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11611 for ; Mon, 13 May 2002 03:51:46 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4D9pjs7013748 for ; Mon, 13 May 2002 11:51:46 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon May 13 11:51:36 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4GBZH>; Mon, 13 May 2002 11:51:35 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF05380457CDD5@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: emadaq@yahoo.com, "'James Kempf'" , "'Phil Roberts'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Date: Mon, 13 May 2002 11:51:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I agree with James about the requirements aspect. " against the > proposed solutions". > > I have asked the authors question(s) about the real-time impact > to the MIP protocol? What is it really? => This has nothing to do with this particular draft. Your question is a general concern about MIP and real time. Is it not clear that a local agent will reduce the registration time to the HA? I can't see how this could not be obvious. > Is the added complexity to the overall MIP architecture worth > the few MS for a trip to the home network/the added > signaling message to > the home? => I can understand that for MIPv4, it is a valid question to raise. However, I would not say 'few ms'. This clearly depends on the location of the HA. Across the atlantic this is easily in the order of tens of ms at best. That is, if the first packet makes it to the HA. > Also, looking at from a services point view and a direction of > how handheld devices with dual access (or more) would be used, I > strongly believe (may be only me) that the granularity of > the location > to the home network/info-provider would of high importance > for location > based services. I don't want to know that my subscriber is > visiting the > North section of town, I need to have more information about the > location so I can "push/send" more personalized data to > him, i.e. his > favorite pizza restaurant. => But again, this has nothing to do with what is being discussed here. In fact, I would highly recommend that you consider this type of geographical location management as an application layer issue. There are proposals in SIPPING to handle this. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 11:09:03 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14761 for ; Mon, 13 May 2002 11:09:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08713; Mon, 13 May 2002 09:08:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06520; Mon, 13 May 2002 08:08:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DF7GrP006609 for ; Mon, 13 May 2002 08:07:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DF7GjE006608 for mobile-ip-dist; Mon, 13 May 2002 08:07:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DF7DrP006601 for ; Mon, 13 May 2002 08:07:13 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15774 for ; Mon, 13 May 2002 08:07:14 -0700 (PDT) From: Padmakumar.AV@lntinfotech.com Received: from ltitlin.lntinfotech.com ([203.199.54.35]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08119 for ; Mon, 13 May 2002 09:07:13 -0600 (MDT) Received: from bangalore.lntinfotech.com ([172.29.4.3]) by ltitlin.lntinfotech.com (Lotus Domino Release 5.0.8) with ESMTP id 2002051320380457:6823 ; Mon, 13 May 2002 20:38:04 +0530 Subject: [mobile-ip] MN Returning Home To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Mon, 13 May 2002 20:34:27 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/13/2002 08:34:28 PM, Itemize by SMTP Server on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/13/2002 08:38:04 PM, Serialize by Router on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/13/2002 08:38:07 PM, Serialize complete at 05/13/2002 08:38:07 PM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello, If the mobile node had to restart at its home network, after returning home and before doing deregistration and before its binding with home agent expires, then how to handle DAD as part of auto configuration, since the HA is armed to defend any use of this IP address. Does it means that HA should not permit any binding lifetime, which is more than some threshold. Thank you pav From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 11:29:38 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15812 for ; Mon, 13 May 2002 11:29:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27370; Mon, 13 May 2002 09:29:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22001; Mon, 13 May 2002 08:28:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DFRwrP006718 for ; Mon, 13 May 2002 08:27:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DFRvQL006717 for mobile-ip-dist; Mon, 13 May 2002 08:27:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DFRsrP006710 for ; Mon, 13 May 2002 08:27:54 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18908 for ; Mon, 13 May 2002 08:27:56 -0700 (PDT) Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA00952 for ; Mon, 13 May 2002 08:27:56 -0700 (PDT) Received: from unknown (HELO EmadQ) (emadaq@194.165.137.97 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 13 May 2002 15:27:54 -0000 Reply-To: From: "Emad Qaddoura" To: "'Hesham Soliman \(ERA\)'" , Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Date: Mon, 13 May 2002 18:26:54 +0200 Message-ID: <001501c1fa9b$01497230$6189a5c2@EmadQ> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F05CF@Esealnt861.al.sw.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Hesham, Sorry, did not mean to take the list off, too quick on the REPLY option. I agree with you here, the question may be stated better the way you did: "So the question here is whether people think the optimisation is worth the complexity. But I don't see a question of whether this mechanism will add benefit or not, it certainly does. The question is: How big is the benefit? that's probably a better focus for the discussion. Thx. > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Monday, May 13, 2002 4:35 PM > To: 'emadaq@yahoo.com' > Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue > #1 > > Hi Emad, > > I don't know if you accidentally removed > the list or not, so I won't put it back. > But feel free to forward. > > > > => But again, this has nothing to do with what > > > is being discussed here. In fact, I would highly > > > recommend that you consider this type of geographical > > > location management as an application layer issue. > > > There are proposals in SIPPING to handle this. > > > > > I agree that MIP may not deal directly with services, but what > > is the benefit of mobility information? I may not mean exact > > geographical location, but what I mean is the service > > provider may care > > about the proximity of the MN, and GFA will prevent, > > depending on the > > size of the coverage area, such info from being propagated. > > => Yes, that's true, but the question is whether > you could rely on IP addresses at all for > geogrphical location management. 3G systems for > example have very large coverage areas per FA, which > would prevent operators from locating MNs to even > a suburb, so it's difficult to reply on IP > addresses for this purpose. > > > > > In general, I believe the group should follow a mechanism of not > > introducing features/enhancements that may add to the real > > time impact. > > I may be wrong from others point view, but just raising my concern. > > => I don't think your statement above is wrong, in fact > I agree, but I don't see that being the case in this > draft. > The difference between updating the GFA in Reg reg, and > the FA in FMIP is the type of optimisation that you > get. When updating the GFA, you are optimising for > minimal delays for new packets, but you will be likely > to introduce more losses (depending on the pipe between > the GFA and FA). If you rely on updating the FA > only (FMIP approach) then you could minimise the packet > losses, but possibly get more delays (depending on the > pipe between oFA and nFA). So each approach has > its pro and con, combining both (as outlined in the FMIP) > draft, would lead to better results than if each > one is used separately. > > So the question here is whether people think the > optimisation is worth the complexity. But I don't > see a question of whether this mechanism will add > benefit or not, it certainly does. The question > is: How big is the benefit? that's probably a better > focus for the discussion. > > Hesham > > > > > Thx. > > > > > -----Original Message----- > > > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > > > ip@sunroof.eng.sun.com] On Behalf Of Hesham Soliman (ERA) > > > Sent: Monday, May 13, 2002 11:51 AM > > > To: emadaq@yahoo.com; 'James Kempf'; 'Phil Roberts'; mobile- > > > ip@sunroof.eng.sun.com > > > Subject: RE: [mobile-ip] Regional Registration Last Call > > Resolution > > Issue > > > #1 > > > > > > > I agree with James about the requirements > > aspect. " against the > > > > proposed solutions". > > > > > > > > I have asked the authors question(s) about the > > real-time impact > > > > to the MIP protocol? What is it really? > > > > > > => This has nothing to do with this particular > > > draft. Your question is a general concern about > > > MIP and real time. Is it not clear that a local > > > agent will reduce the registration time to the > > > HA? I can't see how this could not be obvious. > > > > > > > Is the added complexity to the overall MIP > > architecture worth > > > > the few MS for a trip to the home network/the added > > > > signaling message to > > > > the home? > > > > > > => I can understand that for MIPv4, it is a valid > > > question to raise. However, I would not say > > > 'few ms'. This clearly depends on the location > > > of the HA. Across the atlantic this is easily > > > in the order of tens of ms at best. That is, > > > if the first packet makes it to the HA. > > > > > > > Also, looking at from a services point view and > > a direction of > > > > how handheld devices with dual access (or more) would > > be used, I > > > > strongly believe (may be only me) that the granularity of > > > > the location > > > > to the home network/info-provider would of high importance > > > > for location > > > > based services. I don't want to know that my subscriber is > > > > visiting the > > > > North section of town, I need to have more > > information about the > > > > location so I can "push/send" more personalized data to > > > > him, i.e. his > > > > favorite pizza restaurant. > > > > > > => But again, this has nothing to do with what > > > is being discussed here. In fact, I would highly > > > recommend that you consider this type of geographical > > > location management as an application layer issue. > > > There are proposals in SIPPING to handle this. > > > > > > Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 11:46:01 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16368 for ; Mon, 13 May 2002 11:46:00 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12149; Mon, 13 May 2002 08:43:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27436; Mon, 13 May 2002 08:43:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DFgprP006777 for ; Mon, 13 May 2002 08:42:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DFgpMX006776 for mobile-ip-dist; Mon, 13 May 2002 08:42:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DFglrP006769 for ; Mon, 13 May 2002 08:42:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27105 for ; Mon, 13 May 2002 08:42:50 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07925 for ; Mon, 13 May 2002 08:42:49 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4DFgbc17613; Mon, 13 May 2002 17:42:37 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA08458; Mon, 13 May 2002 17:42:37 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4DFgaT75327; Mon, 13 May 2002 17:42:37 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205131542.g4DFgaT75327@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Padmakumar.AV@lntinfotech.com cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MN Returning Home In-reply-to: Your message of Mon, 13 May 2002 20:34:27 +0530. Date: Mon, 13 May 2002 17:42:36 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: If the mobile node had to restart at its home network, after returning home and before doing deregistration and before its binding with home agent expires, then how to handle DAD as part of auto configuration, since the HA is armed to defend any use of this IP address. Does it means that HA should not permit any binding lifetime, which is more than some threshold. => you really have a problem when the "whole subnet" is registered and makes the link-local address not available to do an "in force" deregistration. (just a comment) Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 11:56:58 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16818 for ; Mon, 13 May 2002 11:56:58 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09132; Mon, 13 May 2002 09:55:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01292; Mon, 13 May 2002 08:55:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DFsArP006856 for ; Mon, 13 May 2002 08:54:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DFsAbi006855 for mobile-ip-dist; Mon, 13 May 2002 08:54:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DFs7rP006848 for ; Mon, 13 May 2002 08:54:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29828 for ; Mon, 13 May 2002 08:54:08 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13056 for ; Mon, 13 May 2002 09:54:31 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4DFs6s7027931 for ; Mon, 13 May 2002 17:54:06 +0200 (MEST) Received: from bends.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id RAA27605; Mon, 13 May 2002 17:54:04 +0200 Message-Id: <5.1.0.14.0.20020513174340.0287b200@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 13 May 2002 17:52:38 +0200 To: mobile-ip@sunroof.eng.sun.com From: Annika Jonsson Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Here are my conclusions and proposals for additions/changes to solve the backwards compatibility issues in the Regional Registrations draft: A: Backwards compatibility with RFC3220 MN:s. FA:s must advertise their own address, since it is used for movement detection by RFC3220 MN:s. This requires one change and one clarification to the draft: - To be backwards compatible, if the FA only advertises one CoA it must be its own address (not the GFA address as specified now). This FA must be able to act as a normal RFC3220 FA (that's in the draft already). - clarify that if the FA advertises a zero address, it will not support RFC3220 MN:s. In some cases the owner of the network might prefer this. B: Backwards compatibility with RFC3220 HA:s The problem here is that an RFC 3220 HA does not understand the GFA IP extension used if the MN sends a registration with zero CoA. There are two ways to solve this: B1: According to the draft right now, the MN MUST NOT send a Registration Request with zero CoA if it's HA doesn't support that. This is simple, but not very flexible. If the FA advertises a GFA CoA (in addition to the FA CoA), the MN should use that, and can then make use of regional registrations even though it's HA does not support it. If the FA only advertises it's own address, the MN can not make use of regional registration unless it's HA supports it, but can still use normal Mobile IP. An FA that only advertises a zero address will not be backwards compatible. B2: The other alternative is that the draft could be changed by adding a new error code from the GFA to tell the MN that the HA did not support the GFA IP extension. The MN could then try the advertised CoA instead (or, possibly, a new extension added so the the GFA could tell the MN what CoA to use). I see one problem with this: I'm not sure how an RFC3220 HA would deal with this kind of registration. In the draft today, the GFA IP extension is non-skippable (because the HA MUST support it if the MN uses it). A HA that doesn't support this would not answer to this registration at all, it would silently discard the message. If the extension was changed to be skippable, how would the HA react? Either it would notice that something is wrong with the CoA, and send a reply with some error code (e.g. "poorly formed request??). Or it would not even check the CoA (I couldn't find this mentioned anywhere in RFC3220). In this case it would accept the registration, and set the CoA to zero. The GFA will then receive a reply without a GFA IP extension. In both cases, the GFA _could_ assume that the HA did not support the GFA IP extension, but it doesn't know for sure. To conclude: this option (B2) seems too uncertain, so I would rather go for the (more unflexible, but simple) B1 (i.e. no changes to the current draft, but it could be clarified a bit). /Annika From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 12:19:18 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18296 for ; Mon, 13 May 2002 12:19:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23894; Mon, 13 May 2002 10:18:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29577; Mon, 13 May 2002 09:18:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DGHdrP006939 for ; Mon, 13 May 2002 09:17:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DGHdP3006938 for mobile-ip-dist; Mon, 13 May 2002 09:17:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DGHarP006931 for ; Mon, 13 May 2002 09:17:36 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09478 for ; Mon, 13 May 2002 09:17:38 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01460 for ; Mon, 13 May 2002 09:17:37 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4DGHZ0E028605; Mon, 13 May 2002 18:17:35 +0200 (MEST) Received: from bends.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id SAA28203; Mon, 13 May 2002 18:17:32 +0200 Message-Id: <5.1.0.14.0.20020513175420.0287a090@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 13 May 2002 18:16:05 +0200 To: "Madhavi W. Chandra" , Phil Roberts From: Annika Jonsson Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Cc: "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: <20020509130354.A25864@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Madhavi, see below... At 01:03 PM 5/9/2002 -0400, Madhavi W. Chandra wrote: >On Thu, May 09, 2002 at 10:41:32AM -0400, Phil Roberts wrote: > > There were a few comments questioning whether or not this draft should be > > published as a proposed standard at all, specifically whether it provides > > useful functionality, or functionality that is not otherwise available, or > > is described in a way that makes it clear to what extent it is optional to > > implement. A separate thread will address the issue of whether this draft > > should be published because it raises issue with fundamental architectural > > principles in the Internet. > > > > The document clearly states what it is attempting to do - reduce > > registration messaging traffic across the Internet, and reduce the handover > > latency when Home Agents are far from the Mobile Nodes which they serve. > > There has been expressed interest in the working group for pursuing > this and > > there continues to be interest in doing so. > > > > There were suggestions that these requirements might better be served > by the > > low latency draft (draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt). The > > techniques can be deployed in a > > complementary fashion. Low latency discusses how the drafts can be used > > together (see Appendix A). Given that the only plans for advancing > > lowlatency now are in an experimental status, offering to replace this with > > that doesn't necessarily advance the interests of the community. > > > > Another issue was raised as to what extent it is optional to implement the > > functionality described here. > > Given that it can be made clear that this is optional to implement, > there is > > interest across the working group in doing so, and the proposed > alternate is > > only experimental, these objections are not sufficient to stop the advance > > of this document to Proposed Standard. > > > > Attached below is modified text for the abstract and the introduction, > > Annika's words based on input > > from Madhavi. > >DISAGREE...as written below. > >As per the feedback we provided, it should be clearly stated in the >Abstract and Introduction that this architecture is OPTIONAL and not >required in typical Mobile IP deployments. In the proposed text, both the Abstract and the Introduction _does_ say that this is an optional extension to MIP, so what are you disagreeing with? >Also, reference to the new >Section that will describe scenarios that may benefit from this >architecture should be included in the Introduction. The agreement to >include the new Section is to alleviate the doubts for the necessity >of this architecture. Hopefully, the new Section will highlight when >the architecture is useful, and not when it is NOT. I think that the text in the Introduction gives sufficent information about what makes regional registrations useful and see no need for an extra section. Regards, Annika >I have provided Annika with the suggested text. Please incorporate >the above comments. > >Thanks, >Madhavi > > > > Phil > > > > "Abstract > > > > Using Mobile IP, a mobile node registers with its home agent each time it > > changes care-of address. If the distance between the visited network and > > the home network of the mobile node is large, the signaling delay for > these > > registrations may be long. This document describes a new kind of > "regional" > > registration, i.e., registration local to the visited domain. The regional > > signaling is performed via a new network entity called a Gateway Foreign > > Agent and introduces a layer of hierarchy in the foreign domain. Regional > > registrations reduce the number of signaling messages to the home network, > > and reduce the signaling delay when a mobile node moves from one foreign > > agent to another, within the same visited domain. This document is an > > optional extension to the Mobile IP protocol." > > > > > > "Introduction > > > > This document is an optional extension to the Mobile IP protocol, and > > proposes a means for mobile nodes to register locally within a visited > > domain. By registering locally, the number of signaling messages to the > > home network are keept to a minimum, and the signaling delay is reduced. > > > > In Mobile IP, as specified in RFC 3220 [9], a mobile node registers with > > its home agent each time it changes care-of address. If the distance > > between the visited network and the home network of the mobile node is > > large, the signaling delay for these registrations may be long. We propose > > a solution for performing registrations locally in the visited domain: > > regional registrations. The regional registration design introduces new > > Mobile IP messages - Regional Registrations, new Mobile IP extensions to > > convey information between the mobile node, foreign agent, and home agent, > > and a new network entity - Gateway Foreign Agent (GFA). Regional > > registrations reduce the number of signaling messages to the home network, > > and reduce the signaling delay when a mobile node moves from one foreign > > agent to another, within the same visited domain. This will both decrease > > the load on the home network, and speed up the process of handover within > > the visited domain. The introduction of a GFA also makes it possible to > > have different addressing realms in the home and in the visited networks." > > > > > > The last three paragraphs of the Introduction are unmodified. From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 12:41:05 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19069 for ; Mon, 13 May 2002 12:41:04 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15283; Mon, 13 May 2002 09:38:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06657; Mon, 13 May 2002 09:38:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DGbgrP007005 for ; Mon, 13 May 2002 09:37:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DGbgue007004 for mobile-ip-dist; Mon, 13 May 2002 09:37:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DGbcrP006997 for ; Mon, 13 May 2002 09:37:38 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17356 for ; Mon, 13 May 2002 09:37:41 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14480 for ; Mon, 13 May 2002 09:37:41 -0700 (PDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4DGbbHT008449; Mon, 13 May 2002 09:37:37 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id MAA01357; Mon, 13 May 2002 12:37:37 -0400 (EDT) Date: Mon, 13 May 2002 12:37:37 -0400 From: "Madhavi W. Chandra" To: Annika Jonsson Cc: "Madhavi W. Chandra" , Phil Roberts , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Message-ID: <20020513123737.A1353@cisco.com> References: <20020509130354.A25864@cisco.com> <5.1.0.14.0.20020513175420.0287a090@era-t.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20020513175420.0287a090@era-t.ericsson.se>; from annika.jonsson@ericsson.com on Mon, May 13, 2002 at 06:16:05PM +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: HI Annika, On Mon, May 13, 2002 at 06:16:05PM +0200, Annika Jonsson wrote: > Hi Madhavi, > > see below... > > At 01:03 PM 5/9/2002 -0400, Madhavi W. Chandra wrote: > >On Thu, May 09, 2002 at 10:41:32AM -0400, Phil Roberts wrote: > > > There were a few comments questioning whether or not this draft should be > > > published as a proposed standard at all, specifically whether it provides > > > useful functionality, or functionality that is not otherwise available, or > > > is described in a way that makes it clear to what extent it is optional to > > > implement. A separate thread will address the issue of whether this draft > > > should be published because it raises issue with fundamental architectural > > > principles in the Internet. > > > > > > The document clearly states what it is attempting to do - reduce > > > registration messaging traffic across the Internet, and reduce the handover > > > latency when Home Agents are far from the Mobile Nodes which they serve. > > > There has been expressed interest in the working group for pursuing > > this and > > > there continues to be interest in doing so. > > > > > > There were suggestions that these requirements might better be served > > by the > > > low latency draft (draft-ietf-mobileip-lowlatency-handoffs-v4-03.txt). The > > > techniques can be deployed in a > > > complementary fashion. Low latency discusses how the drafts can be used > > > together (see Appendix A). Given that the only plans for advancing > > > lowlatency now are in an experimental status, offering to replace this with > > > that doesn't necessarily advance the interests of the community. > > > > > > Another issue was raised as to what extent it is optional to implement the > > > functionality described here. > > > Given that it can be made clear that this is optional to implement, > > there is > > > interest across the working group in doing so, and the proposed > > alternate is > > > only experimental, these objections are not sufficient to stop the advance > > > of this document to Proposed Standard. > > > > > > Attached below is modified text for the abstract and the introduction, > > > Annika's words based on input > > > from Madhavi. > > > >DISAGREE...as written below. > > > >As per the feedback we provided, it should be clearly stated in the > >Abstract and Introduction that this architecture is OPTIONAL and not > >required in typical Mobile IP deployments. > > In the proposed text, both the Abstract and the Introduction _does_ say > that this is an optional extension to MIP, so what are you disagreeing with? As I stated in the email above and in my writeup, it should say clearly in the Abstract and Introduction that the architecture is OPTIONAL *and not required in typical Mobile IP deployments.* Since this is not what you wrote above, we are DISAGREEING. > > >Also, reference to the new > >Section that will describe scenarios that may benefit from this > >architecture should be included in the Introduction. The agreement to > >include the new Section is to alleviate the doubts for the necessity > >of this architecture. Hopefully, the new Section will highlight when > >the architecture is useful, and not when it is NOT. > > I think that the text in the Introduction gives sufficent information about > what makes regional registrations useful and see no need for an extra section. This is not what Charlie and I agreed to. We agreed to a new Section that describes where this architecture would be useful...perhaps you can provide network architectures that would benefit from the regional tunneling. As per the agreement, the new section would go into Section 3...probably Section 3.1 as Charlie mentioned. Refer to the original email thread on this. If we had thought that the Introduction was sufficient, the original email thread would not have occured. Please do not go back to square one. Thanks, Madhavi > Regards, > Annika > > >I have provided Annika with the suggested text. Please incorporate > >the above comments. > > > >Thanks, > >Madhavi > > > > > > > Phil > > > > > > "Abstract > > > > > > Using Mobile IP, a mobile node registers with its home agent each time it > > > changes care-of address. If the distance between the visited network and > > > the home network of the mobile node is large, the signaling delay for > > these > > > registrations may be long. This document describes a new kind of > > "regional" > > > registration, i.e., registration local to the visited domain. The regional > > > signaling is performed via a new network entity called a Gateway Foreign > > > Agent and introduces a layer of hierarchy in the foreign domain. Regional > > > registrations reduce the number of signaling messages to the home network, > > > and reduce the signaling delay when a mobile node moves from one foreign > > > agent to another, within the same visited domain. This document is an > > > optional extension to the Mobile IP protocol." > > > > > > > > > "Introduction > > > > > > This document is an optional extension to the Mobile IP protocol, and > > > proposes a means for mobile nodes to register locally within a visited > > > domain. By registering locally, the number of signaling messages to the > > > home network are keept to a minimum, and the signaling delay is reduced. > > > > > > In Mobile IP, as specified in RFC 3220 [9], a mobile node registers with > > > its home agent each time it changes care-of address. If the distance > > > between the visited network and the home network of the mobile node is > > > large, the signaling delay for these registrations may be long. We propose > > > a solution for performing registrations locally in the visited domain: > > > regional registrations. The regional registration design introduces new > > > Mobile IP messages - Regional Registrations, new Mobile IP extensions to > > > convey information between the mobile node, foreign agent, and home agent, > > > and a new network entity - Gateway Foreign Agent (GFA). Regional > > > registrations reduce the number of signaling messages to the home network, > > > and reduce the signaling delay when a mobile node moves from one foreign > > > agent to another, within the same visited domain. This will both decrease > > > the load on the home network, and speed up the process of handover within > > > the visited domain. The introduction of a GFA also makes it possible to > > > have different addressing realms in the home and in the visited networks." > > > > > > > > > The last three paragraphs of the Introduction are unmodified. From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 12:55:11 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19629 for ; Mon, 13 May 2002 12:55:11 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16648; Mon, 13 May 2002 10:54:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24318; Mon, 13 May 2002 09:54:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DGrRrP007073 for ; Mon, 13 May 2002 09:53:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DGrRbA007072 for mobile-ip-dist; Mon, 13 May 2002 09:53:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DGrOrP007065 for ; Mon, 13 May 2002 09:53:24 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26652 for ; Mon, 13 May 2002 09:53:26 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27723 for ; Mon, 13 May 2002 09:53:26 -0700 (PDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g4DGrP416975; Mon, 13 May 2002 11:53:25 -0500 (CDT) Message-ID: <3CDFEF9C.1050700@alcatel.com> Date: Mon, 13 May 2002 11:53:48 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Annika Jonsson CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #2 References: <5.1.0.14.0.20020513174340.0287b200@era-t.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Annika, I have a question on how your draft which I strongly support would behave in the presence of NAT/NAPT boxes and IPsec VPNs? I could not see any GFA consideration in? http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-02.txt and in http://www.ietf.org/internet-drafts/draft-ietf-mobileip-vpn-problem-statement-00.txt Regards, Annika Jonsson wrote: --behcet From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 13:39:12 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21627 for ; Mon, 13 May 2002 13:39:12 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20704; Mon, 13 May 2002 11:39:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13327; Mon, 13 May 2002 10:38:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DHbSrP007181 for ; Mon, 13 May 2002 10:37:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DHbSLI007180 for mobile-ip-dist; Mon, 13 May 2002 10:37:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DHbPrP007173 for ; Mon, 13 May 2002 10:37:26 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10103 for ; Mon, 13 May 2002 13:37:25 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g4DHbOqp012846 for ; Mon, 13 May 2002 13:37:24 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g4DHbOUK012845 for mobile-ip@sunroof.eng.sun.com; Mon, 13 May 2002 13:37:24 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ALErrP002664 for ; Fri, 10 May 2002 14:14:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12207 for ; Fri, 10 May 2002 14:14:54 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA05827 for ; Fri, 10 May 2002 15:14:53 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 8EC0E375D; Fri, 10 May 2002 16:14:52 -0500 (CDT) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id F13B810AF; Fri, 10 May 2002 16:14:51 -0500 (CDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id RAA0001395357; Fri, 10 May 2002 17:14:51 -0400 (EDT) Message-ID: <3CDC384B.7AB7417B@hp.com> Date: Fri, 10 May 2002 17:14:51 -0400 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.78 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Brian Haley , Charlie Perkins , mobile-ip@sunroof.eng.sun.com Subject: Re: [Fwd: [mobile-ip] S-bit and building a link-local address] References: <3CD7E4AB.617F8688@compaq.com> <3CD9B0DB.2060802@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Vijay, RFC 2462 (address autoconfiguration) tells you how to make a link-local address from an interface identifier, but not how to make an address identifier from a unicast address. I guess the Home Agent could figure this out since it should know the link type, but this will not work in all cases (Section 2.5.4 of the new address architecture imposed some limitations). Anyways, maybe it is more useful to have the Mobile Node supply it's interface identifier if it wishes to have more than one address registered, then it's not ambigous. I didn't really want to go there, I would still favor removing the S-bit, that way the MN can register only the addresses it wants. Right now, if the S-bit isn't set, there is no way for the MN to know exactly which addresses the HA configured - by the time it does a prefix solicitation there could have been a change. -Brian P.S. I might be slow to respond to email next week... Vijay Devarapalli wrote: > hi Brian, > > sorry for the late reply. from 2462 Section 5.3 > > A link-local address is formed by prepending the well-known link- > local prefix FE80::0 [ADDR-ARCH] (of appropriate length) to the > interface identifier. If the interface identifier has a length of N > bits, the interface identifier replaces the right-most N zero bits of > the link-local prefix. If the interface identifier is more than 118 > bits in length, autoconfiguration fails and manual configuration is > required. Note that interface identifiers will typically be 64-bits > long and based on EUI-64 identifiers as described in [ADDR-ARCH]. > > since the home agent knows the prefix length of the home link and > thereby the interface id length of the MN's HoA, it can construct > the link local address for the MN. > > if the mobile node knows that it uses a different interface id for > the link local address and the home address, it should always set > the 'S' bit to 1. Then the home agent would defend only the home > address. > > regards > Vijay > > Brian Haley wrote: > > > Hi Charlie and Vijay, > > > > On April 23rd I raised an issue about the S-bit in Binding Updates on > > the mailing list that had only one response (Francis Dupont), hardly > > consensus. Jari put it on the issues list for the draft, but wanted me to > > get more input on it. Instead of re-posting to the list, I figured I'd > > send mail to you two since Charlie's the co-author and I've talked to > > Vijay about other draft things. > > > > If you want to post a reponse to the list, that's fine, I just wanted to > > make sure other people hadn't missed it. Francis had the same > > conclusion I did btw... > > > > Thanks, > > > > -Brian > > > > > > ------------------------------------------------------------------------ > > > > Subject: > > > > [mobile-ip] S-bit and building a link-local address > > From: > > > > Brian Haley > > Date: > > > > Tue, 23 Apr 2002 17:55:27 -0400 > > To: > > > > mobile ip > > > > > > Hi, > > > > I have an issue with the use of the S-bit in Binding Updates. > > > > I'll start with a hard question: > > > > Where can I find the spec/RFC that defines how to build a link-local address > > from a global unicast address? > > > > The BU only has the global address, and I think everyone's assuming /64 prefix > > lengths, but according to the addressing architecture > > (draft-ietf-ipngwg-addr-arch-v3-07.txt, soon to update RFC 2373), that's not > > the case: > > > > Section 2.5.4 on Global Unicast Addresses > > > > "All global unicast addresses other than those that start with binary > > 000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as > > described in section 2.5.1. Global unicast addresses that start with > > binary 000 have no such constraint on the size or structure of the > > interface ID field." > > > > I've been struggling with this one for a while, but it doesn't seem like we > > can just mask-off the upper 64 bits, stuff an FE80 in there, and call it a > > link-local address. This isn't even considering the IPv6-over-foo RFCs. > > > > So if that question can't be answered, I feel the S-bit must be removed > > from the draft, unless someone is willing to write-up the method in > > question, but since building link-local addresses has media type > > implications, I wasn't going to go there. > > > > This also has ramifications with the D-bit since Section 9.1 of the > > Mobile IPv6 spec says we must do DAD for the link-local address. > > > > Am I missing something here? > > > > -Brian > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 13:48:47 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22039 for ; Mon, 13 May 2002 13:48:46 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01873; Mon, 13 May 2002 10:46:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17285; Mon, 13 May 2002 10:46:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DHjxrP007375 for ; Mon, 13 May 2002 10:45:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DHjxsj007374 for mobile-ip-dist; Mon, 13 May 2002 10:45:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DHjvrP007367 for ; Mon, 13 May 2002 10:45:57 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12892 for ; Mon, 13 May 2002 13:45:58 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g4DHjvqp012853 for ; Mon, 13 May 2002 13:45:57 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g4DHjvOj012852 for mobile-ip@sunroof.eng.sun.com; Mon, 13 May 2002 13:45:57 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ALZMrP002714 for ; Fri, 10 May 2002 14:35:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18540 for ; Fri, 10 May 2002 14:35:23 -0700 (PDT) Received: from ns0.utdallas.edu (ns0.utdallas.edu [129.110.10.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10783 for ; Fri, 10 May 2002 14:35:22 -0700 (PDT) Received: from dslab10 (dslab10.utdallas.edu [129.110.94.72]) by ns0.utdallas.edu (Postfix) with SMTP id EBCF01A123C for ; Fri, 10 May 2002 16:35:21 -0500 (CDT) Message-ID: <004a01c1f86a$b7e40380$485e6e81@dslab10> From: "Mansoor Mohsin" To: Subject: [mobile-ip] POMC - Call For Papers Date: Fri, 10 May 2002 16:36:17 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C1F840.CEEC69C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0047_01C1F840.CEEC69C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Call For Papers --------------- Preliminary Announcement and Call for Papers POMC 2002 Workshop on Principles of Mobile Computing October 30-31, 2002, Toulouse, France. Workshop URL: www.utdallas.edu/~ravip/pomc/POMC/POMC.html Sponsor: ACM SIGACT Accepted papers published by ACM Submission deadline : July 5, 2002 To be held in conjunction with International Symposium on DIStributed = Computing (DISC 2002) http://www.enseeiht.fr/~disc02/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mobile computing and communications devices are proliferating in recent = years. The mobility of distributed computing components raises a number = of interesting, and difficult, algorithmic issues. This two-day workshop is intended to bring together researchers in = mobile computing (especially, but not exclusively, ad hoc networks) and = distributed algorithms (especially, but not exclusively, dynamic = networks). To facilitate such interaction, the workshop is scheduled to = begin on the last day of DISC 2002. The planned format is a combination of contributed papers and one-hour = tutorials. Significant time for discussion will be allocated. It is = intended to be a lively and informal meeting, and to foster cooperation = among mobile computing systems researchers and distributed algorithms = theoreticians. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Topics ------ Papers are solicited in all research and applied areas that touch on the = application of, or need for, distributed algorithms in the context of = mobile computing systems. Papers covering work in progress are = especially welcome. Papers should describe original, previously = unpublished work that is not currently under review by another = conference, workshop, or journal. Specific topics include, but are not limited to: - distributed algorithms=20 - routing=20 - dynamic networks=20 - dynamic graph algorithms=20 - location tracking=20 - middleware=20 - security=20 - scheduling=20 - media access techniques=20 - quality-of-service issues=20 - sensor networks=20 - complexity analysis of algorithms for mobile environments=20 Please consult any member of the technical program committee if you are = uncertain whether your paper falls within the scope of the workshop. Submission Instructions ---------------------- Submission should be up to 10 pages in length with reasonable margins = and line spacing using at least 11-point font. Submission instructions will be available on the conference website. Important Dates: Paper Submissions Due: July 5, 2002 Notification of Acceptance: August 8, 2002 Camera-ready Version Due: August 30, 2002 Authors of accepted papers are expected to present their paper at the = workshop. FOR MORE INFORMATION: Check the workshop website or send email to Ravi = Prakash (ravip@utdallas.edu) Organsing Commitee =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D General Chair - Andre Schiper, EPFL=20 andre.schiper@epfl.ch=20 Technical Program Co-chairs - Roberto Baldoni, University of Rome "La Sapienza" baldoni@dis.uniroma1.it - Ravi Prakash, University of Texas at Dallas ravip@utdallas.edu Technical Program Committee - Maurizio Bonuccelli, University of Pisa bonucce@di.unipi.it=20 - Sandeep Gupta, Arizona State University sandeep.gupta@asu.edu=20 - David B. Johnson, Rice University dbj@cs.rice.edu=20 - Marc-Olivier Killijian, LAAS-CNRS=20 marco.killijian@laas.fr=20 - Amy Murphy, University of Rochester murphy@cs.rochester.edu=20 - Michel Raynal, IRISA=20 michel.raynal@irisa.fr=20 - Mukesh Singhal, University of Kentucky singhal@cs.uky.edu=20 Registration and Finance Chair - Xavier Defago, JAIST=20 defago@jaist.ac.jp=20 Local Arrangements Chair - Marc-Olivier Killijian, LAAS-CNRS=20 marco.killijian@laas.fr Webmaster and Publicity Co-chair - Mansoor Mohsin, University of Texas at Dallas mmohsin@utdallas.edu - Parag Agarwal, University of Texas at Dallas pxa016500@utdallas.edu Steering Committee - Nancy Lynch, MIT=20 lynch@theory.lcs.mit.edu=20 - Andre Schiper, EPFL=20 andre.schiper@epfl.ch=20 - Nitin Vaidya, University of Illinois at Urbana-Champaign nhv@uiuc.edu=20 - Jennifer Welch, Texas A&M University=20 welch@cs.tamu.edu -------------------------------------------------------------------------= ------- Mansoor Mohsin=20 ------=_NextPart_000_0047_01C1F840.CEEC69C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Call For=20 Papers
---------------
 
Preliminary = Announcement and Call=20 for Papers
 
POMC 2002
Workshop = on Principles=20 of Mobile Computing
October 30-31, 2002, Toulouse, = France.
 
Workshop URL: www.utdallas.= edu/~ravip/pomc/POMC/POMC.html
 
Sponsor: ACM = SIGACT
 
Accepted papers = published by=20 ACM
 
Submission deadline : = July 5,=20 2002
 
To be held in = conjunction with=20 International Symposium on DIStributed Computing (DISC 2002)
http://www.enseeiht.fr/~disc02/<= /A>
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
 
Mobile computing and = communications=20 devices are proliferating in recent years. The mobility of distributed = computing=20 components raises a number of interesting, and difficult, algorithmic=20 issues.
 
This two-day workshop = is intended=20 to bring together researchers in mobile computing (especially, but not=20 exclusively, ad hoc networks) and distributed algorithms (especially, = but not=20 exclusively, dynamic networks). To facilitate such interaction, the = workshop is=20 scheduled to begin on the last day of DISC 2002.
 
The planned format is = a combination=20 of contributed papers and one-hour tutorials. Significant time for = discussion=20 will be allocated. It is intended to be a lively and informal meeting, = and to=20 foster cooperation among mobile computing systems researchers and = distributed=20 algorithms theoreticians.
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
 
Topics
------
 
Papers are solicited = in all=20 research and applied areas that touch on the application of, or need = for,=20 distributed algorithms in the context of mobile computing systems. = Papers=20 covering work in progress are especially welcome. Papers should describe = original, previously unpublished work that is not currently under review = by=20 another conference, workshop, or journal.
 
Specific topics = include, but are=20 not limited to:
 
- distributed = algorithms
-=20 routing
- dynamic networks
- dynamic graph algorithms
- = location=20 tracking
- middleware
- security
- scheduling
- media = access=20 techniques
- quality-of-service issues
- sensor networks
-=20 complexity analysis of algorithms for mobile environments
 
Please consult any = member of the=20 technical program committee if you are uncertain whether your paper = falls within=20 the scope of the workshop.
 
Submission=20 Instructions
----------------------
 
Submission should be = up to 10 pages=20 in length with reasonable margins and line spacing using at least = 11-point=20 font.
 
Submission = instructions will be=20 available on the conference website.
 
Important = Dates:
 
Paper Submissions = Due: July 5,=20 2002
Notification of Acceptance: August 8, = 2002
Camera-ready Version Due: August 30,=20 2002
Authors of accepted papers are = expected to=20 present their paper at the workshop.
 
FOR MORE INFORMATION: = Check the=20 workshop website or send  email to Ravi=20 Prakash (ravip@utdallas.edu)
 

Organsing = Commitee
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
General Chair
 
- Andre Schiper, EPFL
 
Technical Program Co-chairs
 
- Roberto Baldoni, University of Rome "La = Sapienza"
 =20 baldoni@dis.uniroma1.it
=
 
- Ravi Prakash, University of Texas at = Dallas
  ravip@utdallas.edu
 
Technical Program Committee
 
- Maurizio Bonuccelli, University of Pisa
  = bonucce@di.unipi.it
 
- Sandeep Gupta, Arizona State University
  = sandeep.gupta@asu.edu
 
- David B. Johnson, Rice University
  dbj@cs.rice.edu
 
- Marc-Olivier Killijian, LAAS-CNRS 
  = marco.killijian@laas.fr =
 
- Amy Murphy, University of Rochester
  murphy@cs.rochester.edu =
 
- Michel Raynal, IRISA 
  michel.raynal@irisa.fr
 
- Mukesh Singhal, University of Kentucky
  = singhal@cs.uky.edu
 
Registration and Finance Chair
 
- Xavier Defago, JAIST
 
Local Arrangements Chair
 
- Marc-Olivier Killijian, LAAS-CNRS 
  = marco.killijian@laas.fr
=
 
Webmaster and Publicity Co-chair
 
- Mansoor Mohsin, University of Texas at = Dallas
  mmohsin@utdallas.edu
 
- Parag Agarwal, University of Texas at = Dallas
  pxa016500@utdallas.edu
 
Steering Committee
 
- Nancy Lynch, MIT
  lynch@theory.lcs.mit.edu =
 
- Andre Schiper, EPFL
 
- Nitin Vaidya, University of Illinois at=20 Urbana-Champaign
  nhv@uiuc.edu
 
- Jennifer Welch, Texas A&M = University 
  welch@cs.tamu.edu

Mansoor=20 Mohsin
------=_NextPart_000_0047_01C1F840.CEEC69C0-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 13:49:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22088 for ; Mon, 13 May 2002 13:49:46 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26949; Mon, 13 May 2002 11:49:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18520; Mon, 13 May 2002 10:49:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DHmLrP007466 for ; Mon, 13 May 2002 10:48:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DHmLj5007465 for mobile-ip-dist; Mon, 13 May 2002 10:48:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DHmIrP007458 for ; Mon, 13 May 2002 10:48:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18190 for ; Mon, 13 May 2002 10:48:19 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26313 for ; Mon, 13 May 2002 11:48:43 -0600 (MDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4DHljkc014815; Mon, 13 May 2002 10:47:45 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id NAA01416; Mon, 13 May 2002 13:47:45 -0400 (EDT) Date: Mon, 13 May 2002 13:47:45 -0400 From: "Madhavi W. Chandra" To: Henrik Levkowetz Cc: "Madhavi W. Chandra" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Feedback on NAT draft Message-ID: <20020513134745.A1412@cisco.com> References: <20020510102825.E26141@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from henrik@levkowetz.com on Sat, May 11, 2002 at 11:27:06AM +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Henrik, On Sat, May 11, 2002 at 11:27:06AM +0200, Henrik Levkowetz wrote: > Hello Madhavi, > > > > > Hi Henrik and Sami, > > > > We've gone through your NAT draft with much interest > > and have a few comments: > > > > 1) Is the F bit in the UDP Reg Request Extension needed? > > Probably can let HA make the decision of IP-in-UDP tunneling. > > If HA determines that the RRQ did not traverse a NAT box, > > it still MAY accept the IP-in-UDP tunneling request based > > on administrative policy on the HA. Don't see the need > > for the MN to mandate this with the 'F' bit, since the HA > > is in the better position to decide. > > The function of the F bit is to have a mechanism to Force > UDP tunnelling to be used also when no NAT is detected. > It seems some people find this desireable, and I agree, > and it also turns out to have a function when handling > the FA R-bit case. We certainly agree that UDP tunneling may be useful even when no NAT is detected. I guess the difference is that we feel it can be done on the HA side...in fact, the HA is the one that should make this decision. Not sure why an MN should mandate to an HA what it should do. For example, maybe there is an adminstrative firewall policy on the HA that would require UDP tunneling irrespective of NAT presence. In this case, the HA would set up the UDP tunnel. Can you please elaborate on why you feel the MN is in a better position to force UDP tunneling on the HA? Also, what function are you refering to in the FA R-bit case? > > > > 2) Sect. 1.2. Comparison of IP SRC address against (a) CoA, > > (b) Home address, or (c) 0.0.0.0. Is this only the case > > when MN is sending RRQ in Co-CoA case? > > Should be made precise, as this does not hold in FA case. > > Right. It should say e.g. "mobile node IP source address..." > > > > 3) For FA case, HA detection of NAT traversal is suspect since > > CoA and source IP address (FA egress interface) need not be the same. > > Right, good point. > > > > > We suggest: > > > > Can either append UDP Reg Request Ext with *IP address > > of FA* when FA relays the RRQ to HA. Then HA can compare the IP > > SRC against the IP address of FA in UDP ext. If mismatch, HA > > can determine that RRQ traversed a NAT box. > > > > Or, can mandate that the IP SRC used at FA (FA egress interface) > > is the same as the FA CoA. > > Right. The second solution is simpler, and I'd go for that unless > others on the list feel otherwise. I agree that this is the simpler and cleaner solution. > > > > 4) The draft does not specifically state what the tunnel end > > point should be...it only states it precisely for the case that the > > 'R' bit and 'F' bit are set in the UDP request extension in Section 4.6. > > Moreover, it is not clear when the tunnel endpoint is decided...upon > > receipt of the initial RRQ or keepalive? Please clarify and add > > appropriate/precise text to the draft. > > I gather you're not referring to the tunnel end points, really, as those > are at the HA and FA/MN, exactly as for IP-IP tunnelling, but rather > the apparent destination address the HA needs to use for the tunnel. > Yes, we'll add a clarification of this. There's a typo in the relevant > section in draft -02 which may have helped make this obscure, too :-) Right...even though the tunnel is at the HA and 'FA/MN' (actually, on the NAT box)...it is being determined by the IP SRC of the RRQ, and not the CoA field. This should be clearly stated. > > > > 5) The draft says that periodic keepalive signaling SHOULD be in the > > form of an RRQ...this seems like heavy signaling to do every K > > seconds. I'm trying to dig through the nat-vpn archives to find the > > thread you mentioned previously. No luck so far. Do you have a > > writeup of your analysis that I may refer to? Perhaps the SHOULD should > > be relaxed. > > Ok, the bandwidth calculation. Let us assume: > a low-bandwidth channel of 14400 bits per second, > a keepalive every 20 seconds > a registration request which is typically some 80 bytes, > IP header included > a registration reply of the same length > a binding lifetime of 120 seconds > > In this case, the bandwidth consumed by using registration requests > and replies are roughly 5*2*8*80 out of 14400*120, or 6400/1728000, > or about 0.37 % of the channel. > > If we compare this with zero-data icmp echo requests/replies, we get > 5*2*8*28/(14400*120), or 0.13% of the channel. > > Yes, this is less. But no, I can't see about 0.4 % of a 14400 bit/s > channel as heavy signalling. > > So here we differ in opinion. I on my part hold that > > 1) registration request keepalives are not particularly heavy, and > > 2) there are benefits to using reg. requests as keepalives, > which makes at least a SHOULD appropriate, while > > 3) for extremely! processor-challenged mobiles, it may be heavy > work to calculate the HMAC-MD5, so we need to use a SHOULD > rather than a MUST (I think this third point is weak) > and finally > > 4) in the FA R-bit case, we *cannot* use reg. requests / > replies as keepalives, so we must have an alternative. Sorry for not being clear. We were refering to 'heavy signaling' from the HA's perspective. If an HA is supporting a large number of MNs, and every MN is re-registering every 20 seconds, this can easily overload the HA. Every incoming registration will require processing on the HA. Regards, Madhavi > > Best regards, > > Henrik From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 14:21:02 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23860 for ; Mon, 13 May 2002 14:21:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18102; Mon, 13 May 2002 12:20:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10836; Mon, 13 May 2002 11:20:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DIJMrP007621 for ; Mon, 13 May 2002 11:19:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DIJMLk007620 for mobile-ip-dist; Mon, 13 May 2002 11:19:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from purol.East.Sun.COM (purol.East.Sun.COM [129.148.9.11]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DIJIrP007613 for ; Mon, 13 May 2002 11:19:18 -0700 (PDT) Received: from onion (onion [129.148.174.110]) by purol.East.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4DIJIg24708 for ; Mon, 13 May 2002 14:19:18 -0400 (EDT) Date: Mon, 13 May 2002 14:19:18 -0400 (EDT) From: "Steven M. Glass" Reply-To: "Steven M. Glass" Subject: [mobile-ip] archive down To: mobile-ip@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: With appologies, as Madhavi pointed out a few days ago, our archive is currently down (due to a config that changed out from under us), but we're working on the communications needed, and it should be back shortly... Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 14:39:33 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25399 for ; Mon, 13 May 2002 14:39:32 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16659; Mon, 13 May 2002 12:39:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19613; Mon, 13 May 2002 11:39:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DIc6rP007685 for ; Mon, 13 May 2002 11:38:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DIc6pb007684 for mobile-ip-dist; Mon, 13 May 2002 11:38:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DIc2rP007677 for ; Mon, 13 May 2002 11:38:03 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19166 for ; Mon, 13 May 2002 11:38:04 -0700 (PDT) Received: from chardonnay.levkowetz.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28790 for ; Mon, 13 May 2002 12:38:03 -0600 (MDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.02) id GW2BRB-0004DG-00; Mon, 13 May 2002 20:37:59 +0200 From: "Henrik Levkowetz" To: "Madhavi W. Chandra" Cc: Subject: RE: [mobile-ip] Feedback on NAT draft Date: Mon, 13 May 2002 20:37:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020513134745.A1412@cisco.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Madhavi, Madhavi wrote: > > Hi Henrik, > > On Sat, May 11, 2002 at 11:27:06AM +0200, Henrik Levkowetz wrote: > > Hello Madhavi, > > > > > > > > Hi Henrik and Sami, > > > > > > We've gone through your NAT draft with much interest > > > and have a few comments: > > > > > > 1) Is the F bit in the UDP Reg Request Extension needed? > > > Probably can let HA make the decision of IP-in-UDP tunneling. > > > If HA determines that the RRQ did not traverse a NAT box, > > > it still MAY accept the IP-in-UDP tunneling request based > > > on administrative policy on the HA. Don't see the need > > > for the MN to mandate this with the 'F' bit, since the HA > > > is in the better position to decide. > > > > The function of the F bit is to have a mechanism to Force > > UDP tunnelling to be used also when no NAT is detected. > > It seems some people find this desireable, and I agree, > > and it also turns out to have a function when handling > > the FA R-bit case. > > We certainly agree that UDP tunneling may be useful even when no NAT > is detected. I guess the difference is that we feel it can be done on > the HA side...in fact, the HA is the one that should make this > decision. Not sure why an MN should mandate to an HA what it should > do. For example, maybe there is an adminstrative firewall policy on > the HA that would require UDP tunneling irrespective of NAT presence. > In this case, the HA would set up the UDP tunnel. > > Can you please elaborate on why you feel the MN is in a better > position to force UDP tunneling on the HA? Also, what function are > you refering to in the FA R-bit case? This is not an either - or thing. If the MN indicates that it is able to do UDP tunnelling, then sure, you could do as you suggest, let the HA indicate tunnelling for policy reasons also in the absence of a NAT. Having the 'F' bit simply permits the MN to act similarly. Do you have any particular reason why you don't want the MN to be able to request this? The FA R-bit case, where the 'F' bit is needed, is the one described in Section 4.10 of the -02 draft. > > > > > > > 2) Sect. 1.2. Comparison of IP SRC address against (a) CoA, > > > (b) Home address, or (c) 0.0.0.0. Is this only the case > > > when MN is sending RRQ in Co-CoA case? > > > Should be made precise, as this does not hold in FA case. > > > > Right. It should say e.g. "mobile node IP source address..." > > > > > > 3) For FA case, HA detection of NAT traversal is suspect since > > > CoA and source IP address (FA egress interface) need not be the same. > > > > Right, good point. > > > > > > > > We suggest: > > > > > > Can either append UDP Reg Request Ext with *IP address > > > of FA* when FA relays the RRQ to HA. Then HA can compare the IP > > > SRC against the IP address of FA in UDP ext. If mismatch, HA > > > can determine that RRQ traversed a NAT box. > > > > > > Or, can mandate that the IP SRC used at FA (FA egress interface) > > > is the same as the FA CoA. > > > > Right. The second solution is simpler, and I'd go for that unless > > others on the list feel otherwise. > > I agree that this is the simpler and cleaner solution. Ok, good. > > > > > > > 4) The draft does not specifically state what the tunnel end > > > point should be...it only states it precisely for the case that the > > > 'R' bit and 'F' bit are set in the UDP request extension in Section 4.6. > > > Moreover, it is not clear when the tunnel endpoint is decided...upon > > > receipt of the initial RRQ or keepalive? Please clarify and add > > > appropriate/precise text to the draft. > > > > I gather you're not referring to the tunnel end points, really, as those > > are at the HA and FA/MN, exactly as for IP-IP tunnelling, but rather > > the apparent destination address the HA needs to use for the tunnel. > > Yes, we'll add a clarification of this. There's a typo in the relevant > > section in draft -02 which may have helped make this obscure, too :-) > > Right...even though the tunnel is at the HA and 'FA/MN' (actually, on > the NAT box)...it is being determined by the IP SRC of the RRQ, and > not the CoA field. This should be clearly stated. Yes, as I said, we'll add a clarification on this. > > > > > > > 5) The draft says that periodic keepalive signaling SHOULD be in the > > > form of an RRQ...this seems like heavy signaling to do every K > > > seconds. I'm trying to dig through the nat-vpn archives to find the > > > thread you mentioned previously. No luck so far. Do you have a > > > writeup of your analysis that I may refer to? Perhaps the SHOULD should > > > be relaxed. > > > > Ok, the bandwidth calculation. Let us assume: > > a low-bandwidth channel of 14400 bits per second, > > a keepalive every 20 seconds > > a registration request which is typically some 80 bytes, > > IP header included > > a registration reply of the same length > > a binding lifetime of 120 seconds > > > > In this case, the bandwidth consumed by using registration requests > > and replies are roughly 5*2*8*80 out of 14400*120, or 6400/1728000, > > or about 0.37 % of the channel. > > > > If we compare this with zero-data icmp echo requests/replies, we get > > 5*2*8*28/(14400*120), or 0.13% of the channel. > > > > Yes, this is less. But no, I can't see about 0.4 % of a 14400 bit/s > > channel as heavy signalling. > > > > So here we differ in opinion. I on my part hold that > > > > 1) registration request keepalives are not particularly heavy, and > > > > 2) there are benefits to using reg. requests as keepalives, > > which makes at least a SHOULD appropriate, while > > > > 3) for extremely! processor-challenged mobiles, it may be heavy > > work to calculate the HMAC-MD5, so we need to use a SHOULD > > rather than a MUST (I think this third point is weak) > > and finally > > > > 4) in the FA R-bit case, we *cannot* use reg. requests / > > replies as keepalives, so we must have an alternative. > > Sorry for not being clear. We were refering to 'heavy signaling' > from the HA's perspective. If an HA is supporting a large number of > MNs, and every MN is re-registering every 20 seconds, this can easily > overload the HA. Every incoming registration will require processing > on the HA. Ok, I see what you are concerned about. But in view of the hijacking and DoS scenarios which Francis Dupont brought up recently, I think it is still very prudent to have a short time between registrations. If you still want to, you can always use the alternative icmp echo keepalives, but I don't think that would be the wise thing to do. We have drafted a new security considerations section to discuss this in more depth, too. Regards, Henrik From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 15:45:14 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29011 for ; Mon, 13 May 2002 15:45:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15827; Mon, 13 May 2002 12:43:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02829; Mon, 13 May 2002 12:43:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DJfFrP007890 for ; Mon, 13 May 2002 12:41:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DJfFjJ007889 for mobile-ip-dist; Mon, 13 May 2002 12:41:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DJfCrP007882 for ; Mon, 13 May 2002 12:41:12 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20390 for ; Mon, 13 May 2002 12:41:14 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05782 for ; Mon, 13 May 2002 13:41:13 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 15:37:52 -0400 Message-ID: From: Phil Roberts To: "'Annika Jonsson'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #2 Date: Mon, 13 May 2002 15:37:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: We would like to know whether folks agree or disagree with these proposed resolutions. Annika, we're going to need proposed text for each of them, and a pointer to where it would go in the draft. Thanks, Phil > -----Original Message----- > From: Annika Jonsson [mailto:annika.jonsson@ericsson.com] > Sent: Monday, May 13, 2002 11:53 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Regional Registration Last Call > Resolution Issue #2 > > > Hi > > Here are my conclusions and proposals for additions/changes > to solve the > backwards compatibility issues in the Regional Registrations draft: > > A: Backwards compatibility with RFC3220 MN:s. > FA:s must advertise their own address, since it is used for movement > detection by RFC3220 MN:s. This requires one change and one > clarification > to the draft: > - To be backwards compatible, if the FA only advertises one > CoA it must be > its own address (not the GFA address as specified now). This > FA must be > able to act as a normal RFC3220 FA (that's in the draft already). > - clarify that if the FA advertises a zero address, it will > not support > RFC3220 MN:s. In some cases the owner of the network might > prefer this. > > > B: Backwards compatibility with RFC3220 HA:s > The problem here is that an RFC 3220 HA does not understand > the GFA IP > extension used if the MN sends a registration with zero CoA. > There are two > ways to solve this: > > B1: According to the draft right now, the MN MUST NOT send a > Registration > Request with zero CoA if it's HA doesn't support that. This > is simple, but > not very flexible. If the FA advertises a GFA CoA (in > addition to the FA > CoA), the MN should use that, and can then make use of regional > registrations even though it's HA does not support it. If the FA only > advertises it's own address, the MN can not make use of regional > registration unless it's HA supports it, but can still use > normal Mobile > IP. An FA that only advertises a zero address will not be > backwards compatible. > > B2: The other alternative is that the draft could be changed > by adding a > new error code from the GFA to tell the MN that the HA did > not support the > GFA IP extension. The MN could then try the advertised CoA > instead (or, > possibly, a new extension added so the the GFA could tell the > MN what CoA > to use). > > I see one problem with this: I'm not sure how an RFC3220 HA > would deal with > this kind of registration. In the draft today, the GFA IP > extension is > non-skippable (because the HA MUST support it if the MN uses > it). A HA that > doesn't support this would not answer to this registration at > all, it would > silently discard the message. > > If the extension was changed to be skippable, how would the HA react? > Either it would notice that something is wrong with the CoA, > and send a > reply with some error code (e.g. "poorly formed request??). > Or it would not > even check the CoA (I couldn't find this mentioned anywhere > in RFC3220). In > this case it would accept the registration, and set the CoA > to zero. The > GFA will then receive a reply without a GFA IP extension. In > both cases, > the GFA _could_ assume that the HA did not support the GFA IP > extension, > but it doesn't know for sure. > > To conclude: this option (B2) seems too uncertain, so I would > rather go for > the (more unflexible, but simple) B1 (i.e. no changes to the > current draft, > but it could be clarified a bit). > > /Annika > From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 15:45:16 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29025 for ; Mon, 13 May 2002 15:45:15 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18269; Mon, 13 May 2002 12:43:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02838; Mon, 13 May 2002 12:43:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DJfJrP007900 for ; Mon, 13 May 2002 12:41:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DJfJhp007899 for mobile-ip-dist; Mon, 13 May 2002 12:41:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DJfGrP007892 for ; Mon, 13 May 2002 12:41:16 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01622 for ; Mon, 13 May 2002 12:41:18 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17052 for ; Mon, 13 May 2002 12:41:18 -0700 (PDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4DJekPI006867; Mon, 13 May 2002 12:40:46 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA01515; Mon, 13 May 2002 15:40:45 -0400 (EDT) Date: Mon, 13 May 2002 15:40:45 -0400 From: "Madhavi W. Chandra" To: Henrik Levkowetz Cc: "Madhavi W. Chandra" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Feedback on NAT draft Message-ID: <20020513154045.A1509@cisco.com> References: <20020513134745.A1412@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from henrik@levkowetz.com on Mon, May 13, 2002 at 08:37:58PM +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Henrik, On Mon, May 13, 2002 at 08:37:58PM +0200, Henrik Levkowetz wrote: > Hi Madhavi, > > Madhavi wrote: > > > > Hi Henrik, > > > > On Sat, May 11, 2002 at 11:27:06AM +0200, Henrik Levkowetz wrote: > > > Hello Madhavi, > > > > > > > > > > > Hi Henrik and Sami, > > > > > > > > We've gone through your NAT draft with much interest > > > > and have a few comments: > > > > > > > > 1) Is the F bit in the UDP Reg Request Extension needed? > > > > Probably can let HA make the decision of IP-in-UDP tunneling. > > > > If HA determines that the RRQ did not traverse a NAT box, > > > > it still MAY accept the IP-in-UDP tunneling request based > > > > on administrative policy on the HA. Don't see the need > > > > for the MN to mandate this with the 'F' bit, since the HA > > > > is in the better position to decide. > > > > > > The function of the F bit is to have a mechanism to Force > > > UDP tunnelling to be used also when no NAT is detected. > > > It seems some people find this desireable, and I agree, > > > and it also turns out to have a function when handling > > > the FA R-bit case. > > > > We certainly agree that UDP tunneling may be useful even when no NAT > > is detected. I guess the difference is that we feel it can be done on > > the HA side...in fact, the HA is the one that should make this > > decision. Not sure why an MN should mandate to an HA what it should > > do. For example, maybe there is an adminstrative firewall policy on > > the HA that would require UDP tunneling irrespective of NAT presence. > > In this case, the HA would set up the UDP tunnel. > > > > Can you please elaborate on why you feel the MN is in a better > > position to force UDP tunneling on the HA? Also, what function are > > you refering to in the FA R-bit case? > > This is not an either - or thing. If the MN indicates that it is > able to do UDP tunnelling, then sure, you could do as you suggest, > let the HA indicate tunnelling for policy reasons also in the absence > of a NAT. Having the 'F' bit simply permits the MN to act similarly. > Do you have any particular reason why you don't want the MN to be > able to request this? The MN is indicating that it can do UDP tunneling with the presence of the UDP Tunnel Request Extension. The HA can decide whether to do UDP tunneling irrespective of NAT. There doesn't seem to be a role for the MN to force UDP tunneling...unless we are missing something. Hence, implementation can be simplified without 'F' bit. > The FA R-bit case, where the 'F' bit is needed, is the one described > in Section 4.10 of the -02 draft. Actually, taken from Section 4.4: "If a mobile node is registering through a foreign agent but using a co-located care-of address, and the agent advertisement from the foreign agent had the 'U' bit set, the mobile node SHOULD set both the 'R' flag and the 'F' flag in its UDP Tunnel Request Extension, in order to make the HA use MIP UDP tunnelling." I'm not sure I understand...if the RRQ went through a NAT box, the HA would still be able to detect this and set up the UDP tunnel. If it didn't go through a NAT box, why does MN want to force UDP tunneling just because it is FA 'R' bit case? Perhaps I am missing your point. Maybe if you parsed the following sentence for me (taken from Section 4.6), it would help: If the 'R' flag is set but the 'F' flag is not set, the home agent MUST NOT assent to UDP tunnelling, even if there is an address mismatch. I'm not seeing the needed 'F' bit functionality in the FA 'R' bit case. > > > > > > > > > > 2) Sect. 1.2. Comparison of IP SRC address against (a) CoA, > > > > (b) Home address, or (c) 0.0.0.0. Is this only the case > > > > when MN is sending RRQ in Co-CoA case? > > > > Should be made precise, as this does not hold in FA case. > > > > > > Right. It should say e.g. "mobile node IP source address..." > > > > > > > > 3) For FA case, HA detection of NAT traversal is suspect since > > > > CoA and source IP address (FA egress interface) need not be the same. > > > > > > Right, good point. > > > > > > > > > > > We suggest: > > > > > > > > Can either append UDP Reg Request Ext with *IP address > > > > of FA* when FA relays the RRQ to HA. Then HA can compare the IP > > > > SRC against the IP address of FA in UDP ext. If mismatch, HA > > > > can determine that RRQ traversed a NAT box. > > > > > > > > Or, can mandate that the IP SRC used at FA (FA egress interface) > > > > is the same as the FA CoA. > > > > > > Right. The second solution is simpler, and I'd go for that unless > > > others on the list feel otherwise. > > > > I agree that this is the simpler and cleaner solution. > > Ok, good. > > > > > > > > > > 4) The draft does not specifically state what the tunnel end > > > > point should be...it only states it precisely for the case that the > > > > 'R' bit and 'F' bit are set in the UDP request extension in Section 4.6. > > > > Moreover, it is not clear when the tunnel endpoint is decided...upon > > > > receipt of the initial RRQ or keepalive? Please clarify and add > > > > appropriate/precise text to the draft. > > > > > > I gather you're not referring to the tunnel end points, really, as those > > > are at the HA and FA/MN, exactly as for IP-IP tunnelling, but rather > > > the apparent destination address the HA needs to use for the tunnel. > > > Yes, we'll add a clarification of this. There's a typo in the relevant > > > section in draft -02 which may have helped make this obscure, too :-) > > > > Right...even though the tunnel is at the HA and 'FA/MN' (actually, on > > the NAT box)...it is being determined by the IP SRC of the RRQ, and > > not the CoA field. This should be clearly stated. > > Yes, as I said, we'll add a clarification on this. > > > > > > > > > > > 5) The draft says that periodic keepalive signaling SHOULD be in the > > > > form of an RRQ...this seems like heavy signaling to do every K > > > > seconds. I'm trying to dig through the nat-vpn archives to find the > > > > thread you mentioned previously. No luck so far. Do you have a > > > > writeup of your analysis that I may refer to? Perhaps the SHOULD should > > > > be relaxed. > > > > > > Ok, the bandwidth calculation. Let us assume: > > > a low-bandwidth channel of 14400 bits per second, > > > a keepalive every 20 seconds > > > a registration request which is typically some 80 bytes, > > > IP header included > > > a registration reply of the same length > > > a binding lifetime of 120 seconds > > > > > > In this case, the bandwidth consumed by using registration requests > > > and replies are roughly 5*2*8*80 out of 14400*120, or 6400/1728000, > > > or about 0.37 % of the channel. > > > > > > If we compare this with zero-data icmp echo requests/replies, we get > > > 5*2*8*28/(14400*120), or 0.13% of the channel. > > > > > > Yes, this is less. But no, I can't see about 0.4 % of a 14400 bit/s > > > channel as heavy signalling. > > > > > > So here we differ in opinion. I on my part hold that > > > > > > 1) registration request keepalives are not particularly heavy, and > > > > > > 2) there are benefits to using reg. requests as keepalives, > > > which makes at least a SHOULD appropriate, while > > > > > > 3) for extremely! processor-challenged mobiles, it may be heavy > > > work to calculate the HMAC-MD5, so we need to use a SHOULD > > > rather than a MUST (I think this third point is weak) > > > and finally > > > > > > 4) in the FA R-bit case, we *cannot* use reg. requests / > > > replies as keepalives, so we must have an alternative. > > > > Sorry for not being clear. We were refering to 'heavy signaling' > > from the HA's perspective. If an HA is supporting a large number of > > MNs, and every MN is re-registering every 20 seconds, this can easily > > overload the HA. Every incoming registration will require processing > > on the HA. > > Ok, I see what you are concerned about. But in view of the hijacking > and DoS scenarios which Francis Dupont brought up recently, I think > it is still very prudent to have a short time between registrations. But, wouldn't a man-in-the-middle still be able to do a DoS attack by intercepting each of the re-registrations? It can still blackhole the MNs traffic, can't it? I think the requirement of RRQ keepalives should be relaxed from a SHOULD, since it is processing intensive on the HA. > If you still want to, you can always use the alternative icmp echo keepalives, > but I don't think that would be the wise thing to do. We have drafted > a new security considerations section to discuss this in more depth, > too. I look forward to seeing the new section. Regards, Madhavi > > > Regards, > Henrik From owner-mobile-ip@sunroof.eng.sun.com Mon May 13 16:19:01 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00884 for ; Mon, 13 May 2002 16:19:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05731; Mon, 13 May 2002 13:17:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03199; Mon, 13 May 2002 13:16:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DKFWrP008032 for ; Mon, 13 May 2002 13:15:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4DKFWW0008031 for mobile-ip-dist; Mon, 13 May 2002 13:15:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4DKFRrP008021 for ; Mon, 13 May 2002 13:15:28 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA14495 for ; Mon, 13 May 2002 13:15:28 -0700 (PDT) Received: from chardonnay.levkowetz.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08960 for ; Mon, 13 May 2002 13:15:27 -0700 (PDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.02) id GW2G9O-0004DC-00 for mobile-ip@sunroof.eng.sun.com; Mon, 13 May 2002 22:15:24 +0200 From: "Henrik Levkowetz" To: Subject: RE: [mobile-ip] Feedback on NAT draft Date: Mon, 13 May 2002 22:15:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020513154045.A1509@cisco.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Madhavi, Madhavi wrote: > > > > > > > > > > 1) Is the F bit in the UDP Reg Request Extension needed? > > > > > Probably can let HA make the decision of IP-in-UDP tunneling. > > > > > If HA determines that the RRQ did not traverse a NAT box, > > > > > it still MAY accept the IP-in-UDP tunneling request based > > > > > on administrative policy on the HA. Don't see the need > > > > > for the MN to mandate this with the 'F' bit, since the HA > > > > > is in the better position to decide. > > > > > > > > The function of the F bit is to have a mechanism to Force > > > > UDP tunnelling to be used also when no NAT is detected. > > > > It seems some people find this desireable, and I agree, > > > > and it also turns out to have a function when handling > > > > the FA R-bit case. > > > > > > We certainly agree that UDP tunneling may be useful even when no NAT > > > is detected. I guess the difference is that we feel it can be done on > > > the HA side...in fact, the HA is the one that should make this > > > decision. Not sure why an MN should mandate to an HA what it should > > > do. For example, maybe there is an adminstrative firewall policy on > > > the HA that would require UDP tunneling irrespective of NAT presence. > > > In this case, the HA would set up the UDP tunnel. > > > > > > Can you please elaborate on why you feel the MN is in a better > > > position to force UDP tunneling on the HA? Also, what function are > > > you refering to in the FA R-bit case? > > > > This is not an either - or thing. If the MN indicates that it is > > able to do UDP tunnelling, then sure, you could do as you suggest, > > let the HA indicate tunnelling for policy reasons also in the absence > > of a NAT. Having the 'F' bit simply permits the MN to act similarly. > > Do you have any particular reason why you don't want the MN to be > > able to request this? > > The MN is indicating that it can do UDP tunneling with the > presence of the UDP Tunnel Request Extension. The HA can decide > whether to do UDP tunneling irrespective of NAT. There doesn't seem > to be a role for the MN to force UDP tunneling...unless we are missing > something. Hence, implementation can be simplified without 'F' bit. Correction: You do not find it useful. Other people have indicatet that it would be useful, so I'd tend to keep it in for that reason. But there is still the FA R-bit case, too. > > > The FA R-bit case, where the 'F' bit is needed, is the one described > > in Section 4.10 of the -02 draft. > > Actually, taken from Section 4.4: > > "If a mobile node is registering through a foreign agent but using a > co-located care-of address, and the agent advertisement from the > foreign agent had the 'U' bit set, the mobile node SHOULD set both > the 'R' flag and the 'F' flag in its UDP Tunnel Request Extension, in > order to make the HA use MIP UDP tunnelling." > > I'm not sure I understand...if the RRQ went through a NAT box, the HA > would still be able to detect this and set up the UDP tunnel. > If it didn't go through a NAT box, why does MN want to force UDP > tunneling just because it is FA 'R' bit case? Perhaps I am missing your > point. Maybe if you parsed the following sentence for me (taken from > Section 4.6), it would help: > > If the 'R' flag is set but the 'F' flag > is not set, the home agent MUST NOT assent to UDP tunnelling, even if > there is an address mismatch. > > I'm not seeing the needed 'F' bit functionality in the FA 'R' bit > case. Madhavi, I think it would clear up your questions if you were to read section 4.10, which I referred to earlier. It really does answer the questions you ask here. But in short: In this case, the HA cannot detect the presence of a NAT in the usual manner, so it needs to be forced by the mobile node. ...... > > > > > > Sorry for not being clear. We were refering to 'heavy signaling' > > > from the HA's perspective. If an HA is supporting a large number of > > > MNs, and every MN is re-registering every 20 seconds, this can easily > > > overload the HA. Every incoming registration will require processing > > > on the HA. > > > > Ok, I see what you are concerned about. But in view of the hijacking > > and DoS scenarios which Francis Dupont brought up recently, I think > > it is still very prudent to have a short time between registrations. > > But, wouldn't a man-in-the-middle still be able to do a DoS attack by > intercepting each of the re-registrations? It can still blackhole the > MNs traffic, can't it? > > I think the requirement of RRQ keepalives should be relaxed from a > SHOULD, since it is processing intensive on the HA. Well, we obviously disagree on this, then. I believe that it is clearly desireable to keep this as a SHOULD, both for security reasons, and for the performance reasons discussed in sections 5.1 and 5.2 of the draft. Regards, Henrik From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 00:07:48 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19982 for ; Tue, 14 May 2002 00:07:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA08743; Mon, 13 May 2002 22:07:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA19049; Mon, 13 May 2002 21:06:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E45lrP008841 for ; Mon, 13 May 2002 21:05:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4E45l5P008840 for mobile-ip-dist; Mon, 13 May 2002 21:05:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E45irP008833 for ; Mon, 13 May 2002 21:05:44 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA14345 for ; Mon, 13 May 2002 21:05:41 -0700 (PDT) From: Padmakumar.AV@lntinfotech.com Received: from ltitlin.lntinfotech.com ([203.199.54.35]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA08368 for ; Mon, 13 May 2002 22:05:40 -0600 (MDT) Received: from bangalore.lntinfotech.com ([172.29.4.3]) by ltitlin.lntinfotech.com (Lotus Domino Release 5.0.8) with ESMTP id 2002051409362976:9173 ; Tue, 14 May 2002 09:36:29 +0530 Subject: Re: [mobile-ip] MN Returning Home To: mobile-ip@sunroof.eng.sun.com Cc: Francis.Dupont@enst-bretagne.fr X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 14 May 2002 09:32:52 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/14/2002 09:32:54 AM, Itemize by SMTP Server on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/14/2002 09:36:29 AM, Serialize by Router on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/14/2002 09:36:33 AM, Serialize complete at 05/14/2002 09:36:33 AM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Francis, You wrote 'you really have a problem when the "whole subnet" is registered ' you mean the case where 'S' bit is not set. But even though the 'S' bit is set, HA still defend the use of link local address as part of the proxy functionality. So till the binding life time expires the MN has to wait right? Regards pav. Francis Dupont cc: mobile-ip@sunroof.eng.sun.com Sent by: Subject: Re: [mobile-ip] MN Returning Home Francis.Dupont@enst-bre tagne.fr 05/13/2002 09:12 PM In your previous mail you wrote: If the mobile node had to restart at its home network, after returning home and before doing deregistration and before its binding with home agent expires, then how to handle DAD as part of auto configuration, since the HA is armed to defend any use of this IP address. Does it means that HA should not permit any binding lifetime, which is more than some threshold. => you really have a problem when the "whole subnet" is registered and makes the link-local address not available to do an "in force" deregistration. (just a comment) Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 00:12:01 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20115 for ; Tue, 14 May 2002 00:12:01 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26957; Mon, 13 May 2002 22:12:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA19553; Mon, 13 May 2002 21:11:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E4AjrP008867 for ; Mon, 13 May 2002 21:10:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4E4Ajji008866 for mobile-ip-dist; Mon, 13 May 2002 21:10:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E4AgrP008859 for ; Mon, 13 May 2002 21:10:42 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA15214 for ; Mon, 13 May 2002 21:10:43 -0700 (PDT) From: arvind.sevalkar@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA09929 for ; Mon, 13 May 2002 22:10:42 -0600 (MDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002051409443092:3723 ; Tue, 14 May 2002 09:44:30 +0530 Subject: [mobile-ip] Rate limiting of Binding Error Message. To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Tue, 14 May 2002 09:40:24 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/14/2002 09:41:06 AM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/14/2002 09:44:30 AM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/14/2002 09:44:33 AM, Serialize complete at 05/14/2002 09:44:33 AM Message-ID: X-Priority: 3 (Normal) 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 g4E4AgrP008860 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi All I have a problem. In "mobile ip draft-17", section 6.3 Home address destination option, it is mentioned that Binding Error essage should be rate limited. But How to do rate limiting of Binding Error Message?? If we put some constrain like CN will send binding error once in one second, or once in five seconds. Then it may possible that CN can receive some packet, which contains Home address option, but no Binding Cache entry exists, but still CN can't send Binding Error Message. or CN can keep the entry in the Binding Cache whith state as invalid so that rate limiting should be done for that destination address. but this may cause problem of insufficient resources,if some fake node keep sending such packets with different source address, then CN will keep adding entry in binding Cache. Best Regards Arvind From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 02:52:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04865 for ; Tue, 14 May 2002 02:52:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA16163; Tue, 14 May 2002 00:52:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA17781; Mon, 13 May 2002 23:51:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E6osrP009072 for ; Mon, 13 May 2002 23:50:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4E6os5T009071 for mobile-ip-dist; Mon, 13 May 2002 23:50:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E6oprP009064 for ; Mon, 13 May 2002 23:50:51 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25527 for ; Mon, 13 May 2002 23:50:53 -0700 (PDT) Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA10335 for ; Tue, 14 May 2002 00:50:46 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mobile-ip] Feedback on NAT draft Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 May 2002 09:50:41 +0300 Message-ID: Thread-Topic: [mobile-ip] Feedback on NAT draft Thread-Index: AcH6toeAapjsrkzESVeaxv/46xNRiQAVayvg From: "Sami Vaarala" To: "Madhavi W. Chandra" , "Henrik Levkowetz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4E6oprP009065 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Madhavi, >[snip] > The MN is indicating that it can do UDP tunneling with the > presence of the UDP Tunnel Request Extension. The HA can decide > whether to do UDP tunneling irrespective of NAT. There doesn't seem > to be a role for the MN to force UDP tunneling...unless we are missing > something. Hence, implementation can be simplified without 'F' bit. There may be cases where the mobile node knows more about the network it is using to contact the HA. It might know that the UDP tunnelling is absolutely required through the network; the HA might not know this. The feature may be useful if the MN is in a network which filters packets and neither the HA or the MN know about this. The sequence would be as follows: 1. The MN registers without F-bit. The registration succeeds but the firewall blocks traffic. 2. The MN re-registers with F-bit, being wiser from step 1. This could also be done by an intelligent HA, but I don't think the HA has enough context to do this? (It doesn't know whether the MN just doesn't want to communicate or that the communication attempt failed.) -Sami From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 03:30:57 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06687 for ; Tue, 14 May 2002 03:30:57 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA01092; Tue, 14 May 2002 01:31:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11088; Tue, 14 May 2002 00:30:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E7TRrP009140 for ; Tue, 14 May 2002 00:29:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4E7TRQa009139 for mobile-ip-dist; Tue, 14 May 2002 00:29:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E7TOrP009132 for ; Tue, 14 May 2002 00:29:24 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA04581 for ; Tue, 14 May 2002 00:29:27 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25801 for ; Tue, 14 May 2002 00:29:26 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 2B6A46A905; Tue, 14 May 2002 10:29:20 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 70B6E6A901; Tue, 14 May 2002 10:29:18 +0300 (EEST) Message-ID: <3CE0BD0A.6040108@piuha.net> Date: Tue, 14 May 2002 10:30:18 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: arvind.sevalkar@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Rate limiting of Binding Error Message. References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit arvind.sevalkar@lntinfotech.com wrote: > Hi All > I have a problem. > In "mobile ip draft-17", section 6.3 Home address destination option, it > is mentioned that Binding Error essage should be rate limited. > But How to do rate limiting of Binding Error Message?? > > If we put some constrain like CN will send binding error once in one > second, or once in five seconds. Then it may possible that CN can receive > some packet, which contains Home address option, but no Binding Cache entry > exists, but still CN can't send Binding Error Message. > > or CN can keep the entry in the Binding Cache whith state as invalid so > that rate limiting should be done for that destination address. but this > may cause problem of insufficient resources,if some fake node keep sending > such packets with different source address, then CN will keep adding entry > in binding Cache. Good point. I agree that keeping memory to rate limit BEs is contrary to the whole idea of BE, as it may be caused by running out of memory or having to do a reboot. I'm not sure I agree that every packet with a HAO and no BCE should be reported as an error. Assuming a stream of packets with a HAO hits a recently rebooted CN, I would expect only one or two BEs to be sent back. The question is then, how do we achieve this? Note that the limits for BEs would typically be higher (more BEs allowed / s) than for more expensive messages such as Binding Updates. Is that enough? Or should we define the maximum rate for BEs as a function of the number of packets received with a HAO? Jari From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 04:45:41 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09546 for ; Tue, 14 May 2002 04:45:41 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28774; Tue, 14 May 2002 01:43:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06389; Tue, 14 May 2002 01:43:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E8garP009219 for ; Tue, 14 May 2002 01:42:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4E8gag4009218 for mobile-ip-dist; Tue, 14 May 2002 01:42:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E8gXrP009211 for ; Tue, 14 May 2002 01:42:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA06298 for ; Tue, 14 May 2002 01:42:36 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA25106 for ; Tue, 14 May 2002 02:42:35 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4E8gW0E014691; Tue, 14 May 2002 10:42:32 +0200 (MEST) Received: from bends.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA19736; Tue, 14 May 2002 10:42:30 +0200 Message-Id: <5.1.0.14.0.20020514100419.02851500@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 14 May 2002 10:40:45 +0200 To: "Madhavi W. Chandra" From: Annika Jonsson Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Cc: Phil Roberts , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: <20020513123737.A1353@cisco.com> References: <5.1.0.14.0.20020513175420.0287a090@era-t.ericsson.se> <20020509130354.A25864@cisco.com> <5.1.0.14.0.20020513175420.0287a090@era-t.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Madhavi, At 12:37 PM 5/13/2002 -0400, Madhavi W. Chandra wrote: >HI Annika, > >On Mon, May 13, 2002 at 06:16:05PM +0200, Annika Jonsson wrote: > > Hi Madhavi, > > > > see below... > > ... > > > > Attached below is modified text for the abstract and the introduction, > > > > Annika's words based on input > > > > from Madhavi. > > > > > >DISAGREE...as written below. > > > > > >As per the feedback we provided, it should be clearly stated in the > > >Abstract and Introduction that this architecture is OPTIONAL and not > > >required in typical Mobile IP deployments. > > > > In the proposed text, both the Abstract and the Introduction _does_ say > > that this is an optional extension to MIP, so what are you disagreeing > with? > >As I stated in the email above and in my writeup, it should say >clearly in the Abstract and Introduction that the architecture is >OPTIONAL *and not required in typical Mobile IP deployments.* Since >this is not what you wrote above, we are DISAGREEING. To me, optional means just that, that it is not required, and that, I think, is clearly stated. I don't like the expression "in typical Mobile IP deployments". What is a "typical" Mobile IP deployment, and will it always be the same? > > > > > >Also, reference to the new > > >Section that will describe scenarios that may benefit from this > > >architecture should be included in the Introduction. The agreement to > > >include the new Section is to alleviate the doubts for the necessity > > >of this architecture. Hopefully, the new Section will highlight when > > >the architecture is useful, and not when it is NOT. > > > > I think that the text in the Introduction gives sufficent information > about > > what makes regional registrations useful and see no need for an extra > section. > >This is not what Charlie and I agreed to. We agreed to a new >Section that describes where this architecture would be >useful...perhaps you can provide network architectures that would >benefit from the regional tunneling. As per the agreement, the new >section would go into Section 3...probably Section 3.1 as Charlie >mentioned. Refer to the original email thread on this. If we had >thought that the Introduction was sufficient, the original email >thread would not have occured. Please do not go back to square one. Sorry, I missed that. I went back to see what you and Charlie had written. You offered to help with text, could you please do that? I'm not really sure what you want in this new section, that's why I'm asking. In the Introduction now it says: " If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. We propose a solution for performing registrations locally in the visited domain: regional registrations." Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another, within the same visited domain. This will both decrease the load on the home network, and speed up the process of handover within the visited domain. " What would you like to add to that? Regards, Annika >Thanks, >Madhavi > > > > Regards, > > Annika > > > > >I have provided Annika with the suggested text. Please incorporate > > >the above comments. > > > > > >Thanks, > > >Madhavi > > > > > > > > > > Phil > > > > > > > > "Abstract > > > > > > > > Using Mobile IP, a mobile node registers with its home agent each > time it > > > > changes care-of address. If the distance between the visited > network and > > > > the home network of the mobile node is large, the signaling delay for > > > these > > > > registrations may be long. This document describes a new kind of > > > "regional" > > > > registration, i.e., registration local to the visited domain. The > regional > > > > signaling is performed via a new network entity called a Gateway > Foreign > > > > Agent and introduces a layer of hierarchy in the foreign domain. > Regional > > > > registrations reduce the number of signaling messages to the home > network, > > > > and reduce the signaling delay when a mobile node moves from one > foreign > > > > agent to another, within the same visited domain. This document is an > > > > optional extension to the Mobile IP protocol." > > > > > > > > > > > > "Introduction > > > > > > > > This document is an optional extension to the Mobile IP protocol, and > > > > proposes a means for mobile nodes to register locally within a visited > > > > domain. By registering locally, the number of signaling messages to the > > > > home network are keept to a minimum, and the signaling delay is > reduced. > > > > > > > > In Mobile IP, as specified in RFC 3220 [9], a mobile node registers > with > > > > its home agent each time it changes care-of address. If the distance > > > > between the visited network and the home network of the mobile node is > > > > large, the signaling delay for these registrations may be long. We > propose > > > > a solution for performing registrations locally in the visited domain: > > > > regional registrations. The regional registration design introduces new > > > > Mobile IP messages - Regional Registrations, new Mobile IP > extensions to > > > > convey information between the mobile node, foreign agent, and home > agent, > > > > and a new network entity - Gateway Foreign Agent (GFA). Regional > > > > registrations reduce the number of signaling messages to the home > network, > > > > and reduce the signaling delay when a mobile node moves from one > foreign > > > > agent to another, within the same visited domain. This will both > decrease > > > > the load on the home network, and speed up the process of handover > within > > > > the visited domain. The introduction of a GFA also makes it possible to > > > > have different addressing realms in the home and in the visited > networks." > > > > > > > > > > > > The last three paragraphs of the Introduction are unmodified. From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 05:50:55 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10843 for ; Tue, 14 May 2002 05:50:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11767; Tue, 14 May 2002 03:50:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09276; Tue, 14 May 2002 02:49:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E9n3rP009325 for ; Tue, 14 May 2002 02:49:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4E9n3Fp009324 for mobile-ip-dist; Tue, 14 May 2002 02:49:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E9n0rP009317 for ; Tue, 14 May 2002 02:49:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09055 for ; Tue, 14 May 2002 02:49:04 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA22149 for ; Tue, 14 May 2002 03:49:03 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4E9n10E027213; Tue, 14 May 2002 11:49:01 +0200 (MEST) Received: from bends.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA21464; Tue, 14 May 2002 11:48:59 +0200 Message-Id: <5.1.0.14.0.20020514104109.0285ace0@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 14 May 2002 11:47:13 +0200 To: Phil Roberts , mobile-ip@sunroof.eng.sun.com From: Annika Jonsson Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #2 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: At 03:37 PM 5/13/2002 -0400, Phil Roberts wrote: >We would like to know whether folks agree or disagree with these >proposed resolutions. > >Annika, we're going to need proposed text for each of them, and a >pointer to where it would go in the draft. se below... >Thanks, >Phil > > > > -----Original Message----- > > From: Annika Jonsson [mailto:annika.jonsson@ericsson.com] > > Sent: Monday, May 13, 2002 11:53 AM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] Regional Registration Last Call > > Resolution Issue #2 > > > > > > Hi > > > > Here are my conclusions and proposals for additions/changes > > to solve the > > backwards compatibility issues in the Regional Registrations draft: > > > > A: Backwards compatibility with RFC3220 MN:s. > > FA:s must advertise their own address, since it is used for movement > > detection by RFC3220 MN:s. This requires one change and one > > clarification > > to the draft: > > - To be backwards compatible, if the FA only advertises one > > CoA it must be > > its own address (not the GFA address as specified now). This > > FA must be > > able to act as a normal RFC3220 FA (that's in the draft already). This would go into section 3.3. It would be changed to: " 3.3. Advertising Foreign Agent and GFA A foreign agent typically announces its presence via an Agent Advertisement message [9]. If the domain to which a foreign agent belongs supports regional registrations, the following changes are applied to the Agent Advertisement message. The `I' flag (see Section 7) MUST be set to indicate that the domain supports regional tunnel management. If the `I' bit is set, there MUST be at least one care-of address in the Agent Advertisement message, but that address MAY be set to zero. If the `I' bit is set, and there is only one care-of address (i.e. not zero), it is the address of the FA. If the `I' bit is set, and there are multiple care-of addresses, the first care-of address is the local FA, and the last care-of address is the GFA. The FA-NAI (see section 7.2) SHOULD also be present to enable the mobile node to decide whether or not it is in its home domain. The decision is based on whether the realm part of the advertised FA-NAI matches the mobile node's realm. " > > - clarify that if the FA advertises a zero address, it will > > not support > > RFC3220 MN:s. In some cases the owner of the network might > > prefer this. > > > > A new section about backwards compatibility: "3.4 Backwards compatibility with RFC3220 A domain that supports Regional Regisratiosn SHOULD also be backwards compatible with RFC3220. If the Foreign Agent does not advertise a zero care-of-address, it MUST support registrations according to Mobile IPv4 [9]. This allows mobile nodes that doesn't support Regional Registrations to register via this Foreign Agent using standard Mobile IPv4. If the Foreign Agent advertises both its own care- of address and a GFA care-of address, a mobile node that supports Regional Registrations but has a Home Agent that doesn't, will still be able to make use of Regional Registrations through that GFA care-of address. A Foreign Agent that advertises a zero care-of address will not be backwards compatible wiht RFC3220, since both mobile nodes and Home Agents have to understand the zero care-of address. If the mobile node sets the care-of address to zero, the mobile node and its home agent MUST support the GFA IP address extension." > > > B: Backwards compatibility with RFC3220 HA:s > > The problem here is that an RFC 3220 HA does not understand > > the GFA IP > > extension used if the MN sends a registration with zero CoA. > > There are two > > ways to solve this: > > > > B1: According to the draft right now, the MN MUST NOT send a > > Registration > > Request with zero CoA if it's HA doesn't support that. This > > is simple, but > > not very flexible. If the FA advertises a GFA CoA (in > > addition to the FA > > CoA), the MN should use that, and can then make use of regional > > registrations even though it's HA does not support it. If the FA only > > advertises it's own address, the MN can not make use of regional > > registration unless it's HA supports it, but can still use > > normal Mobile > > IP. An FA that only advertises a zero address will not be > > backwards compatible. > > > > B2: The other alternative is that the draft could be changed > > by adding a > > new error code from the GFA to tell the MN that the HA did > > not support the > > GFA IP extension. The MN could then try the advertised CoA > > instead (or, > > possibly, a new extension added so the the GFA could tell the > > MN what CoA > > to use). > > > > I see one problem with this: I'm not sure how an RFC3220 HA > > would deal with > > this kind of registration. In the draft today, the GFA IP > > extension is > > non-skippable (because the HA MUST support it if the MN uses > > it). A HA that > > doesn't support this would not answer to this registration at > > all, it would > > silently discard the message. > > > > If the extension was changed to be skippable, how would the HA react? > > Either it would notice that something is wrong with the CoA, > > and send a > > reply with some error code (e.g. "poorly formed request??). > > Or it would not > > even check the CoA (I couldn't find this mentioned anywhere > > in RFC3220). In > > this case it would accept the registration, and set the CoA > > to zero. The > > GFA will then receive a reply without a GFA IP extension. In > > both cases, > > the GFA _could_ assume that the HA did not support the GFA IP > > extension, > > but it doesn't know for sure. > > > > To conclude: this option (B2) seems too uncertain, so I would > > rather go for > > the (more unflexible, but simple) B1 (i.e. no changes to the > > current draft, > > but it could be clarified a bit). > > see the proposed new section 3.4 above. /Annika > > > /Annika > > From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 05:59:54 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11157 for ; Tue, 14 May 2002 05:59:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA02852; Tue, 14 May 2002 02:57:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA10817; Tue, 14 May 2002 02:57:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E9v7rP009360 for ; Tue, 14 May 2002 02:57:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4E9v6YF009359 for mobile-ip-dist; Tue, 14 May 2002 02:57:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4E9v2rP009352 for ; Tue, 14 May 2002 02:57:03 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4E9v4g09557; Tue, 14 May 2002 11:57:04 +0200 (MEST) Date: Tue, 14 May 2002 11:56:15 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] How to process HAO To: Vijay Devarapalli Cc: keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3CC842BD.A42F7D0F@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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > hi Keiichi, > > There was a discussion between Erik Normark and myself. I think > we concluded on something similar to the following. (correct me > if missed something, Erik). > > HAO is processed if > > - if there is a BCE with CoA = IPv6 src and HoA = HAO content > - if there is a home registration BCE with HoA = HAO content > - if packet contains BU and satisfies the security policy > between MN and HA > - if packet contains AH or ESP header and satisfies the security > policy check between MN and HA. [Catching up on email] I think only in the first case should the HAO be processed without any additional checks. So my thinking is that conservative logic looks like this: if there is a BCE with CoA = IPv6 src and HoA = HAO content accept packet if there is NOT a home registration BCE with HoA = HAO content drop packet; send "binding missing" error verify that packet is IPsec protected e.g. by verifying first that AH or ESP is the next header and then later (as part of or after IPsec processing) verify that the HoA "matches" the IPsec SA. Note that "home registration BCE" needs to capture both the case of an "active" BCE and the case when the HoA is a user of the HA that might not have an "active" BCE at the time. Whether such entries are captured using BCEs or something else is an implementation detail. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 06:28:46 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12106 for ; Tue, 14 May 2002 06:28:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA27669; Tue, 14 May 2002 03:26:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16775; Tue, 14 May 2002 03:26:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EAPmrP009400 for ; Tue, 14 May 2002 03:25:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EAPmnP009399 for mobile-ip-dist; Tue, 14 May 2002 03:25:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EAPjrP009392 for ; Tue, 14 May 2002 03:25:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA21323 for ; Tue, 14 May 2002 03:25:47 -0700 (PDT) Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA04609 for ; Tue, 14 May 2002 04:25:46 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 14 May 2002 13:25:45 +0300 Message-ID: Thread-Topic: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security Thread-Index: AcHxshZ7wufw1kH8Rv6sRHK7U9LnJAJf1tcQ From: "Sami Vaarala" To: "Francis Dupont" Cc: =?iso-8859-1?Q?Hans_Sj=F6strand?= , "Henrik Levkowetz" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4EAPjrP009393 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi all, Here is a new try on the security considerations section. We tried to partition the discussion to a more manageable form. Francis, does this seem reasonable to you? Any other issues to be discussed? Best regards, -Sami -------- 6. Security Considerations The ordinary Mobile IP security mechanisms are also used with the NAT traversal mechanism described in this document. However, there is one noticeable change: the NAT traversal mechanism requires that the HA trust unauthenticated address (and port) fields possibly modified by NATs. Relying on unauthenticated address information when forming or updating a mobility binding leads to several redirection attack vulnerabilities. In essence, an attacker may do what NATs do, i.e. modify addresses and ports and thus cause traffic to be redirected to a chosen address. The same vulnerabilities apply to both MN-HA and FA-HA NAT traversal. In more detail: without a NAT, the care-of address in the registration request will be directly used by the HA to send traffic back to the MN (or the FA), and the care-of address is protected by the MN-HA (or FA-HA) authentication extension. When communicating across a NAT, the effective care-of address from the HA point of view is that of the NAT, which is not protected by any authentication extension, but inferred from the apparent IP source address of received packets. This means that by using the mobile IP registration extensions described in this document to enable traversal of NATs, one is opening oneself up to having the care-of address of a MN (or a FA) maliciously changed by an attacker. Some, but not all, of the attacks could be alleviated to some extent by using a simple routability check. However, this document does not specify such a mechanism for simplicity reasons and because the mechanism would not protect against all redirection attacks. To limit the duration of such redirection attacks, it is RECOMMENDED to use a conservative (that is, short) mobility binding lifetime when using the NAT traversal mechanism specified in this document, and also use registration request keepalives rather than ICMP echo request keepalives. The known security issues are described in the sections that follow. 6.1 Traffic Redirection Vulnerabilities 6.1.1 Manipulation of the Registration Request Message An attacker on the route between the mobile node (or foreign agent) and the home agent may redirect mobility bindings to a desired address simply by modifying the IP and UDP headers of the Registration Request message. Having modified the binding, the attacker no longer needs to listen to (or manipulate) the traffic. The redirection is in force until the mobility binding expires or the mobile node re-registers. This vulnerability may be used by an attacker to read traffic destined to a mobile node, and to send traffic impersonating the mobile node. The vulnerability may also be used to redirect traffic to a victim host in order to cause denial-of-service on the victim. The only defence against this vulnerability is to have a short time between re-registrations, which limits the duration of the redirection attack after the attacker has stopped modifying registration messages. 6.1.2 Sending a Bogus Keepalive Message When registering through a FA using a co-located care-of address, another redirection vulnerability opens up. Having exchanged RRQ/RRP messages with the HA through the FA, the MN is expected to send the first keepalive message to the HA, thus finalizing the mobility binding (the binding will remain in a "half open" state until the keepalive is received). Having observed a RRQ/RRP exchange, an attacker may send a bogus keepalive message assuming that the mobility binding is in the "half open" state. This opens up a similar redirection attack as discussed in Section 6.1.1. Note, however, that the attacker does not need to be able to modify packets in flight; simply being able to observe the RRQ/RRP message exchange is sufficient to mount the attack. With this in mind, the home agent MUST NOT accept a keepalive message from a different source IP address than where the RRQ came from, as specified in Section 4.6. This requirement limits the extent of the attack to redirecting the traffic to a bogus UDP port, while the IP address must remain the same as in the initial RRQ. The only defences against this vulnerability are: (1) to have a short time between re-registrations, which limits the duration of the redirection attack after the attacker has stopped sending bogus keepalive messages, and (2) to minimize the time the binding is in a "half open" state by having the mobile node send the first keepalive message immediately after receiving an affirmative registration reply. 6.2 Use of IPsec If the intermediate network is considered insecure, it is recommended that IPsec be used to protect user data traffic. However, IPsec does not protect against the redirection attacks described previously, other than to protect confidentiality of hijacked user data traffic. The NAT traversal mechanism described in this document allows all IPsec-related traffic to go through NATs without any modifications to IPsec. In addition, the IPsec security associations do not need to be re-established when the mobile node moves. 6.3 Firewall Considerations This document does not specify a general firewall traversal mechanism. However, the mechanism makes it possible to use only a single address and a port for all MN-HA (or FA-HA) communication. Furthermore, using the same port for the MIP UDP tunnelled traffic as for control messages makes it quite probable that if a MIP registration can reach the home agent, MIP tunnelling and reverse tunnelling using the described mechanism will also work. From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 08:14:54 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14897 for ; Tue, 14 May 2002 08:14:53 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02464; Tue, 14 May 2002 06:14:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA09213; Tue, 14 May 2002 05:13:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ECD8rP009637 for ; Tue, 14 May 2002 05:13:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4ECD84s009636 for mobile-ip-dist; Tue, 14 May 2002 05:13:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ECD5rP009629 for ; Tue, 14 May 2002 05:13:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06798 for ; Tue, 14 May 2002 05:13:08 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23966 for ; Tue, 14 May 2002 06:13:34 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4ECD3s7006496; Tue, 14 May 2002 14:13:03 +0200 (MEST) Received: from bends.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id OAA24858; Tue, 14 May 2002 14:13:02 +0200 Message-Id: <5.1.0.14.0.20020514130814.02858ec0@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 14 May 2002 14:11:11 +0200 To: Behcet Sarikaya From: Annika Jonsson Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #2 Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: <3CDFEF9C.1050700@alcatel.com> References: <5.1.0.14.0.20020513174340.0287b200@era-t.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Behcet, I have only looked at those drafts briefly, but my guess is that regional registartions would have the same problems, and they could be solved in the same way as basic Mobile IPv4. The GFA will act as, and look like, any FA to the outside world, so there shouldn't be a big difference. It could of course be good if these drafts also included GFA considerations. There might be one difference in the NAT case: a GFA could in itself be placed on the border between a private and a public domain, instead of a NAT. This has always been the intention with this draft, although it was not really stated explicitly. But now, after incorporationg some of Alan's comments (as I think we will, but of course it depends on if we get consensus on the list), this will become clearer, and more flexible. /Annika At 11:53 AM 5/13/2002 -0500, Behcet Sarikaya wrote: >Hello Annika, > I have a question on how your draft which I strongly support would > behave in the presence of NAT/NAPT boxes and IPsec VPNs? I could not see > any GFA consideration in? >http://www.ietf.org/internet-drafts/draft-ietf-mobileip-nat-traversal-02.txt >and in >http://www.ietf.org/internet-drafts/draft-ietf-mobileip-vpn-problem-statement-00.txt > >Regards, > >Annika Jonsson wrote: > > >--behcet > > From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 08:23:18 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15315 for ; Tue, 14 May 2002 08:23:17 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06242; Tue, 14 May 2002 06:22:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11231; Tue, 14 May 2002 05:22:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ECLirP009682 for ; Tue, 14 May 2002 05:21:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4ECLiqI009681 for mobile-ip-dist; Tue, 14 May 2002 05:21:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ECLerP009674 for ; Tue, 14 May 2002 05:21:40 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4ECLfg15489; Tue, 14 May 2002 14:21:41 +0200 (MEST) Date: Tue, 14 May 2002 14:20:54 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Error DOS Attack? To: James Kempf Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <01be01c1f6e0$6321ef00$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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Section 6.1.1 of draft 17 specifies that an error is sent to the source > if the MH type is not recognized (pg. 32). > > An attacker could pump packets at the CN or MN with erroneous MH type > values, and the attacked node would have to continue replying, thus > tying it up. None of the rest of the RR protocol seems to have any error > returns, so this would be the only place that it could occur. > > Is this worth worrying about? It might make sense to copy the ICMP error generation behavior from the ICMPv6 specification which is basically to rate limit errors. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 08:39:33 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15988 for ; Tue, 14 May 2002 08:39:32 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05072; Tue, 14 May 2002 05:37:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA15038; Tue, 14 May 2002 05:37:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ECaSrP009719 for ; Tue, 14 May 2002 05:36:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4ECaS4E009718 for mobile-ip-dist; Tue, 14 May 2002 05:36:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ECaPrP009711 for ; Tue, 14 May 2002 05:36:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA11081 for ; Tue, 14 May 2002 05:36:29 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA27637 for ; Tue, 14 May 2002 06:36:27 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4ECZmc03449; Tue, 14 May 2002 14:35:52 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA20845; Tue, 14 May 2002 14:35:48 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4ECZiT79618; Tue, 14 May 2002 14:35:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205141235.g4ECZiT79618@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian Haley cc: Vijay Devarapalli , Brian Haley , Charlie Perkins , mobile-ip@sunroof.eng.sun.com Subject: Re: [Fwd: [mobile-ip] S-bit and building a link-local address] In-reply-to: Your message of Fri, 10 May 2002 17:14:51 EDT. <3CDC384B.7AB7417B@hp.com> Date: Tue, 14 May 2002 14:35:44 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: RFC 2462 (address autoconfiguration) tells you how to make a link-local address from an interface identifier, but not how to make an address identifier from a unicast address. => I don't know what is an address identifier. If it means interface identifier then it is part of the unicast address and a known part if the unicast address is a global address not starting with 000. I guess the Home Agent could figure this out since it should know the link type, but this will not work in all cases (Section 2.5.4 of the new address architecture imposed some limitations). => I disagree : this is easy in all reasonnable cases. Anyways, maybe it is more useful to have the Mobile Node supply it's interface identifier if it wishes to have more than one address registered, then it's not ambigous. I didn't really want to go there, I would still favor removing the S-bit, that way the MN can register only the addresses it wants. Right now, if the S-bit isn't set, there is no way for the MN to know exactly which addresses the HA configured - by the time it does a prefix solicitation there could have been a change. => I don't like "subnet registrations" but this is not the good argument. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 09:26:15 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17948 for ; Tue, 14 May 2002 09:26:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28338; Tue, 14 May 2002 07:26:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27860; Tue, 14 May 2002 06:25:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EDOSrP009822 for ; Tue, 14 May 2002 06:24:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EDORc2009821 for mobile-ip-dist; Tue, 14 May 2002 06:24:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EDOOrP009814 for ; Tue, 14 May 2002 06:24:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27597 for ; Tue, 14 May 2002 06:24:28 -0700 (PDT) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id HAA22663 for ; Tue, 14 May 2002 07:24:27 -0600 (MDT) Received: from unknown (HELO EmadQ) (emadaq@194.165.157.197 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 May 2002 13:24:23 -0000 Reply-To: From: "Emad Qaddoura" To: "'Phil Roberts'" , , Subject: [mobile-ip] Charter Suggestion Date: Tue, 14 May 2002 16:23:08 +0200 Message-ID: <000a01c1fb52$e86c8280$5701a8c0@EmadQ> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C1FB63.ABF55280" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000B_01C1FB63.ABF55280 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I would like to suggest another statement in the charter along the lines of the following statement: "Working Group will ensure that solutions proposed for these problem domains are suitable for IPv4 and IPv6 respectively", The suggested statement would be: "Working group will ensure that all new MIP protocol enhancements should NOT add any additional delay to the in flight traffic to/from the MN". If the above statement is acceptable, possibly a section would be added in new drafts to indicate how such enhancements don't avoid the above impact? Thanks, Emad ------=_NextPart_000_000B_01C1FB63.ABF55280 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hi,

 

I would like to suggest another = statement in the charter along the lines of the following = statement:

 

        = ;    “Working Group will ensure that solutions proposed for these problem domains are suitable for IPv4 and IPv6 respectively”,

 

The suggested statement would = be:

 

        = ;    “Working group will ensure that all new MIP protocol enhancements should NOT add = any additional delay to the in flight traffic to/from the = MN”.

 

        = ;    If the above statement is acceptable, possibly a section would be added in = new drafts to indicate how such enhancements don’t avoid the above = impact?

 

Thanks,

=

Emad

 

 

------=_NextPart_000_000B_01C1FB63.ABF55280-- From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 09:26:27 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17964 for ; Tue, 14 May 2002 09:26:26 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28339; Tue, 14 May 2002 07:26:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27906; Tue, 14 May 2002 06:25:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EDOLrP009812 for ; Tue, 14 May 2002 06:24:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EDOLeC009811 for mobile-ip-dist; Tue, 14 May 2002 06:24:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EDOIrP009804 for ; Tue, 14 May 2002 06:24:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27550 for ; Tue, 14 May 2002 06:24:22 -0700 (PDT) Received: from smtp017.mail.yahoo.com (smtp017.mail.yahoo.com [216.136.174.114]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA27504 for ; Tue, 14 May 2002 07:24:48 -0600 (MDT) Received: from unknown (HELO EmadQ) (emadaq@194.165.157.197 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 May 2002 13:24:17 -0000 Reply-To: From: "Emad Qaddoura" To: Cc: , , Subject: RE: [mobile-ip] Last Call: Regional Tunneling input Date: Tue, 14 May 2002 16:23:08 +0200 Message-ID: <000501c1fb52$e452b480$5701a8c0@EmadQ> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C1FB63.A7DB8480" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <000101c1f0d7$644fa2a0$830490d9@EmadQ> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C1FB63.A7DB8480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Annika, I would appreciate if you can answer the question below as I have not heard if I was totally wrong in understanding the statement or can it be enhanced? 1) From Section 5.0, 4th paragraph, "If the advertised GFA is not the same as the one the mobile node has registered as its care-of address, and if the mobile node is still within the same domain as it was when it registered that care-of address, the mobile node MAY try to perform a regional registration with its registered GFA. If the foreign agent cannot support regional registration to a GFA, other than advertised, the foreign agent denies the regional registration with code UNKNOWN_GFA (see section 9.3). In this case the MN has to do a new home registration via the new GFA." As you see, there is extra registration step here,( if the current GFA used by the MN is not supported by the FA), adding possible delays to traffic, would it be reasonable to expect all FAs in the same domain to handle the regional registration to the different GFAs. Or do I misunderstand the above paragraph? Thanks, Emad. -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Emad Qaddoura Sent: Wednesday, May 01, 2002 8:14 AM To: annika.jonsson@ericsson.com; mobile-ip@sunroof.eng.sun.com; charliep@iprg.nokia.com; eva.gustafsson@ericsson.com Subject: RE: [mobile-ip] Last Call: Regional Tunneling input Authors, Since I have not heard back from Annika on Q1 below, I would like to repost and get clarification from any of the co-authors/group. Personally, reading the draft and all the if/then cases like, get the impression that MIP will have added delay. Working for several years to improve MIP's real-time aspects, makes me concerned about the ultimate impact without seeing from the detailed analysis of this feature's impact (positive/negative). I am re-stating Q2 to the authors/service providers/content providers for their views, as location based services may require the finer granularity of the MN's where about. Thx. EQ ------------------------------------------------------------------------ -------------------------- 1) From Section 5.0, 4th paragraph, "If the advertised GFA is not the same as the one the mobile node has registered as its care-of address, and if the mobile node is still within the same domain as it was when it registered that care-of address, the mobile node MAY try to perform a regional registration with its registered GFA. If the foreign agent cannot support regional registration to a GFA, other than advertised, the foreign agent denies the regional registration with code UNKNOWN_GFA (see section 9.3). In this case the MN has to do a new home registration via the new GFA." As you see, there is extra registration step here,( if the current GFA used by the MN is not supported by the FA), adding possible delays to traffic, would it be reasonable to expect all FAs in the same domain to handle the regional registration to the different GFAs. Or do I misunderstand the above paragraph? With the route optimization draft being optional extensions, we should be concerned about any additional delays to traffic destined to the MN. 2) If the coverage area is large, and the home network does provide personalized content services based on the mobile node's location (location based services) requiring a finer location, would you expect this feature to be turned off most of the time? ------=_NextPart_000_0006_01C1FB63.A7DB8480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Annika,

=

 

        = ;    I would appreciate if you can answer the question below as I have not = heard if I was totally wrong in understanding the statement or can it be = enhanced?

 

1) From Section 5.0, 4th paragraph,

"If the advertised GFA is not the same as the one the mobile node = has

   registered as its care-of address, and if the mobile node is = still

   within the same domain as it was when it registered that = care-of

   address, the mobile node MAY try to perform a regional = registration

   with its registered GFA. If the foreign agent cannot = support

   regional registration to a GFA, other than advertised, the = foreign

   agent denies the regional registration with code UNKNOWN_GFA = (see

   section 9.3).  In this case the MN has to do a = new home registration

   via the new GFA."

 

As you see, there is extra registration step here,( if = the current GFA used by the MN is not supported by the FA), adding possible delays = to traffic, would it be reasonable to expect all FAs in the same domain to handle the regional registration to the different = GFAs. Or do I misunderstand the above = paragraph?

 

 

Thanks,

=

Emad.

 

-----Original Message-----
From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Emad Qaddoura
Sent: = Wednesday, May 01, = 2002 8:14 AM
To: = annika.jonsson@ericsson.com; mobile-ip@sunroof.eng.sun.com; charliep@iprg.nokia.com; eva.gustafsson@ericsson.com
Subject: RE: [mobile-ip] = Last Call: Regional Tunneling input

 

Authors,

        = ; 

        = ;  Since I have not heard back from Annika on Q1 below, I would like to repost = and get clarification from any of the co-authors/group. Personally, reading the = draft and all the if/then cases like, get the impression that MIP will have = added delay. Working for several years to improve MIP’s real-time = aspects, makes me concerned about the ultimate impact without seeing from the = detailed analysis of this feature’s impact = (positive/negative).

 

        = ;  I am re-stating Q2 to the authors/service providers/content providers for = their views, as location based services may require the finer granularity of = the MN’s where about.

 

Thx.

EQ

------------------------------------------------------= --------------------------------------------

=

 

1) From Section 5.0, 4th paragraph,

"If the advertised GFA is not the same as the one the mobile node = has

   registered as its care-of = address, and if the mobile node is still

   within the same domain as = it was when it registered that care-of

   address, the mobile node = MAY try to perform a regional registration

   with its registered GFA. = If the foreign agent cannot support

   regional registration to = a GFA, other than advertised, the foreign

   agent denies the regional registration with code UNKNOWN_GFA (see

   section 9.3).  In = this case the MN has to do a new home registration

   via the new = GFA."

 

As you see, there is extra registration step here,( if the current GFA used by the = MN is not supported by the FA), adding possible delays to traffic, would it be = reasonable to expect all FAs in the same domain to handle the regional registration = to the different GFAs. Or do I misunderstand the above = paragraph?

 

With the route optimization draft being optional extensions, we should be = concerned about any additional delays to traffic destined to the = MN.

 

2) If the coverage area is large, and the home network does provide personalized = content services based on the mobile node's location (location based services) requiring a finer location, would you expect this feature to be turned = off most of the time?

 

 

------=_NextPart_000_0006_01C1FB63.A7DB8480-- From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 09:28:18 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18078 for ; Tue, 14 May 2002 09:28:15 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29128; Tue, 14 May 2002 06:25:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27946; Tue, 14 May 2002 06:25:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EDOhrP009832 for ; Tue, 14 May 2002 06:24:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EDOgxL009831 for mobile-ip-dist; Tue, 14 May 2002 06:24:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EDOcrP009824 for ; Tue, 14 May 2002 06:24:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21029 for ; Tue, 14 May 2002 06:24:43 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27704 for ; Tue, 14 May 2002 07:25:08 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4EDOKc13532; Tue, 14 May 2002 15:24:21 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA21735; Tue, 14 May 2002 15:24:20 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4EDOFT79914; Tue, 14 May 2002 15:24:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205141324.g4EDOFT79914@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Padmakumar.AV@lntinfotech.com cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MN Returning Home In-reply-to: Your message of Tue, 14 May 2002 09:32:52 +0530. Date: Tue, 14 May 2002 15:24:15 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: You wrote 'you really have a problem when the "whole subnet" is registered you mean the case where 'S' bit is not set. => yes, to be in trouble the S bit must be zero. But even though the 'S' bit is set, HA still defend the use of link local address as part of the proxy functionality. => no, it doesn't. The current draft is terrible but it doesn't say (yet :-) the link-local address is defended against DAD: - if the D bit is set a DAD is performed for the link-local address before the BU is accepted. - if the S bit is set then the proxy address set is reduced to the home address else it is the whole set of derived addresses, including the link-local one. - the proxy function includes the defense against DAD (just because it replies to any NS for the proxied addresses). - if the R bit is set then it is copied into NAs. (at the last IETF meeting I said the R bit was forgotten, I-D authors, wake up and PLEASE PUT IT BACK. BTW fix the unicast NS to get the home agent link-layer address) Note an agnostic MN returning at home can fail to perform DAD on a previous home address registered with D=1, S=1. IMHO 11.6.7 should be more accurate, I propose to add to: agent's use of the same address. If the mobile node returns home after the bindings for all of its care-of addresses have expired, then it SHOULD perform DAD. near the end of page 138 . Regards Francis.Dupont@enst-bretagne.fr PS: I-D 17 has more than 170 pages. This is ridiculous, all not finished features should be moved to other documents. It seems that RR should not be in the list but I propose to begin with: - renumbering support (complex, dubious utility today) - home agent address discovery (or make it secure, good luck :-). From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 09:32:13 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18230 for ; Tue, 14 May 2002 09:32:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08134; Tue, 14 May 2002 07:30:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29489; Tue, 14 May 2002 06:30:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EDTJrP009905 for ; Tue, 14 May 2002 06:29:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EDTJ49009904 for mobile-ip-dist; Tue, 14 May 2002 06:29:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EDTFrP009897 for ; Tue, 14 May 2002 06:29:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29075 for ; Tue, 14 May 2002 06:29:20 -0700 (PDT) Received: from smtp015.mail.yahoo.com (smtp015.mail.yahoo.com [216.136.173.59]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA00367 for ; Tue, 14 May 2002 07:29:46 -0600 (MDT) Received: from unknown (HELO EmadQ) (emadaq@194.165.157.197 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 14 May 2002 13:29:17 -0000 Reply-To: From: "Emad Qaddoura" To: "'Phil Roberts'" , , Subject: [mobile-ip] Charter Question Date: Tue, 14 May 2002 16:28:13 +0200 Message-ID: <001e01c1fb53$97838200$5701a8c0@EmadQ> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C1FB64.5B0C5200" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C1FB64.5B0C5200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Raj/Phil, In the charter, there is a statement: "Working Group will ensure that solutions proposed for these problem domains are suitable for IPv4 and IPv6 respectively", What does such statement require from new solutions/drafts before moving forward through a last call? A good example, would a draft like regional registrations have to provide its applicability/mapping (whatever the term may be) to IPv6? Thanks, Emad. ------=_NextPart_000_001F_01C1FB64.5B0C5200 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Raj= /Phil,

 

        = ;    In the charter, there is a statement:

 

        = ;    “Working Group will ensure that solutions proposed for these problem domains are suitable for IPv4 and IPv6 respectively”,

 

        = ;    What does such statement require from new solutions/drafts before moving = forward through a last call?

 

        = ;    A good example, would a draft like regional registrations have to provide = its applicability/mapping (whatever the term may be) to = IPv6?

 

Thanks,

Emad.

 

------=_NextPart_000_001F_01C1FB64.5B0C5200-- From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 09:47:01 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18971 for ; Tue, 14 May 2002 09:47:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29401; Tue, 14 May 2002 06:45:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03599; Tue, 14 May 2002 06:44:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EDherP009980 for ; Tue, 14 May 2002 06:43:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EDhdWw009979 for mobile-ip-dist; Tue, 14 May 2002 06:43:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EDhVrP009972 for ; Tue, 14 May 2002 06:43:31 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24163 for ; Tue, 14 May 2002 06:43:33 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04564 for ; Tue, 14 May 2002 07:43:33 -0600 (MDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4EDhSHs004101; Tue, 14 May 2002 06:43:29 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA02589; Tue, 14 May 2002 09:43:28 -0400 (EDT) Date: Tue, 14 May 2002 09:43:28 -0400 From: "Madhavi W. Chandra" To: Annika Jonsson Cc: "Madhavi W. Chandra" , Phil Roberts , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Message-ID: <20020514094328.A2517@cisco.com> References: <5.1.0.14.0.20020513175420.0287a090@era-t.ericsson.se> <20020509130354.A25864@cisco.com> <5.1.0.14.0.20020513175420.0287a090@era-t.ericsson.se> <20020513123737.A1353@cisco.com> <5.1.0.14.0.20020514100419.02851500@era-t.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.0.20020514100419.02851500@era-t.ericsson.se>; from annika.jonsson@ericsson.com on Tue, May 14, 2002 at 10:40:45AM +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Annika, On Tue, May 14, 2002 at 10:40:45AM +0200, Annika Jonsson wrote: > Hi Madhavi, > > At 12:37 PM 5/13/2002 -0400, Madhavi W. Chandra wrote: > >HI Annika, > > > >On Mon, May 13, 2002 at 06:16:05PM +0200, Annika Jonsson wrote: > > > Hi Madhavi, > > > > > > see below... > > > > > ... > > > > > > Attached below is modified text for the abstract and the introduction, > > > > > Annika's words based on input > > > > > from Madhavi. > > > > > > > >DISAGREE...as written below. > > > > > > > >As per the feedback we provided, it should be clearly stated in the > > > >Abstract and Introduction that this architecture is OPTIONAL and not > > > >required in typical Mobile IP deployments. > > > > > > In the proposed text, both the Abstract and the Introduction _does_ say > > > that this is an optional extension to MIP, so what are you disagreeing > > with? > > > >As I stated in the email above and in my writeup, it should say > >clearly in the Abstract and Introduction that the architecture is > >OPTIONAL *and not required in typical Mobile IP deployments.* Since > >this is not what you wrote above, we are DISAGREEING. > > To me, optional means just that, that it is not required, and that, I > think, is clearly stated. I don't like the expression "in typical Mobile IP > deployments". What is a "typical" Mobile IP deployment, and will it always > be the same? Well, you can choose another word besides 'typical' then. I want to convey that not only is Regional Registration OPTIONAL, but not required in *typical* (or whatever word you like) networks. For example, Route Optimization is also optional, but more of a need to alleviate triangle routing. Do you see my point now? > > > > > > > > > >Also, reference to the new > > > >Section that will describe scenarios that may benefit from this > > > >architecture should be included in the Introduction. The agreement to > > > >include the new Section is to alleviate the doubts for the necessity > > > >of this architecture. Hopefully, the new Section will highlight when > > > >the architecture is useful, and not when it is NOT. > > > > > > I think that the text in the Introduction gives sufficent information > > about > > > what makes regional registrations useful and see no need for an extra > > section. > > > >This is not what Charlie and I agreed to. We agreed to a new > >Section that describes where this architecture would be > >useful...perhaps you can provide network architectures that would > >benefit from the regional tunneling. As per the agreement, the new > >section would go into Section 3...probably Section 3.1 as Charlie > >mentioned. Refer to the original email thread on this. If we had > >thought that the Introduction was sufficient, the original email > >thread would not have occured. Please do not go back to square one. > > Sorry, I missed that. I went back to see what you and Charlie had written. > You offered to help with text, could you please do that? I'm not really > sure what you want in this new section, that's why I'm asking. In the > Introduction now it says: Annika, how can I provide you text for something that I am asking? These are the concerns that I raised initially. We came to a good understanding that the authors would describe where the regional registration architecture is useful in another Section...you could articulate the network scenarios that would benefit. The purpose of the Section is to assuage doubts on its applicability. I offered to provide text for the OPTIONAL statements, which I did. Instead of continuing in circles, perhaps we should wait until Charlie returns. Regards, Madhavi > " If the distance between the visited network and the home network of the > mobile node is large, the signaling delay for these registrations may be > long. We propose a solution for performing registrations locally in the > visited domain: regional registrations." > > Regional registrations reduce the number of signaling messages to the home > network, and reduce the signaling delay when a mobile node moves from one > foreign agent to another, within the same visited domain. This will both > decrease the load on the home network, and speed up the process of handover > within the visited domain. " > > What would you like to add to that? > > Regards, > Annika > > >Thanks, > >Madhavi > > > > > > > Regards, > > > Annika > > > > > > >I have provided Annika with the suggested text. Please incorporate > > > >the above comments. > > > > > > > >Thanks, > > > >Madhavi > > > > > > > > > > > > > Phil > > > > > > > > > > "Abstract > > > > > > > > > > Using Mobile IP, a mobile node registers with its home agent each > > time it > > > > > changes care-of address. If the distance between the visited > > network and > > > > > the home network of the mobile node is large, the signaling delay for > > > > these > > > > > registrations may be long. This document describes a new kind of > > > > "regional" > > > > > registration, i.e., registration local to the visited domain. The > > regional > > > > > signaling is performed via a new network entity called a Gateway > > Foreign > > > > > Agent and introduces a layer of hierarchy in the foreign domain. > > Regional > > > > > registrations reduce the number of signaling messages to the home > > network, > > > > > and reduce the signaling delay when a mobile node moves from one > > foreign > > > > > agent to another, within the same visited domain. This document is an > > > > > optional extension to the Mobile IP protocol." > > > > > > > > > > > > > > > "Introduction > > > > > > > > > > This document is an optional extension to the Mobile IP protocol, and > > > > > proposes a means for mobile nodes to register locally within a visited > > > > > domain. By registering locally, the number of signaling messages to the > > > > > home network are keept to a minimum, and the signaling delay is > > reduced. > > > > > > > > > > In Mobile IP, as specified in RFC 3220 [9], a mobile node registers > > with > > > > > its home agent each time it changes care-of address. If the distance > > > > > between the visited network and the home network of the mobile node is > > > > > large, the signaling delay for these registrations may be long. We > > propose > > > > > a solution for performing registrations locally in the visited domain: > > > > > regional registrations. The regional registration design introduces new > > > > > Mobile IP messages - Regional Registrations, new Mobile IP > > extensions to > > > > > convey information between the mobile node, foreign agent, and home > > agent, > > > > > and a new network entity - Gateway Foreign Agent (GFA). Regional > > > > > registrations reduce the number of signaling messages to the home > > network, > > > > > and reduce the signaling delay when a mobile node moves from one > > foreign > > > > > agent to another, within the same visited domain. This will both > > decrease > > > > > the load on the home network, and speed up the process of handover > > within > > > > > the visited domain. The introduction of a GFA also makes it possible to > > > > > have different addressing realms in the home and in the visited > > networks." > > > > > > > > > > > > > > > The last three paragraphs of the Introduction are unmodified. From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 09:49:16 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19101 for ; Tue, 14 May 2002 09:49:16 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18094; Tue, 14 May 2002 07:48:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04594; Tue, 14 May 2002 06:48:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EDlurP010017 for ; Tue, 14 May 2002 06:47:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EDlu4l010016 for mobile-ip-dist; Tue, 14 May 2002 06:47:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EDlqrP010009 for ; Tue, 14 May 2002 06:47:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04472 for ; Tue, 14 May 2002 06:47:55 -0700 (PDT) Received: from cecom6.monmouth.army.mil (cecom6.monmouth.army.mil [134.80.0.9]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17750 for ; Tue, 14 May 2002 07:47:54 -0600 (MDT) Received: from mailsw2.monmouth.army.mil (mailsw2.monmouth.army.mil [134.80.0.139]) by cecom6.monmouth.army.mil (8.11.6+Sun/8.11.6) with ESMTP id g4EDlrT10049 for ; Tue, 14 May 2002 09:47:53 -0400 (EDT) Received: from swgm6.monmouth.army.mil (unverified) by mailsw2.monmouth.army.mil (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Tue, 14 May 2002 09:47:53 -0400 Received: by swgm6.monmouth.army.mil with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 09:47:53 -0400 Message-ID: From: "Palumbo, Jeffrey CECOM RDEC STCD" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] MIPv6 Implementations Date: Tue, 14 May 2002 09:47:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello- I am looking to get some different implementations of Mobile IPv6 for testing/evaluation. The only flavors I am finding that are relatively current is the MSR (win2k/XP) and the Mobile IP for Linux (MIPL) releases. Any additional direction appreciated. -jeff From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 10:20:31 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20692 for ; Tue, 14 May 2002 10:20:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19376; Tue, 14 May 2002 07:18:22 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00508; Tue, 14 May 2002 07:18:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EEGprP010181 for ; Tue, 14 May 2002 07:16:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EEGpxS010180 for mobile-ip-dist; Tue, 14 May 2002 07:16:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EEGlrP010173 for ; Tue, 14 May 2002 07:16:47 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11711 for ; Tue, 14 May 2002 07:16:50 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02773 for ; Tue, 14 May 2002 08:16:50 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4EEGvi09566; Tue, 14 May 2002 09:16:57 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 09:17:34 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCCD9@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Phil Roberts'" , "'mobile-ip@sunroof.eng.sun.com'" Cc: "'Annika Jonsson'" Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Date: Tue, 14 May 2002 09:17:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FB52.110784C0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FB52.110784C0 Content-Type: text/plain; charset="iso-8859-1" Phil/Annika, Please see my comments inline. Regards; Ahmad Muhanna > > Phil > > "Abstract > > Using Mobile IP, a mobile node registers with its home agent > each time it > changes care-of address. If the distance between the visited Well, this statement is correct. However, the proposed Regional Registration draft still does exactly what this sentence states!!!! > network and > the home network of the mobile node is large, the signaling > delay for these > registrations may be long. This document describes a new kind > of "regional" > registration, i.e., registration local to the visited domain. > The regional > signaling is performed via a new network entity called a > Gateway Foreign > Agent and introduces a layer of hierarchy in the foreign > domain. Regional > registrations reduce the number of signaling messages to the > home network, > and reduce the signaling delay when a mobile node moves from > one foreign > agent to another, within the same visited domain. This document is an > optional extension to the Mobile IP protocol." > > > "Introduction > > This document is an optional extension to the Mobile IP protocol, and > proposes a means for mobile nodes to register locally within > a visited > domain. By registering locally, the number of signaling > messages to the > home network are keept to a minimum, and the signaling delay > is reduced. > > In Mobile IP, as specified in RFC 3220 [9], a mobile node > registers with > its home agent each time it changes care-of address. If the distance same comment as above!!!! > between the visited network and the home network of the > mobile node is > large, the signaling delay for these registrations may be > long. We propose > a solution for performing registrations locally in the > visited domain: > regional registrations. The regional registration design > introduces new > Mobile IP messages - Regional Registrations, new Mobile IP > extensions to > convey information between the mobile node, foreign agent, > and home agent, > and a new network entity - Gateway Foreign Agent (GFA). Regional > registrations reduce the number of signaling messages to the > home network, > and reduce the signaling delay when a mobile node moves from > one foreign > agent to another, within the same visited domain. This will > both decrease > the load on the home network, and speed up the process of > handover within > the visited domain. The introduction of a GFA also makes it > possible to > have different addressing realms in the home and in the > visited networks." > > > The last three paragraphs of the Introduction are unmodified. > ------_=_NextPart_001_01C1FB52.110784C0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Regional Registration Last Call Resolution Issue #1

Phil/Annika,

Please see my comments inline.

Regards;
Ahmad Muhanna

>
> Phil
>
> "Abstract
>
> Using Mobile IP, a mobile node registers with its home agent
> each time it
> changes care-of address. If the distance between the visited

Well, this statement is correct.
However, the proposed Regional Registration draft still does exactly what this sentence states!!!!
 
> network and
> the home network of the mobile node is large, the signaling
> delay for these
> registrations may be long. This document describes a new kind
> of "regional"
> registration, i.e., registration local to the visited domain.
> The regional
> signaling is performed via a new network entity called a
> Gateway Foreign
> Agent and introduces a layer of hierarchy in the foreign
> domain. Regional
> registrations reduce the number of signaling messages to the
> home network,
> and reduce the signaling delay when a mobile node moves from
> one foreign
> agent to another, within the same visited domain. This document is an
> optional extension to the Mobile IP protocol."
>
>
> "Introduction
>
> This document is an optional extension to the Mobile IP protocol, and
> proposes a means for mobile nodes to register locally within
> a visited
> domain. By registering locally, the number of signaling
> messages to the
> home network are keept to a minimum, and the signaling delay
> is reduced.
>
> In Mobile IP, as specified in RFC 3220 [9], a mobile node
> registers with
> its home agent each time it changes care-of address. If the distance

same comment as above!!!!
 
> between the visited network and the home network of the
> mobile node is
> large, the signaling delay for these registrations may be
> long. We propose
> a solution for performing registrations locally in the
> visited domain:
> regional registrations. The regional registration design
> introduces new
> Mobile IP messages - Regional Registrations, new Mobile IP
> extensions to
> convey information between the mobile node, foreign agent,
> and home agent,
> and a new network entity - Gateway Foreign Agent (GFA). Regional
> registrations reduce the number of signaling messages to the
> home network,
> and reduce the signaling delay when a mobile node moves from
> one foreign
> agent to another, within the same visited domain. This will
> both decrease
> the load on the home network, and speed up the process of
> handover within
> the visited domain. The introduction of a GFA also makes it
> possible to
> have different addressing realms in the home and in the
> visited networks."
>
>
> The last three paragraphs of the Introduction are unmodified.
>

------_=_NextPart_001_01C1FB52.110784C0-- From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 10:20:35 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20704 for ; Tue, 14 May 2002 10:20:34 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19217; Tue, 14 May 2002 07:18:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00426; Tue, 14 May 2002 07:17:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EEGWrP010171 for ; Tue, 14 May 2002 07:16:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EEGWiI010170 for mobile-ip-dist; Tue, 14 May 2002 07:16:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EEGSrP010163 for ; Tue, 14 May 2002 07:16:29 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11654 for ; Tue, 14 May 2002 07:16:31 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23344; Tue, 14 May 2002 08:16:30 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4EEGSc24504; Tue, 14 May 2002 16:16:28 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA22754; Tue, 14 May 2002 16:16:28 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4EEGST80374; Tue, 14 May 2002 16:16:28 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205141416.g4EEGST80374@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Vijay Devarapalli , keiichi@iij.ad.jp, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to process HAO In-reply-to: Your message of Tue, 14 May 2002 11:56:15 +0200. Date: Tue, 14 May 2002 16:16:28 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > There was a discussion between Erik Normark and myself. I think > we concluded on something similar to the following. (correct me > if missed something, Erik). > > HAO is processed if > > - if there is a BCE with CoA = IPv6 src and HoA = HAO content > - if there is a home registration BCE with HoA = HAO content > - if packet contains BU and satisfies the security policy > between MN and HA > - if packet contains AH or ESP header and satisfies the security > policy check between MN and HA. So my thinking is that conservative logic looks like this: if there is a BCE with CoA = IPv6 src and HoA = HAO content accept packet if there is NOT a home registration BCE with HoA = HAO content drop packet; send "binding missing" error verify that packet is IPsec protected e.g. by verifying first that AH or ESP is the next header and then later (as part of or after IPsec processing) verify that the HoA "matches" the IPsec SA. => first this match is part of IPsec processing (RFC 2401 5.2.1) and the proposal is to check the policy (i.e. the SPD) which is also part of IPsec processing. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 10:29:23 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21079 for ; Tue, 14 May 2002 10:29:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24566; Tue, 14 May 2002 07:27:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02234; Tue, 14 May 2002 07:27:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EEQfrP010280 for ; Tue, 14 May 2002 07:26:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EEQeoK010279 for mobile-ip-dist; Tue, 14 May 2002 07:26:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EEQbrP010272 for ; Tue, 14 May 2002 07:26:37 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02155 for ; Tue, 14 May 2002 07:26:41 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24085 for ; Tue, 14 May 2002 07:26:40 -0700 (PDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4EEQ8Hs024035; Tue, 14 May 2002 07:26:08 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA02633; Tue, 14 May 2002 10:26:08 -0400 (EDT) Date: Tue, 14 May 2002 10:26:08 -0400 From: "Madhavi W. Chandra" To: Henrik Levkowetz Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Feedback on NAT draft Message-ID: <20020514102608.C2517@cisco.com> References: <20020513154045.A1509@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from henrik@levkowetz.com on Mon, May 13, 2002 at 10:14:39PM +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Henrik, On Mon, May 13, 2002 at 10:14:39PM +0200, Henrik Levkowetz wrote: > Madhavi, > > Madhavi wrote: > > > > > > > > > > > > 1) Is the F bit in the UDP Reg Request Extension needed? > > > > > > Probably can let HA make the decision of IP-in-UDP tunneling. > > > > > > If HA determines that the RRQ did not traverse a NAT box, > > > > > > it still MAY accept the IP-in-UDP tunneling request based > > > > > > on administrative policy on the HA. Don't see the need > > > > > > for the MN to mandate this with the 'F' bit, since the HA > > > > > > is in the better position to decide. > > > > > > > > > > The function of the F bit is to have a mechanism to Force > > > > > UDP tunnelling to be used also when no NAT is detected. > > > > > It seems some people find this desireable, and I agree, > > > > > and it also turns out to have a function when handling > > > > > the FA R-bit case. > > > > > > > > We certainly agree that UDP tunneling may be useful even when no NAT > > > > is detected. I guess the difference is that we feel it can be done on > > > > the HA side...in fact, the HA is the one that should make this > > > > decision. Not sure why an MN should mandate to an HA what it should > > > > do. For example, maybe there is an adminstrative firewall policy on > > > > the HA that would require UDP tunneling irrespective of NAT presence. > > > > In this case, the HA would set up the UDP tunnel. > > > > > > > > Can you please elaborate on why you feel the MN is in a better > > > > position to force UDP tunneling on the HA? Also, what function are > > > > you refering to in the FA R-bit case? > > > > > > This is not an either - or thing. If the MN indicates that it is > > > able to do UDP tunnelling, then sure, you could do as you suggest, > > > let the HA indicate tunnelling for policy reasons also in the absence > > > of a NAT. Having the 'F' bit simply permits the MN to act similarly. > > > Do you have any particular reason why you don't want the MN to be > > > able to request this? > > > > The MN is indicating that it can do UDP tunneling with the > > presence of the UDP Tunnel Request Extension. The HA can decide > > whether to do UDP tunneling irrespective of NAT. There doesn't seem > > to be a role for the MN to force UDP tunneling...unless we are missing > > something. Hence, implementation can be simplified without 'F' bit. > > Correction: You do not find it useful. Other people have indicatet that > it would be useful, so I'd tend to keep it in for that reason. But there Yes, I do not find it useful. Otherwise, I would not have brought it up. Perhaps if you share the reasons and be a little more specific, I can find it useful too. Understand that I'm not adverse to it, but at present I don't see the need. And hence, it seems like unnecessary implementation. > is still the FA R-bit case, too. > > > > > > > The FA R-bit case, where the 'F' bit is needed, is the one described > > > in Section 4.10 of the -02 draft. > > > > Actually, taken from Section 4.4: > > > > "If a mobile node is registering through a foreign agent but using a > > co-located care-of address, and the agent advertisement from the > > foreign agent had the 'U' bit set, the mobile node SHOULD set both > > the 'R' flag and the 'F' flag in its UDP Tunnel Request Extension, in > > order to make the HA use MIP UDP tunnelling." > > > > I'm not sure I understand...if the RRQ went through a NAT box, the HA > > would still be able to detect this and set up the UDP tunnel. > > If it didn't go through a NAT box, why does MN want to force UDP > > tunneling just because it is FA 'R' bit case? Perhaps I am missing your > > point. Maybe if you parsed the following sentence for me (taken from > > Section 4.6), it would help: > > > > If the 'R' flag is set but the 'F' flag > > is not set, the home agent MUST NOT assent to UDP tunnelling, even if > > there is an address mismatch. > > > > I'm not seeing the needed 'F' bit functionality in the FA 'R' bit > > case. > > Madhavi, I think it would clear up your questions if you were to read > section 4.10, which I referred to earlier. It really does answer the > questions you ask here. But in short: In this case, the HA cannot > detect the presence of a NAT in the usual manner, so it needs to be > forced by the mobile node. Just because I still have doubts is not a valid reason for you to assume that I didn't read section 4.10. As I indicated earlier, we have much interest in your draft and read it quite carefully. I understand that the HA cannot detect the presence of the NAT in the usual way with the FA 'R' bit case...which is why you have carefully explained the use of the 'U' bit and proper inclusion of the UDP Tunnel Request Extension. But, how does the 'F' bit help here? The fact that the UDP Tunnel Request Extension is present, with the 'R' bit set indicates to the HA that the FA knows it is behind a NAT (since it advertised the 'U' bit...which is why the MN included the UDP Tunnel Request Extension). The HA will notice the difference in IP SRC, and set up the UDP tunnel. Did I misunderstand the behavior? Thanks, Madhavi > ...... > > > > > > > > Sorry for not being clear. We were refering to 'heavy signaling' > > > > from the HA's perspective. If an HA is supporting a large number of > > > > MNs, and every MN is re-registering every 20 seconds, this can easily > > > > overload the HA. Every incoming registration will require processing > > > > on the HA. > > > > > > Ok, I see what you are concerned about. But in view of the hijacking > > > and DoS scenarios which Francis Dupont brought up recently, I think > > > it is still very prudent to have a short time between registrations. > > > > But, wouldn't a man-in-the-middle still be able to do a DoS attack by > > intercepting each of the re-registrations? It can still blackhole the > > MNs traffic, can't it? > > > > I think the requirement of RRQ keepalives should be relaxed from a > > SHOULD, since it is processing intensive on the HA. > > Well, we obviously disagree on this, then. I believe that it is clearly > desireable to keep this as a SHOULD, both for security reasons, and for > the performance reasons discussed in sections 5.1 and 5.2 of the draft. > > Regards, > Henrik From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 11:01:28 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22402 for ; Tue, 14 May 2002 11:01:27 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26474; Tue, 14 May 2002 09:01:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12029; Tue, 14 May 2002 08:00:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EExgrP010444 for ; Tue, 14 May 2002 07:59:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EExgHe010443 for mobile-ip-dist; Tue, 14 May 2002 07:59:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EExdrP010436 for ; Tue, 14 May 2002 07:59:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26012 for ; Tue, 14 May 2002 07:59:42 -0700 (PDT) From: arvind.sevalkar@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21155 for ; Tue, 14 May 2002 08:59:40 -0600 (MDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002051420333060:12 ; Tue, 14 May 2002 20:33:30 +0530 Subject: [mobile-ip] Sending Binding Acknowledgement with routing header. To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Tue, 14 May 2002 20:29:41 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/14/2002 08:30:05 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/14/2002 08:33:30 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/14/2002 08:33:33 PM, Serialize complete at 05/14/2002 08:33:33 PM Message-ID: X-Priority: 3 (Normal) Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi All In "Mobile IP Draft-17", in section 6.1.8 Binding Acknowledgement (BA) Message: it is mentioned that No routing header are added to the message, and in section 9.4.4 Sending Binding Acknowledgements: it is mentioned that the packet, in which the binding acknowledgement is returned, is to be sent to the mobile node at any address other than the mobile nodes home address, it must be sent using a routing header (even if the binding was rejected ). this creates little confusion ........isn't it ? regards Arvind From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 11:43:09 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23978 for ; Tue, 14 May 2002 11:43:08 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11166; Tue, 14 May 2002 08:40:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12804; Tue, 14 May 2002 08:40:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EFdqrP010551 for ; Tue, 14 May 2002 08:39:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EFdp2R010550 for mobile-ip-dist; Tue, 14 May 2002 08:39:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EFdmrP010543 for ; Tue, 14 May 2002 08:39:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24646 for ; Tue, 14 May 2002 08:39:52 -0700 (PDT) Received: from chardonnay.levkowetz.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 JAA21258 for ; Tue, 14 May 2002 09:40:18 -0600 (MDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.02) id GW3Y6B-0001P8-00; Tue, 14 May 2002 17:39:47 +0200 From: "Henrik Levkowetz" To: "Madhavi W. Chandra" Cc: Subject: RE: [mobile-ip] Feedback on NAT draft Date: Tue, 14 May 2002 17:39:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020514102608.C2517@cisco.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.50.4910.0300 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Madhavi, You wrote: ...... > > > The MN is indicating that it can do UDP tunneling with the > > > presence of the UDP Tunnel Request Extension. The HA can decide > > > whether to do UDP tunneling irrespective of NAT. There doesn't seem > > > to be a role for the MN to force UDP tunneling...unless we are missing > > > something. Hence, implementation can be simplified without 'F' bit. > > > > Correction: You do not find it useful. Other people have indicatet that > > it would be useful, so I'd tend to keep it in for that reason. But there > > Yes, I do not find it useful. Otherwise, I would not have brought it up. > Perhaps if you share the reasons and be a little more specific, I can find it > useful too. Understand that I'm not adverse to it, but at > present I don't see the need. And hence, it seems like unnecessary > implementation. Please see Sami's reply earlier today on this one. > > > > Madhavi, I think it would clear up your questions if you were to read > > section 4.10, which I referred to earlier. It really does answer the > > questions you ask here. But in short: In this case, the HA cannot > > detect the presence of a NAT in the usual manner, so it needs to be > > forced by the mobile node. > > Just because I still have doubts is not a valid reason for you to assume > that I didn't read section 4.10. As I indicated earlier, we have much > interest in your draft and read it quite carefully. Fair enough; sorry. I mistakenly got that impression when you only quoted 4.4. > > I understand that the HA cannot detect the presence of the NAT in the usual > way with the FA 'R' bit case...which is why you have carefully explained the > use of the 'U' bit and proper inclusion of the UDP Tunnel Request Extension. > > But, how does the 'F' bit help here? The fact that the UDP Tunnel Request > Extension is present, with the 'R' bit set indicates to the HA that the > FA knows it is behind a NAT (since it advertised the 'U' bit...which is > why the MN included the UDP Tunnel Request Extension). The HA will notice > the difference in IP SRC, and set up the UDP tunnel. Did I misunderstand > the behavior? Madhavi, you are right! and I apoligize. The requirements that the MN should not use the UDP Tunnel Request extension when registering through an FA with a co-located address unless the FA has the 'U' bit set, and that the MN should set the 'R' bit in the extension in that case does indeed provide enough information for the HA. Setting the 'F' bit does not add any information, and supposing it is decided to still have the 'F' bit available, it should be set in this case just for consistency - it is indeed not needed in this case. ( ... :-) I originally did not have the restriction that the MN must not add the extension in the non 'U' bit case, which led to the current text.) Returning for a moment to another issue on which we know we disagree, I would mention in the case of the HA processing load that even if we assume that handling a mip re-registration requires many (10? 50?) times the processing power of forwarding a mip packet, you will have keepalive re-registrations taking less power than would be consumed by the same MN running 14400 bit/s of traffic. And I believe the box should be sized so that it will be able to handle a much larger traffic load than that, per user - so maybe the keepalive signalling, which will only occur when you have no other traffic, is not such a heavy load after all? Regards, Henrik From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 12:08:59 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24796 for ; Tue, 14 May 2002 12:08:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29035; Tue, 14 May 2002 09:06:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24310; Tue, 14 May 2002 09:06:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EG5ZrP010617 for ; Tue, 14 May 2002 09:05:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EG5ZJj010616 for mobile-ip-dist; Tue, 14 May 2002 09:05:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EG5WrP010609 for ; Tue, 14 May 2002 09:05:33 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA21500 for ; Tue, 14 May 2002 12:05:32 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g4EG5Tqp013586 for ; Tue, 14 May 2002 12:05:29 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g4EG5TVY013585 for mobile-ip@sunroof.eng.sun.com; Tue, 14 May 2002 12:05:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EEetrP010344 for ; Tue, 14 May 2002 07:40:55 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07416 for ; Tue, 14 May 2002 07:40:58 -0700 (PDT) Received: from satanas.hds.utc.fr (satanas.hds.utc.fr [195.83.157.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11796 for ; Tue, 14 May 2002 07:40:58 -0700 (PDT) Received: by satanas.hds.utc.fr (Postfix, from userid 1100) id 3A9085C5F; Tue, 14 May 2002 16:41:22 +0200 (MEST) To: "Palumbo, Jeffrey CECOM RDEC STCD" Subject: Re: [mobile-ip] MIPv6 Implementations Message-ID: <1021387281.3ce12211de44d@www.hds.utc.fr> Date: Tue, 14 May 2002 16:41:21 +0200 (MEST) From: Imed Romdhani Cc: "'mobile-ip@sunroof.eng.sun.com'" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.5 X-Originating-IP: 212.234.3.190 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Dear jeff, You can try the LIVSIX stack of Motorola Labs (Centre de Recherche de Motorola, Paris). LIVSIX is an IPv6 stack with interesting features designed entirely from scratch, to be used in IPv6 mobility environments. http://www.nal.motlabs.com/livsix/ Best Regards Imed --------------------------------------- Imed Romdhani PhD Student Centre de Recherche de Motorola. Paris E-mail: Imed.Romdhani@utc.fr Phone: (+33) 06 22 86 44 39 --------------------------------------- > Hello- > > I am looking to get some different implementations of Mobile IPv6 for > testing/evaluation. The only flavors I am finding that are relatively > current is the MSR (win2k/XP) and the Mobile IP for Linux (MIPL) > releases. > > Any additional direction appreciated. > > -jeff > From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 15:43:34 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02855 for ; Tue, 14 May 2002 15:43:33 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10868; Tue, 14 May 2002 12:41:12 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12424; Tue, 14 May 2002 12:41:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EJdVrP011292 for ; Tue, 14 May 2002 12:39:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EJdVOe011291 for mobile-ip-dist; Tue, 14 May 2002 12:39:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EJdOrP011284 for ; Tue, 14 May 2002 12:39:24 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24039 for ; Tue, 14 May 2002 12:39:28 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16005 for ; Tue, 14 May 2002 13:39:28 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4EJchc07178; Tue, 14 May 2002 21:38:43 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA28253; Tue, 14 May 2002 21:38:43 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4EJcgT81830; Tue, 14 May 2002 21:38:42 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205141938.g4EJcgT81830@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Sami Vaarala" cc: =?iso-8859-1?Q?Hans_Sj=F6strand?= , "Henrik Levkowetz" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security In-reply-to: Your message of Tue, 14 May 2002 13:25:45 +0300. Date: Tue, 14 May 2002 21:38:42 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Here is a new try on the security considerations section. We tried to partition the discussion to a more manageable form. Francis, does this seem reasonable to you? => this is fine. Perhaps a bit long but IMHO this is a good property for security considerations. Any other issues to be discussed? => no. MIP is not the only protocol which becomes vulnerable when one adds NAT traversal to it, even if the base protocol is itself very secure... So this is only another hard issue from NATs. Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 16:29:31 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05217 for ; Tue, 14 May 2002 16:29:30 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA14183; Tue, 14 May 2002 14:29:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03038; Tue, 14 May 2002 13:28:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EKRwrP011385 for ; Tue, 14 May 2002 13:27:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EKRwbP011384 for mobile-ip-dist; Tue, 14 May 2002 13:27:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EKRsrP011377 for ; Tue, 14 May 2002 13:27:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02692 for ; Tue, 14 May 2002 13:27:59 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA25806 for ; Tue, 14 May 2002 14:27:58 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g4EKRvx28047 for ; Tue, 14 May 2002 15:27:58 -0500 (CDT) Message-ID: <3CE17363.9050201@alcatel.com> Date: Tue, 14 May 2002 15:28:19 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt security References: <200204261202.g3QC2TT77081@givry.rennes.enst-bretagne.fr> <20020426101122.E13617@cisco.com> <3CC967F2.BCEBA47E@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit and the draft's correct name is draft-ietf-mobileip-nat-traversal-02.txt of this thread, right? not draft-levkowetz-mobileip-nat-tunnel-00.txt which does not exist. Milind Kulkarni wrote: >Francis, > >I am sure the authors will correct you as well, but the latest >version for this draft is -02.txt (and not 00). Though even in >that draft, the scheme is susceptible to man-in-the-middle attack. > >Milind > >"Madhavi W. Chandra" wrote: > >>Francis, >> >>Excellent point which we were going to raise as well. >>It is the similar situation as in the Regional Registration >>draft...the tunnel end point is set up to an CoA, that is >>not part of protected data. (In the Regional Registration >>case, when the GFA IPext is protected by FHAE, this is not >>an issue.) >> >>Regarding the NAT draft, the basic need is for the HA to >>somehow verify that the IP SRC address is in fact from a >>NAT, and not some man-in-the-middle. However, I'm not sure >>that given the current nature of NAT, if this is possible. >>I was looking at the STUN draft in midcomm WG as a possible hook, >>but I think this approach is also susceptible to man-in-the-middle. >> >>It seems that establishing a MIP tunnel as above opens up greater >>risk for MN traffic hijacking. However, as I'm not a security >>expert, I don't know for sure. Perhaps you and others can shed >>some light on this. >> >>Since NAT/MIP interaction is a real need in MIP deployments, hopefully >>we can ensure that we are not opening up any further security >>risks than base MIP. >> >>Regards, >>Madhavi >> >>On Fri, Apr 26, 2002 at 02:02:29PM +0200, Francis Dupont wrote: >> >>>I've just done a comment about NAT/NATPT traversal security >>>at IPCN and I believe it is useful to discuss about the raised >>>issue in this list. >>> >>>The basic problem is the HA has to trust the CoA found from the >>>source address in the IP header which can be forged by anyone >>>in the path (note this is different from my "trust the CoA given >>>by the MN argument" in a previous mail). >>> >>>I don't know if this is enough to restrict/reject the NAT traversal >>>proposal but at least the security section should *not* stay empty! >>> >>>Regards >>> >>>Francis.Dupont@enst-bretagne.fr >>> -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 16:31:24 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05418 for ; Tue, 14 May 2002 16:31:23 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14596; Tue, 14 May 2002 13:29:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03177; Tue, 14 May 2002 13:29:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EKSVrP011395 for ; Tue, 14 May 2002 13:28:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4EKSVdd011394 for mobile-ip-dist; Tue, 14 May 2002 13:28:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4EKSQrP011387 for ; Tue, 14 May 2002 13:28:27 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10863 for ; Tue, 14 May 2002 13:28:31 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08184 for ; Tue, 14 May 2002 14:28:31 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Tue, 14 May 2002 16:25:07 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Tue, 14 May 2002 16:24:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Several folks raised the issue of to what extent introducing regional registration entities in the visited network violates principles of the Internet architecture, specifically with regard to the introduction of single points of failure in the communication path of visiting nodes. I've excerpted the relevant text from rfc 1958 on the architectural principle which is at issue. "The end-to-end argument is discussed in depth in [Saltzer]. The basic argument is that, as a first principle, certain required end- to-end functions can only be performed correctly by the end-systems themselves. A specific case is that any network, however carefully designed, will be subject to failures of transmission at some statistically determined rate. The best way to cope with this is to accept it, and give responsibility for the integrity of communication to the end systems. Another specific case is end-to-end security. To quote from [Saltzer], "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.") This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). An immediate consequence of this is that datagrams are better than classical virtual circuits. The network's job is to transmit datagrams as efficiently and flexibly as possible." draft-iab-arch-changes-00.txt provides a discussion of this issue of fate-sharing in middleboxes and asserts that the principle is preserved in the case that the middlebox is a partner in the communication when the failure can be detected and dealt with.: "The idea of fate-sharing survives this recursion, but requires that all application state created in middleboxes must be capable of re- creation after failure. Additionally, to support this requirement, where a function cannot be fulfilled completely, reliably and securely by two endpoints of a conversation, the necessary middleboxes to fulfil the function should be explicit partners in explicit communication with at least one endpoint (or, by recursion of the same principle, with an intermediate middlebox). In other words, middleboxes should not be invisible, because their failures need to be detected and dealt with by their communication partners." As currently specified it's not immediately obvious how the regional registration agents are compatible with the above guidelines. It's conceivable that they can be made so, and perhaps it's immediately obvious to others how they are so. This issue is not insurmountable but the functionality does need to be specified in a way that preserves the fate sharing principle and allows for one party in the communication to detect and deal with a failure of one of the new registration entities. From owner-mobile-ip@sunroof.eng.sun.com Tue May 14 23:07:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19802 for ; Tue, 14 May 2002 23:07:07 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08007; Tue, 14 May 2002 21:06:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA14579; Tue, 14 May 2002 20:06:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F35YrP012293 for ; Tue, 14 May 2002 20:05:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F35YdN012292 for mobile-ip-dist; Tue, 14 May 2002 20:05:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F35VrP012285 for ; Tue, 14 May 2002 20:05:31 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA17273 for ; Tue, 14 May 2002 20:05:35 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08175 for ; Tue, 14 May 2002 20:05:34 -0700 (PDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id MAA14770; Wed, 15 May 2002 12:05:33 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA16923; Wed, 15 May 2002 12:05:32 +0900 (JST) Date: Wed, 15 May 2002 12:05:18 +0900 (JST) Message-Id: <20020515.120518.113274767.keiichi@iij.ad.jp> To: arvind.sevalkar@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sending Binding Acknowledgement with routing header. From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: References: X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, From: arvind.sevalkar@lntinfotech.com > In "Mobile IP Draft-17", in section 6.1.8 Binding Acknowledgement (BA) > Message: it is > mentioned that No routing header are added to the message, and in > section 9.4.4 Sending Binding Acknowledgements: it is mentioned that the > packet, in which the binding acknowledgement is returned, is to be sent to > the mobile node at any address other than the mobile nodes home address, it > must be sent using a routing header (even if the binding was rejected ). > > this creates little confusion ........isn't it ? I don't understand the reason why the above change (not inserting a routing header to a BA). Could anybody explain it? Since all the packet should be sent with a routing header if the sending node has a valid bindinc cache, a binding ack should have a routing header also. The MN thinks that the sending node doesn't have a binging cache when it receives a packet without a routing header. As a result, the MN will send a binding update.. If the MN receives a binding ack without routing header, it sends a bu again even if the binding ack indicates that the binding update has succeeded. Otherwise, we must write a special code to treat a binding ack when checking the route optimization status when receiving packets. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 00:24:03 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23274 for ; Wed, 15 May 2002 00:24:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA02579; Tue, 14 May 2002 22:23:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA01880; Tue, 14 May 2002 21:23:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F4MerP012447 for ; Tue, 14 May 2002 21:22:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F4MeSZ012446 for mobile-ip-dist; Tue, 14 May 2002 21:22:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F4MbrP012439 for ; Tue, 14 May 2002 21:22:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA29383 for ; Tue, 14 May 2002 21:22:40 -0700 (PDT) From: arvind.sevalkar@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24203 for ; Tue, 14 May 2002 22:23:06 -0600 (MDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002051509562874:240 ; Wed, 15 May 2002 09:56:28 +0530 Subject: Re: [mobile-ip] Sending Binding Acknowledgement with routing header. To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Wed, 15 May 2002 09:52:39 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/15/2002 09:53:02 AM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/15/2002 09:56:28 AM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/15/2002 09:56:31 AM, Serialize complete at 05/15/2002 09:56:31 AM Message-ID: X-Priority: 3 (Normal) Content-type: text/plain; charset=iso-2022-jp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Keiichi SHIMA / $BEg7D0l(B To: arvind.sevalkar@lntinfotech.com Sent by: cc: mobile-ip@sunroof.eng.sun.com owner-mobile-ip@sunroof.e Subject: Re: [mobile-ip] Sending Binding ng.sun.com Acknowledgement with routing header. 05/15/2002 08:35 AM Hi, From: arvind.sevalkar@lntinfotech.com > In "Mobile IP Draft-17", in section 6.1.8 Binding Acknowledgement (BA) > Message: it is > mentioned that No routing header are added to the message, and in > section 9.4.4 Sending Binding Acknowledgements: it is mentioned that the > packet, in which the binding acknowledgement is returned, is to be sent to > the mobile node at any address other than the mobile nodes home address, it > must be sent using a routing header (even if the binding was rejected ). > > this creates little confusion ........isn't it ? I don't understand the reason why the above change (not inserting a routing header to a BA). Could anybody explain it? Since all the packet should be sent with a routing header if the sending node has a valid bindinc cache, a binding ack should have a routing header also. The MN thinks that the sending node doesn't have a binging cache when it receives a packet without a routing header. As a result, the MN will send a binding update.. If the MN receives a binding ack without routing header, it sends a bu again even if the binding ack indicates that the binding update has succeeded. Otherwise, we must write a special code to treat a binding ack when checking the route optimization status when receiving packets. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project Hi I think in draft nowhere it is mentioned that MN will send BU when it receives packet without routing header. MN will send BU when it receives tunneled packet, right ? And as BA is send to the source address of the BU message and source address of the BU message is the COA, so for COA there will be no any binding exist in the Binding Cache as key for searching Binding Cache is the Home address, so CN will not add routing header..... but the question is in section 9.4.4 Sending Binding Acknowledgements : it says routing header must be added..... Arvind From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 00:27:44 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23436 for ; Wed, 15 May 2002 00:27:43 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04182; Tue, 14 May 2002 22:27:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03319; Tue, 14 May 2002 21:27:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F4QhrP012499 for ; Tue, 14 May 2002 21:26:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F4QhBh012498 for mobile-ip-dist; Tue, 14 May 2002 21:26:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F4QdrP012488 for ; Tue, 14 May 2002 21:26:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03179 for ; Tue, 14 May 2002 21:26:42 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA03787 for ; Tue, 14 May 2002 22:26:41 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id NAA17517; Wed, 15 May 2002 13:26:40 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id NAA04835; Wed, 15 May 2002 13:26:39 +0900 (JST) Date: Wed, 15 May 2002 13:26:24 +0900 (JST) Message-Id: <20020515.132624.11825225.keiichi@iij.ad.jp> To: jari.arkko@piuha.net Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Unresolved issue #22: SHOULD or MUST for CN RO? From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3CD4FE4E.2030104@piuha.net> References: <3CD4FE4E.2030104@piuha.net> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, From: Jari Arkko > Background: Draft 17 will have a section that describes the requirements > for correspondent nodes. The initial attempt at this text is the > following: > > Since any IPv6 node may at any time be a correspondent node of a > mobile node, either sending a packet to a mobile node or receiving a > packet from a mobile node, the following requirements apply to ALL > IPv6 nodes (whether host or router, whether mobile or stationary): > > - Every IPv6 node MUST be able to process a Home Address option > received in any IPv6 packet. > > - Every IPv6 node SHOULD be able to participate in a return > routability procedure, process Binding Update messages, and to > return a Binding Acknowledgement option if the Acknowledge (A) > bit is set in the received Binding Update. > > - Every IPv6 node SHOULD be able to maintain a Binding Cache of the > bindings received in accepted Binding Updates. As many other people reply, I thinks this topic should be discussed in the ipng wg too. In my personal opinion, SHOULD is OK. If many IPv6 implementors think that MIP6 is useful, want to use it, want to make it effective, they eventually support a RR. A RR is a key function of MIP6, but not essential. We can deploy MIP6 even if a RR is not mandatory. Couldn't we leave the decision to the implementors? # I may be too optimistic... Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 00:27:59 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23470 for ; Wed, 15 May 2002 00:27:59 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA25688; Tue, 14 May 2002 22:27:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03209; Tue, 14 May 2002 21:26:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F4QDrP012479 for ; Tue, 14 May 2002 21:26:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F4QD3d012478 for mobile-ip-dist; Tue, 14 May 2002 21:26:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F4QArP012471 for ; Tue, 14 May 2002 21:26:10 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28266 for ; Tue, 14 May 2002 21:26:13 -0700 (PDT) Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA03613 for ; Tue, 14 May 2002 22:26:13 -0600 (MDT) Received: from unknown (HELO EmadQ) (emadaq@194.165.132.86 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 May 2002 04:26:11 -0000 Reply-To: From: "Emad Qaddoura" To: "'Phil Roberts'" , Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Wed, 15 May 2002 07:25:04 +0200 Message-ID: <000001c1fbd0$e15fb600$5701a8c0@EmadQ> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Phil, How is the GFA is different from the HA and FA from the stand point of single point of failure or other reliability issues? I believe this can be implementation dependent, i.e. someone can implement GFA as a cluster. I believe the regional registration draft has some complexity into it, and without some a bake-off like tests, it should remain at the experimental level. Thx. > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] On Behalf Of Phil Roberts > Sent: Tuesday, May 14, 2002 10:25 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #4 > > Several folks raised the issue of to what extent introducing regional > registration entities in the visited network violates principles of the > Internet architecture, specifically with regard to the introduction of > single points of failure in the communication path of visiting nodes. > > I've excerpted the relevant text from rfc 1958 on the architectural > principle which is at issue. > > "The end-to-end argument is discussed in depth in [Saltzer]. The > basic argument is that, as a first principle, certain required end- > to-end functions can only be performed correctly by the end-systems > themselves. A specific case is that any network, however carefully > designed, will be subject to failures of transmission at some > statistically determined rate. The best way to cope with this is to > accept it, and give responsibility for the integrity of communication > to the end systems. Another specific case is end-to-end security. > > To quote from [Saltzer], "The function in question can completely and > correctly be implemented only with the knowledge and help of the > application standing at the endpoints of the communication system. > Therefore, providing that questioned function as a feature of the > communication system itself is not possible. (Sometimes an incomplete > version of the function provided by the communication system may be > useful as a performance enhancement.") > > This principle has important consequences if we require applications > to survive partial network failures. An end-to-end protocol design > should not rely on the maintenance of state (i.e. information about > the state of the end-to-end communication) inside the network. Such > state should be maintained only in the endpoints, in such a way that > the state can only be destroyed when the endpoint itself breaks > (known as fate-sharing). An immediate consequence of this is that > datagrams are better than classical virtual circuits. The network's > job is to transmit datagrams as efficiently and flexibly as possible." > > draft-iab-arch-changes-00.txt provides a discussion of this issue of > fate-sharing in middleboxes and asserts that the principle is preserved in > the case that the middlebox is a partner in the communication when the > failure can be detected and dealt with.: > > "The idea of fate-sharing survives this recursion, but requires that > all application state created in middleboxes must be capable of re- > creation after failure. Additionally, to support this requirement, > where a function cannot be fulfilled completely, reliably and > securely by two endpoints of a conversation, the necessary > middleboxes to fulfil the function should be explicit partners in > explicit communication with at least one endpoint (or, by recursion > of the same principle, with an intermediate middlebox). In other > words, middleboxes should not be invisible, because their failures > need to be detected and dealt with by their communication partners." > > > As currently specified it's not immediately obvious how the regional > registration agents are compatible with the above guidelines. It's > conceivable that they can be made so, and perhaps it's immediately obvious > to others how they are so. > > This issue is not insurmountable but the functionality does need to be > specified in a way that preserves the fate sharing principle and allows > for > one party in the communication to detect and deal with a failure of one of > the new registration entities. From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 00:36:45 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23792 for ; Wed, 15 May 2002 00:36:45 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA06898; Tue, 14 May 2002 22:36:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA05142; Tue, 14 May 2002 21:36:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F4ZKrP012548 for ; Tue, 14 May 2002 21:35:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F4ZKZq012547 for mobile-ip-dist; Tue, 14 May 2002 21:35:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F4ZHrP012540 for ; Tue, 14 May 2002 21:35:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA00730 for ; Tue, 14 May 2002 21:35:20 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA06492 for ; Tue, 14 May 2002 21:35:20 -0700 (PDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id NAA17833 for ; Wed, 15 May 2002 13:35:19 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id NAA07254; Wed, 15 May 2002 13:35:18 +0900 (JST) Date: Wed, 15 May 2002 13:35:03 +0900 (JST) Message-Id: <20020515.133503.03003810.keiichi@iij.ad.jp> To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sending Binding Acknowledgement with routing header. From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: References: X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: From: arvind.sevalkar@lntinfotech.com Content-Transfer-Encoding: 7bit > I think in draft nowhere it is mentioned that MN will send BU when it > receives packet without routing header. MN will send BU when it receives > tunneled packet, right ? > And as BA is send to the source address of the BU message and source > address of the BU message is the COA, so for COA there will be no any > binding exist in the Binding Cache as key for searching Binding Cache is > the Home address, so CN will not add routing header..... > but the question is in section 9.4.4 Sending Binding Acknowledgements : it > says routing header must be added..... I may have missed something. I will check the draft and my code. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 03:22:15 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20523 for ; Wed, 15 May 2002 03:22:15 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06005; Wed, 15 May 2002 00:20:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09309; Wed, 15 May 2002 00:20:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F7JLrP012828 for ; Wed, 15 May 2002 00:19:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F7JL3D012827 for mobile-ip-dist; Wed, 15 May 2002 00:19:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F7JHrP012820 for ; Wed, 15 May 2002 00:19:17 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01748 for ; Wed, 15 May 2002 00:19:19 -0700 (PDT) Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA26415 for ; Wed, 15 May 2002 01:19:13 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-02.txt security Date: Wed, 15 May 2002 10:19:11 +0300 Message-ID: Thread-Topic: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-02.txt security Thread-Index: AcH7hhLi185cMsHxQxK0f9+BZ+MCawAWqpfg From: "Sami Vaarala" To: "Behcet Sarikaya" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4F7JIrP012821 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi, You're right, this is about -02. -Sami > -----Original Message----- > From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] > Sent: 14 May 2002 23:28 > To: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt > security > > and the draft's correct name is > draft-ietf-mobileip-nat-traversal-02.txt > > of this thread, right? not draft-levkowetz-mobileip-nat-tunnel-00.txt > which does not exist. > > Milind Kulkarni wrote: > > >Francis, > > > >I am sure the authors will correct you as well, but the latest > >version for this draft is -02.txt (and not 00). Though even in > >that draft, the scheme is susceptible to man-in-the-middle attack. > > > >Milind > > > >"Madhavi W. Chandra" wrote: > > > >>Francis, > >> > >>Excellent point which we were going to raise as well. > >>It is the similar situation as in the Regional Registration > >>draft...the tunnel end point is set up to an CoA, that is > >>not part of protected data. (In the Regional Registration > >>case, when the GFA IPext is protected by FHAE, this is not > >>an issue.) > >> > >>Regarding the NAT draft, the basic need is for the HA to > >>somehow verify that the IP SRC address is in fact from a > >>NAT, and not some man-in-the-middle. However, I'm not sure > >>that given the current nature of NAT, if this is possible. > >>I was looking at the STUN draft in midcomm WG as a possible hook, > >>but I think this approach is also susceptible to man-in-the-middle. > >> > >>It seems that establishing a MIP tunnel as above opens up greater > >>risk for MN traffic hijacking. However, as I'm not a security > >>expert, I don't know for sure. Perhaps you and others can shed > >>some light on this. > >> > >>Since NAT/MIP interaction is a real need in MIP deployments, hopefully > >>we can ensure that we are not opening up any further security > >>risks than base MIP. > >> > >>Regards, > >>Madhavi > >> > >>On Fri, Apr 26, 2002 at 02:02:29PM +0200, Francis Dupont wrote: > >> > >>>I've just done a comment about NAT/NATPT traversal security > >>>at IPCN and I believe it is useful to discuss about the raised > >>>issue in this list. > >>> > >>>The basic problem is the HA has to trust the CoA found from the > >>>source address in the IP header which can be forged by anyone > >>>in the path (note this is different from my "trust the CoA given > >>>by the MN argument" in a previous mail). > >>> > >>>I don't know if this is enough to restrict/reject the NAT traversal > >>>proposal but at least the security section should *not* stay empty! > >>> > >>>Regards > >>> > >>>Francis.Dupont@enst-bretagne.fr > >>> > > -- > Behcet > > From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 03:25:12 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20559 for ; Wed, 15 May 2002 03:25:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA10224; Wed, 15 May 2002 00:23:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA09920; Wed, 15 May 2002 00:23:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F7MarP012851 for ; Wed, 15 May 2002 00:22:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F7MaMl012850 for mobile-ip-dist; Wed, 15 May 2002 00:22:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F7MXrP012843 for ; Wed, 15 May 2002 00:22:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA02054 for ; Wed, 15 May 2002 00:22:35 -0700 (PDT) Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21429 for ; Wed, 15 May 2002 01:23:02 -0600 (MDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] draft-ietf-mobileip-nat-traversal-02.txt security Date: Wed, 15 May 2002 10:22:32 +0300 Message-ID: Thread-Topic: [mobile-ip] draft-ietf-mobileip-nat-traversal-02.txt security Thread-Index: AcH7hhLi185cMsHxQxK0f9+BZ+MCawAWqpfgAAAZeKA= From: "Sami Vaarala" To: "Sami Vaarala" , "Behcet Sarikaya" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4F7MXrP012844 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit .. and what's more, about a different draft: draft-ietf-mobileip-nat-traversal-02.txt ;) -Sami > -----Original Message----- > From: Sami Vaarala > Sent: 15 May 2002 10:19 > To: Behcet Sarikaya; mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-02.txt > security > > Hi, > > You're right, this is about -02. > > -Sami > > > -----Original Message----- > > From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] > > Sent: 14 May 2002 23:28 > > To: mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] draft-levkowetz-mobileip-nat-tunnel-00.txt > > security > > > > and the draft's correct name is > > draft-ietf-mobileip-nat-traversal-02.txt > > > > of this thread, right? not draft-levkowetz-mobileip-nat-tunnel-00.txt > > which does not exist. > > > > Milind Kulkarni wrote: > > > > >Francis, > > > > > >I am sure the authors will correct you as well, but the latest > > >version for this draft is -02.txt (and not 00). Though even in > > >that draft, the scheme is susceptible to man-in-the-middle attack. > > > > > >Milind > > > > > >"Madhavi W. Chandra" wrote: > > > > > >>Francis, > > >> > > >>Excellent point which we were going to raise as well. > > >>It is the similar situation as in the Regional Registration > > >>draft...the tunnel end point is set up to an CoA, that is > > >>not part of protected data. (In the Regional Registration > > >>case, when the GFA IPext is protected by FHAE, this is not > > >>an issue.) > > >> > > >>Regarding the NAT draft, the basic need is for the HA to > > >>somehow verify that the IP SRC address is in fact from a > > >>NAT, and not some man-in-the-middle. However, I'm not sure > > >>that given the current nature of NAT, if this is possible. > > >>I was looking at the STUN draft in midcomm WG as a possible hook, > > >>but I think this approach is also susceptible to man-in-the-middle. > > >> > > >>It seems that establishing a MIP tunnel as above opens up greater > > >>risk for MN traffic hijacking. However, as I'm not a security > > >>expert, I don't know for sure. Perhaps you and others can shed > > >>some light on this. > > >> > > >>Since NAT/MIP interaction is a real need in MIP deployments, > hopefully > > >>we can ensure that we are not opening up any further security > > >>risks than base MIP. > > >> > > >>Regards, > > >>Madhavi > > >> > > >>On Fri, Apr 26, 2002 at 02:02:29PM +0200, Francis Dupont wrote: > > >> > > >>>I've just done a comment about NAT/NATPT traversal security > > >>>at IPCN and I believe it is useful to discuss about the raised > > >>>issue in this list. > > >>> > > >>>The basic problem is the HA has to trust the CoA found from the > > >>>source address in the IP header which can be forged by anyone > > >>>in the path (note this is different from my "trust the CoA given > > >>>by the MN argument" in a previous mail). > > >>> > > >>>I don't know if this is enough to restrict/reject the NAT traversal > > >>>proposal but at least the security section should *not* stay empty! > > >>> > > >>>Regards > > >>> > > >>>Francis.Dupont@enst-bretagne.fr > > >>> > > > > -- > > Behcet > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 03:59:55 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21209 for ; Wed, 15 May 2002 03:59:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24465; Wed, 15 May 2002 00:58:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17712; Wed, 15 May 2002 00:57:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F7uArP012951 for ; Wed, 15 May 2002 00:56:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F7uANw012950 for mobile-ip-dist; Wed, 15 May 2002 00:56:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F7u7rP012943 for ; Wed, 15 May 2002 00:56:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA07014 for ; Wed, 15 May 2002 00:56:09 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA09341 for ; Wed, 15 May 2002 01:56:08 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4F7u7s7019656 for ; Wed, 15 May 2002 09:56:07 +0200 (MEST) Received: from bends.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id JAA22793; Wed, 15 May 2002 09:56:05 +0200 Message-Id: <5.1.0.14.0.20020514151146.0286d940@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 May 2002 09:53:51 +0200 To: mobile-ip@sunroof.eng.sun.com From: Annika Jonsson Subject: [mobile-ip] Regional Registration Last Call issue #3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Here are my conclusions and proposals for additions/changes to solve most of the technical issues raised during last call of Regional Registrations. I have excluded the issues around multiple levels of hierarchies, which will be dealt with separatley. Respond as to whether you AGREE, DISAGREE, or CAN LIVE WITH the recommendation. And on the response put in the subject line, CLARIFICATION if you have a clarification to recommend, or ISSUE if you have an issue to raise. A. Differnet addressing realms. The issues raised about supporting different addressing realms between FA-GFA and GFA-HA (i.e. the GFA is placed on the border between those addressing realms). The basic problem is how to allow for flexibility in addressing between FA-GFA and GFA-HA, which does not work with the way the draft specifies the use of GFA CoA today. To allow this, it should be the GFA that decides wich CoA to use, possibly individually for each MN. To support this, the following changes are proposed: - clarify that a MN that supports regional registrations SHOULD send home registrations with a zero CoA, to allow the GFA to allocate CoA. (it is SHOULD and not MUST, because if the MN's HA doesn't support regional registrations, it should be allowed to use an advertised CoA, see mail on issue #2). An FA can force the use of zero CoA by not advertising any CoA address, but it will then not be backwards compatible (see mail on issues #2). This will be clarified in section 4.1. - change the allocation of CoA if the MN uses zero COA in the registration: in the draft right now, it is the FA that decides what CoA the MN gets. This should be changed so that the FA only forwards the registration to a GFA node (using an address in the address realm between the FA-GFA). Then the GFA selects the CoA (possibly based on the MN:s HA address, or MN-NAI if present, or information from AAA server etc...), adds GFA IP extension, protects it with FA-HA auth- extension and sends it to the HA. This will be changed in section 4.2, 4.3 and 8.1. - clarifiy that if the FA advertises a GFA CoA, this is regarded as a "default" CoA that could be used, especially by MN:s that supports regional registrations, but have HA:s that don't. If this CoA is not within the same addressing realm as the FA-GFA, the FA needs to have a mapping to the address that it should use to communicate with the GFA. This will be added to section 4.2 B. too many options. Some people commented that it is a problem with too may optional ways to do things, since it would be difficlut to imlement and can create problems for interoperability. - Most of the options are around the advertised addresses and what address the mobile node uses in registration messages. Hopefully this is much better now that we clarifies the use of those addresses both for backwards compatibility and for different addressing realms, so I consider this issue solved C. protection of the GFA IP address extension It was pointed out that the GFA IP address extension needs to be protected by an authentication extension. - this should be clarified in section 4.3. D. reverse tunnelling clarification It was pointed out that if reverse tunnelling is used, the FA must use the address in the registration request (from the HFA extension) as source for the tunnel. - this should be clarified in section 4.2 and 4.3. E. Generalized NAI extension There was a question about why the Generalized NAI extension is needed, why not use an FA-NAI extension directly? - RFC3220 recommends that new extensions should be in this format if possible. Therefore I propose that we keep this. F. added delay with extra round-trip It was pointed out that if the FA is allowed to deny a regional registration because it doesn't support that GFA, this means one extra round-trip before the registration is completed, which could lead to extra delay for traffic. - That is true, but I still think we should allow this feature because: * the first "round-trip" is very short, only to the FA and back. * FAs in the same domain should in most cases support the same GFAs so this would not happen very often. * allowing an FA to deny the use of a specific GFA would be useful, for example if a GFA breaks down, since it would force the MN to register a new GFA with it's HA. * the FA needs a way to deny unvalid registrations, in this case if a mobile node uses a non-existent CoA in the registration request. Therefore I propose that we don't change this. Regards, Annika From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 04:36:45 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21922 for ; Wed, 15 May 2002 04:36:44 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA08993; Wed, 15 May 2002 01:34:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14057; Wed, 15 May 2002 01:34:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F8Y5rP013006 for ; Wed, 15 May 2002 01:34:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F8Y5VX013005 for mobile-ip-dist; Wed, 15 May 2002 01:34:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F8Y1rP012998 for ; Wed, 15 May 2002 01:34:01 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27173 for ; Wed, 15 May 2002 01:34:04 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06296 for ; Wed, 15 May 2002 02:34:03 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4F8Xec21933; Wed, 15 May 2002 10:33:41 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA04641; Wed, 15 May 2002 10:33:40 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4F8XdT83897; Wed, 15 May 2002 10:33:39 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205150833.g4F8XdT83897@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= cc: arvind.sevalkar@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sending Binding Acknowledgement with routing header. In-reply-to: Your message of Wed, 15 May 2002 12:05:18 +0900. <20020515.120518.113274767.keiichi@iij.ad.jp> Date: Wed, 15 May 2002 10:33:39 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I don't understand the reason why the above change (not inserting a routing header to a BA). Could anybody explain it? => confusion? Since all the packet should be sent with a routing header if the sending node has a valid bindinc cache, a binding ack should have a routing header also. The MN thinks that the sending node doesn't have a binging cache when it receives a packet without a routing header. As a result, the MN will send a binding update.. If the MN receives a binding ack without routing header, it sends a bu again even if the binding ack indicates that the binding update has succeeded. Otherwise, we must write a special code to treat a binding ack when checking the route optimization status when receiving packets. => I agree, the only case where the routing header is not needed is for binding deletion when the MN has returned at home. In all other cases, including for errors, the RH is mandatory. 9.4.4 is right and 6.1.8 should only refer to it. Regards Francis.Dupont@enst-bretagne.fr PS: I know some implementations which explicitely check the presence of the RH. From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 05:00:57 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22286 for ; Wed, 15 May 2002 05:00:57 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19480; Wed, 15 May 2002 01:59:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02115; Wed, 15 May 2002 01:59:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F8wDrP013118 for ; Wed, 15 May 2002 01:58:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F8wDpO013117 for mobile-ip-dist; Wed, 15 May 2002 01:58:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F8wArP013110 for ; Wed, 15 May 2002 01:58:10 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17820 for ; Wed, 15 May 2002 01:58:13 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21088 for ; Wed, 15 May 2002 01:58:12 -0700 (PDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4F8wAs7027187; Wed, 15 May 2002 10:58:10 +0200 (MEST) Received: from bends.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA24353; Wed, 15 May 2002 10:58:08 +0200 Message-Id: <5.1.0.14.0.20020515100103.028daa60@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 May 2002 10:55:53 +0200 To: "Madhavi W. Chandra" From: Annika Jonsson Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Cc: Phil Roberts , "'mobile-ip@sunroof.eng.sun.com'" In-Reply-To: <20020514094328.A2517@cisco.com> References: <5.1.0.14.0.20020514100419.02851500@era-t.ericsson.se> <5.1.0.14.0.20020513175420.0287a090@era-t.ericsson.se> <20020509130354.A25864@cisco.com> <5.1.0.14.0.20020513175420.0287a090@era-t.ericsson.se> <20020513123737.A1353@cisco.com> <5.1.0.14.0.20020514100419.02851500@era-t.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Madhavi, At 09:43 AM 5/14/2002 -0400, Madhavi W. Chandra wrote: >Annika, > >On Tue, May 14, 2002 at 10:40:45AM +0200, Annika Jonsson wrote: > > Hi Madhavi, > > > > At 12:37 PM 5/13/2002 -0400, Madhavi W. Chandra wrote: > > >HI Annika, > > > > > >On Mon, May 13, 2002 at 06:16:05PM +0200, Annika Jonsson wrote: > > > > Hi Madhavi, > > > > > > > > see below... > > > > > > > > ... > > > > > > > > Attached below is modified text for the abstract and the > introduction, > > > > > > Annika's words based on input > > > > > > from Madhavi. > > > > > > > > > >DISAGREE...as written below. > > > > > > > > > >As per the feedback we provided, it should be clearly stated in the > > > > >Abstract and Introduction that this architecture is OPTIONAL and not > > > > >required in typical Mobile IP deployments. > > > > > > > > In the proposed text, both the Abstract and the Introduction _does_ say > > > > that this is an optional extension to MIP, so what are you disagreeing > > > with? > > > > > >As I stated in the email above and in my writeup, it should say > > >clearly in the Abstract and Introduction that the architecture is > > >OPTIONAL *and not required in typical Mobile IP deployments.* Since > > >this is not what you wrote above, we are DISAGREEING. > > > > To me, optional means just that, that it is not required, and that, I > > think, is clearly stated. I don't like the expression "in typical > Mobile IP > > deployments". What is a "typical" Mobile IP deployment, and will it always > > be the same? > >Well, you can choose another word besides 'typical' then. I want to >convey that not only is Regional Registration OPTIONAL, but not >required in *typical* (or whatever word you like) networks. >For example, Route Optimization is also optional, but more of a need >to alleviate triangle routing. Do you see my point now? I understand what you mean, but I disagree. You are saying that even though both route opt. and regional reg. are optional, route opt. is more important, or is likely to be used more, or something like that. That may be, I don't feel that I can predict that. But I totally disagree that this should in any way be expressed in an RFC. Route opt. will be used to avoid triangular routing, regional reg. will be used to reduce the number of signaling messages to the home network, and reduce the signaling delay within the same visited domain. That's what you need to know about them. Then it's up to those building the networks to decide what functions they think are important enough to use. > > > > > > > > > > > > > >Also, reference to the new > > > > >Section that will describe scenarios that may benefit from this > > > > >architecture should be included in the Introduction. The agreement to > > > > >include the new Section is to alleviate the doubts for the necessity > > > > >of this architecture. Hopefully, the new Section will highlight when > > > > >the architecture is useful, and not when it is NOT. > > > > > > > > I think that the text in the Introduction gives sufficent information > > > about > > > > what makes regional registrations useful and see no need for an extra > > > section. > > > > > >This is not what Charlie and I agreed to. We agreed to a new > > >Section that describes where this architecture would be > > >useful...perhaps you can provide network architectures that would > > >benefit from the regional tunneling. As per the agreement, the new > > >section would go into Section 3...probably Section 3.1 as Charlie > > >mentioned. Refer to the original email thread on this. If we had > > >thought that the Introduction was sufficient, the original email > > >thread would not have occured. Please do not go back to square one. > > > > Sorry, I missed that. I went back to see what you and Charlie had written. > > You offered to help with text, could you please do that? I'm not really > > sure what you want in this new section, that's why I'm asking. In the > > Introduction now it says: > >Annika, how can I provide you text for something that I am asking? These are >the concerns that I raised initially. We came to a good understanding >that the authors would describe where the regional registration architecture >is useful in another Section...you could articulate the network scenarios >that would benefit. The purpose of the Section is to assuage doubts on >its applicability. > >I offered to provide text for the OPTIONAL statements, which I did. > >Instead of continuing in circles, perhaps we should wait until Charlie >returns. I can't speek for Charlie, of course, but I think that he would more or less agree with me. He usually likes people to propose text because that's the best way to understand what they want. But, we have been considering adding an Applicability section to the draft. In view of these discussions I think we should, and that will hopefully address your concerns. Regards, Annika >Regards, >Madhavi > > > " If the distance between the visited network and the home network of the > > mobile node is large, the signaling delay for these registrations may be > > long. We propose a solution for performing registrations locally in the > > visited domain: regional registrations." > > > > Regional registrations reduce the number of signaling messages to the home > > network, and reduce the signaling delay when a mobile node moves from one > > foreign agent to another, within the same visited domain. This will both > > decrease the load on the home network, and speed up the process of > handover > > within the visited domain. " > > > > What would you like to add to that? > > > > Regards, > > Annika > > > > >Thanks, > > >Madhavi > > > > > > > > > > Regards, > > > > Annika > > > > > > > > >I have provided Annika with the suggested text. Please incorporate > > > > >the above comments. > > > > > > > > > >Thanks, > > > > >Madhavi > > > > > > > > > > > > > > > > Phil > > > > > > > > > > > > "Abstract > > > > > > > > > > > > Using Mobile IP, a mobile node registers with its home agent each > > > time it > > > > > > changes care-of address. If the distance between the visited > > > network and > > > > > > the home network of the mobile node is large, the signaling > delay for > > > > > these > > > > > > registrations may be long. This document describes a new kind of > > > > > "regional" > > > > > > registration, i.e., registration local to the visited domain. The > > > regional > > > > > > signaling is performed via a new network entity called a Gateway > > > Foreign > > > > > > Agent and introduces a layer of hierarchy in the foreign domain. > > > Regional > > > > > > registrations reduce the number of signaling messages to the home > > > network, > > > > > > and reduce the signaling delay when a mobile node moves from one > > > foreign > > > > > > agent to another, within the same visited domain. This document > is an > > > > > > optional extension to the Mobile IP protocol." > > > > > > > > > > > > > > > > > > "Introduction > > > > > > > > > > > > This document is an optional extension to the Mobile IP > protocol, and > > > > > > proposes a means for mobile nodes to register locally within a > visited > > > > > > domain. By registering locally, the number of signaling > messages to the > > > > > > home network are keept to a minimum, and the signaling delay is > > > reduced. > > > > > > > > > > > > In Mobile IP, as specified in RFC 3220 [9], a mobile node > registers > > > with > > > > > > its home agent each time it changes care-of address. If the > distance > > > > > > between the visited network and the home network of the mobile > node is > > > > > > large, the signaling delay for these registrations may be long. We > > > propose > > > > > > a solution for performing registrations locally in the visited > domain: > > > > > > regional registrations. The regional registration design > introduces new > > > > > > Mobile IP messages - Regional Registrations, new Mobile IP > > > extensions to > > > > > > convey information between the mobile node, foreign agent, and > home > > > agent, > > > > > > and a new network entity - Gateway Foreign Agent (GFA). Regional > > > > > > registrations reduce the number of signaling messages to the home > > > network, > > > > > > and reduce the signaling delay when a mobile node moves from one > > > foreign > > > > > > agent to another, within the same visited domain. This will both > > > decrease > > > > > > the load on the home network, and speed up the process of handover > > > within > > > > > > the visited domain. The introduction of a GFA also makes it > possible to > > > > > > have different addressing realms in the home and in the visited > > > networks." > > > > > > > > > > > > > > > > > > The last three paragraphs of the Introduction are unmodified. From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 05:06:01 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22359 for ; Wed, 15 May 2002 05:06:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA14450; Wed, 15 May 2002 03:05:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA03627; Wed, 15 May 2002 02:05:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F94trP013154 for ; Wed, 15 May 2002 02:04:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F94tIM013153 for mobile-ip-dist; Wed, 15 May 2002 02:04:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F94qrP013146 for ; Wed, 15 May 2002 02:04:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA03440 for ; Wed, 15 May 2002 02:04:55 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07876 for ; Wed, 15 May 2002 03:04:54 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4F94ks7004516; Wed, 15 May 2002 11:04:46 +0200 (MEST) Received: from bends.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id LAA24503; Wed, 15 May 2002 11:04:44 +0200 Message-Id: <5.1.0.14.0.20020515105607.028d8ad0@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 15 May 2002 11:02:26 +0200 To: "Ahmad Muhanna", "'Phil Roberts'" , "'mobile-ip@sunroof.eng.sun.com'" From: Annika Jonsson Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #1 In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCCD9@zrc2c013.us.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_782265811==_.ALT" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --=====================_782265811==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Ahmad, At 09:17 AM 5/14/2002 -0500, Ahmad Muhanna wrote: >Phil/Annika, > >Please see my comments inline. > >Regards; >Ahmad Muhanna > > > > > Phil > > > > "Abstract > > > > Using Mobile IP, a mobile node registers with its home agent > > each time it > > changes care-of address. If the distance between the visited > >Well, this statement is correct. >However, the proposed Regional Registration draft still does exactly what >this sentence states!!!! sorry, I don't understand what you want to say. Could you please be more specific? /Annika > > > network and > > the home network of the mobile node is large, the signaling > > delay for these > > registrations may be long. This document describes a new kind > > of "regional" > > registration, i.e., registration local to the visited domain. > > The regional > > signaling is performed via a new network entity called a > > Gateway Foreign > > Agent and introduces a layer of hierarchy in the foreign > > domain. Regional > > registrations reduce the number of signaling messages to the > > home network, > > and reduce the signaling delay when a mobile node moves from > > one foreign > > agent to another, within the same visited domain. This document is an > > optional extension to the Mobile IP protocol." > > > > > > "Introduction > > > > This document is an optional extension to the Mobile IP protocol, and > > proposes a means for mobile nodes to register locally within > > a visited > > domain. By registering locally, the number of signaling > > messages to the > > home network are keept to a minimum, and the signaling delay > > is reduced. > > > > In Mobile IP, as specified in RFC 3220 [9], a mobile node > > registers with > > its home agent each time it changes care-of address. If the distance > >same comment as above!!!! > > > between the visited network and the home network of the > > mobile node is > > large, the signaling delay for these registrations may be > > long. We propose > > a solution for performing registrations locally in the > > visited domain: > > regional registrations. The regional registration design > > introduces new > > Mobile IP messages - Regional Registrations, new Mobile IP > > extensions to > > convey information between the mobile node, foreign agent, > > and home agent, > > and a new network entity - Gateway Foreign Agent (GFA). Regional > > registrations reduce the number of signaling messages to the > > home network, > > and reduce the signaling delay when a mobile node moves from > > one foreign > > agent to another, within the same visited domain. This will > > both decrease > > the load on the home network, and speed up the process of > > handover within > > the visited domain. The introduction of a GFA also makes it > > possible to > > have different addressing realms in the home and in the > > visited networks." > > > > > > The last three paragraphs of the Introduction are unmodified. > > --=====================_782265811==_.ALT Content-Type: text/html; charset="us-ascii" Hi Ahmad,

At 09:17 AM 5/14/2002 -0500, Ahmad Muhanna wrote:

Phil/Annika,

Please see my comments inline.

Regards;
Ahmad Muhanna

>
> Phil
>
> "Abstract
>
> Using Mobile IP, a mobile node registers with its home agent
> each time it
> changes care-of address. If the distance between the visited

Well, this statement is correct.
However, the proposed Regional Registration draft still does exactly what this sentence states!!!!

sorry, I don't understand what you want to say. Could you please be more specific?

/Annika

 
> network and
> the home network of the mobile node is large, the signaling
> delay for these
> registrations may be long. This document describes a new kind
> of "regional"
> registration, i.e., registration local to the visited domain.
> The regional
> signaling is performed via a new network entity called a
> Gateway Foreign
> Agent and introduces a layer of hierarchy in the foreign
> domain. Regional
> registrations reduce the number of signaling messages to the
> home network,
> and reduce the signaling delay when a mobile node moves from
> one foreign
> agent to another, within the same visited domain. This document is an
> optional extension to the Mobile IP protocol."
>
>
> "Introduction
>
> This document is an optional extension to the Mobile IP protocol, and
> proposes a means for mobile nodes to register locally within
> a visited
> domain. By registering locally, the number of signaling
> messages to the
> home network are keept to a minimum, and the signaling delay
> is reduced.
>
> In Mobile IP, as specified in RFC 3220 [9], a mobile node
> registers with
> its home agent each time it changes care-of address. If the distance

same comment as above!!!!
 
> between the visited network and the home network of the
> mobile node is
> large, the signaling delay for these registrations may be
> long. We propose
> a solution for performing registrations locally in the
> visited domain:
> regional registrations. The regional registration design
> introduces new
> Mobile IP messages - Regional Registrations, new Mobile IP
> extensions to
> convey information between the mobile node, foreign agent,
> and home agent,
> and a new network entity - Gateway Foreign Agent (GFA). Regional
> registrations reduce the number of signaling messages to the
> home network,
> and reduce the signaling delay when a mobile node moves from
> one foreign
> agent to another, within the same visited domain. This will
> both decrease
> the load on the home network, and speed up the process of
> handover within
> the visited domain. The introduction of a GFA also makes it
> possible to
> have different addressing realms in the home and in the
> visited networks."
>
>
> The last three paragraphs of the Introduction are unmodified.
>
--=====================_782265811==_.ALT-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 05:23:12 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22599 for ; Wed, 15 May 2002 05:23:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29776; Wed, 15 May 2002 02:21:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07665; Wed, 15 May 2002 02:21:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F9KUrP013212 for ; Wed, 15 May 2002 02:20:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F9KU4R013211 for mobile-ip-dist; Wed, 15 May 2002 02:20:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F9KRrP013204 for ; Wed, 15 May 2002 02:20:27 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07255 for ; Wed, 15 May 2002 02:20:30 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00905 for ; Wed, 15 May 2002 02:20:30 -0700 (PDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id SAA00833; Wed, 15 May 2002 18:20:28 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id SAA24965; Wed, 15 May 2002 18:20:28 +0900 (JST) Date: Wed, 15 May 2002 18:20:11 +0900 (JST) Message-Id: <20020515.182011.33026425.keiichi@iij.ad.jp> To: arvind.sevalkar@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sending Binding Acknowledgement with routing header. From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: References: X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: From: arvind.sevalkar@lntinfotech.com Content-Transfer-Encoding: 7bit > I think in draft nowhere it is mentioned that MN will send BU when it > receives packet without routing header. MN will send BU when it receives > tunneled packet, right ? Yes. I think the following two are same. - check if the packet is tunneled like below or not. [src:HA][dst:MNCoA]([src:HA][dst:MNHoA](payload)) - check if the packet doesn't have a mip6 routing header like below or not. [src:HA][dst:MNHoA](payload) If the MN receives a packet sent from some address to its home address without routing header, we can conclude that the peer doesn't have a binding. The original idea of this algorithm is presented by Hesham Soliman on the mobile-ip mailing-list <034BEFD03799D411A59F00508BDF754603008B1F@esealnt448.al.sw.ericsson.se> > And as BA is send to the source address of the BU message and source > address of the BU message is the COA, so for COA there will be no any > binding exist in the Binding Cache as key for searching Binding Cache is > the Home address, so CN will not add routing header..... A BU is sent with a HAO. It looks that the packet is logically sent from the home address of the MN. Since the source address of the BU is the home address of the MN, the HA will send a BA to the home address of the MN. At this point, the HA has a valid binding cache entry for the MN. As a result, a routing header will be inserted as a normal outgoing packet processing. Am I missing something? --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 05:27:08 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22719 for ; Wed, 15 May 2002 05:27:07 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01569; Wed, 15 May 2002 02:25:23 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08937; Wed, 15 May 2002 02:25:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F9OirP013250 for ; Wed, 15 May 2002 02:24:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4F9OiEt013249 for mobile-ip-dist; Wed, 15 May 2002 02:24:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4F9OfrP013242 for ; Wed, 15 May 2002 02:24:41 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19722 for ; Wed, 15 May 2002 02:24:44 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29933 for ; Wed, 15 May 2002 03:24:44 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id CAA14224; Wed, 15 May 2002 02:24:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4F9Og131793; Wed, 15 May 2002 02:24:42 -0700 X-mProtect: <200205150924> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.84, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGC1IrU; Wed, 15 May 2002 02:24:38 PDT Message-ID: <3CE2294A.DED694DD@iprg.nokia.com> Date: Wed, 15 May 2002 02:24:26 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Annika Jonsson , "Madhavi W. Chandra" CC: Phil Roberts , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Regional Registration Last Call ResolutionIssue #1 References: <5.1.0.14.0.20020514100419.02851500@era-t.ericsson.se> <5.1.0.14.0.20020513175420.0287a090@era-t.ericsson.se> <20020509130354.A25864@cisco.com> <5.1.0.14.0.20020513175420.0287a090@era-t.ericsson.se> <20020513123737.A1353@cisco.com> <5.1.0.14.0.20020514100419.02851500@era-t.ericsson.se> <5.1.0.14.0.20020515100103.028daa60@era-t.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, The discussion revolves around when regional registration might be useful, and how to indicate that within the draft. I think it's best to be very exact. Regional registration will be useful when there's too much signaling traffic from registration traffic across the Internet all emanating from the same visited domain and all caused by movement between foreign agents in that same domain. This is intuitive. "Too much" is clearly a matter for determination by individual systems and access networks. If an access network does not have this problem, then it does not need regional registration. Whether or not a "typical" visited domain or access network will have this problem is hard to say. I do know that we undertook this work originally with a clear mandate to get something to work, presumably because people saw the need, and because we saw the need ourselves. In fact, the implementations and simulations do show the effect, and that bolsters the intuition. I don't it is possible to prove to anyone that they "need" regional registration. Nor QoS, nor multicast, nor voice-quality handovers, nor ... But if we have a good tool for people to use, then they can more easily solve problems that require that tool. It doesn't mean that everyone has the same problems. The text contribution that I would like to see from Madhavi or anyone would be something that would shed more light on problems where regional registration is clearly needed, or clearly not needed, along with enough discussion to make the point. It seems like good material for an appendix. I hope this is at least helpful in some way, and that further discussion doesn't have to wait until I return. Regards, Charlie P. Annika Jonsson wrote (in response to Madhavi): > >Well, you can choose another word besides 'typical' then. I want to > >convey that not only is Regional Registration OPTIONAL, but not > >required in *typical* (or whatever word you like) networks. > >For example, Route Optimization is also optional, but more of a need > >to alleviate triangle routing. Do you see my point now? > > I understand what you mean, but I disagree. You are saying that even though > both route opt. and regional reg. are optional, route opt. is more > important, or is likely to be used more, or something like that. That may > be, I don't feel that I can predict that. But I totally disagree that this > should in any way be expressed in an RFC. Route opt. will be used to avoid > triangular routing, regional reg. will be used to reduce the number of > signaling messages to the home network, and reduce the signaling delay > within the same visited domain. That's what you need to know about them. > Then it's up to those building the networks to decide what functions they > think are important enough to use. .................................... > > >Annika, how can I provide you text for something that I am asking? These are > >the concerns that I raised initially. We came to a good understanding > >that the authors would describe where the regional registration architecture > >is useful in another Section...you could articulate the network scenarios > >that would benefit. The purpose of the Section is to assuage doubts on > >its applicability. > > > >I offered to provide text for the OPTIONAL statements, which I did. > > > >Instead of continuing in circles, perhaps we should wait until Charlie > >returns. > > I can't speek for Charlie, of course, but I think that he would more or > less agree with me. He usually likes people to propose text because that's > the best way to understand what they want. But, we have been considering > adding an Applicability section to the draft. In view of these discussions > I think we should, and that will hopefully address your concerns. From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 08:14:28 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28491 for ; Wed, 15 May 2002 08:14:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12704; Wed, 15 May 2002 06:14:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23483; Wed, 15 May 2002 05:13:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FCD0rP013527 for ; Wed, 15 May 2002 05:13:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4FCD01j013526 for mobile-ip-dist; Wed, 15 May 2002 05:13:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FCCvrP013519 for ; Wed, 15 May 2002 05:12:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17714 for ; Wed, 15 May 2002 05:13:01 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12353 for ; Wed, 15 May 2002 06:13:28 -0600 (MDT) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 08:12:58 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE469948D5@ftmail> From: Scott Corson To: "'Phil Roberts'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Wed, 15 May 2002 08:12:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > As currently specified it's not immediately obvious how the regional > registration agents are compatible with the above guidelines. Phil, The particulars of RegReg aside, it's not clear how MIP is consistent with e2e either. Your note raises a couple of issues infrequently discussed in this WG. 1) MIP breaks the end-to-end architecture of the Internet. The HA is a stateful, single point of failure. It is an architectural compromise (an evil in the minds of purists), necessary only because of the Internet routing infrastructure's inability to deal with prefix mobility. What the current discussion over regional elements questions is whether *another* such element should be added to the MIP standard. The unfortunate conclusion is probably *yes* for the following reasons. 2) Operators need a way to shield the effects of what is commonly termed micro-mobility from each other's networks (i.e. mobility signalling). That is the *primary* reason for needing a regional MIP element, and not latency or many of the other issues frequently discussed on this list. What is necessary is *separation* of the effects of localized domain/provider mobility from global mobility/reachability at the network layer. Two current mobile network architectures (e.g. 3GPP/3GPP2) achieve this separation through the usage of L2 mobility mechanisms for micro-mobility support. This L2 mobility is hidden from the IP layer by the existence of two IP-level boxes: GGSN/PDSN for 3GPP/3GPP2, respectively. These are stateful, single points of failure which (if visible in the MIP plane) would represent the regional elements your note suggests are harmful. It turns out that the PDSN and GGSN are extremely stateful (middleboxes of the most complex kind involving not only network layer state, but L2 and higher session layer state as well). In accordance with the e2e principle, their removal would be a good thing from what are obstensibly "all-IP" networks. The addition of regional elements to MIP is a step towards making this removal feasible. It would add the necessary localization/separation properties MIP currently lacks to the standard, making MIP a deployable control plane between operators and, when desired, within operator's networks. It would limit the architecturally-compromising effects of stateful elements to the network layer, which is consistent with existing MIP, as a compromise solution for a network-layer routing deficiency. All other layers would be free to operate in an e2e fashion. As a consequence, these MIP regional elements need only be network layer entities (i.e. routers), thus far cheaper to build, maintain, etc, enabling the Internet to function closer to the way e2e principle suggests. It should also be noted that many of the desired properties currently lacking in MIP can be realized in a less stateful manner through the use of "nested" MIP as detailed in http://search.ietf.org/internet-drafts/draft-oneill-mip-nested-00.txt However, additional capabilities/features are realizable through the use of network layer-stateful entities as detailed in the recently submitted drafts related to nested MIP. There are many facets to this issue which are explored in these drafts. In short, MIP does not survive the e2e test, and some current network architectures fail woefully as well. Regards, -Scott __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 08:34:07 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29730 for ; Wed, 15 May 2002 08:34:07 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20925; Wed, 15 May 2002 06:34:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28337; Wed, 15 May 2002 05:33:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FCWprP013577 for ; Wed, 15 May 2002 05:32:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4FCWp6N013576 for mobile-ip-dist; Wed, 15 May 2002 05:32:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FCWmrP013569 for ; Wed, 15 May 2002 05:32:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28123 for ; Wed, 15 May 2002 05:32:52 -0700 (PDT) From: Padmakumar.AV@lntinfotech.com Received: from ltitlin.lntinfotech.com ([203.199.54.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20501 for ; Wed, 15 May 2002 06:33:19 -0600 (MDT) Received: from bangalore.lntinfotech.com ([172.29.4.3]) by ltitlin.lntinfotech.com (Lotus Domino Release 5.0.8) with ESMTP id 2002051518033414:9060 ; Wed, 15 May 2002 18:03:34 +0530 Subject: [mobile-ip] mobile-ip] Where to insert HAO? To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Wed, 15 May 2002 17:58:22 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/15/2002 06:00:01 PM, Itemize by SMTP Server on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/15/2002 06:03:34 PM, Serialize by Router on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/15/2002 06:03:40 PM, Serialize complete at 05/15/2002 06:03:40 PM 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 g4FCWnrP013570 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi All, Section 6.3 says "The Home Address option MUST be placed as follows: - After the Routing Header, if that header is present - Before the Fragment Header, if that header is present - Before the AH Header or ESP Header, if either one of those Headers is present " "After the Routing Header, if that header is present" does it mean that HAO has to be placed in the inner destination option header, because outer destination header usually comes before routing header. "Before the Fragment Header, if that header is present" ? ok this rules out the case of inner destination option header, in this case outer destination option and routing header both are part of non fragmentable part, but still outer destination option header comes before routing header (for example in Linux Ipv6). What if both routing and fragment headers are present? "Before the AH Header or ESP Header, if either one of those Headers is present " this again rules out the use of inner destination header. So where should we actually place the HAO? Best Regards pav From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 10:16:58 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06155 for ; Wed, 15 May 2002 10:16:58 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12466; Wed, 15 May 2002 08:16:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16579; Wed, 15 May 2002 07:16:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FEFKrP013679 for ; Wed, 15 May 2002 07:15:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4FEFKIw013678 for mobile-ip-dist; Wed, 15 May 2002 07:15:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FEFGrP013671 for ; Wed, 15 May 2002 07:15:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12989 for ; Wed, 15 May 2002 07:15:19 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11662 for ; Wed, 15 May 2002 08:15:18 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g4FEFF410859; Wed, 15 May 2002 09:15:15 -0500 (CDT) Message-ID: <3CE26D89.6050804@alcatel.com> Date: Wed, 15 May 2002 09:15:37 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Scott Corson CC: "'Phil Roberts'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 References: <8C92E23A3E87FB479988285F9E22BE469948D5@ftmail> Content-Type: multipart/alternative; boundary="------------080707030200070302060406" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------080707030200070302060406 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Scott, Agreed. But you must underline the MIP without route optimization. If route optimization is achieved which probably is going to be the case with MIPv6, then the HA in the architecture is a necessary stateful network box to enable the route optimization to work. Also we can view MIPv4 regreg trying to help in the route optimization in its own way so its architecture has better e2e characteristic than MIPv4 in this sense. We must also add that these days it is a fashion to keep adding proxy boxes, the most recent one being the STUN proxy that would also violate e2e principle. SIP servers are probably of this category. However like in route optimization, SIP uses them carefully in order to establish e2e communications. My 0.02 euro cents. Regards, Scott Corson wrote: >>As currently specified it's not immediately obvious how the regional >>registration agents are compatible with the above guidelines. >> > >Phil, > >The particulars of RegReg aside, it's not clear how MIP is consistent with >e2e either. > >Your note raises a couple of issues infrequently discussed in this WG. > >1) MIP breaks the end-to-end architecture of the Internet. > >The HA is a stateful, single point of failure. It is an architectural >compromise (an evil in the minds of purists), necessary only because of the >Internet routing infrastructure's inability to deal with prefix mobility. > >What the current discussion over regional elements questions is whether >*another* such element should be added to the MIP standard. The unfortunate >conclusion is probably *yes* for the following reasons. > >2) Operators need a way to shield the effects of what is commonly termed >micro-mobility from each other's networks (i.e. mobility signalling). That >is the *primary* reason for needing a regional MIP element, and not latency >or many of the other issues frequently discussed on this list. What is >necessary is *separation* of the effects of localized domain/provider >mobility from global mobility/reachability at the network layer. > >Two current mobile network architectures (e.g. 3GPP/3GPP2) achieve this >separation through the usage of L2 mobility mechanisms for micro-mobility >support. This L2 mobility is hidden from the IP layer by the existence of >two IP-level boxes: GGSN/PDSN for 3GPP/3GPP2, respectively. These are >stateful, single points of failure which (if visible in the MIP plane) would >represent the regional elements your note suggests are harmful. > >It turns out that the PDSN and GGSN are extremely stateful (middleboxes of >the most complex kind involving not only network layer state, but L2 and >higher session layer state as well). In accordance with the e2e principle, >their removal would be a good thing from what are obstensibly "all-IP" >networks. > >The addition of regional elements to MIP is a step towards making this >removal feasible. It would add the necessary localization/separation >properties MIP currently lacks to the standard, making MIP a deployable >control plane between operators and, when desired, within operator's >networks. It would limit the architecturally-compromising effects of >stateful elements to the network layer, which is consistent with existing >MIP, as a compromise solution for a network-layer routing deficiency. All >other layers would be free to operate in an e2e fashion. As a consequence, >these MIP regional elements need only be network layer entities (i.e. >routers), thus far cheaper to build, maintain, etc, enabling the Internet to >function closer to the way e2e principle suggests. > >It should also be noted that many of the desired properties currently >lacking in MIP can be realized in a less stateful manner through the use of >"nested" MIP as detailed in > >http://search.ietf.org/internet-drafts/draft-oneill-mip-nested-00.txt > >However, additional capabilities/features are realizable through the use of >network layer-stateful entities as detailed in the recently submitted drafts >related to nested MIP. There are many facets to this issue which are >explored in these drafts. > >In short, MIP does not survive the e2e test, and some current network >architectures fail woefully as well. > >Regards, > >-Scott > > >__________________________________________________ >Do You Yahoo!? >LAUNCH - Your Yahoo! Music Experience >http://launch.yahoo.com > -- Behcet --------------080707030200070302060406 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Scott,
  Agreed.
  But you must underline the MIP without route optimization. If route optimization is achieved which probably is going to be the case with MIPv6, then the HA in the architecture is a necessary stateful network box to enable the route optimization to work.
  Also we can view MIPv4 regreg trying to help in the route optimization in its own way so its architecture has better e2e characteristic than MIPv4 in this sense.
  We must also add that these days it is a fashion to keep adding proxy boxes, the most recent one being  the STUN proxy that would also violate e2e principle. SIP servers are probably of this category. However like in route optimization, SIP uses them carefully in order to establish e2e communications.

  My 0.02 euro cents.

Regards,

Scott Corson wrote:
As currently specified it's not immediately obvious how the regional
registration agents are compatible with the above guidelines.  

Phil,

The particulars of RegReg aside, it's not clear how MIP is consistent with
e2e either.

Your note raises a couple of issues infrequently discussed in this WG.

1) MIP breaks the end-to-end architecture of the Internet.

The HA is a stateful, single point of failure.  It is an architectural
compromise (an evil in the minds of purists), necessary only because of the
Internet routing infrastructure's inability to deal with prefix mobility.

What the current discussion over regional elements questions is whether
*another* such element should be added to the MIP standard.  The unfortunate
conclusion is probably *yes* for the following reasons.

2) Operators need a way to shield the effects of what is commonly termed
micro-mobility from each other's networks (i.e. mobility signalling).  That
is the *primary* reason for needing a regional MIP element, and not latency
or many of the other 
issues frequently discussed on this list.  What is
necessary is *separation* of the effects of localized domain/provider
mobility from global mobility/reachability at the network layer.

Two current mobile network architectures (e.g. 3GPP/3GPP2) achieve this
separation through the usage of L2 mobility mechanisms for micro-mobility
support.  This L2 mobility is hidden from the IP layer by the existence of
two IP-level boxes: GGSN/PDSN for 3GPP/3GPP2, respectively.  These are
stateful, single points of failure which (if visible in the MIP plane) would
represent the regional elements your note suggests are harmful.

It turns out that the PDSN and GGSN are extremely stateful (middleboxes of
the most complex kind involving not only network layer state, but L2 and
higher session layer state as well).  In accordance with the e2e principle,
their removal would be a good thing from what are obstensibly "all-IP"
networks.

The addition
 of regional elements to MIP is a step towards making this
removal feasible.   It would add the necessary localization/separation
properties MIP currently lacks to the standard, making MIP a deployable
control plane between operators and, when desired, within operator's
networks.  It would limit the architecturally-compromising effects of
stateful elements to the network layer, which is consistent with existing
MIP, as a compromise solution for a network-layer routing deficiency.  All
other layers would be free to operate in an e2e fashion.  As a consequence,
these MIP regional elements need only be network layer entities (i.e.
routers), thus far cheaper to build, maintain, etc, enabling the Internet to
function closer to the way e2e principle suggests.

It should also be noted that many of the desired properties currently
lacking in MIP can be realized in a less stateful manner through the use of
"nested" MIP as detailed in 

<
a class="moz-txt-link-freetext" href="http://search.ietf.org/internet-drafts/draft-oneill-mip-nested-00.txt">http://search.ietf.org/internet-drafts/draft-oneill-mip-nested-00.txt

However, additional capabilities/features are realizable through the use of
network layer-stateful entities as detailed in the recently submitted drafts
related to nested MIP.  There are many facets to this issue which are
explored in these drafts.

In short, MIP does not survive the e2e test, and some current network
architectures fail woefully as well.

Regards,

-Scott


__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

-- 
Behcet

--------------080707030200070302060406-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 11:02:53 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09146 for ; Wed, 15 May 2002 11:02:53 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18356; Wed, 15 May 2002 09:02:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28690; Wed, 15 May 2002 08:02:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FF1FrP013779 for ; Wed, 15 May 2002 08:01:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4FF1F5j013778 for mobile-ip-dist; Wed, 15 May 2002 08:01:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FF1CrP013771 for ; Wed, 15 May 2002 08:01:12 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28278 for ; Wed, 15 May 2002 08:01:15 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17566 for ; Wed, 15 May 2002 09:01:14 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 125908F90; Wed, 15 May 2002 11:01:14 -0400 (EDT) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id E6D271170; Wed, 15 May 2002 10:01:09 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id LAA0001419547; Wed, 15 May 2002 11:01:09 -0400 (EDT) Message-ID: <3CE27835.9040605@hp.com> Date: Wed, 15 May 2002 11:01:09 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Padmakumar.AV@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] mobile-ip] Where to insert HAO? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The draft actually defined a new destination option header location (in addition to the ones defined in 2460). This location is what you described in your message. For example: IPv6 [ HbH [ Dest{1} [ Rtrhdr [ Dest (HOA) [ Frag ...]]]]] However, I believe that'll change in the next revision since the HOA will be a parameter in the Mobility Header. -vlad Padmakumar.AV@lntinfotech.com wrote: > Hi All, > > Section 6.3 says > "The Home Address option MUST be placed as follows: > > - After the Routing Header, if that header is present > > - Before the Fragment Header, if that header is present > > - Before the AH Header or ESP Header, if either one of those > Headers is present " > "After the Routing Header, if that header is present" does it mean that HAO > has to be placed in the inner destination option header, because outer > destination header usually comes before routing header. > > "Before the Fragment Header, if that header is present" ? ok this rules out > the case of inner destination option header, in this case outer destination > option and routing header both are part of non fragmentable part, but still > outer destination option header comes before routing header (for example in > Linux Ipv6). What if both routing and fragment headers are present? > > "Before the AH Header or ESP Header, if either one of those Headers is > present " this again rules out the use of inner destination header. > > So where should we actually place the HAO? > > Best Regards > pav > > > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 13:36:26 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15044 for ; Wed, 15 May 2002 13:36:21 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22070; Wed, 15 May 2002 11:36:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26034; Wed, 15 May 2002 10:35:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FHYkrP013974 for ; Wed, 15 May 2002 10:34:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4FHYkQ2013973 for mobile-ip-dist; Wed, 15 May 2002 10:34:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FHYhrP013966 for ; Wed, 15 May 2002 10:34:43 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21306 for ; Wed, 15 May 2002 10:34:45 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19070 for ; Wed, 15 May 2002 10:34:45 -0700 (PDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id F0203214; Wed, 15 May 2002 12:34:44 -0500 (CDT) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 5C03013D0; Wed, 15 May 2002 10:34:43 -0700 (PDT) Received: from hp.com by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id NAA0001439136; Wed, 15 May 2002 13:34:41 -0400 (EDT) Message-ID: <3CE29C31.3080209@hp.com> Date: Wed, 15 May 2002 13:34:41 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Padmakumar.AV@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] mobile-ip] Where to insert HAO? References: <3CE27835.9040605@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Correction... Vladislav Yasevich wrote: > However, I believe that'll change in the next revision since > the HOA will be a parameter in the Mobility Header. I was thinking of something else. The HOA will still be a destination option positioned in it's own Desitination Option header. -vlad +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 13:51:04 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15577 for ; Wed, 15 May 2002 13:51:04 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28026; Wed, 15 May 2002 10:48:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02149; Wed, 15 May 2002 10:47:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FHkprP014036 for ; Wed, 15 May 2002 10:46:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4FHko95014035 for mobile-ip-dist; Wed, 15 May 2002 10:46:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FHklrP014028 for ; Wed, 15 May 2002 10:46:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01468 for ; Wed, 15 May 2002 10:46:50 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA04561 for ; Wed, 15 May 2002 11:46:49 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4FHktV09157; Wed, 15 May 2002 12:46:55 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 12:46:46 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCCEA@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Annika Jonsson'" , Phil Roberts , mobile-ip@sunroof.eng.sun.com Cc: "'A.ONeill@flarion.com'" Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #2 Date: Wed, 15 May 2002 12:46:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC38.7ABDED00" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FC38.7ABDED00 Content-Type: text/plain; charset="iso-8859-1" Hello Annika, Please see my comments inline. Regards; Ahmad Muhanna > > This would go into section 3.3. It would be changed to: > > " > 3.3. Advertising Foreign Agent and GFA > > A foreign agent typically announces its presence via an Agent > Advertisement > message [9]. If the domain to which a foreign agent belongs supports > regional registrations, the following changes are applied to > the Agent > Advertisement message. > > The `I' flag (see Section 7) MUST be set to indicate that the domain > supports regional tunnel management. If the `I' bit is set, > there MUST be > at least one care-of address in the Agent Advertisement > message, but that > address MAY be set to zero. If the `I' bit is set, and there > is only one See my comments below. > care-of address (i.e. not zero), it is the address of the FA. > If the `I' > bit is set, and there are multiple care-of addresses, the > first care-of > address is the local FA, and the last care-of address is the GFA. The > FA-NAI (see section 7.2) SHOULD also be present to enable the > mobile node > to decide whether or not it is in its home domain. The > decision is based on > whether the realm part of the advertised FA-NAI matches the > mobile node's > realm. " > > > > - clarify that if the FA advertises a zero address, it will > > > not support > > > RFC3220 MN:s. In some cases the owner of the network might > > > prefer this. > > > > > > > > > A new section about backwards compatibility: > > "3.4 Backwards compatibility with RFC3220 > > A domain that supports Regional Regisratiosn SHOULD also be backwards > compatible with RFC3220. If the Foreign Agent does not > advertise a zero > care-of-address, it MUST support registrations according to > Mobile IPv4 > [9]. This allows mobile nodes that doesn't support Regional > Registrations > to register via this Foreign Agent using standard Mobile IPv4. If the > Foreign Agent advertises both its own care- of address and a > GFA care-of > address, a mobile node that supports Regional Registrations > but has a Home > Agent that doesn't, will still be able to make use of Regional > Registrations through that GFA care-of address. A Foreign Agent that > advertises a zero care-of address will not be backwards > compatible wiht > RFC3220, since both mobile nodes and Home Agents have to > understand the > zero care-of address. If the mobile node sets the care-of > address to zero, > the mobile node and its home agent MUST support the GFA IP > address extension." > Despite the fact that I earlier suggested the restriction when the FA advertise a care of address of zero, I need to DISAGREE here! A more in depth reading of RFC3220 reveals the following: 1. There is nothing in RFC3220 mandates the Mobile Node to check if the advertised care-of address is other than ZERO. 2. On the other hand, the only thing RFC3220 indicate to the Mobile Node that there is (are) advertised care-of address(es) is by checking the length of the Mobility Agent Advertisement Extension. (see section 2.1.1.) 3. Therefore, when a Foreign Agent advertised a care-of address of ZERO, Mobile Node will accept this address as a valid address and use it as a valid care-of address in its registration request. 4. Now is the dilemma, the proposed FA will receive this Registration Request with care-of address is set to ZERO. 5. Guess what, the FA will add the GFA IP address extension and send it the registration request to the GFA which will forward it to the Home Agent of this (RFC3220 compliant) Mobile Node. 6. Again, this Home Agent does not support the GFA IP Address extension which is a non-skippable extension!!! 7. Home Agent will drop the registration request. 8. GFA and probably the FA will timeout, and send a Registration Reply message with error code 78. "registration time out" 9. Guess what, Mobile Node will retry to register again, and the loop continues!!! I guarantee you many people will be very upset. I am not sure if there is a way around this!!!!! > > see the proposed new section 3.4 above. > > /Annika > > > > > > > /Annika > > > > > ------_=_NextPart_001_01C1FC38.7ABDED00 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Regional Registration Last Call Resolution Issue #2

Hello Annika,
Please see my comments inline.

Regards;
Ahmad Muhanna

>
> This would go into section 3.3. It would be changed to:
>
> "
> 3.3. Advertising Foreign Agent and GFA
>
> A foreign agent typically announces its presence via an Agent
> Advertisement
> message [9]. If the domain to which a foreign agent belongs supports
> regional registrations, the following changes are applied to
> the Agent
> Advertisement message.
>
> The `I' flag (see Section 7) MUST be set to indicate that the domain
> supports regional tunnel management. If the `I' bit is set,
> there MUST be
> at least one care-of address in the Agent Advertisement
> message, but that
> address MAY be set to zero. If the `I' bit is set, and there
> is only one

See my comments below.
 
> care-of address (i.e. not zero), it is the address of the FA.
> If the `I'
> bit is set, and there are multiple care-of addresses, the
> first care-of
> address is the local FA, and the last care-of address is the GFA. The
> FA-NAI (see section 7.2) SHOULD also be present to enable the
> mobile node
> to decide whether or not it is in its home domain. The
> decision is based on
> whether the realm part of the advertised FA-NAI matches the
> mobile node's
> realm. "
>
> > > - clarify that if the FA advertises a zero address, it will
> > > not support
> > > RFC3220 MN:s. In some cases the owner of the network might
> > > prefer this.
> > >
> > >
>
>
> A new section about backwards compatibility:
>
> "3.4 Backwards compatibility with RFC3220
>
> A domain that supports Regional Regisratiosn SHOULD also be backwards
> compatible with RFC3220. If the Foreign Agent does not
> advertise a zero
> care-of-address, it MUST support registrations according to
> Mobile IPv4
> [9]. This allows mobile nodes that doesn't support Regional
> Registrations
> to register via this Foreign Agent using standard Mobile IPv4. If the
> Foreign Agent advertises both its own care- of address and a
> GFA care-of
> address, a mobile node that supports Regional Registrations
> but has a Home
> Agent that doesn't, will still be able to make use of Regional
> Registrations through that GFA care-of address. A Foreign Agent that
> advertises a zero care-of address will not be backwards
> compatible wiht
> RFC3220, since both mobile nodes and Home Agents have to
> understand the
> zero care-of address. If the mobile node sets the care-of
> address to zero,
> the mobile node and its home agent MUST support the GFA IP
> address extension."
>

Despite the fact that I earlier suggested the restriction when the
FA advertise a care of address of zero, I need to DISAGREE here!

A more in depth reading of RFC3220 reveals the following:

1. There is nothing in RFC3220 mandates the Mobile Node to check if the advertised
    care-of address is other than ZERO.
2. On the other hand, the only thing RFC3220 indicate to the Mobile Node
    that there is (are) advertised care-of address(es) is by checking the length
    of the Mobility Agent Advertisement Extension. (see section 2.1.1.)
3. Therefore, when a Foreign Agent advertised a care-of address of ZERO,
    Mobile Node will accept this address as a valid address and use it as a valid
    care-of address in its registration request.
4. Now is the dilemma, the proposed FA will receive this Registration Request with
    care-of address is set to ZERO.
5. Guess what, the FA will add the GFA IP address extension and send it the registration
    request to the GFA which will forward it to the Home Agent of this (RFC3220 compliant)
    Mobile Node.
6. Again, this Home Agent does not support the GFA IP Address extension which is
    a non-skippable extension!!!
7. Home Agent will drop the registration request.
8. GFA and probably the FA will timeout, and send a Registration Reply message with
    error code 78. "registration time out"

9. Guess what, Mobile Node will retry to register again, and the loop continues!!!
    I guarantee you many people will be very upset.
   
I am not sure if there is a way around this!!!!!

>
> see the proposed new section 3.4 above.
>
> /Annika
>
>
> >
> > > /Annika
> > >
>
>

------_=_NextPart_001_01C1FC38.7ABDED00-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 14:43:19 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17401 for ; Wed, 15 May 2002 14:43:17 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26520; Wed, 15 May 2002 12:43:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23541; Wed, 15 May 2002 11:42:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FIfirP014191 for ; Wed, 15 May 2002 11:41:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4FIfhtp014190 for mobile-ip-dist; Wed, 15 May 2002 11:41:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FIferP014183 for ; Wed, 15 May 2002 11:41:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22549 for ; Wed, 15 May 2002 11:41:43 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00388 for ; Wed, 15 May 2002 11:41:43 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4FIfoV04820; Wed, 15 May 2002 13:41:50 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 13:41:41 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCCEB@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Annika Jonsson'" , mobile-ip@sunroof.eng.sun.com Cc: "'A.ONeill@flarion.com'" Subject: RE: [mobile-ip] Regional Registration Last Call issue #3 Date: Wed, 15 May 2002 13:41:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC40.2652ED80" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FC40.2652ED80 Content-Type: text/plain; charset="iso-8859-1" Annika; Please see my comments inline. Regards; Ahmad Muhanna > > > Hi > > Here are my conclusions and proposals for additions/changes > to solve most > of the technical issues raised during last call of Regional > Registrations. I have excluded the issues around multiple levels of > hierarchies, which will be dealt with separatley. > > Respond as to whether you AGREE, DISAGREE, or CAN LIVE WITH the > recommendation. And on the response put in the subject line, > CLARIFICATION > if you have a clarification to recommend, or ISSUE if you > have an issue to > raise. > > A. Differnet addressing realms. > > The issues raised about supporting different addressing > realms between > FA-GFA and GFA-HA (i.e. the GFA is placed on the border between those > addressing realms). The basic problem is how to allow for > flexibility in > addressing between FA-GFA and GFA-HA, which does not work > with the way the > draft specifies the use of GFA CoA today. To allow this, it > should be the > GFA that decides wich CoA to use, possibly individually for > each MN. To > support this, the following changes are proposed: > > - clarify that a MN that supports regional registrations > SHOULD send home > registrations with a zero CoA, to allow the GFA to allocate > CoA. (it is > SHOULD and not MUST, because if the MN's HA doesn't support regional > registrations, it should be allowed to use an advertised CoA, > see mail on > issue #2). An FA can force the use of zero CoA by not > advertising any CoA > address, but it will then not be backwards compatible (see > mail on issues > #2). This will be clarified in section 4.1. I DISAGREE. Mail on issue #2 does not talk about the FA advertising NO Care-of Address(es). It talks about advertising one care-of Address and that one is set to ZERO. There is no Foreign Agent allowed to claim that it is a Foreign Agent and at the same time advertise NO care-of address(es). (this is a violation of RFC3220 section 2.1.1.) > > - change the allocation of CoA if the MN uses zero COA in the > registration: > in the draft right now, it is the FA that decides what CoA > the MN gets. > This should be changed so that the FA only forwards the > registration to a > GFA node (using an address in the address realm between the > FA-GFA). Then > the GFA selects the CoA (possibly based on the MN:s HA > address, or MN-NAI > if present, or information from AAA server etc...), adds GFA > IP extension, > protects it with FA-HA auth- extension and sends it to the > HA. This will be > changed in section 4.2, 4.3 and 8.1. > > - clarifiy that if the FA advertises a GFA CoA, this is regarded as a > "default" CoA that could be used, especially by MN:s that > supports regional > registrations, but have HA:s that don't. If this CoA is not > within the same > addressing realm as the FA-GFA, the FA needs to have a mapping to the > address that it should use to communicate with the GFA. This > will be added > to section 4.2 > > B. too many options. > > Some people commented that it is a problem with too may > optional ways to do > things, since it would be difficlut to imlement and can > create problems for > interoperability. > > - Most of the options are around the advertised addresses and > what address > the mobile node uses in registration messages. Hopefully this is much > better now that we clarifies the use of those addresses both > for backwards > compatibility and for different addressing realms, so I > consider this issue > solved > > C. protection of the GFA IP address extension > > It was pointed out that the GFA IP address extension needs to > be protected > by an authentication extension. > > - this should be clarified in section 4.3. > > D. reverse tunnelling clarification > > It was pointed out that if reverse tunnelling is used, the FA > must use the > address in the registration request (from the HFA extension) > as source for > the tunnel. > > - this should be clarified in section 4.2 and 4.3. > > E. Generalized NAI extension > > There was a question about why the Generalized NAI extension > is needed, why > not use an FA-NAI extension directly? > > - RFC3220 recommends that new extensions should be in this format if > possible. Therefore I propose that we keep this. > > F. added delay with extra round-trip > > It was pointed out that if the FA is allowed to deny a regional > registration because it doesn't support that GFA, this means > one extra > round-trip before the registration is completed, which could > lead to extra > delay for traffic. > > - That is true, but I still think we should allow this > feature because: > * the first "round-trip" is very short, only to the FA and back. > * FAs in the same domain should in most cases support the > same GFAs so this > would not happen very often. > * allowing an FA to deny the use of a specific GFA would be > useful, for > example if a GFA breaks down, since it would force the MN to > register a new > GFA with it's HA. > * the FA needs a way to deny unvalid registrations, in this case if a > mobile node uses a non-existent CoA in the registration request. > > Therefore I propose that we don't change this. > I DISAGREE. There is a big difference between the standard proposing a behavior for the Foreign Agent to be used in case the Mobile Node did not follow the standard, like in the case when the FA receives a Registration Request with an invalid care-of address, as indicated in RFC3220, and of a protocol allowing the Mobile Node to act NORMALLY and STANDARD COMPLIANT and the same time considers it as an error scenario. > Regards, > Annika > > ------_=_NextPart_001_01C1FC40.2652ED80 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Regional Registration Last Call issue #3

Annika;
Please see my comments inline.

Regards;
Ahmad Muhanna

>
>
> Hi
>
> Here are my conclusions and proposals for additions/changes
> to solve most
> of  the technical  issues raised during last call of Regional
> Registrations. I have excluded the issues around multiple levels of
> hierarchies, which will be dealt with separatley.
>
> Respond as to whether you AGREE, DISAGREE, or CAN LIVE WITH the
> recommendation. And on the response put in the subject line,
> CLARIFICATION
> if you have a clarification to recommend, or ISSUE if you
> have an issue to
> raise.
>
> A. Differnet addressing realms.
>
> The issues raised about supporting different addressing
> realms between
> FA-GFA and GFA-HA (i.e. the GFA is placed on the border between those
> addressing realms). The basic problem is how to allow for
> flexibility in
> addressing between FA-GFA and GFA-HA, which does not work
> with the way the
> draft specifies the use of GFA CoA today. To allow this, it
> should be the
> GFA that decides wich CoA to use, possibly individually for
> each MN. To
> support this, the following changes are proposed:
>
> - clarify that a MN that supports regional registrations
> SHOULD send home
> registrations with a zero CoA, to allow the GFA to allocate
> CoA. (it is
> SHOULD and not MUST, because if the MN's HA doesn't support regional
> registrations, it should be allowed to use an advertised CoA,
> see mail on
> issue #2). An FA can force the use of zero CoA by not
> advertising any CoA
> address, but it will then not be backwards compatible (see
> mail on issues
> #2). This will be clarified in section 4.1.

I DISAGREE.

Mail on issue #2 does not talk about the FA advertising NO Care-of Address(es).
It talks about advertising one care-of Address and that one is set to ZERO.

There is no Foreign Agent allowed to claim that it is a Foreign Agent and at the same time
advertise NO care-of address(es). (this is a violation of RFC3220 section 2.1.1.)

>
> - change the allocation of CoA if the MN uses zero COA in the
> registration:
> in the draft right now, it is the FA that decides what CoA
> the MN gets.
> This should be changed so that the FA only forwards the
> registration to a
> GFA node (using an address in the address realm between the
> FA-GFA). Then
> the GFA selects the CoA (possibly based on the MN:s HA
> address, or  MN-NAI
> if present, or information from AAA server etc...), adds GFA
> IP extension,
> protects it with FA-HA auth- extension and sends it to the
> HA. This will be
> changed in section 4.2, 4.3 and 8.1.
>
> - clarifiy that if the FA advertises a GFA CoA, this is regarded as a
> "default" CoA that could be used, especially by MN:s that
> supports regional
> registrations, but have HA:s that don't. If this CoA is not
> within the same
> addressing realm as the FA-GFA, the FA needs to have a mapping to the
> address that it should use to communicate with the GFA. This
> will be added
> to section 4.2
>
> B. too many options.
>
> Some people commented that it is a problem with too may
> optional ways to do
> things, since it would be difficlut to imlement and can
> create problems for
> interoperability.
>
> - Most of the options are around the advertised addresses and
> what address
> the mobile node uses in registration messages. Hopefully this is much
> better now that we clarifies the use of those addresses both
> for backwards
> compatibility and for different addressing realms, so I
> consider this issue
> solved
>
> C. protection of the GFA IP address extension
>
> It was pointed out that the GFA IP address extension needs to
> be protected
> by an authentication extension.
>
> - this should be clarified in section 4.3.
>
> D. reverse tunnelling clarification
>
> It was pointed out that if reverse tunnelling is used, the FA
> must use the
> address in the registration request (from the HFA extension)
> as source for
> the tunnel.
>
> - this should be clarified in section 4.2 and 4.3.
>
> E. Generalized NAI extension
>
> There was a question about why the Generalized NAI extension
> is needed, why
> not use an FA-NAI extension directly?
>
> - RFC3220 recommends that new extensions should be in this format if
> possible. Therefore I propose that we keep this.
>
> F. added delay with extra round-trip
>
> It was pointed out that if the FA is allowed to deny a regional
> registration because it doesn't support that GFA, this means
> one extra
> round-trip before the registration is completed, which could
> lead to extra
> delay for traffic.
>
> - That is true, but I still think we should allow this
> feature because:
> *  the first "round-trip" is very short, only to the FA and back.
> * FAs in the same domain should in most cases support the
> same GFAs so this
> would not happen very often.
> * allowing an FA to deny the use of a specific GFA would be
> useful, for
> example if a GFA breaks down, since it would force the MN to
> register a new
> GFA with it's HA.
> * the FA needs a way to deny unvalid registrations, in this case if a
> mobile node uses a non-existent CoA in the registration request.
>
> Therefore I propose that we don't change this.
>

I DISAGREE.

There is a big difference between the standard proposing a behavior for the Foreign
Agent to be used in case the Mobile Node did not follow the standard, like in the case
when the FA receives a Registration Request with an invalid care-of address, as
indicated in RFC3220, and of a protocol allowing the Mobile Node to act NORMALLY
and STANDARD COMPLIANT and the same time considers it as an error scenario.
 
> Regards,
> Annika
>
>

------_=_NextPart_001_01C1FC40.2652ED80-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 15:21:13 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18805 for ; Wed, 15 May 2002 15:21:12 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17834; Wed, 15 May 2002 13:21:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09722; Wed, 15 May 2002 12:20:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FJJUrP014306 for ; Wed, 15 May 2002 12:19:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4FJJTeB014305 for mobile-ip-dist; Wed, 15 May 2002 12:19:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FJJQrP014298 for ; Wed, 15 May 2002 12:19:26 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09198 for ; Wed, 15 May 2002 12:19:30 -0700 (PDT) Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA21542 for ; Wed, 15 May 2002 12:19:30 -0700 (PDT) Received: from unknown (HELO EmadQ) (emadaq@194.165.157.37 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 15 May 2002 19:19:28 -0000 Reply-To: From: "Emad Qaddoura" To: "'Annika Jonsson'" , Subject: RE: [mobile-ip] Regional Registration Last Call issue #3-DISAGREE Date: Wed, 15 May 2002 22:18:18 +0200 Message-ID: <000001c1fc4d$a9ab9440$259da5c2@EmadQ> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <5.1.0.14.0.20020514151146.0286d940@era-t.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Pls see comments below on issue F. > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > ip@sunroof.eng.sun.com] On Behalf Of Annika Jonsson > Sent: Wednesday, May 15, 2002 9:54 AM > To: mobile-ip@sunroof.eng.sun.com > Subject: [mobile-ip] Regional Registration Last Call issue #3 > > Hi > > Here are my conclusions and proposals for additions/changes to solve most > of the technical issues raised during last call of Regional > Registrations. I have excluded the issues around multiple levels of > hierarchies, which will be dealt with separatley. > > Respond as to whether you AGREE, DISAGREE, or CAN LIVE WITH the > recommendation. And on the response put in the subject line, CLARIFICATION > if you have a clarification to recommend, or ISSUE if you have an issue to > raise. > > A. Differnet addressing realms. > > The issues raised about supporting different addressing realms between > FA-GFA and GFA-HA (i.e. the GFA is placed on the border between those > addressing realms). The basic problem is how to allow for flexibility in > addressing between FA-GFA and GFA-HA, which does not work with the way the > draft specifies the use of GFA CoA today. To allow this, it should be the > GFA that decides wich CoA to use, possibly individually for each MN. To > support this, the following changes are proposed: > > - clarify that a MN that supports regional registrations SHOULD send home > registrations with a zero CoA, to allow the GFA to allocate CoA. (it is > SHOULD and not MUST, because if the MN's HA doesn't support regional > registrations, it should be allowed to use an advertised CoA, see mail on > issue #2). An FA can force the use of zero CoA by not advertising any CoA > address, but it will then not be backwards compatible (see mail on issues > #2). This will be clarified in section 4.1. > > - change the allocation of CoA if the MN uses zero COA in the > registration: > in the draft right now, it is the FA that decides what CoA the MN gets. > This should be changed so that the FA only forwards the registration to a > GFA node (using an address in the address realm between the FA-GFA). Then > the GFA selects the CoA (possibly based on the MN:s HA address, or MN-NAI > if present, or information from AAA server etc...), adds GFA IP extension, > protects it with FA-HA auth- extension and sends it to the HA. This will > be > changed in section 4.2, 4.3 and 8.1. > > - clarifiy that if the FA advertises a GFA CoA, this is regarded as a > "default" CoA that could be used, especially by MN:s that supports > regional > registrations, but have HA:s that don't. If this CoA is not within the > same > addressing realm as the FA-GFA, the FA needs to have a mapping to the > address that it should use to communicate with the GFA. This will be added > to section 4.2 > > B. too many options. > > Some people commented that it is a problem with too may optional ways to > do > things, since it would be difficlut to imlement and can create problems > for > interoperability. > > - Most of the options are around the advertised addresses and what address > the mobile node uses in registration messages. Hopefully this is much > better now that we clarifies the use of those addresses both for backwards > compatibility and for different addressing realms, so I consider this > issue > solved > > C. protection of the GFA IP address extension > > It was pointed out that the GFA IP address extension needs to be protected > by an authentication extension. > > - this should be clarified in section 4.3. > > D. reverse tunnelling clarification > > It was pointed out that if reverse tunnelling is used, the FA must use the > address in the registration request (from the HFA extension) as source for > the tunnel. > > - this should be clarified in section 4.2 and 4.3. > > E. Generalized NAI extension > > There was a question about why the Generalized NAI extension is needed, > why > not use an FA-NAI extension directly? > > - RFC3220 recommends that new extensions should be in this format if > possible. Therefore I propose that we keep this. > > F. added delay with extra round-trip > > It was pointed out that if the FA is allowed to deny a regional > registration because it doesn't support that GFA, this means one extra > round-trip before the registration is completed, which could lead to extra > delay for traffic. > > - That is true, but I still think we should allow this feature because: > * the first "round-trip" is very short, only to the FA and back. > * FAs in the same domain should in most cases support the same GFAs so > this > would not happen very often. [<<>>] I don't agree with this justification. Every MS adds up. > * allowing an FA to deny the use of a specific GFA would be useful, for > example if a GFA breaks down, since it would force the MN to register a > new > GFA with it's HA. [<<>>] I agree it would help and handling such case should be part of the protocol. But, the key here, as stated in sec 5.0 (4th paragraph), the GFAs are in the SAME DOMAIN, and may be the protocol should allow a re-direction of the request to another GFA within the domain, update the MN with the new address in the reply and allow the transaction to continue without the additional delay. > * the FA needs a way to deny unvalid registrations, in this case if a > mobile node uses a non-existent CoA in the registration request. > > Therefore I propose that we don't change this. > > Regards, > Annika From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 15:36:56 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19610 for ; Wed, 15 May 2002 15:36:55 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26308; Wed, 15 May 2002 13:37:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16537; Wed, 15 May 2002 12:36:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FJU8rP014339 for ; Wed, 15 May 2002 12:30:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4FJU8ee014338 for mobile-ip-dist; Wed, 15 May 2002 12:30:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FJU5rP014331 for ; Wed, 15 May 2002 12:30:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11446 for ; Wed, 15 May 2002 12:30:07 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA26226 for ; Wed, 15 May 2002 13:30:06 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 15:26:40 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] AAA Keys related draft Date: Wed, 15 May 2002 15:26:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi folks, this is just an FYI. Bernard Aboba called my attention to this draft and we agreed it is something that folks on this list may be interested in: http://search.ietf.org/internet-drafts/draft-walker-aaa-key-distribution-00. txt. Phil From owner-mobile-ip@sunroof.eng.sun.com Wed May 15 16:40:27 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21715 for ; Wed, 15 May 2002 16:40:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01664; Wed, 15 May 2002 14:40:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10361; Wed, 15 May 2002 13:40:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FKcmrP014589 for ; Wed, 15 May 2002 13:38:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4FKcm27014588 for mobile-ip-dist; Wed, 15 May 2002 13:38:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4FKcjrP014581 for ; Wed, 15 May 2002 13:38:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA09751 for ; Wed, 15 May 2002 13:38:49 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29170 for ; Wed, 15 May 2002 14:38:48 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4FKcvV25830; Wed, 15 May 2002 15:38:57 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 15:38:47 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCCF1@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Annika Jonsson'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call issue #3 Date: Wed, 15 May 2002 15:38:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC50.7F01EB60" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FC50.7F01EB60 Content-Type: text/plain; charset="iso-8859-1" Hello Annika, Clarification: Missing technical issue 1: In section 4.1 the third paragraph it talks about Mobile Nodes with co-located care-of address and the way it uses Regional Registration. This section is under Home Registration. This means that it does not talk about the Regional Registration mechanism YET. Because that has a separate section No. 5. Now in the third paragraph section 4.1 as shown below, it talks about the Mobile Node adding a Hierarchical Foreign Agent extension and to be placed after the MN-HA authentication extension in Registration Request message. Also, to be protected by the MN-GFA authentication extension. It also continues to say using the mobility security association which has been established with GFA according to section 3.1.2. " ........... In this case, the mobile node MUST add a Hierarchical Foreign Agent extension 8.2, including its co-located care-of address, to the Registration Request before sending it. The Hierarchical Foreign Agent extension SHOULD be placed after the MN-HA authentication extension. It SHOULD be authenticated by using the MN-GFA authentication extension (see Section 10). The authentication data SHOULD be calculated using a mobility security association that has been established with the GFA (Section 3.1.2). ........... " I am really confused here for the following points: 1. We are talking about Home registration. Which I understand is the initial registration with the Mobile Node Home Agent or when it changes GFA. However, the text talk about the initial registration request here. 2. Now at this point of time, there is no established mobility security association between the mobile Node and GFA. 3. section 3.1.2, talks about using the mobility security association, which has been established during the initial (Home Registration), in Regional Registration NOT Home Registration. 4. In other words, Mobile Node does not have a mobility security association with the GFA at the time of initial or Home registration that paragraph 3 talks about. Am I correct ? or I am missing something. Clarification: Technical issue 2: In section 8.3 paragraph 3: " The mobile node SHOULD append the Replay Protection Style Extension to the home registration following the MN-HA authentication extension, but before any MN-GFA authentication extension. Then, the GFA can remove the extension without damaging the MN-HA authentication data needed by the home agent. " Do we assume here that there is a statically preconfigured security association between the MN and GFA which include a secret key? This issue is very much related with Technical issue No. 1. Clarification: Technical issue 3: In section 5.3. First Paragraph: " If the GFA accepts a request for regional registration, it MUST set the lifetime to be no greater than the remaining lifetime of the mobile node's registration with its home agent, and put this lifetime into the corresponding Regional Registration Reply. The GFA MUST NOT accept a request for a regional registration if the lifetime of the mobile node's registration with its home agent has expired. In that case the GFA sends a Regional Registration Reply with the value in the Code field set to HOME_REG_EXPIRED. " Are you suggesting that the GFA keeps the binding of the Mobile Node EVEN after the Home registration lifetime has already expired? Clarification: Technical issue 4: This is not a technical issue per say BUT it is important in my view: Why you are suggesting two different extensions with two different types for the following extensions: 1. GFA IP Address Extension 2. Hierarchical Foreign Agent Extension. CAN'T we use one extension as per MEIR originally and RFC3220 recently with one TYPE and two different subtypes. You never know, those type numbers are going to be very precious in the very near future!!! Regards; Ahmad Muhanna ------_=_NextPart_001_01C1FC50.7F01EB60 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Regional Registration Last Call issue #3

Hello Annika,

Clarification: Missing technical issue 1:

In section 4.1 the third paragraph it talks about Mobile Nodes
with co-located care-of address and the way it uses
Regional Registration. This section is under Home Registration.
This means that it does not talk about the Regional Registration mechanism
YET. Because that has a separate section No. 5.

Now in the third paragraph section 4.1 as shown below, it talks about the
Mobile Node adding a Hierarchical Foreign Agent extension and to be placed
after the MN-HA authentication extension in Registration Request message.
Also, to be protected by the MN-GFA authentication extension. It also continues
to say using the mobility security association which has been established with
GFA according to section 3.1.2.

" ...........
   In this case, the mobile node MUST add a
   Hierarchical Foreign Agent extension 8.2, including its co-located
   care-of address, to the Registration Request before sending it.  The
   Hierarchical Foreign Agent extension SHOULD be placed after the MN-HA
   authentication extension.  It SHOULD be authenticated by using the
   MN-GFA authentication extension (see Section 10).  The authentication
   data SHOULD be calculated using a mobility security association
   that has been established with the GFA (Section 3.1.2). ...........
"

I am really confused here for the following points:
1. We are talking about Home registration. Which I understand is the initial
registration with the Mobile Node Home Agent or when it changes GFA. However,
the text talk about the initial registration request here.
2. Now at this point of time, there is no established mobility security association
between the mobile Node and GFA.
3. section 3.1.2, talks about using the mobility security association, which has been
established during the initial (Home Registration), in Regional Registration NOT Home
Registration.
4. In other words, Mobile Node does not have a mobility security association with the
GFA at the time of initial or Home registration that paragraph 3 talks about.

Am I correct ? or I am missing something.


Clarification: Technical issue 2:
In section 8.3 paragraph 3:
"
   The mobile node SHOULD append the Replay Protection Style Extension
   to the home registration following the MN-HA authentication
   extension, but before any MN-GFA authentication extension.  Then,
   the GFA can remove the extension without damaging the MN-HA
   authentication data needed by the home agent.
"

Do we assume here that there is a statically preconfigured security association
between the MN and GFA which include a secret key?

This issue is very much related with Technical issue No. 1.


Clarification: Technical issue 3:
In section 5.3. First Paragraph:

" If the GFA accepts a request for regional registration, it MUST set
   the lifetime to be no greater than the remaining lifetime of the
   mobile node's registration with its home agent, and put this lifetime
   into the corresponding Regional Registration Reply.  The GFA MUST NOT
   accept a request for a regional registration if the lifetime of the
   mobile node's registration with its home agent has expired.  In that
   case the GFA sends a Regional Registration Reply with the value in
   the Code field set to HOME_REG_EXPIRED.
"

Are you suggesting that the GFA keeps the binding of the Mobile Node EVEN
after the Home registration lifetime has already expired?


Clarification: Technical issue 4:
This is not a technical issue per say BUT it is important in my view:

Why you are suggesting two different extensions with two different types
for the following extensions:

1.      GFA IP Address Extension
2.      Hierarchical Foreign Agent Extension.

CAN'T we use one extension as per MEIR originally and RFC3220 recently
with one TYPE and two different subtypes.
You never know, those type numbers are going to be very precious
in the very near future!!!


Regards;
Ahmad Muhanna

 

------_=_NextPart_001_01C1FC50.7F01EB60-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 01:44:02 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05318 for ; Thu, 16 May 2002 01:44:01 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA10065; Wed, 15 May 2002 22:42:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA02768; Wed, 15 May 2002 22:42:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G5f8rP015507 for ; Wed, 15 May 2002 22:41:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4G5f85C015506 for mobile-ip-dist; Wed, 15 May 2002 22:41:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G5f5rP015499 for ; Wed, 15 May 2002 22:41:05 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA02636 for ; Wed, 15 May 2002 22:41:09 -0700 (PDT) From: arvind.sevalkar@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA12789 for ; Wed, 15 May 2002 22:41:08 -0700 (PDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002051611145951:1539 ; Thu, 16 May 2002 11:14:59 +0530 Subject: Re: [mobile-ip] Sending Binding Acknowledgement with routing header. To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Thu, 16 May 2002 11:10:55 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/16/2002 11:11:31 AM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/16/2002 11:14:59 AM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/16/2002 11:15:02 AM, Serialize complete at 05/16/2002 11:15:02 AM Message-ID: X-Priority: 3 (Normal) Content-type: text/plain; charset=iso-2022-jp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Keiichi SHIMA / $BEg7D0l(B To: arvind.sevalkar@lntinfotech.com Subject: Re: [mobile-ip] Sending Binding Acknowledgement with routing header. 05/15/2002 02:50 PM From: arvind.sevalkar@lntinfotech.com > I think in draft nowhere it is mentioned that MN will send BU when it > receives packet without routing header. MN will send BU when it receives > tunneled packet, right ? Yes. I think the following two are same. - check if the packet is tunneled like below or not. [src:HA][dst:MNCoA]([src:HA][dst:MNHoA](payload)) - check if the packet doesn't have a mip6 routing header like below or not. [src:HA][dst:MNHoA](payload) If the MN receives a packet sent from some address to its home address without routing header, we can conclude that the peer doesn't have a binding. The original idea of this algorithm is presented by Hesham Soliman on the mobile-ip mailing-list <034BEFD03799D411A59F00508BDF754603008B1F@esealnt448.al.sw.ericsson.se> > And as BA is send to the source address of the BU message and source > address of the BU message is the COA, so for COA there will be no any > binding exist in the Binding Cache as key for searching Binding Cache is > the Home address, so CN will not add routing header..... A BU is sent with a HAO. It looks that the packet is logically sent from the home address of the MN. Since the source address of the BU is the home address of the MN, the HA will send a BA to the home address of the MN. At this point, the HA has a valid binding cache entry for the MN. As a result, a routing header will be inserted as a normal outgoing packet processing. ==>> when MN sends Binding Update to HA, it sends with HAO, but when MN sends Binding Update to CN it will not include HAO. refer section 9.4.1 Receiving binding Update in "Mobile ip Draft- 17". so if we send BA to the source address of BU, then BA will be sent without routing header, and if type 2 routing header is to be added we have to take Home address of MN from the Home Address field of BU Message and then send BA with destination address as a home address. an I right.. ? Arvind From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 02:37:38 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14484 for ; Thu, 16 May 2002 02:37:37 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28672; Wed, 15 May 2002 23:35:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA17457; Wed, 15 May 2002 23:35:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G6YwrP015592 for ; Wed, 15 May 2002 23:34:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4G6Yvpe015591 for mobile-ip-dist; Wed, 15 May 2002 23:34:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G6YsrP015584 for ; Wed, 15 May 2002 23:34:55 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA21610 for ; Wed, 15 May 2002 23:34:57 -0700 (PDT) Received: from web11305.mail.yahoo.com (web11305.mail.yahoo.com [216.136.131.208]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA01715 for ; Wed, 15 May 2002 23:34:57 -0700 (PDT) Message-ID: <20020516063457.31726.qmail@web11305.mail.yahoo.com> Received: from [212.33.195.204] by web11305.mail.yahoo.com via HTTP; Wed, 15 May 2002 23:34:57 PDT Date: Wed, 15 May 2002 23:34:57 -0700 (PDT) From: Osama Younis Subject: [mobile-ip] Re: Welcome to mobile-ip To: mobile-ip@sunroof.eng.sun.com In-Reply-To: <200205160624.g4G6OJul015567@sunroof.eng.sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --- Majordomo@sunroof.eng.sun.com wrote: > -- > > Welcome to the mobile-ip mailing list! > > Please save this message for future reference. > Thank you. > > If you ever want to remove yourself from this > mailing list, > you can send mail to > with the following > command in the body of your email message: > > unsubscribe mobile-ip osamayy@yahoo.com > > If you ever need to get in contact with the owner of > the list, > (if you have trouble unsubscribing, or have > questions about the > list itself) send email to > . > This is the general rule for most mailing lists when > you need > to contact a human. > > Here's the general information for the list you've > subscribed to, > in case you don't already have it: > > > This is the IETF Mobile-IP Working Group discussion > list. > > To post a message to the list, send it to > . > > The mailing list archives are at > http://playground.sun.com/mobile-ip/ . > > >>> DO NOT SEND ADMINISTRATIVE QUERIES ABOUT THE > LIST TO mobile-ip. > > All routine queries should be sent to > majordomo@sunroof.eng.sun.com. > This includes adding, removing, or changing any > subscriber(s) e-mail > address. If you need human intervention, send mail > to > . > __________________________________________________ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 03:13:40 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15588 for ; Thu, 16 May 2002 03:13:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27694; Thu, 16 May 2002 01:13:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA25633; Thu, 16 May 2002 00:13:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7CFrP015730 for ; Thu, 16 May 2002 00:12:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4G7CET5015729 for mobile-ip-dist; Thu, 16 May 2002 00:12:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7C5rP015712 for ; Thu, 16 May 2002 00:12:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA28161 for ; Thu, 16 May 2002 00:12:08 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07530 for ; Thu, 16 May 2002 01:12:07 -0600 (MDT) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 03:12:07 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46E21F6F@ftmail> From: "Alan O'Neill" To: Annika Jonsson , Phil Roberts , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RRn Last Call Resolution Issue #2 - DISAGREE Date: Thu, 16 May 2002 03:12:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Annika, The reason I DISAGREE here is with the 'I' bit representing regional tunnel management, whereas I think we actually need separate bits for indicating support for the signalling extensions and for the associated forwarding model in the data plane. The 'I' bit should mean regional signalling in my book. My reasons are obvious because Nested/Concat would like to share the regional signalling model, extensions, backwards compatibility, security and message flows. If these are tied in with GFA then I will have to do it all again myself and interoperability will be horrendous, and we all have more standards work etc (assuming people understand the benefits of layered - Nested/Concat - MIP). It also makes the support of GFA forwrding under the layered model pretty messy. So then we can make an additional request to have an FAA bit for Nested, one for Concat and another for GFA type forwarding, which is clean and efficient, with each bit being justified by deployment demands. This is very clean IMO but flag inefficient. We could instead just use and all share the 'I' bit which is flag efficient but opens up the potential for confusion. Now I don't expect this request to be blindly accepted because it will only be reasonable if GFA is not overly affected by it. So here is the potential (zero?) effect as justification.. If the I bit means regional signalling and that the second FAA address is a regional address then it can be interpreted a number of ways clearly by a MN. Only Layered (Nested/Concat) MNs can see the regional information in the FA-NAI. So a MN that only knows GFA will correctly interpret the I bit with no side effects. A mobile that reads the FA-NAI and sees the regional information will know that layered is supported. The FA knows whether GFA or Layered has been requested because for GFA forwarding, the advertised GFA address in the FAA is optionally used in the home registration, inserted into the CoA field or that field is zero. In Layered MIP, the RMA address in the FAA is first used in the regional registration to the RMA as the HA address, or that address is zero, whilst the CoA field contains the FA CoA from the FAA. Essentially GFA does home then regional reg whilst Layered MIP does regional then home reg, and hence can be clearly differentiated even without using a new extension into the MIP Reg. Of course this can also be made easy with new MIP message types or extensions but I am ignoring that for now to shorted the discussion A final alternative would be for Layered MIP to have its own bits to distinguish forwarding and signalling plane capabilities and we then bite the bullet of having competing regional signalling planes. Certainly less to argue about in the short term. This might also then be helped if the RegTun docs can be structured so that Layered with Nested/Concat/GFA type forwarding can still re-use as much as possible from those docs... (Oh and I forgot that other unmentionable option of Layered MIP not being addressed by the wg.. :-) Feedback greatly appreciated, Regards, Alan. -----Original Message----- From: Annika Jonsson [mailto:annika.jonsson@ericsson.com] Sent: 14 May 2002 19:17 To: Phil Roberts; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #2 At 03:37 PM 5/13/2002 -0400, Phil Roberts wrote: >We would like to know whether folks agree or disagree with these >proposed resolutions. > >Annika, we're going to need proposed text for each of them, and a >pointer to where it would go in the draft. se below... >Thanks, >Phil > > > > -----Original Message----- > > From: Annika Jonsson [mailto:annika.jonsson@ericsson.com] > > Sent: Monday, May 13, 2002 11:53 AM > > To: mobile-ip@sunroof.eng.sun.com > > Subject: [mobile-ip] Regional Registration Last Call > > Resolution Issue #2 > > > > > > Hi > > > > Here are my conclusions and proposals for additions/changes > > to solve the > > backwards compatibility issues in the Regional Registrations draft: > > > > A: Backwards compatibility with RFC3220 MN:s. > > FA:s must advertise their own address, since it is used for movement > > detection by RFC3220 MN:s. This requires one change and one > > clarification > > to the draft: > > - To be backwards compatible, if the FA only advertises one > > CoA it must be > > its own address (not the GFA address as specified now). This > > FA must be > > able to act as a normal RFC3220 FA (that's in the draft already). This would go into section 3.3. It would be changed to: " 3.3. Advertising Foreign Agent and GFA A foreign agent typically announces its presence via an Agent Advertisement message [9]. If the domain to which a foreign agent belongs supports regional registrations, the following changes are applied to the Agent Advertisement message. The `I' flag (see Section 7) MUST be set to indicate that the domain supports regional tunnel management. If the `I' bit is set, there MUST be at least one care-of address in the Agent Advertisement message, but that address MAY be set to zero. If the `I' bit is set, and there is only one care-of address (i.e. not zero), it is the address of the FA. If the `I' bit is set, and there are multiple care-of addresses, the first care-of address is the local FA, and the last care-of address is the GFA. The FA-NAI (see section 7.2) SHOULD also be present to enable the mobile node to decide whether or not it is in its home domain. The decision is based on whether the realm part of the advertised FA-NAI matches the mobile node's realm. " > > - clarify that if the FA advertises a zero address, it will > > not support > > RFC3220 MN:s. In some cases the owner of the network might > > prefer this. > > > > A new section about backwards compatibility: "3.4 Backwards compatibility with RFC3220 A domain that supports Regional Regisratiosn SHOULD also be backwards compatible with RFC3220. If the Foreign Agent does not advertise a zero care-of-address, it MUST support registrations according to Mobile IPv4 [9]. This allows mobile nodes that doesn't support Regional Registrations to register via this Foreign Agent using standard Mobile IPv4. If the Foreign Agent advertises both its own care- of address and a GFA care-of address, a mobile node that supports Regional Registrations but has a Home Agent that doesn't, will still be able to make use of Regional Registrations through that GFA care-of address. A Foreign Agent that advertises a zero care-of address will not be backwards compatible wiht RFC3220, since both mobile nodes and Home Agents have to understand the zero care-of address. If the mobile node sets the care-of address to zero, the mobile node and its home agent MUST support the GFA IP address extension." > > > B: Backwards compatibility with RFC3220 HA:s > > The problem here is that an RFC 3220 HA does not understand > > the GFA IP > > extension used if the MN sends a registration with zero CoA. > > There are two > > ways to solve this: > > > > B1: According to the draft right now, the MN MUST NOT send a > > Registration > > Request with zero CoA if it's HA doesn't support that. This > > is simple, but > > not very flexible. If the FA advertises a GFA CoA (in > > addition to the FA > > CoA), the MN should use that, and can then make use of regional > > registrations even though it's HA does not support it. If the FA only > > advertises it's own address, the MN can not make use of regional > > registration unless it's HA supports it, but can still use > > normal Mobile > > IP. An FA that only advertises a zero address will not be > > backwards compatible. > > > > B2: The other alternative is that the draft could be changed > > by adding a > > new error code from the GFA to tell the MN that the HA did > > not support the > > GFA IP extension. The MN could then try the advertised CoA > > instead (or, > > possibly, a new extension added so the the GFA could tell the > > MN what CoA > > to use). > > > > I see one problem with this: I'm not sure how an RFC3220 HA > > would deal with > > this kind of registration. In the draft today, the GFA IP > > extension is > > non-skippable (because the HA MUST support it if the MN uses > > it). A HA that > > doesn't support this would not answer to this registration at > > all, it would > > silently discard the message. > > > > If the extension was changed to be skippable, how would the HA react? > > Either it would notice that something is wrong with the CoA, > > and send a > > reply with some error code (e.g. "poorly formed request??). > > Or it would not > > even check the CoA (I couldn't find this mentioned anywhere > > in RFC3220). In > > this case it would accept the registration, and set the CoA > > to zero. The > > GFA will then receive a reply without a GFA IP extension. In > > both cases, > > the GFA _could_ assume that the HA did not support the GFA IP > > extension, > > but it doesn't know for sure. > > > > To conclude: this option (B2) seems too uncertain, so I would > > rather go for > > the (more unflexible, but simple) B1 (i.e. no changes to the > > current draft, > > but it could be clarified a bit). > > see the proposed new section 3.4 above. /Annika > > > /Annika > > From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 03:15:18 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15719 for ; Thu, 16 May 2002 03:15:17 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA12217; Thu, 16 May 2002 00:13:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA25706; Thu, 16 May 2002 00:13:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7C9rP015727 for ; Thu, 16 May 2002 00:12:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4G7C9VM015726 for mobile-ip-dist; Thu, 16 May 2002 00:12:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7C5rP015713 for ; Thu, 16 May 2002 00:12:05 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA28160 for ; Thu, 16 May 2002 00:12:08 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07531 for ; Thu, 16 May 2002 01:12:07 -0600 (MDT) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 03:12:07 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46E21F6E@ftmail> From: "Alan O'Neill" To: Annika Jonsson , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #2 Date: Thu, 16 May 2002 03:11:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Annika, DISAGREE (somewhat..) I would suggest we explore B2 a bit more first. We need to clarify what 3220 should have said then, given that, clarify how a HA should respond to a CoA = 0. The CoA must be checked by the HA to ensure that CoA != HoA, which ceases the existing binding. Given this check, and the fact that a 0.0.0.0 destination address is illegal, then replying with a malformed error code message is optimal. Given this, the GFA can check the error code and decide if it wishes to offer a GFA CoA to the MN. If it is offered then the MN can retry. If the MN only uses this when it knows its HA supports it then we are fine. If the MN knows the HA doesn't support it then why did the MN send it...ie this is merely covering a dark corner case which the GFA error code processing is giving us a way out of.. ? Now if the MN knows the HA does not support GFAIPext then it needs to do something else, and clearly avoiding sending a CoA=0 is good. In this case it can only use the advertised GFA CoA in the FAA. This has all the problems related to disparate address spaces... if the GFA CoA is a private address then it can only work with FAs, GFAs and HAs in the same addressing domain if the GFA CoA is a public address then it can only work with publicly reachable HAs, GFAs and FAs leaving a corporate set of GFAs / FAs publicly exposed (not good) We can add some text that says if the MN knows that its HA is in the same domain as the FA/GFA then it can use the private GFA CoA. Similarly for a public address. All of this then looks fine apart from the fact that the MN really has no way to know the relationship between the FA, GFA and HA, and requiring public addresses everywhere is a practical no-no. So the MN can only try the default CoA blindly to use regional registration which the GFA or HA might then fail given the GFA-HA address space. What then comes back...probably a mal-formed error message which should cause the GFA to allocate an appropriate GFA CoA if possibly...ie we still need this mechanism and it is here that it is most important because this is not a corner case.. Therefore if we combine B1 and B2, convert the MUST NOT to SHOULD NOT wrt CoA=0 and use of a GFA CoA from the wrong space, and allow the GFA to return a GFA CoA in all Replies then we are great..this is good useful information that the FA as well as the MN can use (for the mapping stuff). We can then leave it up to the MN whether or not it tries again, and allow the FA to strip the GFA CoA if it wishes to deny that repeat attempt given the HA or GFA error message. Hope this makes sense...another RTT may well be necessary though... -----Original Message----- From: Annika Jonsson [mailto:annika.jonsson@ericsson.com] Sent: 14 May 2002 01:23 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #2 Hi Here are my conclusions and proposals for additions/changes to solve the backwards compatibility issues in the Regional Registrations draft: A: Backwards compatibility with RFC3220 MN:s. FA:s must advertise their own address, since it is used for movement detection by RFC3220 MN:s. This requires one change and one clarification to the draft: - To be backwards compatible, if the FA only advertises one CoA it must be its own address (not the GFA address as specified now). This FA must be able to act as a normal RFC3220 FA (that's in the draft already). - clarify that if the FA advertises a zero address, it will not support RFC3220 MN:s. In some cases the owner of the network might prefer this. B: Backwards compatibility with RFC3220 HA:s The problem here is that an RFC 3220 HA does not understand the GFA IP extension used if the MN sends a registration with zero CoA. There are two ways to solve this: B1: According to the draft right now, the MN MUST NOT send a Registration Request with zero CoA if it's HA doesn't support that. This is simple, but not very flexible. If the FA advertises a GFA CoA (in addition to the FA CoA), the MN should use that, and can then make use of regional registrations even though it's HA does not support it. If the FA only advertises it's own address, the MN can not make use of regional registration unless it's HA supports it, but can still use normal Mobile IP. An FA that only advertises a zero address will not be backwards compatible. B2: The other alternative is that the draft could be changed by adding a new error code from the GFA to tell the MN that the HA did not support the GFA IP extension. The MN could then try the advertised CoA instead (or, possibly, a new extension added so the the GFA could tell the MN what CoA to use). I see one problem with this: I'm not sure how an RFC3220 HA would deal with this kind of registration. In the draft today, the GFA IP extension is non-skippable (because the HA MUST support it if the MN uses it). A HA that doesn't support this would not answer to this registration at all, it would silently discard the message. If the extension was changed to be skippable, how would the HA react? Either it would notice that something is wrong with the CoA, and send a reply with some error code (e.g. "poorly formed request??). Or it would not even check the CoA (I couldn't find this mentioned anywhere in RFC3220). In this case it would accept the registration, and set the CoA to zero. The GFA will then receive a reply without a GFA IP extension. In both cases, the GFA _could_ assume that the HA did not support the GFA IP extension, but it doesn't know for sure. To conclude: this option (B2) seems too uncertain, so I would rather go for the (more unflexible, but simple) B1 (i.e. no changes to the current draft, but it could be clarified a bit). /Annika From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 03:15:28 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15736 for ; Thu, 16 May 2002 03:15:27 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15877; Thu, 16 May 2002 00:13:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA25685; Thu, 16 May 2002 00:13:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7C1rP015710 for ; Thu, 16 May 2002 00:12:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4G7C0gd015709 for mobile-ip-dist; Thu, 16 May 2002 00:12:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7BvrP015702 for ; Thu, 16 May 2002 00:11:57 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA28141 for ; Thu, 16 May 2002 00:12:00 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA17098 for ; Thu, 16 May 2002 01:12:30 -0600 (MDT) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 03:11:59 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46E21F6D@ftmail> From: "Alan O'Neill" To: Phil Roberts , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] RR Last Call Resolution Issue #4 - CLARIFICATION Date: Thu, 16 May 2002 03:11:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I think this is maybe a bit of a red herring wg for the following reasons. MIP is a soft-state refresh protocol with periodic refresh as a fraction of the binding lifetime. Any arguments about statefulness come down to the refresh interval you are prepared to tolerate in return for higher availability through reduced unavailability when a node crashes. When a router goes down we are typically happy to wait for OSPF convergence times which are large numbers of seconds. We shouldn't ask for much more from MIP. Adding a GFA or an RMA (from Nested) doesn't change the flexibility of the operator and/or MN to tune lifetimes, and having a big router or a big regional element fail impacts just as many flows for OSPF convergence time so I feel that is also a bit of a red herring. especially in a tree network.. The bigger but different problem here is that costly and localised high availability solutions (hot-standby) that vendors would try to use to protect the regional element whilst also having long lifetimes to reduce the signalling overhead, do not work with GFA because the HA must also be updated. This is why the RMA places a routable MN specific address in the HA so that these hot-standby techniques can still be localised. This is the aspect of GFA that is problematic here... Alan. -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: 15 May 2002 05:55 To: 'mobile-ip@sunroof.eng.sun.com' Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Several folks raised the issue of to what extent introducing regional registration entities in the visited network violates principles of the Internet architecture, specifically with regard to the introduction of single points of failure in the communication path of visiting nodes. I've excerpted the relevant text from rfc 1958 on the architectural principle which is at issue. "The end-to-end argument is discussed in depth in [Saltzer]. The basic argument is that, as a first principle, certain required end- to-end functions can only be performed correctly by the end-systems themselves. A specific case is that any network, however carefully designed, will be subject to failures of transmission at some statistically determined rate. The best way to cope with this is to accept it, and give responsibility for the integrity of communication to the end systems. Another specific case is end-to-end security. To quote from [Saltzer], "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.") This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). An immediate consequence of this is that datagrams are better than classical virtual circuits. The network's job is to transmit datagrams as efficiently and flexibly as possible." draft-iab-arch-changes-00.txt provides a discussion of this issue of fate-sharing in middleboxes and asserts that the principle is preserved in the case that the middlebox is a partner in the communication when the failure can be detected and dealt with.: "The idea of fate-sharing survives this recursion, but requires that all application state created in middleboxes must be capable of re- creation after failure. Additionally, to support this requirement, where a function cannot be fulfilled completely, reliably and securely by two endpoints of a conversation, the necessary middleboxes to fulfil the function should be explicit partners in explicit communication with at least one endpoint (or, by recursion of the same principle, with an intermediate middlebox). In other words, middleboxes should not be invisible, because their failures need to be detected and dealt with by their communication partners." As currently specified it's not immediately obvious how the regional registration agents are compatible with the above guidelines. It's conceivable that they can be made so, and perhaps it's immediately obvious to others how they are so. This issue is not insurmountable but the functionality does need to be specified in a way that preserves the fate sharing principle and allows for one party in the communication to detect and deal with a failure of one of the new registration entities. From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 03:25:13 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15882 for ; Thu, 16 May 2002 03:25:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22314; Thu, 16 May 2002 01:25:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA28623; Thu, 16 May 2002 00:24:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7NbrP015816 for ; Thu, 16 May 2002 00:23:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4G7NbYR015815 for mobile-ip-dist; Thu, 16 May 2002 00:23:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7NWrP015801 for ; Thu, 16 May 2002 00:23:32 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA00358 for ; Thu, 16 May 2002 00:23:36 -0700 (PDT) From: Padmakumar.AV@lntinfotech.com Received: from ltitlin.lntinfotech.com ([203.199.54.35]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20173 for ; Thu, 16 May 2002 00:23:33 -0700 (PDT) Received: from bangalore.lntinfotech.com ([172.29.4.3]) by ltitlin.lntinfotech.com (Lotus Domino Release 5.0.8) with ESMTP id 2002051612533786:13740 ; Thu, 16 May 2002 12:53:37 +0530 Subject: Re: [mobile-ip] mobile-ip] Where to insert HAO? To: Vladislav Yasevich Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 16 May 2002 09:35:57 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/16/2002 12:50:07 PM, Itemize by SMTP Server on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/16/2002 12:53:38 PM, Serialize by Router on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/16/2002 12:54:21 PM, Serialize complete at 05/16/2002 12:54:21 PM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, You wrote: >The draft actually defined a new destination option header >location (in addition to the ones defined in 2460). This >location is what you described in your message. >For example: > IPv6 [ HbH [ Dest{1} [ Rtrhdr [ Dest (HOA) [ Frag ...]]]]] But I think RFC-2460 also says that Destination option header can occur utmost twice. So as per your interpretation we have to add a new destination option header, which is destination option {2} (since 0 and 1 being outer and 1 being inner destination options) right? >However, I believe that'll change in the next revision since >The HOA will be a parameter in the Mobility Header. I believe this may not be applicable always since BU to HA require a HAO and this has to be replaced with the COA before the Authentication or ESP header processing is done and more over if we want route optimization any upper layer packet to CN should also have the HAO (if CN has a binding with the MN). Regards pav Vladislav Yasevich To: Padmakumar.AV@lntinfotech.com Subject: Re: [mobile-ip] mobile-ip] Where to insert HAO? 05/15/2002 08:31 PM The draft actually defined a new destination option header location (in addition to the ones defined in 2460). This location is what you described in your message. For example: IPv6 [ HbH [ Dest{1} [ Rtrhdr [ Dest (HOA) [ Frag ...]]]]] However, I believe that'll change in the next revision since the HOA will be a parameter in the Mobility Header. -vlad Padmakumar.AV@lntinfotech.com wrote: > Hi All, > > Section 6.3 says > "The Home Address option MUST be placed as follows: > > - After the Routing Header, if that header is present > > - Before the Fragment Header, if that header is present > > - Before the AH Header or ESP Header, if either one of those > Headers is present " > "After the Routing Header, if that header is present" does it mean that HAO > has to be placed in the inner destination option header, because outer > destination header usually comes before routing header. > > "Before the Fragment Header, if that header is present" ? ok this rules out > the case of inner destination option header, in this case outer destination > option and routing header both are part of non fragmentable part, but still > outer destination option header comes before routing header (for example in > Linux Ipv6). What if both routing and fragment headers are present? > > "Before the AH Header or ESP Header, if either one of those Headers is > present " this again rules out the use of inner destination header. > > So where should we actually place the HAO? > > Best Regards > pav > > > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 03:25:30 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15917 for ; Thu, 16 May 2002 03:25:29 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22335; Thu, 16 May 2002 01:25:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA28708; Thu, 16 May 2002 00:24:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7NdrP015819 for ; Thu, 16 May 2002 00:23:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4G7Nd56015818 for mobile-ip-dist; Thu, 16 May 2002 00:23:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7NYrP015808 for ; Thu, 16 May 2002 00:23:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA00362 for ; Thu, 16 May 2002 00:23:38 -0700 (PDT) From: Srinivasan.Damodaran@lntinfotech.com Received: from ltitlin.lntinfotech.com ([203.199.54.35]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20190 for ; Thu, 16 May 2002 00:23:36 -0700 (PDT) Received: from bangalore.lntinfotech.com ([172.29.4.3]) by ltitlin.lntinfotech.com (Lotus Domino Release 5.0.8) with ESMTP id 2002051612534049:13752 ; Thu, 16 May 2002 12:53:40 +0530 Subject: [mobile-ip] Receiving Binding Refresh Request To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 16 May 2002 09:42:20 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/16/2002 12:50:09 PM, Itemize by SMTP Server on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/16/2002 12:53:40 PM, Serialize by Router on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/16/2002 12:54:24 PM, Serialize complete at 05/16/2002 12:54:24 PM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi all, I have an issue, regarding the processing of the Binding Refresh Request message. The draft says that "When a mobile node receives a Binding Refresh Request message and there already exists a Binding Update List entry for the source of the Binding Refresh Request, it MAY start a return routability procedure." It also mentions that "the state of the BUL, which has a valid binding changes from "Bound" to "WaitHC" state after processing the BRR message". ( As per Appendix. A) The necessity of the Binding Refresh Request message is to update the Binding Cache of the CN, before the Lifetime expires. But as soon as the mobile node get the BRR message, MN initiate the RR procedure and changes the state to WaitHC. Thereafter the packet to that destination will be reverse tunneled, till the BU procedure is complete. This is almost like initiating RR procedure, after the lifetime expires. Though, MN has a valid remaining time in its BUL, why for just refreshing the Bcache, MN should loose the remaining time of the last Binding and reverse tunnel the packet, till the binding update procedure is complete. Regards, Srinivasan From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 03:29:33 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16109 for ; Thu, 16 May 2002 03:29:33 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA14103; Thu, 16 May 2002 01:29:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA29913; Thu, 16 May 2002 00:29:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7SdrP015858 for ; Thu, 16 May 2002 00:28:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4G7Sd7s015857 for mobile-ip-dist; Thu, 16 May 2002 00:28:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7SZrP015850 for ; Thu, 16 May 2002 00:28:35 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20950 for ; Thu, 16 May 2002 00:28:39 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23744 for ; Thu, 16 May 2002 01:29:08 -0600 (MDT) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 03:28:37 -0400 Message-ID: From: "Alan O'Neill" To: "'Annika Jonsson'" , "'Madhavi W. Chandra'" Cc: "'Phil Roberts'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] RR Last Call Resolution Issue #1 - CLARIFICATION Date: Thu, 16 May 2002 03:28:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Folks, I hope you don't mind if I make an attempt to try to help clear this one up. The reaction you are getting Annika is I think because the bandwidth/delay issues are typically irrelevant. This is because IP networks are fast and the signalling delays almost always negligible. In addition, the signalling traffic is a very small portion of the likely throughput for a MN so again, is irrelevant. Both of these facts are known from existing deployments. Working hard by deploying a stateful regional box to reduce the signalling traffic to an even smaller tiny fraction, or to avoid 50ms of delay is therefore highly questionable...I think people would like you to appreciate that and hence limit the applicability to cases where the above statements are not true. Now the reason I am motivated to have a regional element is mainly because of commercial decoupling for cellular networks. If MIP is at the basestation then you have high MIP update rates and the cost of your hand-off, that is primarily due to inter-FA data forwarding during the hand-off, is minimised. Unfortunately, if the distant HA is poorly connected or comes up and down as could easily happen with corporate remote access or small third party stub networks, then the cost of the operators hand-off is now dependent on that third party, potentially leading to extended inter-FA forwarding and even chaining of FA forwarding. The critical point of the regional element here is that it decouples the reachability/availability of the HA from the wireless operators local hand-off. The operator hand-off is then dependent only on elements that they themselves control. In the case of RegTun, the GFA does not do this perfectly because the home reg happens before the local reg..the opposite is true with Nested/Concat for that reason. The other important piece of decoupling is the disparate address space issue. I want to connect to multiple domains with HAs but do not want that connection to force my local addressing decisions (hence 3G swiching and tunnelling architecture). GFA does much better now with this issue but still cannot support HoAs from multiple private HA domains because the FA loses the source HA address which would have made it locally unique. Again Nested supports this. I think if you clearly limit your applicability to where the delay or relative cost of signalling v MN data is excessive, and include the decoupling arguments above then I hope people will be satisfied. This is because they would argue and I would agree that 'normally' RegTun is optional but not generally useful, as opposed to being optional and generally useful as I think you would claim. The reason that want this clear distinction is that they do not want to give the impression that MIP is generally 'broken', which I agree with, whilst in addition I would argue it is specifically and definitely broken in the cellular case with IP to the basestation. Note that this is where deployment experience does not yet exist but we are working on that :-) Hopefully, that helps us all go forward ? Regards, Alan. -----Original Message----- From: Annika Jonsson [mailto:annika.jonsson@ericsson.com] Sent: 14 May 2002 18:11 To: Madhavi W. Chandra Cc: Phil Roberts; 'mobile-ip@sunroof.eng.sun.com' Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #1 Hi Madhavi, At 12:37 PM 5/13/2002 -0400, Madhavi W. Chandra wrote: >HI Annika, > >On Mon, May 13, 2002 at 06:16:05PM +0200, Annika Jonsson wrote: > > Hi Madhavi, > > > > see below... > > ... > > > > Attached below is modified text for the abstract and the introduction, > > > > Annika's words based on input > > > > from Madhavi. > > > > > >DISAGREE...as written below. > > > > > >As per the feedback we provided, it should be clearly stated in the > > >Abstract and Introduction that this architecture is OPTIONAL and not > > >required in typical Mobile IP deployments. > > > > In the proposed text, both the Abstract and the Introduction _does_ say > > that this is an optional extension to MIP, so what are you disagreeing > with? > >As I stated in the email above and in my writeup, it should say >clearly in the Abstract and Introduction that the architecture is >OPTIONAL *and not required in typical Mobile IP deployments.* Since >this is not what you wrote above, we are DISAGREEING. To me, optional means just that, that it is not required, and that, I think, is clearly stated. I don't like the expression "in typical Mobile IP deployments". What is a "typical" Mobile IP deployment, and will it always be the same? > > > > > >Also, reference to the new > > >Section that will describe scenarios that may benefit from this > > >architecture should be included in the Introduction. The agreement to > > >include the new Section is to alleviate the doubts for the necessity > > >of this architecture. Hopefully, the new Section will highlight when > > >the architecture is useful, and not when it is NOT. > > > > I think that the text in the Introduction gives sufficent information > about > > what makes regional registrations useful and see no need for an extra > section. > >This is not what Charlie and I agreed to. We agreed to a new >Section that describes where this architecture would be >useful...perhaps you can provide network architectures that would >benefit from the regional tunneling. As per the agreement, the new >section would go into Section 3...probably Section 3.1 as Charlie >mentioned. Refer to the original email thread on this. If we had >thought that the Introduction was sufficient, the original email >thread would not have occured. Please do not go back to square one. Sorry, I missed that. I went back to see what you and Charlie had written. You offered to help with text, could you please do that? I'm not really sure what you want in this new section, that's why I'm asking. In the Introduction now it says: " If the distance between the visited network and the home network of the mobile node is large, the signaling delay for these registrations may be long. We propose a solution for performing registrations locally in the visited domain: regional registrations." Regional registrations reduce the number of signaling messages to the home network, and reduce the signaling delay when a mobile node moves from one foreign agent to another, within the same visited domain. This will both decrease the load on the home network, and speed up the process of handover within the visited domain. " What would you like to add to that? Regards, Annika >Thanks, >Madhavi > > > > Regards, > > Annika > > > > >I have provided Annika with the suggested text. Please incorporate > > >the above comments. > > > > > >Thanks, > > >Madhavi > > > > > > > > > > Phil > > > > > > > > "Abstract > > > > > > > > Using Mobile IP, a mobile node registers with its home agent each > time it > > > > changes care-of address. If the distance between the visited > network and > > > > the home network of the mobile node is large, the signaling delay for > > > these > > > > registrations may be long. This document describes a new kind of > > > "regional" > > > > registration, i.e., registration local to the visited domain. The > regional > > > > signaling is performed via a new network entity called a Gateway > Foreign > > > > Agent and introduces a layer of hierarchy in the foreign domain. > Regional > > > > registrations reduce the number of signaling messages to the home > network, > > > > and reduce the signaling delay when a mobile node moves from one > foreign > > > > agent to another, within the same visited domain. This document is an > > > > optional extension to the Mobile IP protocol." > > > > > > > > > > > > "Introduction > > > > > > > > This document is an optional extension to the Mobile IP protocol, and > > > > proposes a means for mobile nodes to register locally within a visited > > > > domain. By registering locally, the number of signaling messages to the > > > > home network are keept to a minimum, and the signaling delay is > reduced. > > > > > > > > In Mobile IP, as specified in RFC 3220 [9], a mobile node registers > with > > > > its home agent each time it changes care-of address. If the distance > > > > between the visited network and the home network of the mobile node is > > > > large, the signaling delay for these registrations may be long. We > propose > > > > a solution for performing registrations locally in the visited domain: > > > > regional registrations. The regional registration design introduces new > > > > Mobile IP messages - Regional Registrations, new Mobile IP > extensions to > > > > convey information between the mobile node, foreign agent, and home > agent, > > > > and a new network entity - Gateway Foreign Agent (GFA). Regional > > > > registrations reduce the number of signaling messages to the home > network, > > > > and reduce the signaling delay when a mobile node moves from one > foreign > > > > agent to another, within the same visited domain. This will both > decrease > > > > the load on the home network, and speed up the process of handover > within > > > > the visited domain. The introduction of a GFA also makes it possible to > > > > have different addressing realms in the home and in the visited > networks." > > > > > > > > > > > > The last three paragraphs of the Introduction are unmodified. From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 03:31:39 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16211 for ; Thu, 16 May 2002 03:31:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19450; Thu, 16 May 2002 00:29:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA00175; Thu, 16 May 2002 00:29:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7T9rP015881 for ; Thu, 16 May 2002 00:29:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4G7T9bx015880 for mobile-ip-dist; Thu, 16 May 2002 00:29:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G7T5rP015873 for ; Thu, 16 May 2002 00:29:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA20996 for ; Thu, 16 May 2002 00:29:08 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA23953 for ; Thu, 16 May 2002 01:29:38 -0600 (MDT) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 03:29:07 -0400 Message-ID: From: "Alan O'Neill" To: "'Annika Jonsson'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] RR Last Call issue #3 - AGREE with one ISSUE and CLARIFICATIONs Date: Thu, 16 May 2002 03:29:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Looks good Annika, AGREE in principle with some more work to do....explained below and in my response to Issue 2. -----Original Message----- From: Annika Jonsson [mailto:annika.jonsson@ericsson.com] Sent: 15 May 2002 17:24 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Regional Registration Last Call issue #3 Hi Here are my conclusions and proposals for additions/changes to solve most of the technical issues raised during last call of Regional Registrations. I have excluded the issues around multiple levels of hierarchies, which will be dealt with separatley. Respond as to whether you AGREE, DISAGREE, or CAN LIVE WITH the recommendation. And on the response put in the subject line, CLARIFICATION if you have a clarification to recommend, or ISSUE if you have an issue to raise. A. Differnet addressing realms. The issues raised about supporting different addressing realms between FA-GFA and GFA-HA (i.e. the GFA is placed on the border between those addressing realms). The basic problem is how to allow for flexibility in addressing between FA-GFA and GFA-HA, which does not work with the way the draft specifies the use of GFA CoA today. To allow this, it should be the GFA that decides wich CoA to use, possibly individually for each MN. To support this, the following changes are proposed: - clarify that a MN that supports regional registrations SHOULD send home registrations with a zero CoA AWO>CLARIFICATION 'IF THE MN KNOWS THE HA SUPPORTS REGIONAL REGISTRATION' , to allow the GFA to allocate CoA. (it is SHOULD and not MUST, because if the MN's HA doesn't support regional registrations, it should be allowed to use an advertised CoA, see mail on issue #2). An FA can force the use of zero CoA by not advertising any CoA address, but it will then not be backwards compatible (see mail on issues #2). This will be clarified in section 4.1. - change the allocation of CoA if the MN uses zero COA in the registration: in the draft right now, it is the FA that decides what CoA the MN gets. This should be changed so that the FA only forwards the registration to a GFA node (using an address in the address realm between the FA-GFA). Then the GFA selects the CoA (possibly based on the MN:s HA address, or MN-NAI if present, or information from AAA server etc...), adds GFA IP extension, protects it with FA-HA auth- extension and sends it to the HA. This will be changed in section 4.2, 4.3 and 8.1. AWO>CLARIFICATION The address being sent to the HA is now a CoA between HA and GFA so I would suggest you send this in a HFAext to be strictly correct and not the GFAIPext. The HFAext address is not needed by the MN which instead needs the GFA address from the MN-FA-GFA addressing domain. The HA therefore should return the HFAext to the GFA to confirm it understood it (see mail on Issues 2), but it is the FA that knows the address it used to send to the GFA so it is the FA that should add the GFAIPext in the Reply to the MN (the GFA can't do this because there is maybe no MN-GFA auth ext in place and this address was allocated by the FA so its communication is rightly the FAs responsibility). Then of course HFAext and GFAIPext should be sub-types with a regionally signalling type..as previously mentioned. - clarifiy that if the FA advertises a GFA CoA, this is regarded as a "default" CoA that could be used, especially by MN:s that supports regional registrations, but have HA:s that don't. If this CoA is not within the same addressing realm as the FA-GFA, the FA needs to have a mapping to the address that it should use to communicate with the GFA. This will be added to section 4.2 AWO>ISSUE This does not deal with the case that the default CoA is not within the addressing domain of the GFA-HA. See Issue 2 mail for conclusions... B. too many options. Some people commented that it is a problem with too may optional ways to do things, since it would be difficlut to imlement and can create problems for interoperability. - Most of the options are around the advertised addresses and what address the mobile node uses in registration messages. Hopefully this is much better now that we clarifies the use of those addresses both for backwards compatibility and for different addressing realms, so I consider this issue solved C. protection of the GFA IP address extension It was pointed out that the GFA IP address extension needs to be protected by an authentication extension. - this should be clarified in section 4.3. D. reverse tunnelling clarification It was pointed out that if reverse tunnelling is used, the FA must use the address in the registration request (from the HFA extension) as source for the tunnel. - this should be clarified in section 4.2 and 4.3. E. Generalized NAI extension There was a question about why the Generalized NAI extension is needed, why not use an FA-NAI extension directly? - RFC3220 recommends that new extensions should be in this format if possible. Therefore I propose that we keep this. F. added delay with extra round-trip It was pointed out that if the FA is allowed to deny a regional registration because it doesn't support that GFA, this means one extra round-trip before the registration is completed, which could lead to extra delay for traffic. - That is true, but I still think we should allow this feature because: * the first "round-trip" is very short, only to the FA and back. * FAs in the same domain should in most cases support the same GFAs so this would not happen very often. * allowing an FA to deny the use of a specific GFA would be useful, for example if a GFA breaks down, since it would force the MN to register a new GFA with it's HA. * the FA needs a way to deny unvalid registrations, in this case if a mobile node uses a non-existent CoA in the registration request. Therefore I propose that we don't change this. Regards, Annika From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 04:51:00 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17753 for ; Thu, 16 May 2002 04:50:59 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA12376; Thu, 16 May 2002 02:50:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14759; Thu, 16 May 2002 01:50:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G8nprP016067 for ; Thu, 16 May 2002 01:49:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4G8noQ0016066 for mobile-ip-dist; Thu, 16 May 2002 01:49:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G8nkrP016059 for ; Thu, 16 May 2002 01:49:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14615 for ; Thu, 16 May 2002 01:49:50 -0700 (PDT) Received: from Mistralsoftware.com (PPP-200-7-193.bng.vsnl.net.in [203.200.7.193]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08102 for ; Thu, 16 May 2002 02:49:44 -0600 (MDT) Received: from kalyana [192.168.13.46] by mistralsoftware.com [192.168.10.12] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Thu, 16 May 2002 14:27:56 +0530 Message-ID: <005601c1fcb6$0429cbe0$2e0da8c0@kalyana> From: "Kalyan" To: , References: Subject: Re: [mobile-ip] Receiving Binding Refresh Request Date: Thu, 16 May 2002 14:15:22 +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.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-MDRemoteIP: 192.168.13.46 X-Return-Path: kalyan@mistralsoftware.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, The reason is given below. Any node which is observing the traffic can pretend like a CN and it may send a BRR with the CN's address. As per the security is concerned,MN MUST communicate with those CNs only for which it is having entry in the BUL. Is this OK. Regards, Kalyan. ----- Original Message ----- From: To: Sent: Thursday, May 16, 2002 9:42 AM Subject: [mobile-ip] Receiving Binding Refresh Request > Hi all, > I have an issue, regarding the processing of the Binding Refresh Request > message. > > The draft says that "When a mobile node receives a Binding Refresh Request > message and there already exists a Binding Update List entry for the source > of the Binding Refresh Request, it MAY start a return routability > procedure." > > It also mentions that "the state of the BUL, which has a valid binding > changes from "Bound" to "WaitHC" state after processing the BRR message". > ( As per Appendix. A) > > The necessity of the Binding Refresh Request message is to update the > Binding Cache of the CN, before the Lifetime expires. But as soon as the > mobile node get the BRR message, MN initiate the RR procedure and changes > the state to WaitHC. Thereafter the packet to that destination will be > reverse tunneled, till the BU procedure is complete. This is almost like > initiating RR procedure, after the lifetime expires. > > Though, MN has a valid remaining time in its BUL, why for just refreshing > the Bcache, MN should loose the remaining time of the last Binding and > reverse tunnel the packet, till the binding update procedure is complete. > > Regards, > Srinivasan > > From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 05:44:16 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18767 for ; Thu, 16 May 2002 05:44:15 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA20571; Thu, 16 May 2002 02:42:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04701; Thu, 16 May 2002 02:42:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G9fZrP016196 for ; Thu, 16 May 2002 02:41:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4G9fZa2016195 for mobile-ip-dist; Thu, 16 May 2002 02:41:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G9fVrP016187; Thu, 16 May 2002 02:41:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA11141; Thu, 16 May 2002 02:41:36 -0700 (PDT) From: Srinivasan.Damodaran@lntinfotech.com Received: from ltitlin.lntinfotech.com ([203.199.54.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23976; Thu, 16 May 2002 03:42:04 -0600 (MDT) Received: from bangalore.lntinfotech.com ([172.29.4.3]) by ltitlin.lntinfotech.com (Lotus Domino Release 5.0.8) with ESMTP id 2002051615121848:15111 ; Thu, 16 May 2002 15:12:18 +0530 Subject: [mobile-ip] Receiving Binding Refresh Request To: "Kalyan" Cc: mobile-ip@sunroof.eng.sun.com, owner-mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 16 May 2002 15:08:43 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/16/2002 03:08:47 PM, Itemize by SMTP Server on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/16/2002 03:12:18 PM, Serialize by Router on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/16/2002 03:12:22 PM, Serialize complete at 05/16/2002 03:12:22 PM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Kalyan, You wrote: > Any node which is observing the traffic can pretend like a CN and it may > send a BRR with the CN's address. > As per the security is concerned,MN MUST communicate with those CNs only for > which it is having entry in the BUL. This is fine, for a BRR message from an unknown CN. The draft also has clearly mentioned that "the mobile node SHOULD NOT respond Binding Requests from previously unknown nodes due to Denial-of-Service concerns." My question is, MN has a valid binding with a CN and communication to that node is in progress, & still requires Route optimization. In the meantime (i.e., assume when 90% of the lifetime is over), MN get's a BRR message from CN. MN starts initiating RR procedure and changes state from "Bound" to "WaitHC". MN looses route optimization during the 10% of MN's valid lifetime or till BU procedure is complete, whichever is less. Here the purpose of initiating BRR message before binding expires, is to maintain route optimization steadily. Even if the BRR message is not there, once when the lifetime expires, the packets will be tunneled to MN and MN will initiate the RR procedure. Inorder to avoid this, CN initiates BRR when the lifetime is about to expire. But I feel the purpose of BRR, is not met... regards srinivasan From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 09:00:36 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23156 for ; Thu, 16 May 2002 09:00:36 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11508; Thu, 16 May 2002 05:57:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA25360; Thu, 16 May 2002 05:57:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GCurrP016731 for ; Thu, 16 May 2002 05:56:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4GCurLm016730 for mobile-ip-dist; Thu, 16 May 2002 05:56:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GCuorP016723 for ; Thu, 16 May 2002 05:56:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA25210 for ; Thu, 16 May 2002 05:56:54 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12229 for ; Thu, 16 May 2002 06:57:23 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4GCuec23541; Thu, 16 May 2002 14:56:41 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA28174; Thu, 16 May 2002 14:56:41 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4GCudT88618; Thu, 16 May 2002 14:56:40 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205161256.g4GCudT88618@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Padmakumar.AV@lntinfotech.com cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] mobile-ip] Where to insert HAO? In-reply-to: Your message of Wed, 15 May 2002 17:58:22 +0530. Date: Thu, 16 May 2002 14:56:39 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: => again, again, ... Section 6.3 says "The Home Address option MUST be placed as follows: - After the Routing Header, if that header is present - Before the Fragment Header, if that header is present - Before the AH Header or ESP Header, if either one of those Headers is present " => is this not enough clear? "After the Routing Header, if that header is present" does it mean that HAO has to be placed in the inner destination option header, because outer destination header usually comes before routing header. => there is not such thing like outer and inner destination option header. RFC 2460 is just a recommendation overruled by newer specs like 6.3. "Before the Fragment Header, if that header is present" ? ok this rules out the case of inner destination option header, in this case outer destination option and routing header both are part of non fragmentable part, but still outer destination option header comes before routing header (for example in Linux Ipv6). What if both routing and fragment headers are present? => between. So where should we actually place the HAO? => just apply 6.3. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 09:18:48 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23747 for ; Thu, 16 May 2002 09:18:47 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07048; Thu, 16 May 2002 07:17:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28464; Thu, 16 May 2002 06:17:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GDGnrP016780 for ; Thu, 16 May 2002 06:16:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4GDGnAx016779 for mobile-ip-dist; Thu, 16 May 2002 06:16:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GDGkrP016772 for ; Thu, 16 May 2002 06:16:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27006 for ; Thu, 16 May 2002 06:16:49 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23316 for ; Thu, 16 May 2002 07:16:44 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4GDFjc27173; Thu, 16 May 2002 15:15:45 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA28475; Thu, 16 May 2002 15:15:45 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4GDFiT88837; Thu, 16 May 2002 15:15:45 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205161315.g4GDFiT88837@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vladislav Yasevich cc: Padmakumar.AV@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] mobile-ip] Where to insert HAO? In-reply-to: Your message of Wed, 15 May 2002 11:01:09 EDT. <3CE27835.9040605@hp.com> Date: Thu, 16 May 2002 15:15:44 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: The draft actually defined a new destination option header location (in addition to the ones defined in 2460). This location is what you described in your message. For example: IPv6 [ HbH [ Dest{1} [ Rtrhdr [ Dest (HOA) [ Frag ...]]]]] => right However, I believe that'll change in the next revision since the HOA will be a parameter in the Mobility Header. => wrong: HOA is in any packet from MN to CN with routing optimization. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 09:38:54 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24511 for ; Thu, 16 May 2002 09:38:53 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07721; Thu, 16 May 2002 06:37:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02686; Thu, 16 May 2002 06:36:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GDZSrP016839 for ; Thu, 16 May 2002 06:35:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4GDZSxN016838 for mobile-ip-dist; Thu, 16 May 2002 06:35:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GDZPrP016831 for ; Thu, 16 May 2002 06:35:25 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02409 for ; Thu, 16 May 2002 06:35:29 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16110 for ; Thu, 16 May 2002 07:35:28 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D727B8BFF; Thu, 16 May 2002 09:35:27 -0400 (EDT) Received: from anw.zk3.dec.com (anw4.zk3.dec.com [16.140.48.4]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id A78F5136E; Thu, 16 May 2002 06:35:26 -0700 (PDT) Received: from hp.com by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id JAA0002128537; Thu, 16 May 2002 09:35:25 -0400 (EDT) Message-ID: <3CE3B59D.8060001@hp.com> Date: Thu, 16 May 2002 09:35:25 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Padmakumar.AV@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] mobile-ip] Where to insert HAO? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi pav Padmakumar.AV@lntinfotech.com wrote: > Hi, > > But I think RFC-2460 also says that Destination option header can occur > utmost twice. So as per your interpretation we have to add a new > destination option header, which is destination option {2} (since 0 and 1 > being outer and 1 being inner destination options) right? This was only a suggestion on the part of 2460. There was a lot of discussion about this. Essentially, destination option headers can appear anywhere you want to put them if you don't want to follow the suggestions. So mobile spec defines an additional location where a destination option header may exist. That header contains the HOA. > I believe this may not be applicable always since BU to HA require a HAO > and this has to be replaced with the COA before the Authentication or ESP > header processing is done and more over if we want route optimization any > upper layer packet to CN should also have the HAO (if CN has a binding with > the MN). > Yes, you are right. I got confused about some changes that were discusses a while ago. -vlad +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 10:11:18 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25493 for ; Thu, 16 May 2002 10:11:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20416; Thu, 16 May 2002 07:09:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA09727; Thu, 16 May 2002 07:09:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GE89rP016947 for ; Thu, 16 May 2002 07:08:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4GE88mF016946 for mobile-ip-dist; Thu, 16 May 2002 07:08:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GE85rP016939 for ; Thu, 16 May 2002 07:08:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29385 for ; Thu, 16 May 2002 07:08:07 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03923 for ; Thu, 16 May 2002 08:08:07 -0600 (MDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4GE7uHs029563; Thu, 16 May 2002 07:07:57 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA05537; Thu, 16 May 2002 10:07:55 -0400 (EDT) Date: Thu, 16 May 2002 10:07:55 -0400 From: "Madhavi W. Chandra" To: "Alan O'Neill" Cc: "'Annika Jonsson'" , "'Madhavi W. Chandra'" , "'Phil Roberts'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] RR Last Call Resolution Issue #1 - CLARIFICATION Message-ID: <20020516100755.B4703@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from A.ONeill@flarion.com on Thu, May 16, 2002 at 03:28:32AM -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Alan, Nice clarification! You have correctly captured our concerns. I hope your suggestions will be incorporated into the draft. If so, I'm sure the contentious issues with the draft will abate...else, I'm afraid the circle will continue. Regards, Madhavi On Thu, May 16, 2002 at 03:28:32AM -0400, Alan O'Neill wrote: > Folks, > > I hope you don't mind if I make an attempt to try to help clear this one up. > > The reaction you are getting Annika is I think because the bandwidth/delay > issues are typically irrelevant. This is because IP networks are fast and > the signalling delays almost always negligible. In addition, the signalling > traffic is a very small portion of the likely throughput for a MN so again, > is irrelevant. Both of these facts are known from existing deployments. > Working hard by deploying a stateful regional box to reduce the signalling > traffic to an even smaller tiny fraction, or to avoid 50ms of delay is > therefore highly questionable...I think people would like you to appreciate > that and hence limit the applicability to cases where the above statements > are not true. > > Now the reason I am motivated to have a regional element is mainly because > of commercial decoupling for cellular networks. If MIP is at the basestation > then you have high MIP update rates and the cost of your hand-off, that is > primarily due to inter-FA data forwarding during the hand-off, is minimised. > Unfortunately, if the distant HA is poorly connected or comes up and down as > could easily happen with corporate remote access or small third party stub > networks, then the cost of the operators hand-off is now dependent on that > third party, potentially leading to extended inter-FA forwarding and even > chaining of FA forwarding. The critical point of the regional element here > is that it decouples the reachability/availability of the HA from the > wireless operators local hand-off. The operator hand-off is then dependent > only on elements that they themselves control. In the case of RegTun, the > GFA does not do this perfectly because the home reg happens before the local > reg..the opposite is true with Nested/Concat for that reason. > > The other important piece of decoupling is the disparate address space > issue. I want to connect to multiple domains with HAs but do not want that > connection to force my local addressing decisions (hence 3G swiching and > tunnelling architecture). GFA does much better now with this issue but still > cannot support HoAs from multiple private HA domains because the FA loses > the source HA address which would have made it locally unique. Again Nested > supports this. > > I think if you clearly limit your applicability to where the delay or > relative cost of signalling v MN data is excessive, and include the > decoupling arguments above then I hope people will be satisfied. This is > because they would argue and I would agree that 'normally' RegTun is > optional but not generally useful, as opposed to being optional and > generally useful as I think you would claim. The reason that want this clear > distinction is that they do not want to give the impression that MIP is > generally 'broken', which I agree with, whilst in addition I would argue it > is specifically and definitely broken in the cellular case with IP to the > basestation. Note that this is where deployment experience does not yet > exist but we are working on that :-) > > Hopefully, that helps us all go forward ? > > Regards, Alan. > > > -----Original Message----- > From: Annika Jonsson [mailto:annika.jonsson@ericsson.com] > Sent: 14 May 2002 18:11 > To: Madhavi W. Chandra > Cc: Phil Roberts; 'mobile-ip@sunroof.eng.sun.com' > Subject: Re: [mobile-ip] Regional Registration Last Call Resolution > Issue #1 > > > Hi Madhavi, > > At 12:37 PM 5/13/2002 -0400, Madhavi W. Chandra wrote: > >HI Annika, > > > >On Mon, May 13, 2002 at 06:16:05PM +0200, Annika Jonsson wrote: > > > Hi Madhavi, > > > > > > see below... > > > > > ... > > > > > > Attached below is modified text for the abstract and the > introduction, > > > > > Annika's words based on input > > > > > from Madhavi. > > > > > > > >DISAGREE...as written below. > > > > > > > >As per the feedback we provided, it should be clearly stated in the > > > >Abstract and Introduction that this architecture is OPTIONAL and not > > > >required in typical Mobile IP deployments. > > > > > > In the proposed text, both the Abstract and the Introduction _does_ say > > > that this is an optional extension to MIP, so what are you disagreeing > > with? > > > >As I stated in the email above and in my writeup, it should say > >clearly in the Abstract and Introduction that the architecture is > >OPTIONAL *and not required in typical Mobile IP deployments.* Since > >this is not what you wrote above, we are DISAGREEING. > > To me, optional means just that, that it is not required, and that, I > think, is clearly stated. I don't like the expression "in typical Mobile IP > deployments". What is a "typical" Mobile IP deployment, and will it always > be the same? > > > > > > > > > > >Also, reference to the new > > > >Section that will describe scenarios that may benefit from this > > > >architecture should be included in the Introduction. The agreement to > > > >include the new Section is to alleviate the doubts for the necessity > > > >of this architecture. Hopefully, the new Section will highlight when > > > >the architecture is useful, and not when it is NOT. > > > > > > I think that the text in the Introduction gives sufficent information > > about > > > what makes regional registrations useful and see no need for an extra > > section. > > > >This is not what Charlie and I agreed to. We agreed to a new > >Section that describes where this architecture would be > >useful...perhaps you can provide network architectures that would > >benefit from the regional tunneling. As per the agreement, the new > >section would go into Section 3...probably Section 3.1 as Charlie > >mentioned. Refer to the original email thread on this. If we had > >thought that the Introduction was sufficient, the original email > >thread would not have occured. Please do not go back to square one. > > Sorry, I missed that. I went back to see what you and Charlie had written. > You offered to help with text, could you please do that? I'm not really > sure what you want in this new section, that's why I'm asking. In the > Introduction now it says: > > " If the distance between the visited network and the home network of the > mobile node is large, the signaling delay for these registrations may be > long. We propose a solution for performing registrations locally in the > visited domain: regional registrations." > > Regional registrations reduce the number of signaling messages to the home > network, and reduce the signaling delay when a mobile node moves from one > foreign agent to another, within the same visited domain. This will both > decrease the load on the home network, and speed up the process of handover > within the visited domain. " > > What would you like to add to that? > > Regards, > Annika > > >Thanks, > >Madhavi > > > > > > > Regards, > > > Annika > > > > > > >I have provided Annika with the suggested text. Please incorporate > > > >the above comments. > > > > > > > >Thanks, > > > >Madhavi > > > > > > > > > > > > > Phil > > > > > > > > > > "Abstract > > > > > > > > > > Using Mobile IP, a mobile node registers with its home agent each > > time it > > > > > changes care-of address. If the distance between the visited > > network and > > > > > the home network of the mobile node is large, the signaling delay > for > > > > these > > > > > registrations may be long. This document describes a new kind of > > > > "regional" > > > > > registration, i.e., registration local to the visited domain. The > > regional > > > > > signaling is performed via a new network entity called a Gateway > > Foreign > > > > > Agent and introduces a layer of hierarchy in the foreign domain. > > Regional > > > > > registrations reduce the number of signaling messages to the home > > network, > > > > > and reduce the signaling delay when a mobile node moves from one > > foreign > > > > > agent to another, within the same visited domain. This document is > an > > > > > optional extension to the Mobile IP protocol." > > > > > > > > > > > > > > > "Introduction > > > > > > > > > > This document is an optional extension to the Mobile IP protocol, > and > > > > > proposes a means for mobile nodes to register locally within a > visited > > > > > domain. By registering locally, the number of signaling messages to > the > > > > > home network are keept to a minimum, and the signaling delay is > > reduced. > > > > > > > > > > In Mobile IP, as specified in RFC 3220 [9], a mobile node registers > > with > > > > > its home agent each time it changes care-of address. If the distance > > > > > between the visited network and the home network of the mobile node > is > > > > > large, the signaling delay for these registrations may be long. We > > propose > > > > > a solution for performing registrations locally in the visited > domain: > > > > > regional registrations. The regional registration design introduces > new > > > > > Mobile IP messages - Regional Registrations, new Mobile IP > > extensions to > > > > > convey information between the mobile node, foreign agent, and home > > agent, > > > > > and a new network entity - Gateway Foreign Agent (GFA). Regional > > > > > registrations reduce the number of signaling messages to the home > > network, > > > > > and reduce the signaling delay when a mobile node moves from one > > foreign > > > > > agent to another, within the same visited domain. This will both > > decrease > > > > > the load on the home network, and speed up the process of handover > > within > > > > > the visited domain. The introduction of a GFA also makes it possible > to > > > > > have different addressing realms in the home and in the visited > > networks." > > > > > > > > > > > > > > > The last three paragraphs of the Introduction are unmodified. From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 10:32:05 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26149 for ; Thu, 16 May 2002 10:32:00 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16804; Thu, 16 May 2002 08:31:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA05431; Thu, 16 May 2002 07:31:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GEUYrP017002 for ; Thu, 16 May 2002 07:30:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4GEUYjW017001 for mobile-ip-dist; Thu, 16 May 2002 07:30:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GEUUrP016994 for ; Thu, 16 May 2002 07:30:31 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15104 for ; Thu, 16 May 2002 07:30:33 -0700 (PDT) Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15991 for ; Thu, 16 May 2002 08:30:32 -0600 (MDT) Received: from fredrikj (manmsr.local.ipunplugged.com [213.88.134.212]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g4GEW83O001857; Thu, 16 May 2002 16:32:08 +0200 From: "Fredrik Johansson" To: "MobileIP" , "Charlie Perkins" , "Tony Johansson" , "Phil Roberts" , "Basavaraj Patil" , "Kevin Purser" Cc: "Johan Johansson" Subject: [mobile-ip] Address to use in the SA between FA-HA Date: Thu, 16 May 2002 16:30:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, RFC 3220 doesn't define which address to use when creating the SA between the FA and HA. I have always assumed that it was the care-of-address in the registration request header, but considering the case when a mobile registers with an FA just because it has set the 'R'-bit in its advertisement. The rfc doesn't say which Ip address to use in this case, the CoA or the source address of the incoming reguest. This will cause interoperability problems within mobile ip itself, and also affects other protocols such as Diameter. The best would be to always use the CoA since the incoming request may not always have a source address (e.g. when coming via a Diameter Request). /Fredrik From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 13:50:32 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03897 for ; Thu, 16 May 2002 13:50:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09311; Thu, 16 May 2002 11:49:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15943; Thu, 16 May 2002 10:49:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GHmYrP017442 for ; Thu, 16 May 2002 10:48:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4GHmXxs017441 for mobile-ip-dist; Thu, 16 May 2002 10:48:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GHmUrP017434 for ; Thu, 16 May 2002 10:48:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24833 for ; Thu, 16 May 2002 10:48:32 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04222 for ; Thu, 16 May 2002 11:49:02 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4GHmKc03866; Thu, 16 May 2002 19:48:20 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA03472; Thu, 16 May 2002 19:48:20 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4GHmIT90177; Thu, 16 May 2002 19:48:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205161748.g4GHmIT90177@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: arvind.sevalkar@lntinfotech.com cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sending Binding Acknowledgement with routing header. In-reply-to: Your message of Thu, 16 May 2002 11:10:55 +0530. Date: Thu, 16 May 2002 19:48:18 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: when MN sends Binding Update to HA, it sends with HAO, but when MN sends Binding Update to CN it will not include HAO. refer section 9.4.1 => until this I-D 17 it MUST include HAO. Someone of the Disaster Team has reversed this but next I-D should get an even number and MUST again... Regards Francis.Dupont@enst-bretagne.fr PS: of course it MUST include a HAO if one'd like to protect it by IPsec. From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 14:24:33 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05233 for ; Thu, 16 May 2002 14:24:33 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28256; Thu, 16 May 2002 12:24:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10890; Thu, 16 May 2002 11:24:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GINDrP017542 for ; Thu, 16 May 2002 11:23:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4GINDpB017541 for mobile-ip-dist; Thu, 16 May 2002 11:23:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GINBrP017534 for ; Thu, 16 May 2002 11:23:12 -0700 (PDT) Received: from yellow-cube.east.sun.com (yellow-cube.East.Sun.COM [10.8.49.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02713 for ; Thu, 16 May 2002 14:23:14 -0400 (EDT) Received: from yellow-cube.east.sun.com (localhost [IPv6:::1]) by yellow-cube.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g4GINDdC016602 for ; Thu, 16 May 2002 14:23:13 -0400 (EDT) Received: (from glass@localhost) by yellow-cube.east.sun.com (8.12.1+Sun/8.12.1/Submit) id g4GINDXU016601 for mobile-ip@sunroof.eng.sun.com; Thu, 16 May 2002 14:23:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4G4wtrP015430 for ; Wed, 15 May 2002 21:58:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA04918 for ; Wed, 15 May 2002 21:58:58 -0700 (PDT) From: arvind.sevalkar@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA10466 for ; Wed, 15 May 2002 22:58:53 -0600 (MDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002051610324460:1475 ; Thu, 16 May 2002 10:32:44 +0530 Subject: [mobile-ip] Sending HoT Message with entry in binding cache To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Thu, 16 May 2002 10:28:04 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/16/2002 10:29:16 AM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/16/2002 10:32:44 AM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/16/2002 10:32:51 AM, Serialize complete at 05/16/2002 10:32:51 AM Message-ID: X-Priority: 3 (Normal) Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi All Consider the scenario when CN recieves a HOTI message from a mobile node for which CN already has a valid binding cache entry. CN has to send a HoT message to the MN's Home address. For every outgoing packet, if CN has a Binding cache entry for that destination Address then CN will change the destination address to the COA and add type 2 routing header with home address. So naturally CN will change the Destination address and add a type 2 routing header for the HOTI message also, otherwise CN has to specifically look into each message for the special treatment of HOTI message. As per the draft the HOT should be sent to the Home address of the MN and tunneled to the MN. How to handle this? Regards Arvind From owner-mobile-ip@sunroof.eng.sun.com Thu May 16 16:32:42 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10005 for ; Thu, 16 May 2002 16:32:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00882; Thu, 16 May 2002 13:30:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07765; Thu, 16 May 2002 13:30:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GKTTrP017874 for ; Thu, 16 May 2002 13:29:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4GKTTMI017873 for mobile-ip-dist; Thu, 16 May 2002 13:29:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4GKTOrP017866 for ; Thu, 16 May 2002 13:29:24 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07178 for ; Thu, 16 May 2002 13:29:28 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23342 for ; Thu, 16 May 2002 13:29:27 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 960046A916; Thu, 16 May 2002 23:29:26 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 06EBA6A901; Thu, 16 May 2002 23:29:25 +0300 (EEST) Message-ID: <3CE416E1.1000908@kolumbus.fi> Date: Thu, 16 May 2002 23:30:25 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: arvind.sevalkar@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sending Binding Acknowledgement with routing header. References: <200205161748.g4GHmIT90177@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > when MN sends Binding Update to HA, it sends with HAO, but when MN sends > Binding Update to CN it will not include HAO. refer section 9.4.1 > > => until this I-D 17 it MUST include HAO. Someone of the Disaster Team > has reversed this but next I-D should get an even number and MUST again... > > PS: of course it MUST include a HAO if one'd like to protect it by IPsec. I'm the guilty party for this change. The reason for the change was that per the HAO reflection attack discussion, we didn't want HAOs to be accepted unless there was a BCE entry. Clearly there might not be a BCE entry at the time the BU is sent, so there was a chicken-and-egg problem. The alternative solutions were (a) not use HAO in the BU or (b) special processing of the HAO for certain messages i.e. allowing them for BUs. But you are right of course in your IPsec comment above, and that wasn't considered in making the change. I wonder if alternative (b) would have been the right approach instead. Lets see... we'll assume the CN has an IPsec policy that drops all other traffic except that which comes from the MN's home address. And this traffic needs to use IPsec. For solution (a) we could not have sent a BU at all to the CN. For solution (b), we can include the HAO and have even this packet pass the policies. Does (b) create any new reflection problems? It does not, if the BA is delivered directly to the MN. Can we always know if special processing is needed? Hmm... we can't if the message is encrypted. But if the message is encrypted, then we have an SA and we should trust HAOs when an SA exists... So, my first thought is that alternative (b) would work better. What do you think? Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 02:56:03 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04380 for ; Fri, 17 May 2002 02:56:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA01430; Fri, 17 May 2002 00:55:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA08548; Thu, 16 May 2002 23:55:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4H6srrP018922 for ; Thu, 16 May 2002 23:54:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4H6sqou018921 for mobile-ip-dist; Thu, 16 May 2002 23:54:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4H6snrP018914 for ; Thu, 16 May 2002 23:54:49 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA14030 for ; Thu, 16 May 2002 23:54:52 -0700 (PDT) Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA01137 for ; Fri, 17 May 2002 00:54:51 -0600 (MDT) Received: from fredrikj (a20.local.ipunplugged.com [192.168.4.190]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g4H6uk3O016989 for ; Fri, 17 May 2002 08:56:47 +0200 From: "Fredrik Johansson" To: "MobileIP" Subject: [mobile-ip] draft-ietf-mobileip-aaa-nai-01.txt Date: Fri, 17 May 2002 08:55:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi All, We have submitted a new version of the above mentioned draft, if you want access to it before it gets published, it can be found at http://stargate.ipunplugged.com/ietf/draft-ietf-mobileip-aaa-nai-01.txt /Fredrik From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 05:00:04 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06061 for ; Fri, 17 May 2002 05:00:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14009; Fri, 17 May 2002 02:59:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27122; Fri, 17 May 2002 01:59:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4H8wcrP019181 for ; Fri, 17 May 2002 01:58:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4H8wbhi019180 for mobile-ip-dist; Fri, 17 May 2002 01:58:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4H8wYrP019173 for ; Fri, 17 May 2002 01:58:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02708 for ; Fri, 17 May 2002 01:58:38 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13480 for ; Fri, 17 May 2002 02:58:37 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4H8wQs7029988; Fri, 17 May 2002 10:58:26 +0200 (MEST) Received: from bends.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA02289; Fri, 17 May 2002 10:58:25 +0200 Message-Id: <5.1.0.14.0.20020517101640.029ae900@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 17 May 2002 10:59:20 +0200 To: "Ahmad Muhanna", mobile-ip@sunroof.eng.sun.com From: Annika Jonsson Subject: RE: [mobile-ip] Regional Registration Last Call issue #3 Cc: "'A.ONeill@flarion.com'" In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCCEB@zrc2c013.us.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_165920141==_.ALT" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --=====================_165920141==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Ahmad, At 01:41 PM 5/15/2002 -0500, Ahmad Muhanna wrote: >Annika; >Please see my comments inline. > >Regards; >Ahmad Muhanna > > > > > > > Hi > > > > Here are my conclusions and proposals for additions/changes > > to solve most > > of the technical issues raised during last call of Regional > > Registrations. I have excluded the issues around multiple levels of > > hierarchies, which will be dealt with separatley. > > > > Respond as to whether you AGREE, DISAGREE, or CAN LIVE WITH the > > recommendation. And on the response put in the subject line, > > CLARIFICATION > > if you have a clarification to recommend, or ISSUE if you > > have an issue to > > raise. > > > > A. Differnet addressing realms. > > > > The issues raised about supporting different addressing > > realms between > > FA-GFA and GFA-HA (i.e. the GFA is placed on the border between those > > addressing realms). The basic problem is how to allow for > > flexibility in > > addressing between FA-GFA and GFA-HA, which does not work > > with the way the > > draft specifies the use of GFA CoA today. To allow this, it > > should be the > > GFA that decides wich CoA to use, possibly individually for > > each MN. To > > support this, the following changes are proposed: > > > > - clarify that a MN that supports regional registrations > > SHOULD send home > > registrations with a zero CoA, to allow the GFA to allocate > > CoA. (it is > > SHOULD and not MUST, because if the MN's HA doesn't support regional > > registrations, it should be allowed to use an advertised CoA, > > see mail on > > issue #2). An FA can force the use of zero CoA by not > > advertising any CoA > > address, but it will then not be backwards compatible (see > > mail on issues > > #2). This will be clarified in section 4.1. > >I DISAGREE. > >Mail on issue #2 does not talk about the FA advertising NO Care-of >Address(es). >It talks about advertising one care-of Address and that one is set to ZERO. I was just careless, with NO CoA, I meant ZERO CoA. As you pointed out, there are problems with this approach also, and I am thinking about how to solve that. >There is no Foreign Agent allowed to claim that it is a Foreign Agent and >at the same time >advertise NO care-of address(es). (this is a violation of RFC3220 section >2.1.1.) > > > > > - change the allocation of CoA if the MN uses zero COA in the > > registration: > > in the draft right now, it is the FA that decides what CoA > > the MN gets. > > This should be changed so that the FA only forwards the > > registration to a > > GFA node (using an address in the address realm between the > > FA-GFA). Then > > the GFA selects the CoA (possibly based on the MN:s HA > > address, or MN-NAI > > if present, or information from AAA server etc...), adds GFA > > IP extension, > > protects it with FA-HA auth- extension and sends it to the > > HA. This will be > > changed in section 4.2, 4.3 and 8.1. > > > > - clarifiy that if the FA advertises a GFA CoA, this is regarded as a > > "default" CoA that could be used, especially by MN:s that > > supports regional > > registrations, but have HA:s that don't. If this CoA is not > > within the same > > addressing realm as the FA-GFA, the FA needs to have a mapping to the > > address that it should use to communicate with the GFA. This > > will be added > > to section 4.2 > > > > B. too many options. > > > > Some people commented that it is a problem with too may > > optional ways to do > > things, since it would be difficlut to imlement and can > > create problems for > > interoperability. > > > > - Most of the options are around the advertised addresses and > > what address > > the mobile node uses in registration messages. Hopefully this is much > > better now that we clarifies the use of those addresses both > > for backwards > > compatibility and for different addressing realms, so I > > consider this issue > > solved > > > > C. protection of the GFA IP address extension > > > > It was pointed out that the GFA IP address extension needs to > > be protected > > by an authentication extension. > > > > - this should be clarified in section 4.3. > > > > D. reverse tunnelling clarification > > > > It was pointed out that if reverse tunnelling is used, the FA > > must use the > > address in the registration request (from the HFA extension) > > as source for > > the tunnel. > > > > - this should be clarified in section 4.2 and 4.3. > > > > E. Generalized NAI extension > > > > There was a question about why the Generalized NAI extension > > is needed, why > > not use an FA-NAI extension directly? > > > > - RFC3220 recommends that new extensions should be in this format if > > possible. Therefore I propose that we keep this. > > > > F. added delay with extra round-trip > > > > It was pointed out that if the FA is allowed to deny a regional > > registration because it doesn't support that GFA, this means > > one extra > > round-trip before the registration is completed, which could > > lead to extra > > delay for traffic. > > > > - That is true, but I still think we should allow this > > feature because: > > * the first "round-trip" is very short, only to the FA and back. > > * FAs in the same domain should in most cases support the > > same GFAs so this > > would not happen very often. > > * allowing an FA to deny the use of a specific GFA would be > > useful, for > > example if a GFA breaks down, since it would force the MN to > > register a new > > GFA with it's HA. > > * the FA needs a way to deny unvalid registrations, in this case if a > > mobile node uses a non-existent CoA in the registration request. > > > > Therefore I propose that we don't change this. > > > >I DISAGREE. > >There is a big difference between the standard proposing a behavior for >the Foreign >Agent to be used in case the Mobile Node did not follow the standard, like >in the case >when the FA receives a Registration Request with an invalid care-of >address, as >indicated in RFC3220, and of a protocol allowing the Mobile Node to act >NORMALLY >and STANDARD COMPLIANT and the same time considers it as an error scenario. I disagree, I think that this message, which is the way to tell the MN why a registration was denied and not necessarily an error, can and should be used even if the MN did everything correct if something in the network makes it impossible. The MN did not cause an error, but it needs to know if something else went wrong. RFC3220 has several such codes for the registration reply, such as: "administratively prohibited", "insufficient resources", "home network unreachable" etc. Regards, Annika > > > Regards, > > Annika > > > > --=====================_165920141==_.ALT Content-Type: text/html; charset="us-ascii" Hi Ahmad,

At 01:41 PM 5/15/2002 -0500, Ahmad Muhanna wrote:

Annika;
Please see my comments inline.

Regards;
Ahmad Muhanna

>
>
> Hi
>
> Here are my conclusions and proposals for additions/changes
> to solve most
> of  the technical  issues raised during last call of Regional
> Registrations. I have excluded the issues around multiple levels of
> hierarchies, which will be dealt with separatley.
>
> Respond as to whether you AGREE, DISAGREE, or CAN LIVE WITH the
> recommendation. And on the response put in the subject line,
> CLARIFICATION
> if you have a clarification to recommend, or ISSUE if you
> have an issue to
> raise.
>
> A. Differnet addressing realms.
>
> The issues raised about supporting different addressing
> realms between
> FA-GFA and GFA-HA (i.e. the GFA is placed on the border between those
> addressing realms). The basic problem is how to allow for
> flexibility in
> addressing between FA-GFA and GFA-HA, which does not work
> with the way the
> draft specifies the use of GFA CoA today. To allow this, it
> should be the
> GFA that decides wich CoA to use, possibly individually for
> each MN. To
> support this, the following changes are proposed:
>
> - clarify that a MN that supports regional registrations
> SHOULD send home
> registrations with a zero CoA, to allow the GFA to allocate
> CoA. (it is
> SHOULD and not MUST, because if the MN's HA doesn't support regional
> registrations, it should be allowed to use an advertised CoA,
> see mail on
> issue #2). An FA can force the use of zero CoA by not
> advertising any CoA
> address, but it will then not be backwards compatible (see
> mail on issues
> #2). This will be clarified in section 4.1.

I DISAGREE.

Mail on issue #2 does not talk about the FA advertising NO Care-of Address(es).
It talks about advertising one care-of Address and that one is set to ZERO.

I was just careless, with NO CoA, I meant ZERO CoA. As you pointed out, there are problems with this approach also, and I am thinking about how to solve that.

There is no Foreign Agent allowed to claim that it is a Foreign Agent and at the same time
advertise NO care-of address(es). (this is a violation of RFC3220 section 2.1.1.)

>
> - change the allocation of CoA if the MN uses zero COA in the
> registration:
> in the draft right now, it is the FA that decides what CoA
> the MN gets.
> This should be changed so that the FA only forwards the
> registration to a
> GFA node (using an address in the address realm between the
> FA-GFA). Then
> the GFA selects the CoA (possibly based on the MN:s HA
> address, or  MN-NAI
> if present, or information from AAA server etc...), adds GFA
> IP extension,
> protects it with FA-HA auth- extension and sends it to the
> HA. This will be
> changed in section 4.2, 4.3 and 8.1.
>
> - clarifiy that if the FA advertises a GFA CoA, this is regarded as a
> "default" CoA that could be used, especially by MN:s that
> supports regional
> registrations, but have HA:s that don't. If this CoA is not
> within the same
> addressing realm as the FA-GFA, the FA needs to have a mapping to the
> address that it should use to communicate with the GFA. This
> will be added
> to section 4.2
>
> B. too many options.
>
> Some people commented that it is a problem with too may
> optional ways to do
> things, since it would be difficlut to imlement and can
> create problems for
> interoperability.
>
> - Most of the options are around the advertised addresses and
> what address
> the mobile node uses in registration messages. Hopefully this is much
> better now that we clarifies the use of those addresses both
> for backwards
> compatibility and for different addressing realms, so I
> consider this issue
> solved
>
> C. protection of the GFA IP address extension
>
> It was pointed out that the GFA IP address extension needs to
> be protected
> by an authentication extension.
>
> - this should be clarified in section 4.3.
>
> D. reverse tunnelling clarification
>
> It was pointed out that if reverse tunnelling is used, the FA
> must use the
> address in the registration request (from the HFA extension)
> as source for
> the tunnel.
>
> - this should be clarified in section 4.2 and 4.3.
>
> E. Generalized NAI extension
>
> There was a question about why the Generalized NAI extension
> is needed, why
> not use an FA-NAI extension directly?
>
> - RFC3220 recommends that new extensions should be in this format if
> possible. Therefore I propose that we keep this.
>
> F. added delay with extra round-trip
>
> It was pointed out that if the FA is allowed to deny a regional
> registration because it doesn't support that GFA, this means
> one extra
> round-trip before the registration is completed, which could
> lead to extra
> delay for traffic.
>
> - That is true, but I still think we should allow this
> feature because:
> *  the first "round-trip" is very short, only to the FA and back.
> * FAs in the same domain should in most cases support the
> same GFAs so this
> would not happen very often.
> * allowing an FA to deny the use of a specific GFA would be
> useful, for
> example if a GFA breaks down, since it would force the MN to
> register a new
> GFA with it's HA.
> * the FA needs a way to deny unvalid registrations, in this case if a
> mobile node uses a non-existent CoA in the registration request.
>
> Therefore I propose that we don't change this.
>

I DISAGREE.

There is a big difference between the standard proposing a behavior for the Foreign
Agent to be used in case the Mobile Node did not follow the standard, like in the case
when the FA receives a Registration Request with an invalid care-of address, as
indicated in RFC3220, and of a protocol allowing the Mobile Node to act NORMALLY
and STANDARD COMPLIANT and the same time considers it as an error scenario.
 
I disagree, I think that this message, which is the way to tell the MN why a registration was denied and not necessarily an error, can and should be used even if the MN did everything correct if something in the network makes it impossible. The MN did not cause an error, but it needs to know if something else went wrong. RFC3220 has several such codes for the registration reply, such as: "administratively prohibited", "insufficient resources", "home network unreachable" etc.

Regards,
Annika

 
> Regards,
> Annika
>
>
--=====================_165920141==_.ALT-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 05:11:09 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06281 for ; Fri, 17 May 2002 05:11:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18715; Fri, 17 May 2002 03:10:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28655; Fri, 17 May 2002 02:10:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4H99trP019235 for ; Fri, 17 May 2002 02:09:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4H99tKI019234 for mobile-ip-dist; Fri, 17 May 2002 02:09:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4H99qrP019227 for ; Fri, 17 May 2002 02:09:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26323 for ; Fri, 17 May 2002 02:09:56 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA24230 for ; Fri, 17 May 2002 02:09:51 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4H99gn08958; Fri, 17 May 2002 11:09:43 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA11916; Fri, 17 May 2002 11:09:42 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4H99dT92942; Fri, 17 May 2002 11:09:39 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205170909.g4H99dT92942@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: arvind.sevalkar@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sending Binding Acknowledgement with routing header. In-reply-to: Your message of Thu, 16 May 2002 23:30:25 +0300. <3CE416E1.1000908@kolumbus.fi> Date: Fri, 17 May 2002 11:09:38 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: The reason for the change was that per the HAO reflection attack discussion, we didn't want HAOs to be accepted unless there was a BCE entry. Clearly there might not be a BCE entry at the time the BU is sent, so there was a chicken-and-egg problem. The alternative solutions were (a) not use HAO in the BU or (b) special processing of the HAO for certain messages i.e. allowing them for BUs. => (c) there is a third solution (c): perform the HAO verification at the right time. But you are right of course in your IPsec comment above, and that wasn't considered in making the change. I wonder if alternative (b) would have been the right approach instead. Lets see... we'll assume the CN has an IPsec policy that drops all other traffic except that which comes from the MN's home address. => this is right but for IPsec the HAO is transparent (this is why it must be before any IPsec header). And this traffic needs to use IPsec. For solution (a) we could not have sent a BU at all to the CN. For solution (b), we can include the HAO and have even this packet pass the policies. Does (b) create any new reflection problems? It does not, if the BA is delivered directly to the MN. Can we always know if special processing is needed? Hmm... we can't if the message is encrypted. But if the message is encrypted, then we have an SA and we should trust HAOs when an SA exists... So, my first thought is that alternative (b) would work better. What do you think? => the best is to wait to have the "upper layer" header to perform the verification (BCE check, IPsec, BU, ...). I don't believe there are DoS vulnerabilities (because the HAO processing is very light) but for reflection ICMP error stuff should be careful so I propose: - a HAO processed flag - a HAO verified flag - verification routine uses IPsec results or BCE check or any other good mechanism - "upper layer" processing should check the first flag and call the verification routine - same for ICMP error triggered by something between HAO and "upper layer" etc. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 07:19:32 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07908 for ; Fri, 17 May 2002 07:19:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08594; Fri, 17 May 2002 05:19:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA25441; Fri, 17 May 2002 04:18:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HBI4rP019508 for ; Fri, 17 May 2002 04:18:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HBI4Vi019507 for mobile-ip-dist; Fri, 17 May 2002 04:18:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HBI1rP019500 for ; Fri, 17 May 2002 04:18:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18156 for ; Fri, 17 May 2002 04:18:05 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA06649 for ; Fri, 17 May 2002 05:18:03 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4HBI20E008341; Fri, 17 May 2002 13:18:02 +0200 (MEST) Received: from bends.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id NAA05968; Fri, 17 May 2002 13:18:01 +0200 Message-Id: <5.1.0.14.0.20020517110949.0201d660@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 17 May 2002 13:18:58 +0200 To: , From: Annika Jonsson Subject: RE: [mobile-ip] Regional Registration Last Call issue #3-DISAGREE In-Reply-To: <000001c1fc4d$a9ab9440$259da5c2@EmadQ> References: <5.1.0.14.0.20020514151146.0286d940@era-t.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Emad, At 10:18 PM 5/15/2002 +0200, Emad Qaddoura wrote: >Pls see comments below on issue F. > > > > > F. added delay with extra round-trip > > > > It was pointed out that if the FA is allowed to deny a regional > > registration because it doesn't support that GFA, this means one extra > > round-trip before the registration is completed, which could lead to >extra > > delay for traffic. > > > > - That is true, but I still think we should allow this feature >because: > > * the first "round-trip" is very short, only to the FA and back. > > * FAs in the same domain should in most cases support the same GFAs so > > this > > would not happen very often. >[<<>>] I don't agree with this justification. Every MS adds up. > > > > * allowing an FA to deny the use of a specific GFA would be useful, >for > > example if a GFA breaks down, since it would force the MN to register >a > > new > > GFA with it's HA. >[<<>>] I agree it would help and handling such case should be part >of the protocol. But, the key here, as stated in sec 5.0 (4th >paragraph), the GFAs are in the SAME DOMAIN, and may be the protocol >should allow a re-direction of the request to another GFA within the >domain, update the MN with the new address in the reply and allow the >transaction to continue without the additional delay. But this would be worse because it would take longer time. The reason why the MN need to know that a GFA is not available is that it must then perform a new home registration to update it's HA (section 5 is about _regional_ registrations). To redirect to a new GFA, without involving the MN, takes longer time that just denying the registration at the FA, and no traffic can reach the MN before it has completed a home registration anyway. Therefore the goal is to get the MN to send a new home registration as soon as possible. But what this discussion shows is that we should clarify how _home_ registrations are handled. Regards, Annika > > * the FA needs a way to deny unvalid registrations, in this case if a > > mobile node uses a non-existent CoA in the registration request. > > > > Therefore I propose that we don't change this. > > > > Regards, > > Annika From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 07:51:16 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09432 for ; Fri, 17 May 2002 07:51:15 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20820; Fri, 17 May 2002 05:51:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA00821; Fri, 17 May 2002 04:50:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HBo2rP019571 for ; Fri, 17 May 2002 04:50:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HBo21V019570 for mobile-ip-dist; Fri, 17 May 2002 04:50:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HBnwrP019563 for ; Fri, 17 May 2002 04:49:59 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24073 for ; Fri, 17 May 2002 04:50:02 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20389 for ; Fri, 17 May 2002 05:50:34 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4HBns0E027640; Fri, 17 May 2002 13:49:55 +0200 (MEST) Received: from bends.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id NAA06822; Fri, 17 May 2002 13:49:53 +0200 Message-Id: <5.1.0.14.0.20020517134303.020984c0@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 17 May 2002 13:50:47 +0200 To: "Ahmad Muhanna", mobile-ip@sunroof.eng.sun.com From: Annika Jonsson Subject: RE: [mobile-ip] Regional Registration Last Call issue #3 In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCCF1@zrc2c013.us.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_176208636==_.ALT" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --=====================_176208636==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Ahmad At 03:38 PM 5/15/2002 -0500, Ahmad Muhanna wrote: >Hello Annika, > >Clarification: Missing technical issue 1: > >In section 4.1 the third paragraph it talks about Mobile Nodes >with co-located care-of address and the way it uses >Regional Registration. This section is under Home Registration. >This means that it does not talk about the Regional Registration mechanism >YET. Because that has a separate section No. 5. > >Now in the third paragraph section 4.1 as shown below, it talks about the >Mobile Node adding a Hierarchical Foreign Agent extension and to be placed >after the MN-HA authentication extension in Registration Request message. >Also, to be protected by the MN-GFA authentication extension. It also >continues >to say using the mobility security association which has been established >with >GFA according to section 3.1.2. > >" ........... > In this case, the mobile node MUST add a > Hierarchical Foreign Agent extension 8.2, including its co-located > care-of address, to the Registration Request before sending it. The > Hierarchical Foreign Agent extension SHOULD be placed after the MN-HA > authentication extension. It SHOULD be authenticated by using the > MN-GFA authentication extension (see Section 10). The authentication > data SHOULD be calculated using a mobility security association > that has been established with the GFA (Section 3.1.2). ........... >" > >I am really confused here for the following points: >1. We are talking about Home registration. Which I understand is the initial >registration with the Mobile Node Home Agent or when it changes GFA. However, >the text talk about the initial registration request here. >2. Now at this point of time, there is no established mobility security >association >between the mobile Node and GFA. >3. section 3.1.2, talks about using the mobility security association, >which has been >established during the initial (Home Registration), in Regional >Registration NOT Home >Registration. >4. In other words, Mobile Node does not have a mobility security >association with the >GFA at the time of initial or Home registration that paragraph 3 talks about. > >Am I correct ? or I am missing something. You are right. We have obviously not put enough effort on the co-located case ;-) This should be clarified, so that in the home registrion, it's the MN-HA auth. extension, and in the regional registration, it's the MN-GFA. >Clarification: Technical issue 2: >In section 8.3 paragraph 3: >" > The mobile node SHOULD append the Replay Protection Style Extension > to the home registration following the MN-HA authentication > extension, but before any MN-GFA authentication extension. Then, > the GFA can remove the extension without damaging the MN-HA > authentication data needed by the home agent. >" > >Do we assume here that there is a statically preconfigured security >association >between the MN and GFA which include a secret key? > >This issue is very much related with Technical issue No. 1. see above. >Clarification: Technical issue 3: >In section 5.3. First Paragraph: > >" If the GFA accepts a request for regional registration, it MUST set > the lifetime to be no greater than the remaining lifetime of the > mobile node's registration with its home agent, and put this lifetime > into the corresponding Regional Registration Reply. The GFA MUST NOT > accept a request for a regional registration if the lifetime of the > mobile node's registration with its home agent has expired. In that > case the GFA sends a Regional Registration Reply with the value in > the Code field set to HOME_REG_EXPIRED. >" > >Are you suggesting that the GFA keeps the binding of the Mobile Node EVEN >after the Home registration lifetime has already expired? No. This should be changed so that when the GFA gets a regional reg.and it doesn't have any home reg. for this MN, it should use a code like "NO_HOME_REG". >Clarification: Technical issue 4: >This is not a technical issue per say BUT it is important in my view: > >Why you are suggesting two different extensions with two different types >for the following extensions: > >1. GFA IP Address Extension >2. Hierarchical Foreign Agent Extension. > >CAN'T we use one extension as per MEIR originally and RFC3220 recently >with one TYPE and two different subtypes. >You never know, those type numbers are going to be very precious >in the very near future!!! Yes, we should. Thanks, Annika >Regards; >Ahmad Muhanna > > --=====================_176208636==_.ALT Content-Type: text/html; charset="us-ascii" Hi Ahmad

At 03:38 PM 5/15/2002 -0500, Ahmad Muhanna wrote:

Hello Annika,

Clarification: Missing technical issue 1:

In section 4.1 the third paragraph it talks about Mobile Nodes
with co-located care-of address and the way it uses
Regional Registration. This section is under Home Registration.
This means that it does not talk about the Regional Registration mechanism
YET. Because that has a separate section No. 5.

Now in the third paragraph section 4.1 as shown below, it talks about the
Mobile Node adding a Hierarchical Foreign Agent extension and to be placed
after the MN-HA authentication extension in Registration Request message.
Also, to be protected by the MN-GFA authentication extension. It also continues
to say using the mobility security association which has been established with
GFA according to section 3.1.2.

" ...........
   In this case, the mobile node MUST add a
   Hierarchical Foreign Agent extension 8.2, including its co-located
   care-of address, to the Registration Request before sending it.  The
   Hierarchical Foreign Agent extension SHOULD be placed after the MN-HA
   authentication extension.  It SHOULD be authenticated by using the
   MN-GFA authentication extension (see Section 10).  The authentication
   data SHOULD be calculated using a mobility security association
   that has been established with the GFA (Section 3.1.2). ...........
"

I am really confused here for the following points:
1. We are talking about Home registration. Which I understand is the initial
registration with the Mobile Node Home Agent or when it changes GFA. However,
the text talk about the initial registration request here.
2. Now at this point of time, there is no established mobility security association
between the mobile Node and GFA.
3. section 3.1.2, talks about using the mobility security association, which has been
established during the initial (Home Registration), in Regional Registration NOT Home
Registration.
4. In other words, Mobile Node does not have a mobility security association with the
GFA at the time of initial or Home registration that paragraph 3 talks about.

Am I correct ? or I am missing something.


You are right. We have obviously not put enough effort on the co-located case ;-) This should be clarified, so that in the home registrion, it's the MN-HA auth. extension, and in the regional registration, it's the MN-GFA.

Clarification: Technical issue 2:
In section 8.3 paragraph 3:
"
   The mobile node SHOULD append the Replay Protection Style Extension
   to the home registration following the MN-HA authentication
   extension, but before any MN-GFA authentication extension.  Then,
   the GFA can remove the extension without damaging the MN-HA
   authentication data needed by the home agent.
"

Do we assume here that there is a statically preconfigured security association
between the MN and GFA which include a secret key?

This issue is very much related with Technical issue No. 1.

see above.

Clarification: Technical issue 3:
In section 5.3. First Paragraph:

" If the GFA accepts a request for regional registration, it MUST set
   the lifetime to be no greater than the remaining lifetime of the
   mobile node's registration with its home agent, and put this lifetime
   into the corresponding Regional Registration Reply.  The GFA MUST NOT
   accept a request for a regional registration if the lifetime of the
   mobile node's registration with its home agent has expired.  In that
   case the GFA sends a Regional Registration Reply with the value in
   the Code field set to HOME_REG_EXPIRED.
"

Are you suggesting that the GFA keeps the binding of the Mobile Node EVEN
after the Home registration lifetime has already expired?

No. This should be changed so that when the GFA gets a regional reg.and it doesn't have any home reg. for this MN, it should use a code like "NO_HOME_REG".

Clarification: Technical issue 4:
This is not a technical issue per say BUT it is important in my view:

Why you are suggesting two different extensions with two different types
for the following extensions:

1.      GFA IP Address Extension
2.      Hierarchical Foreign Agent Extension.

CAN'T we use one extension as per MEIR originally and RFC3220 recently
with one TYPE and two different subtypes.
You never know, those type numbers are going to be very precious
in the very near future!!!

Yes, we should.

Thanks,
Annika

Regards;
Ahmad Muhanna

 
--=====================_176208636==_.ALT-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 08:12:21 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09966 for ; Fri, 17 May 2002 08:12:16 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12672; Fri, 17 May 2002 05:10:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA27649; Fri, 17 May 2002 05:10:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HC9NrP019620 for ; Fri, 17 May 2002 05:09:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HC9NT1019619 for mobile-ip-dist; Fri, 17 May 2002 05:09:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HC9JrP019612 for ; Fri, 17 May 2002 05:09:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA03379 for ; Fri, 17 May 2002 05:09:24 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28246 for ; Fri, 17 May 2002 06:09:55 -0600 (MDT) Received: by planetajeans.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 08:09:22 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46E2200A@ftmail> From: "Alan O'Neill" To: Phil Roberts , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] RR Last Call Resolution Issue #4 - CLARIFICATION Date: Fri, 17 May 2002 08:09:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I thought it might be useful if I stated specifically why I feel MIP doesn't affect end to end at all. By definition it is a tunnel protocol coupled with Internet routing which in addition has host routing into that tunnel. The packet within the tunnel is not touched or modified on its travels and hence end to end is not affected. The IP address is still the identifier and the locator, but routing has simply moved the location. The redirection is at the edge of the network (subnet to subnet) so preserving end to end. The fact that the HA is on an edge in the core (just like a webserver) doesn't change the argument. The HA has one tunnel endpoint and the FA or MN the other. If we put a GFA in the middle then it is only affecting the tunnel not the inner packet. Now we wouldn't claim running multicast over unicast tunnels breaks end to end and we wouldn't claim that MPLS lable switching (another switching layer carrying user packets) breaks end to end either. End to end is about the users packets and ensuring that the endpoint is aware of stuff going on. The MN is issuing the redirection so I think we are completely clean here. The issue with GFA and MIP is simply to me the soft-state requirement and its impact on availability, unavailability and signalling load. We begin to impact end to end when the soft-state refresh rate in insufficient to protect the users interests in the flow... Hope that is clear and logical, Alan -----Original Message----- From: Alan O'Neill [mailto:A.ONeill@flarion.com] Sent: 16 May 2002 16:42 To: Phil Roberts; 'mobile-ip@sunroof.eng.sun.com' Subject: RE: [mobile-ip] RR Last Call Resolution Issue #4 - CLARIFICATION I think this is maybe a bit of a red herring wg for the following reasons. MIP is a soft-state refresh protocol with periodic refresh as a fraction of the binding lifetime. Any arguments about statefulness come down to the refresh interval you are prepared to tolerate in return for higher availability through reduced unavailability when a node crashes. When a router goes down we are typically happy to wait for OSPF convergence times which are large numbers of seconds. We shouldn't ask for much more from MIP. Adding a GFA or an RMA (from Nested) doesn't change the flexibility of the operator and/or MN to tune lifetimes, and having a big router or a big regional element fail impacts just as many flows for OSPF convergence time so I feel that is also a bit of a red herring. especially in a tree network.. The bigger but different problem here is that costly and localised high availability solutions (hot-standby) that vendors would try to use to protect the regional element whilst also having long lifetimes to reduce the signalling overhead, do not work with GFA because the HA must also be updated. This is why the RMA places a routable MN specific address in the HA so that these hot-standby techniques can still be localised. This is the aspect of GFA that is problematic here... Alan. -----Original Message----- From: Phil Roberts [mailto:PRoberts@MEGISTO.com] Sent: 15 May 2002 05:55 To: 'mobile-ip@sunroof.eng.sun.com' Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Several folks raised the issue of to what extent introducing regional registration entities in the visited network violates principles of the Internet architecture, specifically with regard to the introduction of single points of failure in the communication path of visiting nodes. I've excerpted the relevant text from rfc 1958 on the architectural principle which is at issue. "The end-to-end argument is discussed in depth in [Saltzer]. The basic argument is that, as a first principle, certain required end- to-end functions can only be performed correctly by the end-systems themselves. A specific case is that any network, however carefully designed, will be subject to failures of transmission at some statistically determined rate. The best way to cope with this is to accept it, and give responsibility for the integrity of communication to the end systems. Another specific case is end-to-end security. To quote from [Saltzer], "The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the endpoints of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.") This principle has important consequences if we require applications to survive partial network failures. An end-to-end protocol design should not rely on the maintenance of state (i.e. information about the state of the end-to-end communication) inside the network. Such state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks (known as fate-sharing). An immediate consequence of this is that datagrams are better than classical virtual circuits. The network's job is to transmit datagrams as efficiently and flexibly as possible." draft-iab-arch-changes-00.txt provides a discussion of this issue of fate-sharing in middleboxes and asserts that the principle is preserved in the case that the middlebox is a partner in the communication when the failure can be detected and dealt with.: "The idea of fate-sharing survives this recursion, but requires that all application state created in middleboxes must be capable of re- creation after failure. Additionally, to support this requirement, where a function cannot be fulfilled completely, reliably and securely by two endpoints of a conversation, the necessary middleboxes to fulfil the function should be explicit partners in explicit communication with at least one endpoint (or, by recursion of the same principle, with an intermediate middlebox). In other words, middleboxes should not be invisible, because their failures need to be detected and dealt with by their communication partners." As currently specified it's not immediately obvious how the regional registration agents are compatible with the above guidelines. It's conceivable that they can be made so, and perhaps it's immediately obvious to others how they are so. This issue is not insurmountable but the functionality does need to be specified in a way that preserves the fate sharing principle and allows for one party in the communication to detect and deal with a failure of one of the new registration entities. From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 09:36:26 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13277 for ; Fri, 17 May 2002 09:36:26 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15230; Fri, 17 May 2002 07:36:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02883; Fri, 17 May 2002 06:36:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HDYwrP019791 for ; Fri, 17 May 2002 06:34:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HDYwc1019790 for mobile-ip-dist; Fri, 17 May 2002 06:34:58 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HDYsrP019782 for ; Fri, 17 May 2002 06:34:54 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02369 for ; Fri, 17 May 2002 06:34:29 -0700 (PDT) Received: from amber.ccs.neu.edu (amber.ccs.neu.edu [129.10.116.51]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00144 for ; Fri, 17 May 2002 06:34:28 -0700 (PDT) Received: from CASABLANCA.ccs.neu.edu (casablanca.ccs.neu.edu [129.10.118.188]) by amber.ccs.neu.edu (Postfix) with ESMTP id C8F241AAEF; Fri, 17 May 2002 09:34:27 -0400 (EDT) Message-Id: <5.0.2.1.0.20020517092500.031bdbe8@mail.ccs.neu.edu> X-Sender: noubir@mail.ccs.neu.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 17 May 2002 09:25:32 -0400 To: mobile-ip@sunroof.eng.sun.com From: "G. Noubir" Subject: [mobile-ip] Deadline Extended to May 30, Workshop on Wireless Security (in conjunction with MobiCom 2002) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The deadline for paper submissions was extended to May 30, 2002. Best regards, Guevara ----------------------------------------------------------------------- Please Accept Our Sincere Apologies Should you Receive Multiple Copies of this CFP ----------------------------------------------------------------------- Call for Papers Workshop on Wireless Security (WiSe) in conjunction with ACM MobiCom 2002 September 28, 2002 Atlanta, Georgia, U.S.A. http://www.crhc.uiuc.edu/~nhv/wise Sponsored by SIGMOBILE (pending) A workshop on Wireless Security will be held in conjunction with ACM MobiCom 2002. The objective of this workshop is to bring together researchers from research communities in wireless networking, security, and dependability, with the goal of fostering interaction among them. With the increasing reliance on wireless networks, issues related to secure and dependable operation of such networks are gaining importance. Topics of interest include, but are not limited to: * Key management in wireless/mobile environments * Intrusion detection * Secure MAC protocols * Secure routing * Denial of service * Privacy and anonymity * Prevention of traffic analysis * Dependable wireless networking * Monitoring and surveillance * Disaster response Paper submission instructions: Submission of papers based on work-in-progress is encouraged. Submitted papers must not be previously published elsewhere or currently under review for any other publication. Please direct any questions about the paper submission process to the Program Co-Chairs. All paper submissions will be handled electronically. Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. Papers must meet the following restrictions: No longer than 10 pages (single or double column); in font no smaller than 11 points; must fit properly on US Letter-sized paper (8.5 inch x 11 inch) with reasonable margins. Instructions for electronic submission of papers will be posted at http://www.crhc.uiuc.edu/~nhv/wise/submission.html. Important dates: Paper submissions due: May 30, 2002 Notification of acceptance: July 5, 2002 Camera-ready papers due: July 31, 2002 Workshop date: September 28, 2002 Workshop Co-Chairs: * Douglas Maughan, Defense Advanced Research Projects Agency (dmaughan@darpa.mil) * Nitin Vaidya, University of Illinois at Urbana-Champaign (nhv@uiuc.edu) Program Committee: Yair Amir, Johns Hopkins University Pete Dinsmore, NAI Chip Elliott, BBN Technologies Zygmunt Haas, Cornell University Jean-Pierre Hubaux, EPFL-Lausanne David B. Johnson, Rice University Douglas Maughan, Defense Advanced Research Projects Agency (co-chair) Brian Noble, University of Michigan Ranga Ramanujan, Architecture Technology Corporation Frank Stajano, University of Cambridge Brian Van Leeuwen, Sandia National Laboratories Nitin Vaidya, University of Illinois at Urbana-Champaign (co-chair) Wei Zhao, Texas A&M University Taieb Znati, National Science Foundation, and University of Pittsburgh Publicity Co-Chairs: Mohsen Guizani, University of West Florida Guevara Noubir, Northeastern University Publication Chair: Saad Biaz, Auburn University Registration Chair: Robin Kravets, University of Illinois at Urbana-Champaign From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 09:36:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13295 for ; Fri, 17 May 2002 09:36:37 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08451; Fri, 17 May 2002 07:36:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02917; Fri, 17 May 2002 06:36:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HDYVrP019780 for ; Fri, 17 May 2002 06:34:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HDYUQc019779 for mobile-ip-dist; Fri, 17 May 2002 06:34:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HDYBrP019772 for ; Fri, 17 May 2002 06:34:11 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11328 for ; Fri, 17 May 2002 06:33:55 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24230 for ; Fri, 17 May 2002 06:33:49 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4HDXv814200; Fri, 17 May 2002 08:33:57 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 08:33:55 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCD05@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Annika Jonsson'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call issue #3 CLARIFIC ATION Date: Fri, 17 May 2002 08:33:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FDA7.7C611EF0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FDA7.7C611EF0 Content-Type: text/plain; charset="iso-8859-1" Hello Annika; > > Hi > > Here are my conclusions and proposals for additions/changes > to solve most > of the technical issues raised during last call of Regional > Registrations. I have excluded the issues around multiple levels of > hierarchies, which will be dealt with separatley. > > Respond as to whether you AGREE, DISAGREE, or CAN LIVE WITH the > recommendation. And on the response put in the subject line, > CLARIFICATION > if you have a clarification to recommend, or ISSUE if you > have an issue to > raise. > > A. Differnet addressing realms. > > The issues raised about supporting different addressing > realms between > FA-GFA and GFA-HA (i.e. the GFA is placed on the border between those > addressing realms). The basic problem is how to allow for > flexibility in > addressing between FA-GFA and GFA-HA, which does not work > with the way the > draft specifies the use of GFA CoA today. To allow this, it > should be the > GFA that decides wich CoA to use, possibly individually for > each MN. To > support this, the following changes are proposed: > > - clarify that a MN that supports regional registrations > SHOULD send home > registrations with a zero CoA, to allow the GFA to allocate > CoA. (it is > SHOULD and not MUST, because if the MN's HA doesn't support regional > registrations, it should be allowed to use an advertised CoA, > see mail on > issue #2). An FA can force the use of zero CoA by not > advertising any CoA > address, but it will then not be backwards compatible (see > mail on issues > #2). This will be clarified in section 4.1. > > - change the allocation of CoA if the MN uses zero COA in the > registration: > in the draft right now, it is the FA that decides what CoA > the MN gets. > This should be changed so that the FA only forwards the > registration to a > GFA node (using an address in the address realm between the > FA-GFA). Then > the GFA selects the CoA (possibly based on the MN:s HA > address, or MN-NAI > if present, or information from AAA server etc...), adds GFA > IP extension, > protects it with FA-HA auth- extension and sends it to the > HA. This will be > changed in section 4.2, 4.3 and 8.1. > > - clarifiy that if the FA advertises a GFA CoA, this is regarded as a > "default" CoA that could be used, especially by MN:s that > supports regional > registrations, but have HA:s that don't. If this CoA is not > within the same > addressing realm as the FA-GFA, the FA needs to have a mapping to the > address that it should use to communicate with the GFA. This > will be added > to section 4.2 > > B. too many options. > > Some people commented that it is a problem with too may > optional ways to do > things, since it would be difficlut to imlement and can > create problems for > interoperability. > > - Most of the options are around the advertised addresses and > what address > the mobile node uses in registration messages. Hopefully this is much > better now that we clarifies the use of those addresses both > for backwards > compatibility and for different addressing realms, so I > consider this issue > solved > > C. protection of the GFA IP address extension > > It was pointed out that the GFA IP address extension needs to > be protected > by an authentication extension. > > - this should be clarified in section 4.3. > > D. reverse tunnelling clarification > > It was pointed out that if reverse tunnelling is used, the FA > must use the > address in the registration request (from the HFA extension) > as source for > the tunnel. > > - this should be clarified in section 4.2 and 4.3. > > E. Generalized NAI extension > > There was a question about why the Generalized NAI extension > is needed, why > not use an FA-NAI extension directly? > I am sorry I forgot to comment on this one. I think I am the one who raised this clarification. I did not mean that you SHOULD NOT use GNAI. What I meant: Why do we need to have a special section about GNAI for this extension. GNAI already presented some where else. You can just say that we are using GNAI extension with this type and subtype. No more no less. What do you think? > - RFC3220 recommends that new extensions should be in this format if > possible. Therefore I propose that we keep this. > > F. added delay with extra round-trip > > It was pointed out that if the FA is allowed to deny a regional > registration because it doesn't support that GFA, this means > one extra > round-trip before the registration is completed, which could > lead to extra > delay for traffic. > > - That is true, but I still think we should allow this > feature because: > * the first "round-trip" is very short, only to the FA and back. > * FAs in the same domain should in most cases support the > same GFAs so this > would not happen very often. > * allowing an FA to deny the use of a specific GFA would be > useful, for > example if a GFA breaks down, since it would force the MN to > register a new > GFA with it's HA. > * the FA needs a way to deny unvalid registrations, in this case if a > mobile node uses a non-existent CoA in the registration request. > > Therefore I propose that we don't change this. > > Regards, > Annika > > ------_=_NextPart_001_01C1FDA7.7C611EF0 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Regional Registration Last Call issue #3 CLARIFICATION

Hello Annika;

>
> Hi
>
> Here are my conclusions and proposals for additions/changes
> to solve most
> of  the technical  issues raised during last call of Regional
> Registrations. I have excluded the issues around multiple levels of
> hierarchies, which will be dealt with separatley.
>
> Respond as to whether you AGREE, DISAGREE, or CAN LIVE WITH the
> recommendation. And on the response put in the subject line,
> CLARIFICATION
> if you have a clarification to recommend, or ISSUE if you
> have an issue to
> raise.
>
> A. Differnet addressing realms.
>
> The issues raised about supporting different addressing
> realms between
> FA-GFA and GFA-HA (i.e. the GFA is placed on the border between those
> addressing realms). The basic problem is how to allow for
> flexibility in
> addressing between FA-GFA and GFA-HA, which does not work
> with the way the
> draft specifies the use of GFA CoA today. To allow this, it
> should be the
> GFA that decides wich CoA to use, possibly individually for
> each MN. To
> support this, the following changes are proposed:
>
> - clarify that a MN that supports regional registrations
> SHOULD send home
> registrations with a zero CoA, to allow the GFA to allocate
> CoA. (it is
> SHOULD and not MUST, because if the MN's HA doesn't support regional
> registrations, it should be allowed to use an advertised CoA,
> see mail on
> issue #2). An FA can force the use of zero CoA by not
> advertising any CoA
> address, but it will then not be backwards compatible (see
> mail on issues
> #2). This will be clarified in section 4.1.
>
> - change the allocation of CoA if the MN uses zero COA in the
> registration:
> in the draft right now, it is the FA that decides what CoA
> the MN gets.
> This should be changed so that the FA only forwards the
> registration to a
> GFA node (using an address in the address realm between the
> FA-GFA). Then
> the GFA selects the CoA (possibly based on the MN:s HA
> address, or  MN-NAI
> if present, or information from AAA server etc...), adds GFA
> IP extension,
> protects it with FA-HA auth- extension and sends it to the
> HA. This will be
> changed in section 4.2, 4.3 and 8.1.
>
> - clarifiy that if the FA advertises a GFA CoA, this is regarded as a
> "default" CoA that could be used, especially by MN:s that
> supports regional
> registrations, but have HA:s that don't. If this CoA is not
> within the same
> addressing realm as the FA-GFA, the FA needs to have a mapping to the
> address that it should use to communicate with the GFA. This
> will be added
> to section 4.2
>
> B. too many options.
>
> Some people commented that it is a problem with too may
> optional ways to do
> things, since it would be difficlut to imlement and can
> create problems for
> interoperability.
>
> - Most of the options are around the advertised addresses and
> what address
> the mobile node uses in registration messages. Hopefully this is much
> better now that we clarifies the use of those addresses both
> for backwards
> compatibility and for different addressing realms, so I
> consider this issue
> solved
>
> C. protection of the GFA IP address extension
>
> It was pointed out that the GFA IP address extension needs to
> be protected
> by an authentication extension.
>
> - this should be clarified in section 4.3.
>
> D. reverse tunnelling clarification
>
> It was pointed out that if reverse tunnelling is used, the FA
> must use the
> address in the registration request (from the HFA extension)
> as source for
> the tunnel.
>
> - this should be clarified in section 4.2 and 4.3.
>
> E. Generalized NAI extension
>
> There was a question about why the Generalized NAI extension
> is needed, why
> not use an FA-NAI extension directly?
>
I am sorry I forgot to comment on this one. I think I am the one who raised this clarification.
I did not mean that you SHOULD NOT use GNAI. What I meant:
Why do we need to have a special section about GNAI for this extension.
GNAI already presented some where else. You can just say that we are using
GNAI extension with this type and subtype. No more no less.

What do you think?

> - RFC3220 recommends that new extensions should be in this format if
> possible. Therefore I propose that we keep this.
>
> F. added delay with extra round-trip
>
> It was pointed out that if the FA is allowed to deny a regional
> registration because it doesn't support that GFA, this means
> one extra
> round-trip before the registration is completed, which could
> lead to extra
> delay for traffic.
>
> - That is true, but I still think we should allow this
> feature because:
> *  the first "round-trip" is very short, only to the FA and back.
> * FAs in the same domain should in most cases support the
> same GFAs so this
> would not happen very often.
> * allowing an FA to deny the use of a specific GFA would be
> useful, for
> example if a GFA breaks down, since it would force the MN to
> register a new
> GFA with it's HA.
> * the FA needs a way to deny unvalid registrations, in this case if a
> mobile node uses a non-existent CoA in the registration request.
>
> Therefore I propose that we don't change this.
>
> Regards,
> Annika
>
>

------_=_NextPart_001_01C1FDA7.7C611EF0-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 09:47:16 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13789 for ; Fri, 17 May 2002 09:47:16 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19660; Fri, 17 May 2002 07:47:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05673; Fri, 17 May 2002 06:46:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HDjlrP019863 for ; Fri, 17 May 2002 06:45:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HDjlCC019862 for mobile-ip-dist; Fri, 17 May 2002 06:45:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HDjirP019855 for ; Fri, 17 May 2002 06:45:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13210 for ; Fri, 17 May 2002 06:45:43 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01173 for ; Fri, 17 May 2002 06:45:43 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 0D7BC6A919; Fri, 17 May 2002 16:45:37 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 31C566A901; Fri, 17 May 2002 16:45:35 +0300 (EEST) Message-ID: <3CE509BC.4090306@piuha.net> Date: Fri, 17 May 2002 16:46:36 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: arvind.sevalkar@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sending Binding Acknowledgement with routing header. References: <200205170909.g4H99dT92942@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > The reason for the change was that per the HAO reflection attack discussion, > we didn't want HAOs to be accepted unless there was a BCE > entry. Clearly there might not be a BCE entry at the time the BU is > sent, so there was a chicken-and-egg problem. > The alternative solutions were (a) not use HAO in the BU or (b) special > processing of the HAO for certain messages i.e. allowing them for BUs. > > => (c) there is a third solution (c): perform the HAO verification at > the right time. > > But you are right of course in your IPsec comment above, and that wasn't > considered in making the change. I wonder if alternative (b) would have been > the right approach instead. Lets see... we'll assume the CN has an IPsec > policy that drops all other traffic except that which comes from > the MN's home address. > > => this is right but for IPsec the HAO is transparent (this is why it must > be before any IPsec header). > > And this traffic needs to use IPsec. For solution (a) we could not have sent > a BU at all to the CN. For solution (b), we can include the HAO and have > even this packet pass the policies. Does (b) create any new reflection > problems? > It does not, if the BA is delivered directly to the MN. Can we always know > if special processing is needed? Hmm... we can't if the message is > encrypted. > But if the message is encrypted, then we have an SA and we should trust HAOs > when an SA exists... So, my first thought is that alternative (b) would work > better. What do you think? > > => the best is to wait to have the "upper layer" header to perform the > verification (BCE check, IPsec, BU, ...). I don't believe there are DoS > vulnerabilities (because the HAO processing is very light) but for > reflection ICMP error stuff should be careful so I propose: > - a HAO processed flag > - a HAO verified flag > - verification routine uses IPsec results or BCE check or any other > good mechanism > - "upper layer" processing should check the first flag and call the > verification routine > - same for ICMP error triggered by something between HAO and "upper layer" > etc. Works for me. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 10:43:46 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16123 for ; Fri, 17 May 2002 10:43:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24413; Fri, 17 May 2002 08:43:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA27448; Fri, 17 May 2002 07:43:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HEgbrP020040 for ; Fri, 17 May 2002 07:42:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HEgbF4020039 for mobile-ip-dist; Fri, 17 May 2002 07:42:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HEgYrP020032 for ; Fri, 17 May 2002 07:42:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22476 for ; Fri, 17 May 2002 07:42:37 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05531 for ; Fri, 17 May 2002 08:42:37 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4HEgh805340; Fri, 17 May 2002 09:42:43 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 09:42:39 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCD08@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Annika Jonsson'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call issue #3 DISAGREE Date: Fri, 17 May 2002 09:42:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FDB1.16F5A2C0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FDB1.16F5A2C0 Content-Type: text/plain; charset="iso-8859-1" Hello Annika; Please see my comment below. Hi Ahmad At 03:38 PM 5/15/2002 -0500, Ahmad Muhanna wrote: Hello Annika, Clarification: Missing technical issue 1: In section 4.1 the third paragraph it talks about Mobile Nodes with co-located care-of address and the way it uses Regional Registration. This section is under Home Registration. This means that it does not talk about the Regional Registration mechanism YET. Because that has a separate section No. 5. Now in the third paragraph section 4.1 as shown below, it talks about the Mobile Node adding a Hierarchical Foreign Agent extension and to be placed after the MN-HA authentication extension in Registration Request message. Also, to be protected by the MN-GFA authentication extension. It also continues to say using the mobility security association which has been established with GFA according to section 3.1.2. " ........... In this case, the mobile node MUST add a Hierarchical Foreign Agent extension 8.2, including its co-located care-of address, to the Registration Request before sending it. The Hierarchical Foreign Agent extension SHOULD be placed after the MN-HA authentication extension. It SHOULD be authenticated by using the MN-GFA authentication extension (see Section 10). The authentication data SHOULD be calculated using a mobility security association that has been established with the GFA (Section 3.1.2). ........... " I am really confused here for the following points: 1. We are talking about Home registration. Which I understand is the initial registration with the Mobile Node Home Agent or when it changes GFA. However, the text talk about the initial registration request here. 2. Now at this point of time, there is no established mobility security association between the mobile Node and GFA. 3. section 3.1.2, talks about using the mobility security association, which has been established during the initial (Home Registration), in Regional Registration NOT Home Registration. 4. In other words, Mobile Node does not have a mobility security association with the GFA at the time of initial or Home registration that paragraph 3 talks about. Am I correct ? or I am missing something. You are right. We have obviously not put enough effort on the co-located case ;-) This should be clarified, so that in the home registrion, it's the MN-HA auth. extension, and in the regional registration, it's the MN-GFA. <> I DISAGREE As per your draft text and the understanding of the functionality you are proposing, the Replay Protection extension is destined to the GFA NOT the Home Agent. It also needed in the Home Registration ONLY. Therefore, it has to come after the MN-HA authentication extension not before. The issue still not addressed. <> Clarification: Technical issue 2: In section 8.3 paragraph 3: " The mobile node SHOULD append the Replay Protection Style Extension to the home registration following the MN-HA authentication extension, but before any MN-GFA authentication extension. Then, the GFA can remove the extension without damaging the MN-HA authentication data needed by the home agent. " Do we assume here that there is a statically preconfigured security association between the MN and GFA which include a secret key? This issue is very much related with Technical issue No. 1. see above. <> I DISAGREE See comments above. <> Clarification: Technical issue 3: In section 5.3. First Paragraph: " If the GFA accepts a request for regional registration, it MUST set the lifetime to be no greater than the remaining lifetime of the mobile node's registration with its home agent, and put this lifetime into the corresponding Regional Registration Reply. The GFA MUST NOT accept a request for a regional registration if the lifetime of the mobile node's registration with its home agent has expired. In that case the GFA sends a Regional Registration Reply with the value in the Code field set to HOME_REG_EXPIRED. " Are you suggesting that the GFA keeps the binding of the Mobile Node EVEN after the Home registration lifetime has already expired? No. This should be changed so that when the GFA gets a regional reg.and it doesn't have any home reg. for this MN, it should use a code like "NO_HOME_REG". Clarification: Technical issue 4: This is not a technical issue per say BUT it is important in my view: Why you are suggesting two different extensions with two different types for the following extensions: 1. GFA IP Address Extension 2. Hierarchical Foreign Agent Extension. CAN'T we use one extension as per MEIR originally and RFC3220 recently with one TYPE and two different subtypes. You never know, those type numbers are going to be very precious in the very near future!!! Yes, we should. Thanks, Annika Regards; Ahmad Muhanna ------_=_NextPart_001_01C1FDB1.16F5A2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Regional Registration Last Call issue #3 = DISAGREE

Hello Annika;
Please see my comment below.

Hi Ahmad

At 03:38 PM 5/15/2002 -0500, Ahmad Muhanna = wrote:


Hello Annika,

Clarification: Missing technical issue 1:

In section 4.1 the third paragraph it talks about = Mobile Nodes
with co-located care-of address and the way it uses =
Regional Registration. This section is under Home = Registration.
This means that it does not talk about the Regional = Registration mechanism
YET. Because that has a separate section No. 5. =

Now in the third paragraph section 4.1 as shown = below, it talks about the
Mobile Node adding a Hierarchical Foreign Agent = extension and to be placed
after the MN-HA authentication extension in = Registration Request message.
Also, to be protected by the MN-GFA authentication = extension. It also continues
to say using the mobility security association which = has been established with
GFA according to section 3.1.2.

" ...........
   In this case, the mobile node MUST add = a
   Hierarchical Foreign Agent extension = 8.2, including its co-located
   care-of address, to the Registration = Request before sending it.  The
   Hierarchical Foreign Agent extension = SHOULD be placed after the MN-HA
   authentication extension.  It = SHOULD be authenticated by using the
   MN-GFA authentication extension (see = Section 10).  The authentication
   data SHOULD be calculated using a = mobility security association
   that has been established with the GFA = (Section 3.1.2). ...........
"

I am really confused here for the following points: =
1. We are talking about Home registration. Which I = understand is the initial
registration with the Mobile Node Home Agent or when = it changes GFA. However,
the text talk about the initial registration request = here.
2. Now at this point of time, there is no = established mobility security association
between the mobile Node and GFA.
3. section 3.1.2, talks about using the mobility = security association, which has been
established during the initial (Home Registration), = in Regional Registration NOT Home
Registration.
4. In other words, Mobile Node does not have a = mobility security association with the
GFA at the time of initial or Home registration that = paragraph 3 talks about.

Am I correct ? or I am missing something.



You are right. We have obviously not put enough = effort on the co-located case ;-) This should be clarified, so that in = the home registrion, it's the MN-HA auth. extension, and in the = regional registration, it's the MN-GFA.

<<Ahmad>>
I DISAGREE

As per your draft text and the understanding of the = functionality you are
proposing, the Replay Protection extension is = destined to the GFA NOT the
Home Agent. It also needed in the Home Registration = ONLY.
Therefore, it has to come after the MN-HA = authentication extension
not before. The issue still not addressed.

<<END>>

Clarification: Technical issue 2:
In section 8.3 paragraph 3:
"
   The mobile node SHOULD append the = Replay Protection Style Extension
   to the home registration following the = MN-HA authentication
   extension, but before any MN-GFA = authentication extension.  Then,
   the GFA can remove the extension = without damaging the MN-HA
   authentication data needed by the home = agent.
"

Do we assume here that there is a statically = preconfigured security association
between the MN and GFA which include a secret key? =

This issue is very much related with Technical issue = No. 1.


see above.
<<Ahmad>>
I DISAGREE

See comments above.

<<END>>

Clarification: Technical issue 3:
In section 5.3. First Paragraph:

" If the GFA accepts a request for regional = registration, it MUST set
   the lifetime to be no greater than the = remaining lifetime of the
   mobile node's registration with its = home agent, and put this lifetime
   into the corresponding Regional = Registration Reply.  The GFA MUST NOT
   accept a request for a regional = registration if the lifetime of the
   mobile node's registration with its = home agent has expired.  In that
   case the GFA sends a Regional = Registration Reply with the value in
   the Code field set to HOME_REG_EXPIRED. =
"

Are you suggesting that the GFA keeps the binding of = the Mobile Node EVEN
after the Home registration lifetime has already = expired?


No. This should be changed so that when the GFA gets = a regional reg.and it doesn't have any home reg. for this MN, it should = use a code like "NO_HOME_REG".


Clarification: Technical issue 4:
This is not a technical issue per say BUT it is = important in my view:

Why you are suggesting two different extensions with = two different types
for the following extensions:

1.      GFA IP Address = Extension
2.      Hierarchical = Foreign Agent Extension.

CAN'T we use one extension as per MEIR originally and = RFC3220 recently
with one TYPE and two different subtypes.
You never know, those type numbers are going to be = very precious
in the very near future!!!


Yes, we should.

Thanks,
Annika


Regards;
Ahmad Muhanna

 

------_=_NextPart_001_01C1FDB1.16F5A2C0-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 11:34:43 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17672 for ; Fri, 17 May 2002 11:34:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24175; Fri, 17 May 2002 09:34:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17914; Fri, 17 May 2002 08:34:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HFXOrP020146 for ; Fri, 17 May 2002 08:33:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HFXOhj020145 for mobile-ip-dist; Fri, 17 May 2002 08:33:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HFXKrP020138 for ; Fri, 17 May 2002 08:33:20 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11444 for ; Fri, 17 May 2002 08:33:25 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12031 for ; Fri, 17 May 2002 08:33:24 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4HFXX827703; Fri, 17 May 2002 10:33:33 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 10:33:22 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCD0A@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Annika Jonsson'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call issue #3: ISSUE Date: Fri, 17 May 2002 10:33:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FDB8.2C95F740" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FDB8.2C95F740 Content-Type: text/plain; charset="iso-8859-1" Hello Annika I just noticed that there is a very serious issue in the replay protection scheme you are proposing. Here is the details: 1. Your proposal suggest that MN inform the GFA about the replay protection it is using with its Home Agent using the Replay Protection Extension " 0 Timestamp, 1 nonce" 2. Despite the fact that there is a serious security hole here, BUT let us assume that there is NOT. 3. When GFA receives the Mobile Node Home registration it looks into the Replay protection extension and find out which scheme it needs to use for this Mobile Node during its regional registration. 4. GFA forwards the registration request without the replay protection extension, since HA knows that from the SA with the Mobile Node. 5. Let us assume that the MN (using timestamp) is NOT in sync with its HA. THEN HA rejects the registration request with code 133 and send the registration reply to the GFA. 6. GFA forwards the registration reply to the MN which uses the registration reply ID to sync itself with its HA. 7. MN sends another Home registration request with the replay protection extension included. 8. GFA forwards the MN home registration request to the HA which accepts it and sends registration reply message with code 0. 9. GFA updates the MN binding with lifetime, etc. NOW: 10. MN moves to a new FA and send a regional registration request to GFA. 11. OOPS! MN IS IN SYNC WITH ITS HA not this GFA. What the GFA is supposed to do. Let us remember the GFA and HA belongs to two different vendors who are very far apart from each other. That is why we are proposing the regional registration to save Home Registration Signaling. Do you suggest that GFA sync itself with the HA, which is apparently impossible. Because, GFA serves many different HAs. OR MN needs another two round trips registration to sync itself with every GFA it register with while away from Home. Thanks for your consideration. Regards; Ahmad Muhanna ------_=_NextPart_001_01C1FDB8.2C95F740 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Regional Registration Last Call issue #3: ISSUE

Hello Annika
I just noticed that there is a very serious issue in the replay protection scheme you are proposing.
Here is the details:

1. Your proposal suggest that MN inform the GFA about the replay protection it is using
    with its Home Agent using the Replay Protection Extension " 0 Timestamp, 1 nonce"
2. Despite the fact that there is a serious security hole here, BUT let us assume that
    there is NOT.
3. When GFA receives the Mobile Node Home registration it looks into the Replay protection
    extension and find out which scheme it needs to use for this Mobile Node during its regional
    registration.
4. GFA forwards the registration request without the replay protection extension, since HA knows
    that from the SA with the Mobile Node.
5. Let us assume that the MN (using timestamp) is NOT in sync with its HA. THEN HA rejects
    the registration request with code 133 and send the registration reply to the GFA.
6. GFA forwards the registration reply to the MN which uses the registration reply ID to sync
    itself with its HA.
7. MN sends another Home registration request with the replay protection extension included.
8. GFA forwards the MN home registration request to the HA which accepts it and sends registration
    reply message with code 0.
9. GFA updates the MN binding with lifetime, etc.

NOW:
10. MN moves to a new FA and send a regional registration request to GFA.
11. OOPS! MN IS IN SYNC WITH ITS HA not this GFA.
      What the GFA is supposed to do.

Let us remember the GFA and HA belongs to two different vendors who are very far apart from each other.
That is why we are proposing the regional registration to save Home Registration Signaling.

Do you suggest that GFA sync itself with the HA, which is apparently impossible.
Because, GFA serves many different HAs.

OR

MN needs another two round trips registration to sync itself with every GFA it register with
while away from Home.

Thanks for your consideration.

Regards;
Ahmad Muhanna
 

------_=_NextPart_001_01C1FDB8.2C95F740-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 12:14:26 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19423 for ; Fri, 17 May 2002 12:14:25 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13102; Fri, 17 May 2002 10:14:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01756; Fri, 17 May 2002 09:13:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HGCprP020290 for ; Fri, 17 May 2002 09:12:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HGCpDp020289 for mobile-ip-dist; Fri, 17 May 2002 09:12:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HGCmrP020282 for ; Fri, 17 May 2002 09:12:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01065 for ; Fri, 17 May 2002 09:12:52 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19118 for ; Fri, 17 May 2002 10:12:51 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 4428C6A919; Fri, 17 May 2002 19:12:50 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 702416A901; Fri, 17 May 2002 19:12:48 +0300 (EEST) Message-ID: <3CE52C3D.4040608@kolumbus.fi> Date: Fri, 17 May 2002 19:13:49 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Srinivasan.Damodaran@lntinfotech.com Cc: Kalyan , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Receiving Binding Refresh Request References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Srinivasan.Damodaran@lntinfotech.com wrote: > My question is, MN has a valid binding with a CN and communication to that > node is in progress, & still requires Route optimization. In the meantime > (i.e., assume when 90% of the lifetime is over), MN get's a BRR message > from CN. MN starts initiating RR procedure and changes state from "Bound" > to "WaitHC". MN looses route optimization during the 10% of MN's valid > lifetime or till BU procedure is complete, whichever is less. > > Here the purpose of initiating BRR message before binding expires, is to > maintain route optimization steadily. > > Even if the BRR message is not there, once when the lifetime expires, the > packets will be tunneled to MN and MN will initiate the RR procedure. > Inorder to avoid this, CN initiates BRR when the lifetime is about to > expire. > > But I feel the purpose of BRR, is not met... You are right; if bidir routing is immediately adopted, the BRR functionality would be equivalent to the BM functionality! It seems though that the current specifications are unclear with respect to whether bidir routing should be adopted immediately upon receiving a BRR. Specifically, it doesn't say anywhere that if your state is WaitHC then you should not use Route Optimization. (In fact, if it would not have required doubling the number of states, I would have written the state machine in a way that you would have had WaitHC-Nobinding and WaitHC-Binding.) We need to clarify this issue. This can probably be done at the same time as the state machine is being rewritten in a more compact form, based on an idea from Charlie that we could keep the binding and the rr state machines separate. In conclusion, the specification should say that route optimization can continue even after receiving a BRR until the lifetime of the binding expires or a BM is received. Assigned issue #28. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 13:45:49 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23582 for ; Fri, 17 May 2002 13:45:49 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08115; Fri, 17 May 2002 11:46:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11914; Fri, 17 May 2002 10:45:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HHiVrP020519 for ; Fri, 17 May 2002 10:44:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HHiVD4020518 for mobile-ip-dist; Fri, 17 May 2002 10:44:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HHiSrP020511 for ; Fri, 17 May 2002 10:44:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02397 for ; Fri, 17 May 2002 10:44:31 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13415 for ; Fri, 17 May 2002 11:44:29 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4HHiG808633; Fri, 17 May 2002 12:44:16 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 12:44:06 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCD0D@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Fredrik Johansson'" , MobileIP Cc: "'bob@marksmob.com'" , "'Tony Johansson'" Subject: RE: [mobile-ip] draft-ietf-mobileip-aaa-nai-01.txt Date: Fri, 17 May 2002 12:44:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FDCA.70519360" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1FDCA.70519360 Content-Type: text/plain; charset="iso-8859-1" Hello Fredrik, I know that you would like to address backward compatibility at the network side rather in this draft. However, If we can come up with something neat here, it would be a plus. What do you think about replacing paragraph 3 in section 4 by the proposed text below. Section 4: " A mobile node MUST provide this in every registration request sent when re-authenticating, or when requesting a specific IP address at initial authentication." Proposed text: " After receiving this extension in a registration reply message, the Mobile Node MUST provide it in every registration request when re-authenticating is needed. If the Mobile Node requests a specific IP address and this extension is available, the Mobile Node MUST provide this extension in its initial registration request. " Regards; Ahmad Muhanna > > > Hi All, > > We have submitted a new version of the above mentioned draft, > if you want > access to it before it gets published, it can be found at > > http://stargate.ipunplugged.com/ietf/draft-ietf-mobileip-aaa-n > ai-01.txt > > /Fredrik > > ------_=_NextPart_001_01C1FDCA.70519360 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] draft-ietf-mobileip-aaa-nai-01.txt

Hello Fredrik,
I know that you would like to address backward = compatibility at the network side rather in this draft.
However, If we can come up with something neat here, = it would be a plus.

What do you think about replacing paragraph 3 in = section 4 by the proposed text below.

Section 4:

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

Proposed text:

"  After receiving this extension in a = registration reply message, the Mobile Node
   MUST provide it in every registration = request when re-authenticating is needed.
   If the Mobile Node requests a specific = IP address and this extension is available,
   the Mobile Node MUST provide this = extension in its initial registration request.
"

Regards;
Ahmad Muhanna


>
>
> Hi All,
>
> We have submitted a new version of the above = mentioned draft,
> if you want
> access to it before it gets published, it can = be found at
>
> http://stargate.ipunplugged.com/ietf/draft-ietf-mobile= ip-aaa-n
> ai-01.txt
>
> /Fredrik
>
>

------_=_NextPart_001_01C1FDCA.70519360-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 14:20:40 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25538 for ; Fri, 17 May 2002 14:20:40 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24354; Fri, 17 May 2002 12:20:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28239; Fri, 17 May 2002 11:20:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HIJErP020637 for ; Fri, 17 May 2002 11:19:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HIJE9A020636 for mobile-ip-dist; Fri, 17 May 2002 11:19:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HIJArP020629 for ; Fri, 17 May 2002 11:19:11 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21714 for ; Fri, 17 May 2002 11:19:14 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14424 for ; Fri, 17 May 2002 11:19:14 -0700 (PDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4HIIfPI019347; Fri, 17 May 2002 11:18:41 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA07559; Fri, 17 May 2002 14:18:40 -0400 (EDT) Date: Fri, 17 May 2002 14:18:40 -0400 From: "Madhavi W. Chandra" To: Henrik Levkowetz Cc: "Madhavi W. Chandra" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Feedback on NAT draft Message-ID: <20020517141840.A7551@cisco.com> References: <20020514102608.C2517@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from henrik@levkowetz.com on Tue, May 14, 2002 at 05:39:46PM +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Henrik, On Tue, May 14, 2002 at 05:39:46PM +0200, Henrik Levkowetz wrote: > Madhavi, > > You wrote: > ...... > > > > The MN is indicating that it can do UDP tunneling with the > > > > presence of the UDP Tunnel Request Extension. The HA can decide > > > > whether to do UDP tunneling irrespective of NAT. There doesn't seem > > > > to be a role for the MN to force UDP tunneling...unless we are missing > > > > something. Hence, implementation can be simplified without 'F' bit. > > > > > > Correction: You do not find it useful. Other people have indicatet that > > > it would be useful, so I'd tend to keep it in for that reason. But there > > > > Yes, I do not find it useful. Otherwise, I would not have brought it up. > > Perhaps if you share the reasons and be a little more specific, I can find it > > useful too. Understand that I'm not adverse to it, but at > > present I don't see the need. And hence, it seems like unnecessary > > implementation. > > Please see Sami's reply earlier today on this one. > > > > > > > Madhavi, I think it would clear up your questions if you were to read > > > section 4.10, which I referred to earlier. It really does answer the > > > questions you ask here. But in short: In this case, the HA cannot > > > detect the presence of a NAT in the usual manner, so it needs to be > > > forced by the mobile node. > > > > Just because I still have doubts is not a valid reason for you to assume > > that I didn't read section 4.10. As I indicated earlier, we have much > > interest in your draft and read it quite carefully. > > Fair enough; sorry. I mistakenly got that impression when you only quoted 4.4. > > > > > I understand that the HA cannot detect the presence of the NAT in the usual > > way with the FA 'R' bit case...which is why you have carefully explained the > > use of the 'U' bit and proper inclusion of the UDP Tunnel Request Extension. > > > > But, how does the 'F' bit help here? The fact that the UDP Tunnel Request > > Extension is present, with the 'R' bit set indicates to the HA that the > > FA knows it is behind a NAT (since it advertised the 'U' bit...which is > > why the MN included the UDP Tunnel Request Extension). The HA will notice > > the difference in IP SRC, and set up the UDP tunnel. Did I misunderstand > > the behavior? > > Madhavi, you are right! and I apoligize. It's OK. I'm glad that you agree now. > The requirements that the MN should > not use the UDP Tunnel Request extension when registering through an FA with > a co-located address unless the FA has the 'U' bit set, and that the MN > should set the 'R' bit in the extension in that case does indeed provide > enough information for the HA. Setting the 'F' bit does not add any information, > and supposing it is decided to still have the 'F' bit available, it should be > set in this case just for consistency - it is indeed not needed in this case. > > ( ... :-) I originally did not have the restriction that the MN must not > add the extension in the non 'U' bit case, which led to the current text.) > > Returning for a moment to another issue on which we know we disagree, I would > mention in the case of the HA processing load that even if we assume that > handling a mip re-registration requires many (10? 50?) times the processing power of > forwarding a mip packet, you will have keepalive re-registrations taking less > power than would be consumed by the same MN running 14400 bit/s of traffic. > And I believe the box should be sized so that it will be able to handle a > much larger traffic load than that, per user - so maybe the keepalive signalling, > which will only occur when you have no other traffic, is not such a heavy load > after all? True...I guess if the HA is a powerful box, it's not as big an issue. However, given that this is not an absolute, I still think that a MAY is more appropriate than a SHOULD. A SHOULD is a rather strong suggestion. I think your points can be made in the draft without the strong SHOULD. Regards, Madhavi > Regards, > Henrik From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 14:31:14 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26189 for ; Fri, 17 May 2002 14:31:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19889; Fri, 17 May 2002 11:29:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02584; Fri, 17 May 2002 11:29:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HISkrP020691 for ; Fri, 17 May 2002 11:28:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HISjwr020690 for mobile-ip-dist; Fri, 17 May 2002 11:28:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HISgrP020683 for ; Fri, 17 May 2002 11:28:42 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02398 for ; Fri, 17 May 2002 11:28:46 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19507 for ; Fri, 17 May 2002 11:28:46 -0700 (PDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4HIRmPI024698; Fri, 17 May 2002 11:27:48 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA07572; Fri, 17 May 2002 14:27:47 -0400 (EDT) Date: Fri, 17 May 2002 14:27:47 -0400 From: "Madhavi W. Chandra" To: Sami Vaarala Cc: "Madhavi W. Chandra" , Henrik Levkowetz , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Feedback on NAT draft Message-ID: <20020517142747.A7547@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from sami.vaarala@netseal.com on Tue, May 14, 2002 at 09:50:41AM +0300 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Sami, Thanks for being more specific. Please see inline... On Tue, May 14, 2002 at 09:50:41AM +0300, Sami Vaarala wrote: > Hi Madhavi, > > >[snip] > > The MN is indicating that it can do UDP tunneling with the > > presence of the UDP Tunnel Request Extension. The HA can decide > > whether to do UDP tunneling irrespective of NAT. There doesn't seem > > to be a role for the MN to force UDP tunneling...unless we are missing > > something. Hence, implementation can be simplified without 'F' bit. > > There may be cases where the mobile node knows more about > the network it is using to contact the HA. It might know > that the UDP tunnelling is absolutely required through the > network; the HA might not know this. > > The feature may be useful if the MN is in a network which > filters packets and neither the HA or the MN know about > this. The sequence would be as follows: > > 1. The MN registers without F-bit. The registration > succeeds but the firewall blocks traffic. On which network is the filtering occuring? Is this a firewall on the home network? If so, the HA will know about it and be able to accept UDP tunneling regardless of NAT. If you mean on the foreign network, this will not affect the MN sending traffic OUT, right? Something is missing... Please clarify. Thanks, Madhavi > > 2. The MN re-registers with F-bit, being wiser from > step 1. > > This could also be done by an intelligent HA, but I don't > think the HA has enough context to do this? (It doesn't > know whether the MN just doesn't want to communicate or > that the communication attempt failed.) > > -Sami From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 15:09:06 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28309 for ; Fri, 17 May 2002 15:09:01 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10743; Fri, 17 May 2002 12:07:19 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11340; Fri, 17 May 2002 12:07:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HJ6KrP020864 for ; Fri, 17 May 2002 12:06:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HJ6JFd020863 for mobile-ip-dist; Fri, 17 May 2002 12:06:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HJ6GrP020856 for ; Fri, 17 May 2002 12:06:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17941 for ; Fri, 17 May 2002 12:06:20 -0700 (PDT) Received: from chardonnay.levkowetz.com (h224n1fls32o89.telia.com [213.66.61.224]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23916 for ; Fri, 17 May 2002 13:06:19 -0600 (MDT) Received: from [127.0.0.1] (helo=chardonnay) by chardonnay.levkowetz.com with smtp (Exim 4.02) id GW9RQ7-0000CS-00; Fri, 17 May 2002 21:06:07 +0200 From: "Henrik Levkowetz" To: "Madhavi W. Chandra" Cc: Subject: RE: [mobile-ip] Feedback on NAT draft Date: Fri, 17 May 2002 21:06:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 In-Reply-To: <20020517141840.A7551@cisco.com> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I wrote and Madhavi responded: ...... > > Returning for a moment to another issue on which we know we disagree, I would > > mention in the case of the HA processing load that even if we assume that > > handling a mip re-registration requires many (10? 50?) times the processing power of > > forwarding a mip packet, you will have keepalive re-registrations taking less > > power than would be consumed by the same MN running 14400 bit/s of traffic. > > And I believe the box should be sized so that it will be able to handle a > > much larger traffic load than that, per user - so maybe the keepalive signalling, > > which will only occur when you have no other traffic, is not such a heavy load > > after all? > > True...I guess if the HA is a powerful box, it's not as big an issue. > However, given that this is not an absolute, I still think that a MAY > is more appropriate than a SHOULD. A SHOULD is a rather strong > suggestion. I think your points can be made in the draft without the > strong SHOULD. Well, then, on that point we still disagree. In view of the updated security consideration section (posted a couple of days ago by Sami) I would think it highly unadvisable to forego the use of registration requests as keepalives, hence the SHOULD. Regards, Henrik From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 15:11:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28435 for ; Fri, 17 May 2002 15:11:46 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26245; Fri, 17 May 2002 13:12:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12781; Fri, 17 May 2002 12:11:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HJAbrP020911 for ; Fri, 17 May 2002 12:10:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HJAbu1020910 for mobile-ip-dist; Fri, 17 May 2002 12:10:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HJAYrP020903 for ; Fri, 17 May 2002 12:10:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12511 for ; Fri, 17 May 2002 12:10:38 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03326 for ; Fri, 17 May 2002 13:10:37 -0600 (MDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4HJA3PI017788; Fri, 17 May 2002 12:10:03 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id PAA07675; Fri, 17 May 2002 15:10:02 -0400 (EDT) Date: Fri, 17 May 2002 15:10:02 -0400 From: "Madhavi W. Chandra" To: sami.vaarala@netseal.com Cc: Madhavi Chandra , Henrik Levkowetz , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Feedback on NAT draft Message-ID: <20020517151002.A7655@cisco.com> References: <20020517142747.A7547@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020517142747.A7547@cisco.com>; from mchandra@cisco.com on Fri, May 17, 2002 at 02:27:47PM -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Sami, On Fri, May 17, 2002 at 02:27:47PM -0400, Madhavi W. Chandra wrote: > Hi Sami, > > Thanks for being more specific. Please see inline... > > On Tue, May 14, 2002 at 09:50:41AM +0300, Sami Vaarala wrote: > > Hi Madhavi, > > > > >[snip] > > > The MN is indicating that it can do UDP tunneling with the > > > presence of the UDP Tunnel Request Extension. The HA can decide > > > whether to do UDP tunneling irrespective of NAT. There doesn't seem > > > to be a role for the MN to force UDP tunneling...unless we are missing > > > something. Hence, implementation can be simplified without 'F' bit. > > > > There may be cases where the mobile node knows more about > > the network it is using to contact the HA. It might know > > that the UDP tunnelling is absolutely required through the > > network; the HA might not know this. > > > > The feature may be useful if the MN is in a network which > > filters packets and neither the HA or the MN know about > > this. The sequence would be as follows: > > > > 1. The MN registers without F-bit. The registration > > succeeds but the firewall blocks traffic. > > On which network is the filtering occuring? Is this a firewall on the > home network? If so, the HA will know about it and be able to accept > UDP tunneling regardless of NAT. If you mean on the foreign network, > this will not affect the MN sending traffic OUT, right? Something is > missing... Ahh...perhaps you mean FW on foreign side won't let IN the IPinIP or GRE traffic. So, the 'F' bit gives flexibility to MN on foreign domain. OK...makes sense. I guess you will clean up the text to remove the dependency of the FA 'R' bit case on the 'F' bit. Thanks for pointing this out. Regards, Madhavi > > Please clarify. > > Thanks, > Madhavi > > > > > 2. The MN re-registers with F-bit, being wiser from > > step 1. > > > > This could also be done by an intelligent HA, but I don't > > think the HA has enough context to do this? (It doesn't > > know whether the MN just doesn't want to communicate or > > that the communication attempt failed.) > > > > -Sami From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 17:16:47 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06009 for ; Fri, 17 May 2002 17:16:33 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA24089; Fri, 17 May 2002 14:14:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24858; Fri, 17 May 2002 14:14:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HLDTrP021237 for ; Fri, 17 May 2002 14:13:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HLDT6Z021236 for mobile-ip-dist; Fri, 17 May 2002 14:13:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HLDQrP021229 for ; Fri, 17 May 2002 14:13:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA14514 for ; Fri, 17 May 2002 14:13:29 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA23889 for ; Fri, 17 May 2002 15:13:28 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 17 May 2002 17:09:59 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] MIP WG Doc Status Date: Fri, 17 May 2002 17:09:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi folks, here's a list of documents that have gone through, are, or are soon to be in WG last call and status. Phil WG last call complete >RFC3220 - amendments posted, a new version with the missing text will be resubmitted to the RFC editor without any new clarifications >AAA keys - comments received from AD review being incorporated, anticipate submitting for IETF last call on 5/24 >Regional Registration - lots of comments received, being resolved per ML discussion in WG last call >MIP NAT traversal - closes today expect WG last call RSN >RFC 3012bis - still updating, anticipate being ready around 5/24 >MIPv6 - not sure whether WG last call will be done on this version, pending some discussion around next steps on bidding down and securing RO within design team From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 18:46:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10672 for ; Fri, 17 May 2002 18:46:32 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15255; Fri, 17 May 2002 16:46:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25253; Fri, 17 May 2002 15:46:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HMj3rP021406 for ; Fri, 17 May 2002 15:45:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HMj30S021405 for mobile-ip-dist; Fri, 17 May 2002 15:45:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HMj0rP021398 for ; Fri, 17 May 2002 15:45:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24761 for ; Fri, 17 May 2002 15:45:04 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14714 for ; Fri, 17 May 2002 16:45:37 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA09988; Fri, 17 May 2002 15:45:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4HMj2509027; Fri, 17 May 2002 15:45:02 -0700 X-mProtect: <200205172245> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEPccLy; Fri, 17 May 2002 15:45:01 PDT Message-ID: <3CE587ED.4C81C272@iprg.nokia.com> Date: Fri, 17 May 2002 15:45:01 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] issue #25 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi, I think Issue #25 can be easily closed. the solution would be to always include the routing header when sending a binding ack (even if the BU fails). the only time, when a routing header is not included in a binding ack is when the MN returns home and sends a deregistration BU. Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 19:13:01 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11688 for ; Fri, 17 May 2002 19:13:01 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06352; Fri, 17 May 2002 17:12:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA03700; Fri, 17 May 2002 16:12:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HNBNrP021510 for ; Fri, 17 May 2002 16:11:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HNBNjc021509 for mobile-ip-dist; Fri, 17 May 2002 16:11:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HNBKrP021502 for ; Fri, 17 May 2002 16:11:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA24973 for ; Fri, 17 May 2002 16:11:24 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA10321 for ; Fri, 17 May 2002 17:11:23 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA11497; Fri, 17 May 2002 16:11:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4HNBNh02300; Fri, 17 May 2002 16:11:23 -0700 X-mProtect: <200205172311> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdR4Rtal; Fri, 17 May 2002 16:11:21 PDT Message-ID: <3CE58E19.C4B3517F@iprg.nokia.com> Date: Fri, 17 May 2002 16:11:21 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net, charliep@iprg.nokia.com CC: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Issue #23 and Issue #30 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi, I think the 'S' bit is being confused with a lot of other things. anyway, here is an attempt to clarify things. 1. it is straight-forward for the HA to derive the MN's link local address from the MN's unicast address. please remove this from the issues. 2. the HA MUST always defend the link local address of MN in addition to the home address (irrespective of what the 'S' bit is set to). this is because of RFC 2462. lets assume the HA is defending the global address of the MN. and it does not defend the link local address. another node on the link could configure the MN's home address. consider the following sequence of events - node A configures MN's home address - node A configures a link local address whose interface id is the same as the home address - node A does DAD on the link local address alone (it does not have to do for the global address) - the HA does not defend the link local address - you have a problem. the MN can return home and do a successful degeristration without using its link local address. the argument that the link local address is needed for deregistration when the MN returns home is not a valid one (sorry, Francis). 3. the philosophy behing the 'S' bit. imagine, the MN is at home. it configures a link local address. it also configures unicast addresses for each and every network prefix advertised on the home link. it also defends all these address, preventing anybody else from claiming these addresses. when the MN is away from home, the 'S' bit simulates the above. the HA defends not only the home address, but also the link local address and every address from every network prefix on the home link. when the MN returs home, it can claim all these addresses back. the problem is, the HA has to figure out all these addresses from the home address in the BU from the MN. its easy deriving the link local address. but for the other addresses, the HA has to make an assumption (this is what Francis and Brian are against) that the same interface id that was used for the home address is used for the other addresses too. IMO, it is safe to make this assumption. this is because the MN is in a position to know if it uses different interface id for each address. accordingly it can set the 'S' bit. setting the 'S' bit to 1 turns off this functionality. the HA only defends the home address. finally issue #23 and #30 can be recast what Francis and Brian are against (having to assume the same interface id for every unicast address). and finally agree with the following text from Francis Dupont > IMHO 11.6.7 should be more accurate, I propose to add to: > > agent's use of the same address. If the mobile node returns home > after the bindings for all of its care-of addresses have expired, > then it SHOULD perform DAD. > > near the end of page 138 > > bits set to one>. hope I havent missed anything. Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri May 17 19:29:15 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12322 for ; Fri, 17 May 2002 19:29:15 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17094; Fri, 17 May 2002 17:29:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08278; Fri, 17 May 2002 16:28:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HNRprP021592 for ; Fri, 17 May 2002 16:27:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4HNRpnw021591 for mobile-ip-dist; Fri, 17 May 2002 16:27:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4HNRmrP021584 for ; Fri, 17 May 2002 16:27:48 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29561 for ; Fri, 17 May 2002 16:27:53 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29699 for ; Fri, 17 May 2002 17:28:26 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA12252; Fri, 17 May 2002 16:27:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4HNRqF18956; Fri, 17 May 2002 16:27:52 -0700 X-mProtect: <200205172327> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUbnuHL; Fri, 17 May 2002 16:27:50 PDT Message-ID: <3CE591F6.5D3D70A3@iprg.nokia.com> Date: Fri, 17 May 2002 16:27:50 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Issue #7 and Issue #27 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think issue #27 affects issue #7, particularly the BU format. for issue 27, the solution (thats been accepted) is that HAO will be present on the BUs to the CN. and for the BUs to HA, the HAO is going to be there irrespective of whether AH or ESP is used. why dont we make the HoA an option in the BU, instead of a fixed field? regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Sat May 18 09:50:48 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13930 for ; Sat, 18 May 2002 09:50:47 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21389; Sat, 18 May 2002 06:49:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27357; Sat, 18 May 2002 06:48:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4IDlkrP022506 for ; Sat, 18 May 2002 06:47:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4IDlkTK022505 for mobile-ip-dist; Sat, 18 May 2002 06:47:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4IDlcrP022498 for ; Sat, 18 May 2002 06:47:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19559 for ; Sat, 18 May 2002 06:47:41 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10581 for ; Sat, 18 May 2002 07:48:14 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4IDlKn05068; Sat, 18 May 2002 15:47:20 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA26546; Sat, 18 May 2002 15:47:20 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4IDlJT99517; Sat, 18 May 2002 15:47:19 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205181347.g4IDlJT99517@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Fri, 17 May 2002 16:11:21 PDT. <3CE58E19.C4B3517F@iprg.nokia.com> Date: Sat, 18 May 2002 15:47:19 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: 2. the HA MUST always defend the link local address of MN in addition to the home address (irrespective of what the 'S' bit is set to). => I strongly object because this requirement will give major problems when the mobile returns at home (the mobile forms the link-local address, performs DAD (both steps are mandatory) and DAD fails: the MN should deregister before or wait until the registration has expired). this is because of RFC 2462... => please sends this issue to the IPv6 WG. the MN can return home and do a successful deregeristration without using its link local address. => I won't argue about the second part of your statement but the first one is wrong and DAD for the link-local address is mandatory (if it was optional why to defend it :-). 3. the philosophy behing the 'S' bit. imagine, the MN is at home. it configures a link local address. it also configures unicast addresses for each and every network prefix advertised on the home link. it also defends all these address, preventing anybody else from claiming these addresses. when the MN is away from home, the 'S' bit simulates the above. the HA defends not only the home address, but also the link local address and every address from every network prefix on the home link. when the MN returs home, it can claim all these addresses back. the problem is, the HA has to figure out all these addresses from the home address in the BU from the MN. its easy deriving the link local address. but for the other addresses, the HA has to make an assumption (this is what Francis and Brian are against) that the => I am against this assumption made "a priori". Even when this assumption is developed (as here) I don't believe it is a good idea because it is complex and misleading. same interface id that was used for the home address is used for the other addresses too. IMO, it is safe to make this assumption. this is because the MN is in a position to know if it uses different interface id for each address. accordingly it can set the 'S' bit. setting the 'S' bit to 1 turns off this functionality. the HA only defends the home address. finally issue #23 and #30 can be recast what Francis and Brian are against (having to assume the same interface id for every unicast address). => for simplicity IMHO the S bit should be removed (reserve its position (set to 1) and put it into the for further study class) and the DAD issue solved by making the "DAD optimization" illegal on the home link, i.e.: - any node attached to the home link MUST perform the DAD procedure (RFC 2462 5.4) for each address - the optional DAD procedure on the link-local address only is explicitely forbidden (because some addresses are not formed in an autoconf like way) - home agents receiving home registrations with the D bit set to 1 MUST perform the DAD procedure on the home address (if we keep the S-bit this becomes on all addresses derived from the home address, including the link-local one) For answers to NSs, the proxy-NA logic is enough: no change is needed. and finally agree with the following text from Francis Dupont > IMHO 11.6.7 should be more accurate, I propose to add to: > > agent's use of the same address. If the mobile node returns home > after the bindings for all of its care-of addresses have expired, > then it SHOULD perform DAD. > > near the end of page 138 > > bits set to one>. => note that in my last proposal this will be the case... Thanks Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat May 18 09:58:53 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14218 for ; Sat, 18 May 2002 09:58:53 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22876; Sat, 18 May 2002 06:57:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28161; Sat, 18 May 2002 06:57:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4IDuWrP022582 for ; Sat, 18 May 2002 06:56:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4IDuWD2022581 for mobile-ip-dist; Sat, 18 May 2002 06:56:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4IDuTrP022574 for ; Sat, 18 May 2002 06:56:29 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04491 for ; Sat, 18 May 2002 06:56:32 -0700 (PDT) From: arvind.sevalkar@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA22698 for ; Sat, 18 May 2002 06:56:31 -0700 (PDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002051819302546:3072 ; Sat, 18 May 2002 19:30:25 +0530 Subject: Re: [mobile-ip] issue #25 To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Sat, 18 May 2002 19:26:29 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/18/2002 07:26:53 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/18/2002 07:30:25 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/18/2002 07:30:29 PM, Serialize complete at 05/18/2002 07:30:29 PM Message-ID: X-Priority: 3 (Normal) Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Vijay Devarapalli To: jari.arkko@piuha.net, Sent by: mobile-ip@sunroof.eng.sun.com owner-mobile-ip@sunroof.e cc: ng.sun.com Subject: [mobile-ip] issue #25 05/18/2002 04:15 AM hi, I think Issue #25 can be easily closed. the solution would be to always include the routing header when sending a binding ack (even if the BU fails). the only time, when a routing header is not included in a binding ack is when the MN returns home and sends a deregistration BU. Vijay I think this will not work. Let's consider MN is in the foreign network it sends BU for the first time to CN and that fails, then in this case, CN don't have binding Cache entry so while sending BA, CN can not add routing header. But u said always include the routing header while sending BA even if the BU fails. How can this is possible in this case ? Arvind From owner-mobile-ip@sunroof.eng.sun.com Sat May 18 10:11:28 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14630 for ; Sat, 18 May 2002 10:11:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25093; Sat, 18 May 2002 07:09:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29510; Sat, 18 May 2002 07:09:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4IE8prP022652 for ; Sat, 18 May 2002 07:08:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4IE8p9C022651 for mobile-ip-dist; Sat, 18 May 2002 07:08:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4IE8lrP022644 for ; Sat, 18 May 2002 07:08:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21516 for ; Sat, 18 May 2002 07:08:50 -0700 (PDT) From: Padmakumar.AV@lntinfotech.com Received: from ltitlin.lntinfotech.com ([203.199.54.35]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03683 for ; Sat, 18 May 2002 08:08:49 -0600 (MDT) Received: from bangalore.lntinfotech.com ([172.29.4.3]) by ltitlin.lntinfotech.com (Lotus Domino Release 5.0.8) with ESMTP id 2002051819392741:27936 ; Sat, 18 May 2002 19:39:27 +0530 Subject: Re: [mobile-ip] MN Returning Home To: Francis Dupont Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Sat, 18 May 2002 19:35:59 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/18/2002 07:36:01 PM, Itemize by SMTP Server on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/18/2002 07:39:27 PM, Serialize by Router on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/18/2002 07:39:31 PM, Serialize complete at 05/18/2002 07:39:31 PM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Francis, > yes, to be in trouble the S bit must be zero. > But even though the 'S' bit is set, > HA still defend the use of link local address as part of the proxy functionality. Yes I am in trouble for the case either 'S' bit is not set or 'S =1 ' & 'D=1' How to come out of this loop? Regards Pav Francis Dupont cc: mobile-ip@sunroof.eng.sun.com Sent by: Subject: Re: [mobile-ip] MN Returning Home owner-mobile-ip@sunroof.e ng.sun.com 05/14/2002 06:54 PM You wrote 'you really have a problem when the "whole subnet" is registered you mean the case where 'S' bit is not set. => yes, to be in trouble the S bit must be zero. But even though the 'S' bit is set, HA still defend the use of link local address as part of the proxy functionality. => no, it doesn't. The current draft is terrible but it doesn't say (yet : -) the link-local address is defended against DAD: - if the D bit is set a DAD is performed for the link-local address before the BU is accepted. - if the S bit is set then the proxy address set is reduced to the home address else it is the whole set of derived addresses, including the link-local one. - the proxy function includes the defense against DAD (just because it replies to any NS for the proxied addresses). - if the R bit is set then it is copied into NAs. (at the last IETF meeting I said the R bit was forgotten, I-D authors, wake up and PLEASE PUT IT BACK. BTW fix the unicast NS to get the home agent link-layer address) Note an agnostic MN returning at home can fail to perform DAD on a previous home address registered with D=1, S=1. IMHO 11.6.7 should be more accurate, I propose to add to: agent's use of the same address. If the mobile node returns home after the bindings for all of its care-of addresses have expired, then it SHOULD perform DAD. near the end of page 138 . Regards Francis.Dupont@enst-bretagne.fr PS: I-D 17 has more than 170 pages. This is ridiculous, all not finished features should be moved to other documents. It seems that RR should not be in the list but I propose to begin with: - renumbering support (complex, dubious utility today) - home agent address discovery (or make it secure, good luck :-). From owner-mobile-ip@sunroof.eng.sun.com Sat May 18 10:21:48 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15066 for ; Sat, 18 May 2002 10:21:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17368; Sat, 18 May 2002 08:21:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00497; Sat, 18 May 2002 07:20:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4IEK6rP022723 for ; Sat, 18 May 2002 07:20:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4IEK6QF022722 for mobile-ip-dist; Sat, 18 May 2002 07:20:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4IEK2rP022715 for ; Sat, 18 May 2002 07:20:03 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08326 for ; Sat, 18 May 2002 07:20:06 -0700 (PDT) From: Padmakumar.AV@lntinfotech.com Received: from ltitlin.lntinfotech.com ([203.199.54.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17082 for ; Sat, 18 May 2002 08:20:39 -0600 (MDT) Received: from bangalore.lntinfotech.com ([172.29.4.3]) by ltitlin.lntinfotech.com (Lotus Domino Release 5.0.8) with ESMTP id 2002051819504351:27952 ; Sat, 18 May 2002 19:50:43 +0530 Subject: Re: [mobile-ip] issue #25 To: arvind.sevalkar@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Sat, 18 May 2002 19:47:15 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/18/2002 07:47:17 PM, Itemize by SMTP Server on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/18/2002 07:50:43 PM, Serialize by Router on LTITLIN/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/18/2002 07:50:46 PM, Serialize complete at 05/18/2002 07:50:46 PM 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 g4IEK3rP022716 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Vijay, Arvind wrote: >I think this will not work. >Let's consider MN is in the foreign network it sends BU for the first time >to CN and that fails, then in this case, CN don't have binding Cache entry >so while sending BA, CN can not add routing header. But u said always >include the routing header while sending BA even if the BU fails. How can >this is possible in this case ? Vijay Wrote: >I think Issue #25 can be easily closed. the solution would be to >always include the routing header when sending a binding ack >(even if the BU fails). the only time, when a routing header is >not included in a binding ack is when the MN returns home and >sends a deregistration BU. I too believe that this may be difficult in the above case.("CN does not have a binding cache entry. CN Rejected the BU. This case, CN cannot do a binding cache look up based on the home address") MH messages are processed in the MH protocol context. The interface functions between Ipv6 and upper layer protocol (like ip6_build_xmit in Linux) we don't really want to modify. So we cannot pass the routing header 2 parameters to these functions. So the decision of adding routing header type 2 is difficult to take in MH protocol context, so we have to move it to the extension header building part. That place if we want to add a routing header 2 for the above mentioned case then after looking into binding cache we have to explicitly evaluate that the message is a BA and since there is no Binding cache entry we have to add routing header type 2 in this case explicitly. Moreover here I am confused that whether I can get the COA at this stage if the destination address is MN's Home Address. Regards pav arvind.sevalkar@lntinfote ch.com To: mobile-ip@sunroof.eng.sun.com Sent by: cc: owner-mobile-ip@sunroof.e Subject: Re: [mobile-ip] issue #25 ng.sun.com 05/18/2002 07:26 PM hi, I think Issue #25 can be easily closed. the solution would be to always include the routing header when sending a binding ack (even if the BU fails). the only time, when a routing header is not included in a binding ack is when the MN returns home and sends a deregistration BU. Vijay I think this will not work. Let's consider MN is in the foreign network it sends BU for the first time to CN and that fails, then in this case, CN don't have binding Cache entry so while sending BA, CN can not add routing header. But u said always include the routing header while sending BA even if the BU fails. How can this is possible in this case ? Arvind From owner-mobile-ip@sunroof.eng.sun.com Sat May 18 12:20:25 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19421 for ; Sat, 18 May 2002 12:20:25 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15858; Sat, 18 May 2002 10:20:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28537; Sat, 18 May 2002 09:19:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4IGJBrP022912 for ; Sat, 18 May 2002 09:19:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4IGJBGM022911 for mobile-ip-dist; Sat, 18 May 2002 09:19:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4IGJ8rP022904 for ; Sat, 18 May 2002 09:19:08 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28423 for ; Sat, 18 May 2002 09:19:12 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21159 for ; Sat, 18 May 2002 09:19:11 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4IGIwn12988; Sat, 18 May 2002 18:18:59 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA27188; Sat, 18 May 2002 18:18:59 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4IGIvT99974; Sat, 18 May 2002 18:18:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205181618.g4IGIvT99974@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: arvind.sevalkar@lntinfotech.com cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issue #25 In-reply-to: Your message of Sat, 18 May 2002 19:26:29 +0530. Date: Sat, 18 May 2002 18:18:57 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I think this will not work. Let's consider MN is in the foreign network it sends BU for the first time to CN and that fails, then in this case, CN don't have binding Cache entry so while sending BA, CN can not add routing header. But u said always include the routing header while sending BA even if the BU fails. How can this is possible in this case ? => special code to handle the special case. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat May 18 12:25:36 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19617 for ; Sat, 18 May 2002 12:25:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22275; Sat, 18 May 2002 09:23:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29397; Sat, 18 May 2002 09:23:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4IGNFrP022996 for ; Sat, 18 May 2002 09:23:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4IGNFPm022995 for mobile-ip-dist; Sat, 18 May 2002 09:23:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4IGNCrP022988 for ; Sat, 18 May 2002 09:23:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13941 for ; Sat, 18 May 2002 09:23:16 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12448 for ; Sat, 18 May 2002 10:23:50 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4IGN8n13293; Sat, 18 May 2002 18:23:08 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA27228; Sat, 18 May 2002 18:23:08 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4IGN8T99996; Sat, 18 May 2002 18:23:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205181623.g4IGN8T99996@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Padmakumar.AV@lntinfotech.com cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MN Returning Home In-reply-to: Your message of Sat, 18 May 2002 19:35:59 +0530. Date: Sat, 18 May 2002 18:23:08 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Yes I am in trouble for the case either 'S' bit is not set or 'S =1 ' & 'D=1' How to come out of this loop? => I believe we should keep the DAD as it is *without* link-local optimization and we should support only the case where the S bit is one (i.e. make it always one in the next I-D and move the discussion to further studies). Read my last message about this (answer to Vijay). Regards Francis.Dupont@enst-bretagne.fr PS: my main argument is this is too complex and must be KISS ASAP. From owner-mobile-ip@sunroof.eng.sun.com Sun May 19 08:20:53 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04917 for ; Sun, 19 May 2002 08:20:52 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19369; Sun, 19 May 2002 06:20:38 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01049; Sun, 19 May 2002 05:19:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4JCJ4rP023875 for ; Sun, 19 May 2002 05:19:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4JCJ47o023874 for mobile-ip-dist; Sun, 19 May 2002 05:19:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4JCJ1rP023867 for ; Sun, 19 May 2002 05:19:01 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00979 for ; Sun, 19 May 2002 05:19:05 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19035 for ; Sun, 19 May 2002 06:19:04 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4JCInn27471; Sun, 19 May 2002 14:18:49 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA02428; Sun, 19 May 2002 14:18:49 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4JCImT01886; Sun, 19 May 2002 14:18:49 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205191218.g4JCImT01886@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Padmakumar.AV@lntinfotech.com cc: arvind.sevalkar@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issue #25 In-reply-to: Your message of Sat, 18 May 2002 19:47:15 +0530. Date: Sun, 19 May 2002 14:18:47 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: MH messages are processed in the MH protocol context. The interface functions between Ipv6 and upper layer protocol (like ip6_build_xmit in Linux) we don't really want to modify. So we cannot pass the routing header 2 parameters to these functions. So the decision of adding routing header type 2 is difficult to take in MH protocol context, so we have to move it to the extension header building part. That place if we want to add a routing header 2 for the above mentioned case then after looking into binding cache we have to explicitly evaluate that the message is a BA and since there is no Binding cache entry we have to add routing header type 2 in this case explicitly. Moreover here I am confused that whether I can get the COA at this stage if the destination address is MN's Home Address. => I believe these implementation considerations are totally irrelevant. More, I believe this requirement for a RH in BA packets in the general case is very far to be new, so has been supported for years. Regards Francis.Dupont@enst-bretagne.fr PS: for the same reason a BU should be with a HAO, a BA should be with a RH... From owner-mobile-ip@sunroof.eng.sun.com Sun May 19 20:20:28 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29866 for ; Sun, 19 May 2002 20:20:27 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25018; Sun, 19 May 2002 18:21:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA14187; Sun, 19 May 2002 17:20:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K0JIrP024403 for ; Sun, 19 May 2002 17:19:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4K0JIq4024402 for mobile-ip-dist; Sun, 19 May 2002 17:19:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K0JFrP024395 for ; Sun, 19 May 2002 17:19:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA16973 for ; Sun, 19 May 2002 17:19:21 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17477 for ; Sun, 19 May 2002 18:19:20 -0600 (MDT) Message-ID: <007301c1ff93$bf499330$096015ac@T23KEMPF> From: "James Kempf" To: "Phil Roberts" , References: Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Sun, 19 May 2002 17:17:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Phil, There are just a few points to add to your excellent presentation of the architectural issues involved in introducing regional routing agents, to which I AGREE. The GFA constitutes a routing proxy. RFC 3238 gives architectural considerations for defining services on application proxies, but many of the considerations involved in introducing fate-sharing between the application proxies and end hosts are difficult to envision for a routing proxy. One argument I have heard in favor is that the Home Agent functions essentially as a routing proxy, so why is introducing a routing proxy in the foreign network any different? The answer is that the Home Agent is architecturally necessary to achieve the separation between node identifier and routing identifier, while the GFA is just a performance enhancement. While there are other ways of achieving the node/routing identifier separation, they all have more serious problems architecturally and practically than the Home Agent. With the GFA, there are other ways to achieve the same performance enhancement, and these are not difficult to implement and probably not particularly more difficult to deploy, since they are based on enhanced edge routing. Their reliability characterstics essentially match those of the access routers. jak ----- Original Message ----- From: "Phil Roberts" To: Sent: Tuesday, May 14, 2002 1:24 PM Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #4 > Several folks raised the issue of to what extent introducing regional > registration entities in the visited network violates principles of the > Internet architecture, specifically with regard to the introduction of > single points of failure in the communication path of visiting nodes. > > I've excerpted the relevant text from rfc 1958 on the architectural > principle which is at issue. > > "The end-to-end argument is discussed in depth in [Saltzer]. The > basic argument is that, as a first principle, certain required end- > to-end functions can only be performed correctly by the end-systems > themselves. A specific case is that any network, however carefully > designed, will be subject to failures of transmission at some > statistically determined rate. The best way to cope with this is to > accept it, and give responsibility for the integrity of communication > to the end systems. Another specific case is end-to-end security. > > To quote from [Saltzer], "The function in question can completely and > correctly be implemented only with the knowledge and help of the > application standing at the endpoints of the communication system. > Therefore, providing that questioned function as a feature of the > communication system itself is not possible. (Sometimes an incomplete > version of the function provided by the communication system may be > useful as a performance enhancement.") > > This principle has important consequences if we require applications > to survive partial network failures. An end-to-end protocol design > should not rely on the maintenance of state (i.e. information about > the state of the end-to-end communication) inside the network. Such > state should be maintained only in the endpoints, in such a way that > the state can only be destroyed when the endpoint itself breaks > (known as fate-sharing). An immediate consequence of this is that > datagrams are better than classical virtual circuits. The network's > job is to transmit datagrams as efficiently and flexibly as possible." > > draft-iab-arch-changes-00.txt provides a discussion of this issue of > fate-sharing in middleboxes and asserts that the principle is preserved in > the case that the middlebox is a partner in the communication when the > failure can be detected and dealt with.: > > "The idea of fate-sharing survives this recursion, but requires that > all application state created in middleboxes must be capable of re- > creation after failure. Additionally, to support this requirement, > where a function cannot be fulfilled completely, reliably and > securely by two endpoints of a conversation, the necessary > middleboxes to fulfil the function should be explicit partners in > explicit communication with at least one endpoint (or, by recursion > of the same principle, with an intermediate middlebox). In other > words, middleboxes should not be invisible, because their failures > need to be detected and dealt with by their communication partners." > > > As currently specified it's not immediately obvious how the regional > registration agents are compatible with the above guidelines. It's > conceivable that they can be made so, and perhaps it's immediately obvious > to others how they are so. > > This issue is not insurmountable but the functionality does need to be > specified in a way that preserves the fate sharing principle and allows for > one party in the communication to detect and deal with a failure of one of > the new registration entities. > From owner-mobile-ip@sunroof.eng.sun.com Sun May 19 20:31:40 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00514 for ; Sun, 19 May 2002 20:31:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA05259; Sun, 19 May 2002 17:29:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA15118; Sun, 19 May 2002 17:29:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K0T4rP024453 for ; Sun, 19 May 2002 17:29:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4K0T4JI024452 for mobile-ip-dist; Sun, 19 May 2002 17:29:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K0T1rP024445 for ; Sun, 19 May 2002 17:29:01 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA17774 for ; Sun, 19 May 2002 17:29:05 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA05018 for ; Sun, 19 May 2002 17:29:05 -0700 (PDT) Message-ID: <00ab01c1ff95$1b4b6360$096015ac@T23KEMPF> From: "James Kempf" To: , "'Phil Roberts'" , References: <000001c1fbd0$e15fb600$5701a8c0@EmadQ> Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Sun, 19 May 2002 17:27:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit EQ, > How is the GFA is different from the HA and FA from the stand > point of single point of failure or other reliability issues? I believe > this can be implementation dependent, i.e. someone can implement GFA as > a cluster. > In my reply to Phil's message, I explained why the GFA is different from the HA. With regard to the FA, the FA was removed from the MIPv6 design for many of the reasons cited by Phil in his note. Unfortunately, the FA can't be removed from MIPv4, but I don't see that as a reason to introduce another level of routing proxy. jak From owner-mobile-ip@sunroof.eng.sun.com Sun May 19 20:42:33 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01035 for ; Sun, 19 May 2002 20:42:32 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA23638; Sun, 19 May 2002 18:42:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA19523; Sun, 19 May 2002 17:42:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K0fArP024534 for ; Sun, 19 May 2002 17:41:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4K0fANs024533 for mobile-ip-dist; Sun, 19 May 2002 17:41:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K0f7rP024526 for ; Sun, 19 May 2002 17:41:07 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA24133 for ; Sun, 19 May 2002 17:41:11 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26115 for ; Sun, 19 May 2002 18:41:10 -0600 (MDT) Message-ID: <00e101c1ff96$c431f470$096015ac@T23KEMPF> From: "James Kempf" To: "Charlie Perkins" , "Annika Jonsson" , "Madhavi W. Chandra" Cc: "Phil Roberts" , References: <5.1.0.14.0.20020514100419.02851500@era-t.ericsson.se> <5.1.0.14.0.20020513175420.0287a090@era-t.ericsson.se> <20020509130354.A25864@cisco.com> <5.1.0.14.0.20020513175420.0287a090@era-t.ericsson.se> <20020513123737.A1353@cisco.com> <5.1.0.14.0.20020514100419.02851500@era-t.ericsson.se> <5.1.0.14.0.20020515100103.028daa60@era-t.ericsson.se> <3CE2294A.DED694DD@iprg.nokia.com> Subject: Re: [mobile-ip] Regional Registration Last Call ResolutionIssue #1 Date: Sun, 19 May 2002 17:39:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, What do you mean by "too much"? My impression is not that the GFA is needed for traffic shaping, but rather that it is primarily for reducing the latency impact of MIP handover on the MN. jak ----- Original Message ----- From: "Charlie Perkins" To: "Annika Jonsson" ; "Madhavi W. Chandra" Cc: "Phil Roberts" ; Sent: Wednesday, May 15, 2002 2:24 AM Subject: Re: [mobile-ip] Regional Registration Last Call ResolutionIssue #1 > Hello folks, > > The discussion revolves around when regional registration might > be useful, and how to indicate that within the draft. > > I think it's best to be very exact. Regional registration will be > useful when there's too much signaling traffic from registration > traffic across the Internet all emanating from the same visited > domain and all caused by movement between foreign agents > in that same domain. This is intuitive. > > "Too much" is clearly a matter for determination by individual > systems and access networks. If an access network does not > have this problem, then it does not need regional registration. > > Whether or not a "typical" visited domain or access network > will have this problem is hard to say. I do know that we undertook > this work originally with a clear mandate to get something to work, > presumably because people saw the need, and because we saw > the need ourselves. In fact, the implementations and simulations > do show the effect, and that bolsters the intuition. > > I don't it is possible to prove to anyone that they "need" > regional registration. Nor QoS, nor multicast, nor voice-quality > handovers, nor ... But if we have a good tool for people to use, > then they can more easily solve problems that require that tool. > It doesn't mean that everyone has the same problems. > > The text contribution that I would like to see from > Madhavi or anyone would be something that would shed > more light on problems where regional registration is > clearly needed, or clearly not needed, along with enough > discussion to make the point. It seems like good material > for an appendix. > > I hope this is at least helpful in some way, and that further > discussion doesn't have to wait until I return. > > Regards, > Charlie P. > > > > Annika Jonsson wrote (in response to Madhavi): > > > >Well, you can choose another word besides 'typical' then. I want to > > >convey that not only is Regional Registration OPTIONAL, but not > > >required in *typical* (or whatever word you like) networks. > > >For example, Route Optimization is also optional, but more of a need > > >to alleviate triangle routing. Do you see my point now? > > > > I understand what you mean, but I disagree. You are saying that even though > > both route opt. and regional reg. are optional, route opt. is more > > important, or is likely to be used more, or something like that. That may > > be, I don't feel that I can predict that. But I totally disagree that this > > should in any way be expressed in an RFC. Route opt. will be used to avoid > > triangular routing, regional reg. will be used to reduce the number of > > signaling messages to the home network, and reduce the signaling delay > > within the same visited domain. That's what you need to know about them. > > Then it's up to those building the networks to decide what functions they > > think are important enough to use. > > .................................... > > > > > >Annika, how can I provide you text for something that I am asking? These are > > >the concerns that I raised initially. We came to a good understanding > > >that the authors would describe where the regional registration architecture > > >is useful in another Section...you could articulate the network scenarios > > >that would benefit. The purpose of the Section is to assuage doubts on > > >its applicability. > > > > > >I offered to provide text for the OPTIONAL statements, which I did. > > > > > >Instead of continuing in circles, perhaps we should wait until Charlie > > >returns. > > > > I can't speek for Charlie, of course, but I think that he would more or > > less agree with me. He usually likes people to propose text because that's > > the best way to understand what they want. But, we have been considering > > adding an Applicability section to the draft. In view of these discussions > > I think we should, and that will hopefully address your concerns. > > > > From owner-mobile-ip@sunroof.eng.sun.com Sun May 19 22:37:25 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06448 for ; Sun, 19 May 2002 22:37:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11324; Sun, 19 May 2002 19:35:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA14947; Sun, 19 May 2002 19:35:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K2Y0rP024696 for ; Sun, 19 May 2002 19:34:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4K2Y0R3024695 for mobile-ip-dist; Sun, 19 May 2002 19:34:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K2XvrP024688 for ; Sun, 19 May 2002 19:33:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA29385 for ; Sun, 19 May 2002 19:34:02 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA22632 for ; Sun, 19 May 2002 20:34:01 -0600 (MDT) Message-ID: <01b701c1ffa6$8fa3df60$096015ac@T23KEMPF> From: "James Kempf" To: "Scott Corson" , "'Phil Roberts'" , References: <8C92E23A3E87FB479988285F9E22BE469948D5@ftmail> Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Sun, 19 May 2002 19:11:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Scott, > 1) MIP breaks the end-to-end architecture of the Internet. > > The HA is a stateful, single point of failure. It is an architectural > compromise (an evil in the minds of purists), necessary only because of the > Internet routing infrastructure's inability to deal with prefix mobility. > See my response to Phil's note for why I think this is different. The HA is the exception that proves the rule. > What the current discussion over regional elements questions is whether > *another* such element should be added to the MIP standard. The unfortunate > conclusion is probably *yes* for the following reasons. > > 2) Operators need a way to shield the effects of what is commonly termed > micro-mobility from each other's networks (i.e. mobility signalling). That > is the *primary* reason for needing a regional MIP element, and not latency > or many of the other issues frequently discussed on this list. What is > necessary is *separation* of the effects of localized domain/provider > mobility from global mobility/reachability at the network layer. > What do you mean by shielding? That it reveals the network topology in the foreign network to the home provider? If so, I think there are other ways to do this that don't involve routing proxies. They use FMIPv4 in a particular way so the localized mobility management is handled closer to the edge, by routers. In addition, our telco types don't cite this as a particular problem. They want something more radical (and as far as I can determine, undoable). They are more concerned that the source IP address on the packet delivered to the CN will be an address in the MN's foreign network, regardless of whether a routing proxy such as the GFA is deployed. They don't want the CN to be able to determine the address in the foreign network, and they don't want the home address there because they don't want tunneling. They don't care about the network topology, they don't want the foreign network revealed, period, and they don't want tunneling, period. So whatever benefits address privacy or topology hiding might be brought by the GFA are not of interest to Docomo (one operator's viewpoint). On the other hand, we do have an interest in limiting the number of special purpose, stateful boxes that only achieve reliability by making them 5 nine's reliable. These tend to be expensive. They start looking like 3G-SN's or VLRs. > Two current mobile network architectures (e.g. 3GPP/3GPP2) achieve this > separation through the usage of L2 mobility mechanisms for micro-mobility > support. This L2 mobility is hidden from the IP layer by the existence of > two IP-level boxes: GGSN/PDSN for 3GPP/3GPP2, respectively. These are > stateful, single points of failure which (if visible in the MIP plane) would > represent the regional elements your note suggests are harmful. > > It turns out that the PDSN and GGSN are extremely stateful (middleboxes of > the most complex kind involving not only network layer state, but L2 and > higher session layer state as well). In accordance with the e2e principle, > their removal would be a good thing from what are obstensibly "all-IP" > networks. > There are two reasons why the 3G networks need these boxes: 1) Their deep radio access networks enforce a connection oriented protocol on the "last" hop (last from the MN IP stack's view, actually there is a lot going on). In 3GPP, this is the PDP context. In 3GPP2, this is a PPP context. A pure MIP solution shouldn't need this. 2) These boxes act as anchors for AAA. For MIPv4, that function is already handled by the FA. Adding a GFA will only complicate AAA. > The addition of regional elements to MIP is a step towards making this > removal feasible. It would add the necessary localization/separation > properties MIP currently lacks to the standard, making MIP a deployable > control plane between operators and, when desired, within operator's > networks. It would limit the architecturally-compromising effects of > stateful elements to the network layer, which is consistent with existing > MIP, as a compromise solution for a network-layer routing deficiency. All > other layers would be free to operate in an e2e fashion. As a consequence, > these MIP regional elements need only be network layer entities (i.e. > routers), thus far cheaper to build, maintain, etc, enabling the Internet to > function closer to the way e2e principle suggests. > I disagree. I believe the required localized mobility management function can be added using minor enhancements to the access routers or other routers closer to the edge, at considerably less expense. > It should also be noted that many of the desired properties currently > lacking in MIP can be realized in a less stateful manner through the use of > "nested" MIP as detailed in > > http://search.ietf.org/internet-drafts/draft-oneill-mip-nested-00.txt > > However, additional capabilities/features are realizable through the use of > network layer-stateful entities as detailed in the recently submitted drafts > related to nested MIP. There are many facets to this issue which are > explored in these drafts. > I have not yet read Alan's drafts but they are my short list. jak From owner-mobile-ip@sunroof.eng.sun.com Mon May 20 00:55:37 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13903 for ; Mon, 20 May 2002 00:55:37 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA28299; Sun, 19 May 2002 22:55:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA19932; Sun, 19 May 2002 21:55:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K4sJrP024916 for ; Sun, 19 May 2002 21:54:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4K4sJYx024915 for mobile-ip-dist; Sun, 19 May 2002 21:54:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K4sFrP024908 for ; Sun, 19 May 2002 21:54:15 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA19768 for ; Sun, 19 May 2002 21:54:20 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA11254 for ; Sun, 19 May 2002 21:54:20 -0700 (PDT) Message-ID: <014e01c1ffba$26699c60$026015ac@T23KEMPF> From: "James Kempf" To: "Alan O'Neill" , "Phil Roberts" , References: <8C92E23A3E87FB479988285F9E22BE46E2200A@ftmail> Subject: Re: [mobile-ip] RR Last Call Resolution Issue #4 - CLARIFICATION Date: Sun, 19 May 2002 21:13:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alan, The issue isn't end to end, it's fate sharing. In some circles, end to end has become so theological that it is the only Internet architectural principle people cite. It is unclear how a routing proxy and the host could communicate to effect fate sharing. jak ----- Original Message ----- From: "Alan O'Neill" To: "Phil Roberts" ; Sent: Friday, May 17, 2002 5:09 AM Subject: RE: [mobile-ip] RR Last Call Resolution Issue #4 - CLARIFICATION > I thought it might be useful if I stated specifically why I feel MIP doesn't > affect end to end at all. > > By definition it is a tunnel protocol coupled with Internet routing which in > addition has host routing into that tunnel. The packet within the tunnel is > not touched or modified on its travels and hence end to end is not affected. > The IP address is still the identifier and the locator, but routing has > simply moved the location. The redirection is at the edge of the network > (subnet to subnet) so preserving end to end. The fact that the HA is on an > edge in the core (just like a webserver) doesn't change the argument. > > The HA has one tunnel endpoint and the FA or MN the other. If we put a GFA > in the middle then it is only affecting the tunnel not the inner packet. Now > we wouldn't claim running multicast over unicast tunnels breaks end to end > and we wouldn't claim that MPLS lable switching (another switching layer > carrying user packets) breaks end to end either. End to end is about the > users packets and ensuring that the endpoint is aware of stuff going on. The > MN is issuing the redirection so I think we are completely clean here. > > The issue with GFA and MIP is simply to me the soft-state requirement and > its impact on availability, unavailability and signalling load. We begin to > impact end to end when the soft-state refresh rate in insufficient to > protect the users interests in the flow... > > Hope that is clear and logical, Alan > > > -----Original Message----- > From: Alan O'Neill [mailto:A.ONeill@flarion.com] > Sent: 16 May 2002 16:42 > To: Phil Roberts; 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] RR Last Call Resolution Issue #4 - > CLARIFICATION > > > I think this is maybe a bit of a red herring wg for the following reasons. > > MIP is a soft-state refresh protocol with periodic refresh as a fraction of > the binding lifetime. > > Any arguments about statefulness come down to the refresh interval you are > prepared to tolerate in return for higher availability through reduced > unavailability when a node crashes. When a router goes down we are typically > happy to wait for OSPF convergence times which are large numbers of seconds. > We shouldn't ask for much more from MIP. Adding a GFA or an RMA (from > Nested) doesn't change the flexibility of the operator and/or MN to tune > lifetimes, and having a big router or a big regional element fail impacts > just as many flows for OSPF convergence time so I feel that is also a bit of > a red herring. especially in a tree network.. > > The bigger but different problem here is that costly and localised high > availability solutions (hot-standby) that vendors would try to use to > protect the regional element whilst also having long lifetimes to reduce the > signalling overhead, do not work with GFA because the HA must also be > updated. This is why the RMA places a routable MN specific address in the HA > so that these hot-standby techniques can still be localised. This is the > aspect of GFA that is problematic here... > > Alan. > > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: 15 May 2002 05:55 > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #4 > > > Several folks raised the issue of to what extent introducing regional > registration entities in the visited network violates principles of th e > Internet architecture, specifically with regard to the introduction of > single points of failure in the communication path of visiting nodes. > > I've excerpted the relevant text from rfc 1958 on the architectural > principle which is at issue. > > "The end-to-end argument is discussed in depth in [Saltzer]. The > basic argument is that, as a first principle, certain required end- > to-end functions can only be performed correctly by the end-systems > themselves. A specific case is that any network, however carefully > designed, will be subject to failures of transmission at some > statistically determined rate. The best way to cope with this is to > accept it, and give responsibility for the integrity of communication > to the end systems. Another specific case is end-to-end security. > > To quote from [Saltzer], "The function in question can completely and > correctly be implemented only with the knowledge and help of the > application standing at the endpoints of the communication system. > Therefore, providing that questioned function as a feature of the > communication system itself is not possible. (Sometimes an incomplete > version of the function provided by the communication system may be > useful as a performance enhancement.") > > This principle has important consequences if we require applications > to survive partial network failures. An end-to-end protocol design > should not rely on the maintenance of state (i.e. information about > the state of the end-to-end communication) inside the network. Such > state should be maintained only in the endpoints, in such a way that > the state can only be destroyed when the endpoint itself breaks > (known as fate-sharing). An immediate consequence of this is that > datagrams are better than classical virtual circuits. The network's > job is to transmit datagrams as efficiently and flexibly as possible." > > draft-iab-arch-changes-00.txt provides a discussion of this issue of > fate-sharing in middleboxes and asserts that the principle is preserved in > the case that the middlebox is a partner in the communication when the > failure can be detected and dealt with.: > > "The idea of fate-sharing survives this recursion, but requires that > all application state created in middleboxes must be capable of re- > creation after failure. Additionally, to support this requirement, > where a function cannot be fulfilled completely, reliably and > securely by two endpoints of a conversation, the necessary > middleboxes to fulfil the function should be explicit partners in > explicit communication with at least one endpoint (or, by recursion > of the same principle, with an intermediate middlebox). In other > words, middleboxes should not be invisible, because their failures > need to be detected and dealt with by their communication partners." > > > As currently specified it's not immediately obvious how the regional > registration agents are compatible with the above guidelines. It's > conceivable that they can be made so, and perhaps it's immediately obvious > to others how they are so. > > This issue is not insurmountable but the functionality does need to be > specified in a way that preserves the fate sharing principle and allows for > one party in the communication to detect and deal with a failure of one of > the new registration entities. > From owner-mobile-ip@sunroof.eng.sun.com Mon May 20 02:43:02 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26673 for ; Mon, 20 May 2002 02:43:01 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25353; Mon, 20 May 2002 00:42:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05402; Sun, 19 May 2002 23:42:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K6fTrP025101 for ; Sun, 19 May 2002 23:41:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4K6fTHd025100 for mobile-ip-dist; Sun, 19 May 2002 23:41:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K6fQrP025093 for ; Sun, 19 May 2002 23:41:26 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA01211 for ; Sun, 19 May 2002 23:41:29 -0700 (PDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25040 for ; Mon, 20 May 2002 00:41:28 -0600 (MDT) Received: from v3smtp (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.1/8.12.1) with SMTP id g4K6bqWM004147 for ; Mon, 20 May 2002 15:37:52 +0900 (KST) Message-ID: <012801c1ffcc$5434c400$eb2d024b@hilbert> From: "JinHyeock Choi" To: Subject: [mobile-ip] A new proposal for Fast Router Discovery Date: Mon, 20 May 2002 16:02:38 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0124_01C20017.C37C0D50" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 x-mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0124_01C20017.C37C0D50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0125_01C20017.C37C0D50" ------=_NextPart_001_0125_01C20017.C37C0D50 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 RGVhciBBbGwNCg0KV2Ugc3VibWl0dGVkIG5ldyBJbnRlcm5ldC1EcmFmdCBvbiBGYXN0IFJvdXRl ciBEaXNjb3ZlcnkuIEl0IGRlYWxzIHdpdGggDQqhrkhvdyBjYW4gYSBtb2JpbGUgbm9kZSBmaW5k IGl0cyBuZXcgYWNjZXNzIHJvdXRlciBzdWZmaWNpZW50bHkgZmFzdD+hryANCk91ciBwcm9wb3Nh bCB1c2VzIGxheWVyIHR3byBtZWNoYW5pc21zIGZvciBwZXJmb3JtYW5jZSBlbmhhbmNlbWVudC4N Cg0KSW4gb3VyIHByb3Bvc2FsIEFQIGNhY2hlcyBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBtZXNzYWdl IGFuZCBzZW5kcyBpdCANCnRvIGEgbmV3IG1vYmlsZSBub2RlIGFzIHNvb24gYXMgTDIgYXNzb2Np YXRpb24gaXMgbWFkZS4gSW4gYW4gYXR0YWNoZWQgDQpJbnRlcm5ldC1kcmFmdCwgd2UgcHJlc2Vu dCBhIHdheSBmb3IgQVAgdG8gY2FjaGUgbmVjZXNzYXJ5IFJBLiANCg0KQnkgcHV0dGluZyAnUkEg Q2FjaGluZycgYW5kICdBUCBOb3RpZmljYXRpb24nIGZ1bmN0aW9uYWxpdHkgb24gYW4gQWNjZXNz IFBvaW50LCANCndlIGdldCB0aGUgb3B0aW1pemVkIHJlc3VsdCB3aXRob3V0IElQdjYgc3RhbmRh cmQgY2hhbmdlLiBJbiBvdXIgc2NoZW1lLCBhIA0KbW9iaWxlIG5vZGUgcmVjZWl2ZXMgUm91dGVy IEFkdmVydGlzZW1lbnQganVzdCBhZnRlciBMMiBhc3NvY2lhdGlvbiBpcyBtYWRlIA0Kd2hpY2gg aXMgdGhlIGVhcmxpZXN0IHBvc3NpYmxlIHRpbWUgdW5kZXIgY3VycmVudCBzdGFuZGFyZC4NCg0K QWxsIGNvbW1lbnRzIGFyZSBhcHByZWNpYXRlZC4gDQogDQpCZXN0IFJlZ2FyZHMNCg0KSmluSHll b2NrIENob2ksIFBoLkQuDQoNClNhbXN1bmcgRWxlY3Rvbmljcw0KdGVsbCkgIDgyLTMxLTI4MC05 MjMzDQpmYXgpICA4Mi0zMS0yODAtOTE1Ng0KZW1haWwpIGF0aGVuZUBzYWl0LnNhbXN1bmcuY28u a3IsIHNhaXRAc2Ftc3VuZy5jby5rcg0KDQogDQo= ------=_NextPart_001_0125_01C20017.C37C0D50 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkRlYXIgQWxsPC9G T05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPldlIHN1Ym1p dHRlZCBuZXcgSW50ZXJuZXQtRHJhZnQgb24gRmFzdCBSb3V0ZXIgRGlzY292ZXJ5LiBJdCANCmRl YWxzIHdpdGggPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+oa5Ib3cgY2FuIGEgbW9i aWxlIG5vZGUgZmluZCBpdHMgbmV3IGFjY2VzcyByb3V0ZXIgc3VmZmljaWVudGx5IA0KZmFzdD+h ryA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5PdXIgcHJvcG9zYWwgdXNlcyBsYXll ciB0d28gbWVjaGFuaXNtcyBmb3IgcGVyZm9ybWFuY2UgDQplbmhhbmNlbWVudC48L0ZPTlQ+PC9E SVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SW4gb3VyIHByb3Bvc2Fs IEFQIGNhY2hlcyBSb3V0ZXIgQWR2ZXJ0aXNlbWVudCBtZXNzYWdlIGFuZCANCnNlbmRzIGl0IDwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPnRvIGEgbmV3IG1vYmlsZSBub2RlIGFzIHNv b24gYXMgTDIgYXNzb2NpYXRpb24gaXMgbWFkZS4gSW4gYW4gDQphdHRhY2hlZCA8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5JbnRlcm5ldC1kcmFmdCwgd2UgcHJlc2VudCBhIHdheSBm b3IgQVAgdG8gY2FjaGUgbmVjZXNzYXJ5IFJBLiANCjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5CeSBwdXR0aW5nICdSQSBDYWNoaW5nJyBhbmQgJ0FQ IE5vdGlmaWNhdGlvbicgZnVuY3Rpb25hbGl0eSBvbiANCmFuIEFjY2VzcyBQb2ludCwgPC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+d2UgZ2V0IHRoZSBvcHRpbWl6ZWQgcmVzdWx0IHdp dGhvdXQgSVB2NiBzdGFuZGFyZCBjaGFuZ2UuIEluIA0Kb3VyIHNjaGVtZSwgYSA8L0ZPTlQ+PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj5tb2JpbGUgbm9kZSByZWNlaXZlcyBSb3V0ZXIgQWR2ZXJ0 aXNlbWVudCBqdXN0IGFmdGVyIEwyIA0KYXNzb2NpYXRpb24gaXMgbWFkZSA8L0ZPTlQ+PC9ESVY+ DQo8RElWPjxGT05UIHNpemU9Mj53aGljaCBpcyB0aGUgZWFybGllc3QgcG9zc2libGUgdGltZSB1 bmRlciBjdXJyZW50IA0Kc3RhbmRhcmQuPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4N CjxESVY+PEZPTlQgc2l6ZT0yPkFsbCBjb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQuIDxCUj4mbmJz cDs8QlI+QmVzdCANClJlZ2FyZHM8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJ Vj48Rk9OVCBzaXplPTI+SmluSHllb2NrIENob2ksIFBoLkQuPC9GT05UPjwvRElWPg0KPERJVj4m bmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlNhbXN1bmcgRWxlY3RvbmljczxCUj50ZWxs KSZuYnNwOyA4Mi0zMS0yODAtOTIzMzxCUj5mYXgpJm5ic3A7IA0KODItMzEtMjgwLTkxNTY8QlI+ ZW1haWwpIDxBIA0KaHJlZj0ibWFpbHRvOmF0aGVuZUBzYWl0LnNhbXN1bmcuY28ua3IiPmF0aGVu ZUBzYWl0LnNhbXN1bmcuY28ua3I8L0E+LCA8QSANCmhyZWY9Im1haWx0bzpzYWl0QHNhbXN1bmcu Y28ua3IiPnNhaXRAc2Ftc3VuZy5jby5rcjwvQT48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7PC9GT05UPjwvRElWPjwvQk9EWT48L0hUTUw+ DQo= ------=_NextPart_001_0125_01C20017.C37C0D50-- ------=_NextPart_000_0124_01C20017.C37C0D50 Content-Type: text/plain; name="draft-jinchoi-l2trigger-fastrd-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-jinchoi-l2trigger-fastrd-00.txt" Content-Transfer-Encoding: quoted-printable INTERNET DRAFT JinHyeock Choi Expires: November 2002 DongYun Shin Samsung AIT May 2002 Fast Router Discovery with AP Notification Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at anytime. It is inappropriate to use Internet Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document presents Fast Router Discovery with AP Notification. For seamless handoff, a mobile node MUST quickly discover its new access router. In our proposal AP caches Router Advertisement message and sends it to a new mobile node as soon as L2 association is made. We present a way for AP to cache necessary RA. By putting 'RA Caching' and 'AP Notification' functionality on an Access = Point,=20 we get the optimized result without IPv6 standard change. Table of Contents: 1. Introduction 2. Terminology 3. Proposal Overview 4. Operation Description 4.1 RA Caching 4.2 AP Notification References Choi, Shin Expires March 2002 [Page 1] =0C INTERNET DRAFT Fast Router Discovery May 2002 1. Introduction The primary movement detection mechanism for Mobile IPv6 defined in [2] uses the facilities of IPv6 Neighbor Discovery [1], including Router Discovery and Neighbor Unreachability Detection. Mobile node MUST quickly detect when it moves to a link served by a new access router, so that it can acquire a new care-of address and send Binding Updates quickly. Mobile node MUST receive Router Advertisement from a new access router as soon as possible. There are several hindrances for sufficiently fast Router Discovery. First Neighbor Discovery protocol [1] limits routers to a minimum interval of 3 seconds between sending unsolicited multicast Router Advertisement messages. Second before a mobile node sends an initial Router Solicitation, it SHOULD delay the transmission for a random amount of time. Third a router MUST delay a response to a Router Solicitation by a random time too. Though solutions are proposed by [2], [3], they require IPv6 standard [1] change. In our proposal AP (Access Point) caches RA (Router Advertisement) message and sends it to a new mobile node as soon as L2 association is made. We present a way for AP to cache necessary RA. By putting 'RA Caching' and 'AP Notification' functionality on an Access = Point,=20 we get the optimized result without IPv6 standard change. In our = scheme,=20 mobile node receives Router Advertisement just after L2 association = is=20 made which is the earliest possible time under current standard. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Access Router (AR) An Access Network Router residing on the edge of an Access Network and offers IP connectivity to mobile nodes Access Point (AP) An L2 entity that has station functionality and provides access to the distribution services, via the wireless medium for associated stations. 3. Proposal Overview In Wireless LAN technology, when a MN (mobile node) arrives at a new link, it should associate with its new AP. Choi, Shin Expires March 2002 [Page 2] =0C INTERNET DRAFT Fast Router Discovery May 2002 In our proposal, AP caches RA message beforehand and sends it to a mobile node as soon as L2 association is made. We can cache RA in AP manually or use the following scheme. AR (Access Router) periodically multicasts unsolicited RAs, which go through AP. So AP can scan incoming L2 frames and cache necessary RA. AP scans L2 frame either continuously or periodically to update stored RA. Moreover if AR and AP are under same network administration, they can be configured such that AP caches RA efficiently. 4. Operation Description Our proposal consists of 'RA Caching' and 'AP Notification', 'RA Caching' periodically scans incoming L2 frame for unsolicited RA=20 and stores it. 'AP Notification' sends stored RA to new MN as soon=20 as L2 association is made. 4.1. RA Caching AP scans incoming L2 frame for unsolicited RA. First it scans L2 frame header to see whether it is a multicast frame. If not, AP sends that frame down link and scans next L2 frame. If so, AP looks IP header to check whether it contains unsolicited RA. If incoming L2 frame doesn't contain unsolicited RA, AP sends that frame down link and scans next L2 frame. When AP finds unsolicited RA, it stores it. AP can scan continuously, updating old RA with new RA. Or if it costs too much for AP to scan every incoming L2 frame, we can control the scanning rate. For example, we can set timer and execute scanning every T seconds. Or we can make AP to be able to send Router Solicitation message. Periodically AP sends Router Solicitation. Then AR will send RA and AP caches it. It is noted that AP doesn't need to have IP address since it can use unspecified address as its source address. 4.2. AP Notification When a new MN arrives at AP, it sends Association Request Message with its MAC address. Then AP grants association by sending Association Response Message. As soon as association is made, AP sends stored RA to a new MN with MAC address in Association Request message. MN receives RA just after association is made which is the earliest possible time in current standard. Choi, Shin Expires March 2002 [Page 3] =0C INTERNET DRAFT Fast Router Discovery May 2002 References [1] T. Narten, E. Nordmark and W. Simpson, Neighbor Discovery for IP Version 6 (IPv6), RFC 2461, December, 1998. [2] D. Johnson, C. Perkins and J. Arkko, Mobility Support in IPv6, draft-ietf-mobileip-ipv6-17.txt, May 2002 [3] J. Kempf, M. M Khalil and B. Pentland, IPv6 Fast Router Advertisement, draft-mkhalil-ipv6-fastra-00.txt, April 2002 Author's Addresses JinHyeock Choi i-Networking Lab, Samsung AIT (SAIT) Phone: +82-31-280-9233 Email: athene@sait.samgung.co.kr DongYun Shin i-Networking Lab, Samsung AIT (SAIT) Phone: +82-31-280-9552 Email: yun7521@samgung.co.kr Choi, Shin Expires March 2002 [Page 4] =0C ------=_NextPart_000_0124_01C20017.C37C0D50-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 20 04:57:51 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00836 for ; Mon, 20 May 2002 04:57:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07589; Mon, 20 May 2002 02:58:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19364; Mon, 20 May 2002 01:57:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K8ucrP025232 for ; Mon, 20 May 2002 01:56:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4K8ubiI025231 for mobile-ip-dist; Mon, 20 May 2002 01:56:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4K8uYrP025224 for ; Mon, 20 May 2002 01:56:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA22989 for ; Mon, 20 May 2002 01:56:39 -0700 (PDT) From: arvind.sevalkar@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14042 for ; Mon, 20 May 2002 02:56:37 -0600 (MDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002052014303432:433 ; Mon, 20 May 2002 14:30:34 +0530 Subject: Re: [mobile-ip] issue #25 To: Francis Dupont Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Mon, 20 May 2002 14:26:18 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/20/2002 02:26:59 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/20/2002 02:30:34 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/20/2002 02:30:38 PM, Serialize complete at 05/20/2002 02:30:38 PM Message-ID: X-Priority: 3 (Normal) Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Francis Dupont cc: mobile-ip@sunroof.eng.sun.com Sent by: Subject: Re: [mobile-ip] issue #25 owner-mobile-ip@sunroof.e ng.sun.com 05/18/2002 09:48 PM I think this will not work. Let's consider MN is in the foreign network it sends BU for the first time to CN and that fails, then in this case, CN don't have binding Cache entry so while sending BA, CN can not add routing header. But u said always include the routing header while sending BA even if the BU fails. How can this is possible in this case ? => special code to handle the special case. ----> But is it really necessary to send Binding Acknowledgement with routing header when there is no binding in cache. Because routing header is included when there is an entry in the binding cache some implementation checks routing header for binding in binding cache. We can simply do one thing when there is a binding in the Binding cache then we will send BA with routing header and when there is no Binding in the Binding cache then we will send BA to the Home address without routing header. So BA will be sent to HA without RH header in two cases. 1>BU successful and which is for deleting Binding cache entry. 2>BU failed and there is no entry in Binding cache, in case when first time MN sends BU to CN and that fails. Arvind From owner-mobile-ip@sunroof.eng.sun.com Mon May 20 06:31:01 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04460 for ; Mon, 20 May 2002 06:31:00 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13570; Mon, 20 May 2002 03:29:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09164; Mon, 20 May 2002 03:29:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KASIrP025404 for ; Mon, 20 May 2002 03:28:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4KASIGl025403 for mobile-ip-dist; Mon, 20 May 2002 03:28:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KASErP025396 for ; Mon, 20 May 2002 03:28:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09090 for ; Mon, 20 May 2002 03:28:17 -0700 (PDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14661 for ; Mon, 20 May 2002 04:28:16 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 May 2002 06:28:14 -0400 Message-ID: <8C92E23A3E87FB479988285F9E22BE46C3739D@ftmail> From: "Alan O'Neill" To: "'James Kempf'" , Phil Roberts , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RR Last Call Resolution Issue #4 - CLARIFICATION Date: Mon, 20 May 2002 06:28:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Fate-sharing is certainly another useful but equally dark cave to explore on this thread .. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: 20 May 2002 13:44 To: Alan O'Neill; Phil Roberts; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR Last Call Resolution Issue #4 - CLARIFICATION Alan, The issue isn't end to end, it's fate sharing. In some circles, end to end has become so theological that it is the only Internet architectural principle people cite. It is unclear how a routing proxy and the host could communicate to effect fate sharing. jak ----- Original Message ----- From: "Alan O'Neill" To: "Phil Roberts" ; Sent: Friday, May 17, 2002 5:09 AM Subject: RE: [mobile-ip] RR Last Call Resolution Issue #4 - CLARIFICATION > I thought it might be useful if I stated specifically why I feel MIP doesn't > affect end to end at all. > > By definition it is a tunnel protocol coupled with Internet routing which in > addition has host routing into that tunnel. The packet within the tunnel is > not touched or modified on its travels and hence end to end is not affected. > The IP address is still the identifier and the locator, but routing has > simply moved the location. The redirection is at the edge of the network > (subnet to subnet) so preserving end to end. The fact that the HA is on an > edge in the core (just like a webserver) doesn't change the argument. > > The HA has one tunnel endpoint and the FA or MN the other. If we put a GFA > in the middle then it is only affecting the tunnel not the inner packet. Now > we wouldn't claim running multicast over unicast tunnels breaks end to end > and we wouldn't claim that MPLS lable switching (another switching layer > carrying user packets) breaks end to end either. End to end is about the > users packets and ensuring that the endpoint is aware of stuff going on. The > MN is issuing the redirection so I think we are completely clean here. > > The issue with GFA and MIP is simply to me the soft-state requirement and > its impact on availability, unavailability and signalling load. We begin to > impact end to end when the soft-state refresh rate in insufficient to > protect the users interests in the flow... > > Hope that is clear and logical, Alan > > > -----Original Message----- > From: Alan O'Neill [mailto:A.ONeill@flarion.com] > Sent: 16 May 2002 16:42 > To: Phil Roberts; 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] RR Last Call Resolution Issue #4 - > CLARIFICATION > > > I think this is maybe a bit of a red herring wg for the following reasons. > > MIP is a soft-state refresh protocol with periodic refresh as a fraction of > the binding lifetime. > > Any arguments about statefulness come down to the refresh interval you are > prepared to tolerate in return for higher availability through reduced > unavailability when a node crashes. When a router goes down we are typically > happy to wait for OSPF convergence times which are large numbers of seconds. > We shouldn't ask for much more from MIP. Adding a GFA or an RMA (from > Nested) doesn't change the flexibility of the operator and/or MN to tune > lifetimes, and having a big router or a big regional element fail impacts > just as many flows for OSPF convergence time so I feel that is also a bit of > a red herring. especially in a tree network.. > > The bigger but different problem here is that costly and localised high > availability solutions (hot-standby) that vendors would try to use to > protect the regional element whilst also having long lifetimes to reduce the > signalling overhead, do not work with GFA because the HA must also be > updated. This is why the RMA places a routable MN specific address in the HA > so that these hot-standby techniques can still be localised. This is the > aspect of GFA that is problematic here... > > Alan. > > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: 15 May 2002 05:55 > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #4 > > > Several folks raised the issue of to what extent introducing regional > registration entities in the visited network violates principles of th e > Internet architecture, specifically with regard to the introduction of > single points of failure in the communication path of visiting nodes. > > I've excerpted the relevant text from rfc 1958 on the architectural > principle which is at issue. > > "The end-to-end argument is discussed in depth in [Saltzer]. The > basic argument is that, as a first principle, certain required end- > to-end functions can only be performed correctly by the end-systems > themselves. A specific case is that any network, however carefully > designed, will be subject to failures of transmission at some > statistically determined rate. The best way to cope with this is to > accept it, and give responsibility for the integrity of communication > to the end systems. Another specific case is end-to-end security. > > To quote from [Saltzer], "The function in question can completely and > correctly be implemented only with the knowledge and help of the > application standing at the endpoints of the communication system. > Therefore, providing that questioned function as a feature of the > communication system itself is not possible. (Sometimes an incomplete > version of the function provided by the communication system may be > useful as a performance enhancement.") > > This principle has important consequences if we require applications > to survive partial network failures. An end-to-end protocol design > should not rely on the maintenance of state (i.e. information about > the state of the end-to-end communication) inside the network. Such > state should be maintained only in the endpoints, in such a way that > the state can only be destroyed when the endpoint itself breaks > (known as fate-sharing). An immediate consequence of this is that > datagrams are better than classical virtual circuits. The network's > job is to transmit datagrams as efficiently and flexibly as possible." > > draft-iab-arch-changes-00.txt provides a discussion of this issue of > fate-sharing in middleboxes and asserts that the principle is preserved in > the case that the middlebox is a partner in the communication when the > failure can be detected and dealt with.: > > "The idea of fate-sharing survives this recursion, but requires that > all application state created in middleboxes must be capable of re- > creation after failure. Additionally, to support this requirement, > where a function cannot be fulfilled completely, reliably and > securely by two endpoints of a conversation, the necessary > middleboxes to fulfil the function should be explicit partners in > explicit communication with at least one endpoint (or, by recursion > of the same principle, with an intermediate middlebox). In other > words, middleboxes should not be invisible, because their failures > need to be detected and dealt with by their communication partners." > > > As currently specified it's not immediately obvious how the regional > registration agents are compatible with the above guidelines. It's > conceivable that they can be made so, and perhaps it's immediately obvious > to others how they are so. > > This issue is not insurmountable but the functionality does need to be > specified in a way that preserves the fate sharing principle and allows for > one party in the communication to detect and deal with a failure of one of > the new registration entities. > From owner-mobile-ip@sunroof.eng.sun.com Mon May 20 07:55:02 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08286 for ; Mon, 20 May 2002 07:55:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01853; Mon, 20 May 2002 05:54:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29404; Mon, 20 May 2002 04:54:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KBrrrP025569 for ; Mon, 20 May 2002 04:53:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4KBrrtG025568 for mobile-ip-dist; Mon, 20 May 2002 04:53:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KBrnrP025561 for ; Mon, 20 May 2002 04:53:49 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21479 for ; Mon, 20 May 2002 04:53:52 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15743 for ; Mon, 20 May 2002 05:53:51 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07966; Mon, 20 May 2002 07:53:33 -0400 (EDT) Message-Id: <200205201153.HAA07966@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-nai-01.txt Date: Mon, 20 May 2002 07:53:32 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : AAA NAI for Mobile IPv4 Extension Author(s) : F. Johansson, T. Johansson Filename : draft-ietf-mobileip-aaa-nai-01.txt Pages : 8 Date : 17-May-02 When a mobile node moves between two foreign networks it has to be reauthenticated. If the home network has multiple AAA servers the reauthentication request may not be received by the same AAAH as previous authentication requests. In order for the new AAAH to be able to forward the request to the correct HA it has to know the identity of the HA. This document defines an extension that enables the HA to pass its identity to the mobile node which can in turn pass it to the AAA server when changing point of attachment. This document specifies a NAI extension that can carry these NAIs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-nai-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-aaa-nai-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-aaa-nai-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020517134821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-aaa-nai-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-aaa-nai-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020517134821.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Mon May 20 11:10:19 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06274 for ; Mon, 20 May 2002 11:10:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14697; Mon, 20 May 2002 08:08:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05538; Mon, 20 May 2002 08:08:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KF7erP025997 for ; Mon, 20 May 2002 08:07:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4KF7eTa025996 for mobile-ip-dist; Mon, 20 May 2002 08:07:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KF7brP025989 for ; Mon, 20 May 2002 08:07:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA10395 for ; Mon, 20 May 2002 08:07:40 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12457 for ; Mon, 20 May 2002 09:08:18 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E08A39143; Mon, 20 May 2002 11:07:38 -0400 (EDT) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 5DE221054; Mon, 20 May 2002 10:07:37 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id LAA0001305434; Mon, 20 May 2002 11:07:36 -0400 (EDT) Message-ID: <3CE91138.6050007@hp.com> Date: Mon, 20 May 2002 11:07:36 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <3CE58E19.C4B3517F@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Vijay Vijay Devarapalli wrote: > > 1. it is straight-forward for the HA to derive the MN's link local > address from the MN's unicast address. please remove this from > the issues. Ok, I'll grant you that, given that the HA knows all the prefixes and their lengths... > > 2. the HA MUST always defend the link local address of MN in addition > to the home address (irrespective of what the 'S' bit is set to). I disagree. Consider the use of privacy exensions that mobile nodes might want to use. There is no link-local address associated with such addresses. > > this is because of RFC 2462. lets assume the HA is defending the > global address of the MN. and it does not defend the link local > address. another node on the link could configure the MN's home > address. consider the following sequence of events > - node A configures MN's home address > - node A configures a link local address whose interface id > is the same as the home address you have the above 2 steps reversed... > - node A does DAD on the link local address alone (it does not > have to do for the global address) > - the HA does not defend the link local address > - you have a problem. I agree with Francis. This optimization is a bad idea on the home link. > 3. the philosophy behing the 'S' bit. > > imagine, the MN is at home. it configures a link local address. > it also configures unicast addresses for each and every network > prefix advertised on the home link. it also defends all these > address, preventing anybody else from claiming these addresses. > > when the MN is away from home, the 'S' bit simulates the above. > the HA defends not only the home address, but also the link > local address and every address from every network prefix on the > home link. when the MN returs home, it can claim all these > addresses back. > > the problem is, the HA has to figure out all these addresses from > the home address in the BU from the MN. its easy deriving the link > local address. but for the other addresses, the HA has to make an > assumption (this is what Francis and Brian are against) that the > same interface id that was used for the home address is used for > the other addresses too. IMO, it is safe to make this assumption. > this is because the MN is in a position to know if it uses different > interface id for each address. accordingly it can set the 'S' bit. > > setting the 'S' bit to 1 turns off this functionality. the HA only > defends the home address. Ahh, but according to the statement you made above, the HA has to defent the link-local as well. What whould happend for more then one binding with S=1? Q: Do we need a "Defend Link-local" bit? Set the bit on the binding for a home address from which to derive the link-local. Just a thought. -vlad +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Mon May 20 13:29:18 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21284 for ; Mon, 20 May 2002 13:29:17 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18059; Mon, 20 May 2002 10:27:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11208; Mon, 20 May 2002 10:27:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KHQLrP026319 for ; Mon, 20 May 2002 10:26:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4KHQLSU026318 for mobile-ip-dist; Mon, 20 May 2002 10:26:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KHQIrP026311 for ; Mon, 20 May 2002 10:26:18 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24172 for ; Mon, 20 May 2002 10:26:20 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17394 for ; Mon, 20 May 2002 10:26:20 -0700 (PDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g4KHQIEU000419; Mon, 20 May 2002 10:26:18 -0700 (PDT) Received: from DBLAIRW2K (rtp-vpn2-495.cisco.com [10.82.241.239]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACX98301; Mon, 20 May 2002 10:26:16 -0700 (PDT) From: "Dana L. Blair" To: "Phil Roberts" , Subject: RE: [mobile-ip] MIP WG Doc Status Date: Mon, 20 May 2002 13:26:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Phil Roberts > Sent: Friday, May 17, 2002 5:10 PM > To: 'mobile-ip@sunroof.eng.sun.com' > Subject: [mobile-ip] MIP WG Doc Status > > > > Hi folks, > > here's a list of documents that have gone through, are, or are > soon to be > in WG last call and status. > > Phil > > > WG last call complete > >RFC3220 - amendments posted, a new version with the missing text will be > resubmitted to the RFC editor without any new clarifications > >AAA keys - comments received from AD review being incorporated, > anticipate > submitting for IETF last call on 5/24 > >Regional Registration - lots of comments received, being resolved per ML > discussion I think the Regional Registration draft will need to go through last call again. The new draft should probably have a new revision number. There are so many threads running on this draft currently it's hard to keep track of what text changes have been agreed to and which are still in debate or not available yet. thanks, Dana > > in WG last call > >MIP NAT traversal - closes today > > expect WG last call RSN > >RFC 3012bis - still updating, anticipate being ready around 5/24 > >MIPv6 - not sure whether WG last call will be done on this > version, pending > some discussion around next steps on bidding down and securing RO within > design team From owner-mobile-ip@sunroof.eng.sun.com Mon May 20 18:28:49 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17170 for ; Mon, 20 May 2002 18:28:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04502; Mon, 20 May 2002 16:29:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29656; Mon, 20 May 2002 15:28:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KMRFrP026832 for ; Mon, 20 May 2002 15:27:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4KMREv2026831 for mobile-ip-dist; Mon, 20 May 2002 15:27:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KMR9rP026824 for ; Mon, 20 May 2002 15:27:09 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29381 for ; Mon, 20 May 2002 15:27:13 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18076 for ; Mon, 20 May 2002 16:27:12 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA28536; Mon, 20 May 2002 15:27:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4KMRAb19072; Mon, 20 May 2002 15:27:10 -0700 X-mProtect: <200205202227> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdaCqAKK; Mon, 20 May 2002 15:27:08 PDT Message-ID: <3CE9783C.65ACBEF9@iprg.nokia.com> Date: Mon, 20 May 2002 15:27:08 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205181347.g4IDlJT99517@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > > In your previous mail you wrote: > > 2. the HA MUST always defend the link local address of MN in addition > to the home address (irrespective of what the 'S' bit is set to). > > => I strongly object because this requirement will give major problems > when the mobile returns at home (the mobile forms the link-local address, > performs DAD (both steps are mandatory) and DAD fails: the MN should > deregister before or wait until the registration has expired). I thought that was obvious. the MN MUST deregister before using either the link local address or the home address after coming home. what is the use in having the link local address available to the MN, if it cant use the home address? it cant use the home address because the HA is defending it. so the first thing the MN has to do after coming to the home link is to deregister. after it deregisters, both the link local address and the home address are available to the MN. > this is because of RFC 2462... > > => please sends this issue to the IPv6 WG. and?? wait for RFC 2462 bis? > > the problem is, the HA has to figure out all these addresses from > the home address in the BU from the MN. its easy deriving the link > local address. but for the other addresses, the HA has to make an > assumption (this is what Francis and Brian are against) that the > > => I am against this assumption made "a priori". Even when this > assumption is developed (as here) I don't believe it is a good idea > because it is complex and misleading. I agree that this assumption is not the right one. but look at it this way. the MN is in the best position to know if it uses different interface id for each address. accordingly it can set the 'S' bit. > => for simplicity IMHO the S bit should be removed (reserve its position > (set to 1) and put it into the for further study class) and the DAD issue > solved by making the "DAD optimization" illegal on the home link, i.e.: > - any node attached to the home link MUST perform the DAD procedure > (RFC 2462 5.4) for each address doesnt this mean RFC 2462 bis?? this is going to take time. and also all links are potentially home links. a MIPv6 HA can be put on any IPv6 link. the change you are suggesting is for every host, not just hosts on the home link. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon May 20 18:41:03 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17991 for ; Mon, 20 May 2002 18:40:58 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10452; Mon, 20 May 2002 16:41:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03748; Mon, 20 May 2002 15:40:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KMdWrP026916 for ; Mon, 20 May 2002 15:39:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4KMdWUX026915 for mobile-ip-dist; Mon, 20 May 2002 15:39:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KMdSrP026908 for ; Mon, 20 May 2002 15:39:28 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA20862 for ; Mon, 20 May 2002 15:39:32 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09298 for ; Mon, 20 May 2002 15:39:32 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA29121; Mon, 20 May 2002 15:39:31 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4KMdVt02603; Mon, 20 May 2002 15:39:31 -0700 X-mProtect: <200205202239> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdknr64D; Mon, 20 May 2002 15:39:29 PDT Message-ID: <3CE97B21.EEA96B23@iprg.nokia.com> Date: Mon, 20 May 2002 15:39:29 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <3CE58E19.C4B3517F@iprg.nokia.com> <3CE91138.6050007@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vladislav Yasevich wrote: > > 2. the HA MUST always defend the link local address of MN in addition > > to the home address (irrespective of what the 'S' bit is set to). > > I disagree. Consider the use of privacy exensions that mobile nodes > might want to use. There is no link-local address associated with such > addresses. use of privacy extensions for the home address? I thought privacy extensions would be used for the CoA. you want to hide your current location, not the reachable address, right? the MN wont be reachable if it keeps changing its HoA often. > > this is because of RFC 2462. lets assume the HA is defending the > > global address of the MN. and it does not defend the link local > > address. another node on the link could configure the MN's home > > address. consider the following sequence of events > > - node A configures MN's home address > > - node A configures a link local address whose interface id > > is the same as the home address > > you have the above 2 steps reversed... you are right.... sorry for the slip. > > > - node A does DAD on the link local address alone (it does not > > have to do for the global address) > > - the HA does not defend the link local address > > - you have a problem. > > I agree with Francis. This optimization is a bad idea on the home link. what is a home link? how is it different from any IPv6 link? you are suggesting modifications to RFC 2462?? > > > > setting the 'S' bit to 1 turns off this functionality. the HA only > > defends the home address. > > Ahh, but according to the statement you made above, the HA has to defent > the link-local as well. What whould happend for more then one binding > with S=1? arghh, another slip. my opinion was that the HA MUST defend both home address and link irrespective of the 'S' bit. > Q: Do we need a "Defend Link-local" bit? Set the bit on the binding > for a home address from which to derive the link-local. we could, if needed. thats fine with me. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon May 20 18:50:11 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18612 for ; Mon, 20 May 2002 18:50:10 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13594; Mon, 20 May 2002 15:48:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06075; Mon, 20 May 2002 15:48:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KMlXrP026996 for ; Mon, 20 May 2002 15:47:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4KMlW1Z026995 for mobile-ip-dist; Mon, 20 May 2002 15:47:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4KMlTrP026988 for ; Mon, 20 May 2002 15:47:29 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA23564 for ; Mon, 20 May 2002 15:47:33 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09026 for ; Mon, 20 May 2002 16:47:33 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA29400; Mon, 20 May 2002 15:47:32 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4KMlUx09958; Mon, 20 May 2002 15:47:30 -0700 X-mProtect: <200205202247> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4cVsS6; Mon, 20 May 2002 15:47:28 PDT Message-ID: <3CE97D01.CE196BEB@iprg.nokia.com> Date: Mon, 20 May 2002 15:47:29 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: arvind.sevalkar@lntinfotech.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issue #25 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit arvind.sevalkar@lntinfotech.com wrote: > Vijay > > I think this will not work. > Let's consider MN is in the foreign network it sends BU for the first time > to CN and that fails, then in this case, CN don't have binding Cache entry > so while sending BA, CN can not add routing header. But u said always > include the routing header while sending BA even if the BU fails. How can > this is possible in this case ? if you have BU processing in the kernel, you dont have a problem. you still have access to the packet. or stored locally in some cache. another way of doing it would be to have a dummy binding cache entry with a failed status. there are other ways. it is really implementation specific. binding cache is a conceptual data structure. you can use it however you want. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon May 20 21:49:12 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28759 for ; Mon, 20 May 2002 21:49:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA11221; Mon, 20 May 2002 19:49:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10816; Mon, 20 May 2002 18:48:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4L1lNrP027280 for ; Mon, 20 May 2002 18:47:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4L1lNHl027279 for mobile-ip-dist; Mon, 20 May 2002 18:47:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4L1lKrP027272 for ; Mon, 20 May 2002 18:47:20 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10970 for ; Mon, 20 May 2002 18:47:24 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00345 for ; Mon, 20 May 2002 19:47:23 -0600 (MDT) Message-ID: <007301c20069$373c25d0$516015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] Clarification Date: Mon, 20 May 2002 18:45:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit In a recent exchange of email on network v.s. mobile controlled handoff, I cited some figures involving the relative performance of the two in some implementation work we have done. Earlier in the thread, I had mentioned that we had done some implementation work in this area for low latency MIPv4, and offered to send some slides with the analysis to anyone who was interested, but I failed to mention that in the particular email in which I cited the figures. If anyone is interested in obtaining the presentation, it will be available via the IPCN web site for the next two weeks, at http://www.mplsworld.com/ipcn02/. jak From owner-mobile-ip@sunroof.eng.sun.com Mon May 20 21:55:52 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29115 for ; Mon, 20 May 2002 21:55:52 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA26622; Mon, 20 May 2002 18:54:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA11999; Mon, 20 May 2002 18:54:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4L1rOrP027367 for ; Mon, 20 May 2002 18:53:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4L1rOPW027366 for mobile-ip-dist; Mon, 20 May 2002 18:53:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4L1rLrP027356 for ; Mon, 20 May 2002 18:53:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12696 for ; Mon, 20 May 2002 18:53:14 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA09310 for ; Mon, 20 May 2002 19:53:14 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4L1r9026866; Mon, 20 May 2002 20:53:09 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 20 May 2002 20:53:11 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCD29@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Dana L. Blair'" , Phil Roberts , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] MIP WG Doc Status Date: Mon, 20 May 2002 20:53:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2006A.3E789B20" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2006A.3E789B20 Content-Type: text/plain; charset="iso-8859-1" I would like to second Dana in her call. Especially that there are several technical issues that we have not heard a solution for YET. Regards; Ahmad Muhanna > > > > > > Hi folks, > > > > here's a list of documents that have gone through, are, or are > > soon to be > > in WG last call and status. > > > > Phil > > > > > > WG last call complete > > >RFC3220 - amendments posted, a new version with the > missing text will be > > resubmitted to the RFC editor without any new clarifications > > >AAA keys - comments received from AD review being incorporated, > > anticipate > > submitting for IETF last call on 5/24 > > >Regional Registration - lots of comments received, being > resolved per ML > > discussion > > I think the Regional Registration draft will need to go through last > call again. The new draft should probably have a new revision number. > There are so many threads running on this draft currently > it's hard to keep track of what text changes have been agreed to and > which are still in debate or not available yet. > > thanks, > Dana > > > > > > in WG last call > > >MIP NAT traversal - closes today > > > > expect WG last call RSN > > >RFC 3012bis - still updating, anticipate being ready around 5/24 > > >MIPv6 - not sure whether WG last call will be done on this > > version, pending > > some discussion around next steps on bidding down and > securing RO within > > design team > > ------_=_NextPart_001_01C2006A.3E789B20 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] MIP WG Doc Status

I would like to second Dana in her call.
Especially that there are several technical issues that we
have not heard a solution for YET.

Regards;
Ahmad Muhanna

> >
> >
> > Hi folks,
> >
> >    here's a list of documents that have gone through, are, or are
> > soon to be
> > in WG last call and status.
> >
> > Phil
> >
> >
> > WG last call complete
> > >RFC3220 - amendments posted, a new version with the
> missing text will be
> > resubmitted to the RFC editor without any new clarifications
> > >AAA keys - comments received from AD review being incorporated,
> > anticipate
> > submitting for IETF last call on 5/24
> > >Regional Registration - lots of comments received, being
> resolved per ML
> > discussion
>
> I think the Regional Registration draft will need to go through last
> call again.  The new draft should probably have a new revision number.
> There are so many threads running on this draft currently
> it's hard to keep track of what text changes have been agreed to and
> which are still in debate or not available yet.
>
> thanks,
> Dana
>
>
> >
> > in WG last call
> > >MIP NAT traversal - closes today
> >
> > expect WG last call RSN
> > >RFC 3012bis - still updating, anticipate being ready around 5/24
> > >MIPv6 - not sure whether WG last call will be done on this
> > version, pending
> > some discussion around next steps on bidding down and
> securing RO within
> > design team
>
>

------_=_NextPart_001_01C2006A.3E789B20-- From owner-mobile-ip@sunroof.eng.sun.com Tue May 21 04:12:27 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26825 for ; Tue, 21 May 2002 04:12:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23812; Tue, 21 May 2002 02:12:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23770; Tue, 21 May 2002 01:12:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4L8AXrP028008 for ; Tue, 21 May 2002 01:10:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4L8AXOR028007 for mobile-ip-dist; Tue, 21 May 2002 01:10:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4L8APrP028000 for ; Tue, 21 May 2002 01:10:25 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23648 for ; Tue, 21 May 2002 01:10:29 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA28331 for ; Tue, 21 May 2002 02:10:28 -0600 (MDT) Received: from era-t.ericsson.se (koff.ericsson.se [147.214.173.137]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4L8AC0E003119; Tue, 21 May 2002 10:10:17 +0200 (MEST) Received: from bends.era.ericsson.se by era-t.ericsson.se (SMI-8.6/LME-DOM-2.2.5(ERA/T)) id KAA28935; Tue, 21 May 2002 10:10:12 +0200 Message-Id: <5.1.0.14.0.20020521100755.029d1ec0@era-t.ericsson.se> X-Sender: erajoaa@era-t.ericsson.se X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 21 May 2002 10:11:25 +0200 To: "Ahmad Muhanna", mobile-ip@sunroof.eng.sun.com From: Annika Jonsson Subject: RE: [mobile-ip] Regional Registration Last Call issue #3 CLARIFIC ATION In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCD05@zrc2c013.us.norte l.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_1837821==_.ALT" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --=====================_1837821==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Ahmad, > > E. Generalized NAI extension > > > > There was a question about why the Generalized NAI extension > > is needed, why > > not use an FA-NAI extension directly? > > >I am sorry I forgot to comment on this one. I think I am the one who >raised this clarification. >I did not mean that you SHOULD NOT use GNAI. What I meant: >Why do we need to have a special section about GNAI for this extension. >GNAI already presented some where else. You can just say that we are using >GNAI extension with this type and subtype. No more no less. > >What do you think? > We had to add that in this draft, because the draft where it was specified before is now deprecated. /Annika --=====================_1837821==_.ALT Content-Type: text/html; charset="us-ascii" Hi Ahmad,

> E. Generalized NAI extension
>
> There was a question about why the Generalized NAI extension
> is needed, why
> not use an FA-NAI extension directly?
>
I am sorry I forgot to comment on this one. I think I am the one who raised this clarification.
I did not mean that you SHOULD NOT use GNAI. What I meant:
Why do we need to have a special section about GNAI for this extension.
GNAI already presented some where else. You can just say that we are using
GNAI extension with this type and subtype. No more no less.

What do you think?


We had to add that in this draft, because the draft where it was specified before is now deprecated.

/Annika


--=====================_1837821==_.ALT-- From owner-mobile-ip@sunroof.eng.sun.com Tue May 21 05:25:35 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29992 for ; Tue, 21 May 2002 05:25:35 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15303; Tue, 21 May 2002 03:25:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26183; Tue, 21 May 2002 02:25:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4L9OTrP028158 for ; Tue, 21 May 2002 02:24:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4L9OTer028157 for mobile-ip-dist; Tue, 21 May 2002 02:24:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4L9OQrP028150 for ; Tue, 21 May 2002 02:24:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22022 for ; Tue, 21 May 2002 02:24:30 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA29877 for ; Tue, 21 May 2002 03:24:25 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4L9O6n17538; Tue, 21 May 2002 11:24:06 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA12313; Tue, 21 May 2002 11:24:06 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4L9O5T10322; Tue, 21 May 2002 11:24:05 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205210924.g4L9O5T10322@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Mon, 20 May 2002 15:27:08 PDT. <3CE9783C.65ACBEF9@iprg.nokia.com> Date: Tue, 21 May 2002 11:24:05 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > 2. the HA MUST always defend the link local address of MN in addition > to the home address (irrespective of what the 'S' bit is set to). > > => I strongly object because this requirement will give major problems > when the mobile returns at home (the mobile forms the link-local address, > performs DAD (both steps are mandatory) and DAD fails: the MN should > deregister before or wait until the registration has expired). I thought that was obvious. the MN MUST deregister before using either the link local address or the home address after coming home. => which source address the MN should use to send the deregistration message? what is the use in having the link local address available to the MN, if it cant use the home address? => this use is the source address of the deregistration message. it cant use the home address because the HA is defending it. so the first thing the MN has to do after coming to the home link is to deregister. => on this point (only :-) we agree. after it deregisters, both the link local address and the home address are available to the MN. => an address should be available before. > this is because of RFC 2462... > > => please sends this issue to the IPv6 WG. and?? wait for RFC 2462 bis? => just read the charters of mobile-ip and ipv6 WGs: DAD is *not* in the charter of mobile-ip! > the problem is, the HA has to figure out all these addresses from > the home address in the BU from the MN. its easy deriving the link > local address. but for the other addresses, the HA has to make an > assumption (this is what Francis and Brian are against) that the > > => I am against this assumption made "a priori". Even when this > assumption is developed (as here) I don't believe it is a good idea > because it is complex and misleading. I agree that this assumption is not the right one. but look at it this way. the MN is in the best position to know if it uses different interface id for each address. accordingly it can set the 'S' bit. > => for simplicity IMHO the S bit should be removed (reserve its position > (set to 1) and put it into the for further study class) and the DAD issue > solved by making the "DAD optimization" illegal on the home link, i.e.: > - any node attached to the home link MUST perform the DAD procedure > (RFC 2462 5.4) for each address doesnt this mean RFC 2462 bis?? => no, RFC 2462 describes a mechanism and an optional optimization. I simply propose(d) to keep the mechanism as it is and to forbid the optimization. this is going to take time. and also all links are potentially home links. => I have no trouble with the second statement. IMHO the optional optimization is a bad idea and should remove from RFC 2462 (bis or before). I believe most IPv6 implementors share my opinion, for instance the KAME team has removed the optimization from its code (ask them why). a MIPv6 HA can be put on any IPv6 link. the change you are suggesting is for every host, not just hosts on the home link. => as soon as an address can be formed in an other way than stateless autoconf (and this is the case with a HA on the link) the optimization opens the door to troubles so *must* be disabled (or, according to RFC 2462 spirit, *must* *not* be enabled). Regards Francis.Dupont@enst-bretagne.fr PS: from RFC 2462 (end of page 9, section 4 Protocol overview): For safety, all addresses must be tested for uniqueness prior to their assignment to an interface. In the case of addresses created through stateless autoconfig, however, the uniqueness of an address is determined primarily by the portion of the address formed from an interface identifier. Thus, if a node has already verified the uniqueness of a link-local address, additional addresses created from the same interface identifier need not be tested individually. In contrast, all addresses obtained manually or via stateful address autoconfiguration should be tested for uniqueness individually. To accommodate sites that believe the overhead of performing Duplicate Address Detection outweighs its benefits, the use of Duplicate Address Detection can be disabled through the administrative setting of a per-interface configuration flag. From owner-mobile-ip@sunroof.eng.sun.com Tue May 21 11:04:15 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13602 for ; Tue, 21 May 2002 11:04:15 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05475; Tue, 21 May 2002 08:02:28 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01807; Tue, 21 May 2002 08:02:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LF1IrP028903 for ; Tue, 21 May 2002 08:01:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4LF1H1I028902 for mobile-ip-dist; Tue, 21 May 2002 08:01:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LF1DrP028895 for ; Tue, 21 May 2002 08:01:14 -0700 (PDT) Received: from lillen ([192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4LF18g02777; Tue, 21 May 2002 17:01:09 +0200 (MEST) Date: Tue, 21 May 2002 17:00:10 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Issue #23 and Issue #30 To: Vijay Devarapalli Cc: Vladislav Yasevich , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3CE97B21.EEA96B23@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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > use of privacy extensions for the home address? I thought privacy > extensions would be used for the CoA. you want to hide your current > location, not the reachable address, right? the MN wont be reachable > if it keeps changing its HoA often. Using RFC 3041 temporary addresses for the CoA doesn't really hide the location - you could still easily see which ISP the CoA is delegated to. I could imagine MNs that want to use RFC 3041 home addresses for communication they originate where the MN wants more anonymity, while the MN retains a stable home address at which it can be contacted. Erik From owner-mobile-ip@sunroof.eng.sun.com Tue May 21 11:45:08 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15252 for ; Tue, 21 May 2002 11:45:07 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26462; Tue, 21 May 2002 08:43:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18856; Tue, 21 May 2002 08:43:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LFgIrP029031 for ; Tue, 21 May 2002 08:42:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4LFgIrC029030 for mobile-ip-dist; Tue, 21 May 2002 08:42:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LFgErP029023 for ; Tue, 21 May 2002 08:42:15 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24977 for ; Tue, 21 May 2002 08:42:19 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02535 for ; Tue, 21 May 2002 08:42:18 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4LFgE0E008621 for ; Tue, 21 May 2002 17:42:17 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue May 21 17:42:13 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 17:31:13 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0639@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark'" , Vijay Devarapalli Cc: Vladislav Yasevich , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Issue #23 and Issue #30 Date: Tue, 21 May 2002 17:42:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Using RFC 3041 temporary addresses for the CoA doesn't > really hide the > location - you could still easily see which ISP the CoA is > delegated to. > > I could imagine MNs that want to use RFC 3041 home > addresses for communication > they originate where the MN wants more anonymity, while the > MN retains > a stable home address at which it can be contacted. => I fully agree. We should not assume that the SA between the MN and the HA will be forever static. New security mechanisms can come out and allow the MN to configure a Home address dynamically, for privacy reasons. At least for the connections it initiates. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue May 21 12:22:31 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16992 for ; Tue, 21 May 2002 12:22:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20284; Tue, 21 May 2002 10:22:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09331; Tue, 21 May 2002 09:21:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LGKrrP029138 for ; Tue, 21 May 2002 09:20:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4LGKraf029137 for mobile-ip-dist; Tue, 21 May 2002 09:20:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LGKorP029130 for ; Tue, 21 May 2002 09:20:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06691 for ; Tue, 21 May 2002 09:20:54 -0700 (PDT) From: arvind.sevalkar@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19424 for ; Tue, 21 May 2002 10:20:53 -0600 (MDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002052121545222:1547 ; Tue, 21 May 2002 21:54:52 +0530 Subject: Re: [mobile-ip] issue #25 To: Vijay Devarapalli Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Tue, 21 May 2002 21:50:11 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/21/2002 09:51:15 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/21/2002 09:54:52 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/21/2002 09:54:55 PM, Serialize complete at 05/21/2002 09:54:55 PM Message-ID: X-Priority: 3 (Normal) Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Vijay Devarapalli To: arvind.sevalkar@lntinfotech.com Sent by: cc: mobile-ip@sunroof.eng.sun.com owner-mobile-ip@sunroof.e Subject: Re: [mobile-ip] issue #25 ng.sun.com 05/21/2002 04:17 AM arvind.sevalkar@lntinfotech.com wrote: > Vijay > > I think this will not work. > Let's consider MN is in the foreign network it sends BU for the first time > to CN and that fails, then in this case, CN don't have binding Cache entry > so while sending BA, CN can not add routing header. But u said always > include the routing header while sending BA even if the BU fails. How can > this is possible in this case ? if you have BU processing in the kernel, you dont have a problem. you still have access to the packet. or stored locally in some cache. another way of doing it would be to have a dummy binding cache entry with a failed status. there are other ways. it is really implementation specific. binding cache is a conceptual data structure. you can use it however you want. regards Vijay ==>> Please consider the following ..... Arvind => special code to handle the special case. ----> But is it really necessary to send Binding Acknowledgement with routing header when there is no binding in cache. Because routing header is included when there is an entry in the binding cache some implementation checks routing header for binding in binding cache. We can simply do one thing when there is a binding in the Binding cache then we will send BA with routing header and when there is no Binding in the Binding cache then we will send BA to the Home address without routing header. So BA will be sent to HA without RH header in two cases. 1>BU successful and which is for deleting Binding cache entry. 2>BU failed and there is no entry in Binding cache, in case when first time MN sends BU to CN and that fails. From owner-mobile-ip@sunroof.eng.sun.com Tue May 21 12:40:24 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18299 for ; Tue, 21 May 2002 12:40:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07955; Tue, 21 May 2002 10:40:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18050; Tue, 21 May 2002 09:39:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LGcvrP029218 for ; Tue, 21 May 2002 09:38:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4LGcunD029217 for mobile-ip-dist; Tue, 21 May 2002 09:38:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LGcrrP029210 for ; Tue, 21 May 2002 09:38:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17330 for ; Tue, 21 May 2002 09:38:58 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02438; Tue, 21 May 2002 10:38:51 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4LGcmn27931; Tue, 21 May 2002 18:38:48 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA19464; Tue, 21 May 2002 18:38:48 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4LGclT12621; Tue, 21 May 2002 18:38:47 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205211638.g4LGclT12621@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Vijay Devarapalli , Vladislav Yasevich , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Tue, 21 May 2002 17:00:10 +0200. Date: Tue, 21 May 2002 18:38:47 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > use of privacy extensions for the home address? I thought privacy > extensions would be used for the CoA. you want to hide your current > location, not the reachable address, right? the MN wont be reachable > if it keeps changing its HoA often. Using RFC 3041 temporary addresses for the CoA doesn't really hide the location - you could still easily see which ISP the CoA is delegated to. => I agree but the idea is to change the interface ID (using for instance the RFC 3041) at the same time to move to another link breaks the continuity of care-of addresses and provides a kind of privacy. I could imagine MNs that want to use RFC 3041 home addresses for communication they originate where the MN wants more anonymity, while the MN retains a stable home address at which it can be contacted. => this is a transparent (to mobility) use of RFC 3041. Regards Francis.Dupont@enst-bretagne.fr PS: this discussion should be on the ipv6 WG list (with comments about my I-D "RFC 3041 Considered Harmful" (draft-dupont-ipv6-rfc3041harmful-00.txt). From owner-mobile-ip@sunroof.eng.sun.com Tue May 21 18:13:35 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03499 for ; Tue, 21 May 2002 18:13:35 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08825; Tue, 21 May 2002 16:14:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27634; Tue, 21 May 2002 15:13:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LMCMrP029942 for ; Tue, 21 May 2002 15:12:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4LMCMWt029941 for mobile-ip-dist; Tue, 21 May 2002 15:12:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4LMCJrP029934 for ; Tue, 21 May 2002 15:12:19 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4LMCM93199877; Tue, 21 May 2002 15:12:23 -0700 (PDT) Message-Id: <200205212212.g4LMCM93199877@jurassic.eng.sun.com> Date: Tue, 21 May 2002 15:14:48 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: RE: [mobile-ip] Unresolved issue #22: SHOULD or MUST for CN RO? To: hesham.soliman@era.ericsson.se Cc: jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iledJl/jBPu/A44MuOOz1w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > > > Samita Chakrabarti comments on this: "IMHO, SHOULD is quite weak > > statement. The whole point of doing route optimization is to save > > round-trip time. Now that we are solving the security > > issues, I think > > route optimization is the feature that a CN (a CN could be > > a MN) must > > implement. But obviously there SHOULD be a knob on MN side > > to turn it > > off and on. > > > > Without RO, the roundtrip time now is even longer through the > > reverse tunnel. Route optimization should be "MUST" for CN, IMHO." > > => I was going to ask, why is this coming up now and > was ok as a SHOULD before, then I saw the last line. > IMHO, this is not a justification for mandating RO. > Yes reverse tunnelling through the HA would cause > additional RTT for CNs outside the MN's home > network, but does it really make a difference > when compared to triangular routing. At least > for most communication scenarios today I can't > see any benefits (in terms of delays) for asymmetric > triangular routing, compared to symmetric rectangular > routing. Would love to hear some explanation from someone > for why there is a significant difference. > BTW, I was comparing RTT of using reverse tunnel vs. route optimization, in case it was not clear. > RO for all sounds nice, but I don't see why it is > more important now than before. > Actually, we are trying to decide on two things. I have discussed this with Jari and Erik. Previously, there was no clarification on the draft that all CNs supporting MIPv6 draft MUST support route optimization. I think, this is quite natural conclusion, otherwise, there is no meaning of providing MIPv6 correspondent node functionality in the base draft. So, I was requesting that there should be a section on "Correspondent Node Behaviour" in the next revision of the draft, which clarifies the RR procedure and binding update requirement for all correspondent nodes supporting MIPv6 base draft. The second thing is whether all ipv6 nodes SHOULD/MUST support the 'Correspondent node behavior' defined MIPv6 draft. > > > Question: Is the text right? Should the keywords be MUST? > > => If it should be a MUST then I don't think it should be > done based on the text above, it would be good to know > if there is anything new that would give a significant > reason for making it a MUST. > Of course the WG can also just have a change of heart > and thing that RO is important anyway and should have > always been a MUST. In future, if we believe all mobile nodes will run IPv6 and use MIPv6 as the mobility protocol, then it makes much sense to make MIPv6 CN functionality mandatory for all ipv6 nodes. If we define the requirement in mobileip and ipng working group, then that requirement can be used for IPv6 node requirements as well. -Samita From owner-mobile-ip@sunroof.eng.sun.com Tue May 21 20:32:37 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07498 for ; Tue, 21 May 2002 20:32:37 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18464; Tue, 21 May 2002 17:30:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26255; Tue, 21 May 2002 17:30:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4M0TjrP000152 for ; Tue, 21 May 2002 17:29:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4M0TjHU000151 for mobile-ip-dist; Tue, 21 May 2002 17:29:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4M0TgrP000144 for ; Tue, 21 May 2002 17:29:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA07548 for ; Tue, 21 May 2002 17:29:46 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA17952 for ; Tue, 21 May 2002 17:29:45 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA20407; Tue, 21 May 2002 17:29:45 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4M0ThJ19063; Tue, 21 May 2002 17:29:43 -0700 X-mProtect: <200205220029> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXlDpTr; Tue, 21 May 2002 17:29:42 PDT Message-ID: <3CEAE676.2CB98A1C@iprg.nokia.com> Date: Tue, 21 May 2002 17:29:42 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205210924.g4L9O5T10322@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Francis, Francis Dupont wrote: > => which source address the MN should use to send the deregistration > message? the global unicast home address. the deregistration BU is unicast to the HA. this works. > => no, RFC 2462 describes a mechanism and an optional optimization. > I simply propose(d) to keep the mechanism as it is and to forbid the > optimization. it is not for MIPv6 to forbid this optimization. the safe thing to do would be for the HA to defend the MN's link local address also. > => I have no trouble with the second statement. IMHO the optional optimization > is a bad idea and should remove from RFC 2462 (bis or before). I believe > most IPv6 implementors share my opinion, for instance the KAME team has > removed the optimization from its code (ask them why). you can include me among the people who share this opinion. but you still have a problem. there could always be an IPv6 implementation which uses this optimization. > => as soon as an address can be formed in an other way than stateless > autoconf (and this is the case with a HA on the link) the optimization why do you say if a HA exists on a link, stateful address configuration would be used? Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue May 21 20:33:36 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07535 for ; Tue, 21 May 2002 20:33:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22740; Tue, 21 May 2002 17:31:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA26662; Tue, 21 May 2002 17:31:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4M0V9rP000179 for ; Tue, 21 May 2002 17:31:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4M0V8A3000178 for mobile-ip-dist; Tue, 21 May 2002 17:31:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4M0V4rP000166 for ; Tue, 21 May 2002 17:31:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA08022 for ; Tue, 21 May 2002 17:31:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA10182 for ; Tue, 21 May 2002 18:31:07 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA20442; Tue, 21 May 2002 17:31:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4M0V5T19776; Tue, 21 May 2002 17:31:05 -0700 X-mProtect: <200205220031> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdulnsTE; Tue, 21 May 2002 17:31:04 PDT Message-ID: <3CEAE6C8.56DEF19C@iprg.nokia.com> Date: Tue, 21 May 2002 17:31:04 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Vladislav Yasevich , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > I could imagine MNs that want to use RFC 3041 home addresses for communication > they originate where the MN wants more anonymity, while the MN retains > a stable home address at which it can be contacted. okay. I guess thats possible.... I hadnt considered this. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 04:50:11 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17730 for ; Wed, 22 May 2002 04:50:11 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09665; Wed, 22 May 2002 02:50:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21953; Wed, 22 May 2002 01:49:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4M8msrP000957 for ; Wed, 22 May 2002 01:48:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4M8mrN2000956 for mobile-ip-dist; Wed, 22 May 2002 01:48:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4M8morP000949 for ; Wed, 22 May 2002 01:48:50 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02217 for ; Wed, 22 May 2002 01:48:56 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA09183 for ; Wed, 22 May 2002 02:48:55 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4M8mJn04335; Wed, 22 May 2002 10:48:19 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA27758; Wed, 22 May 2002 10:48:19 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4M8mIT15108; Wed, 22 May 2002 10:48:18 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Tue, 21 May 2002 17:29:42 PDT. <3CEAE676.2CB98A1C@iprg.nokia.com> Date: Wed, 22 May 2002 10:48:18 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => which source address the MN should use to send the deregistration > message? the global unicast home address. => this address is always protected by the HA: it is the worst choice. the deregistration BU is unicast to the HA. this works. => with an old draft or with my proposal: - the MN has just been attached to the home link - it builds its link-local address and performs DAD for it - (perhaps in parallel) its sends a RtSol to get prefixes and a default router - it gets a RtAdv from any routers on the home link (by application of the Murphy's law, the first router to answer is never the HA). - it finds a home prefix in the RtAdv and discovers it is at home - it builds its addresses from the prefixes: * if it performs DAD, it fails for the home address * if it doesn't perform DAD (it was the case when I try 4 years ago), see after - it tries to send a BU to the HA - as the HA address is not in the neighbor cache it sends a NbSol with: * the home address as the source * the solicited-node multicast of the HA address as the destination * the HA address at the target - the HA receives the NbSol and does a stupid thing with it, in my case it sends a NbAdv to the previous care-of address of the MN with a RH. - the MN retries - the MN retries ... Conclusion: it does not work. My fix was simple: I modify the code to always send the BU from the link-local address. It always works until someone has the bad idea to use S=0 or a previous equivalent. > => no, RFC 2462 describes a mechanism and an optional optimization. > I simply propose(d) to keep the mechanism as it is and to forbid the > optimization. it is not for MIPv6 to forbid this optimization. the safe thing to do would be for the HA to defend the MN's link local address also. => but this doesn't work... > => I have no trouble with the second statement. IMHO the optional optimization > is a bad idea and should remove from RFC 2462 (bis or before). I believe > most IPv6 implementors share my opinion, for instance the KAME team has > removed the optimization from its code (ask them why). you can include me among the people who share this opinion. but you still have a problem. there could always be an IPv6 implementation which uses this optimization. => could => must not > => as soon as an address can be formed in an other way than stateless > autoconf (and this is the case with a HA on the link) the optimization why do you say if a HA exists on a link, stateful address configuration would be used? => no, what I said is mobility in the HA is not using stateless autoconf or even a stateless autoconf like mechanism. Mobility in the HA with S=1 and D=1 is very like manual configuration. I don't believe in DHCPv6: the highly tuned mechanisms to allocate addresses as a rare resource are not so well suited for IPv6 where there are 2^64 available addresses per link... Regards Francis.Dupont@enst-bretagne.fr PS: I propose again: - use RFC 2462 without the link-local optimization of DAD on the home link - engrave the value 1 for the S bit - ask the IPv6 WG to remove the link-local optimization in 2462bis From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 06:04:27 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19787 for ; Wed, 22 May 2002 06:04:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08730; Wed, 22 May 2002 04:04:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA17175; Wed, 22 May 2002 03:04:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MA3HrP001097 for ; Wed, 22 May 2002 03:03:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MA3HNA001096 for mobile-ip-dist; Wed, 22 May 2002 03:03:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MA3ErP001089 for ; Wed, 22 May 2002 03:03:14 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23301 for ; Wed, 22 May 2002 03:03:19 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08291 for ; Wed, 22 May 2002 04:03:14 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MA3Ds7008401 for ; Wed, 22 May 2002 12:03:13 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed May 22 12:02:59 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 11:51:57 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF05380457D55C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: James Kempf , Phil Roberts , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Wed, 22 May 2002 12:02:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, Since I disagree with the 'architecture' argument, I have to comment on this. > The GFA constitutes a routing proxy. RFC 3238 gives architectural > considerations for defining services on application > proxies, but many of > the considerations involved in introducing fate-sharing between the > application proxies and end hosts are difficult to envision for a > routing proxy. => So assuming we agree on the 'proxy' part, why is it architecturally different from application proxies? that is, given the impacts on a particular application. > > One argument I have heard in favor is that the Home Agent functions > essentially as a routing proxy, so why is introducing a > routing proxy in > the foreign network any different? The answer is that the > Home Agent is > architecturally necessary to achieve the separation between node > identifier and routing identifier, while the GFA is just a > performance > enhancement. => Disagree with the role of the HA. The HA is needed to allow MNs to be reachable. That's all it's needed for. It doesn't separate the locator and identifier because they are both represented by the home address. Architecturally, that may not be a clean thing to do but currently there is no other scalable way of providing reachability. Also, regardless of why it's needed, it's already there. We already have a precedence. BTW, this raises the issue of HA redundancy. We need to address that at some stage. While there are other ways of achieving the > node/routing > identifier separation, they all have more serious problems > architecturally and practically than the Home Agent. With > the GFA, there > are other ways to achieve the same performance enhancement, > and these > are not difficult to implement and probably not particularly more > difficult to deploy, since they are based on enhanced edge routing. > Their reliability characterstics essentially match those of > the access > routers. => Like ? Any existig standard? I would also like to add a note, for the WG in general, not only to James. Can we _pleeeease_ have some consistency in the way we assess proposals. Let's consider the RFC being referenced here (1958). Doesn't the quote used by Phil state that the intelligence should be in the end hosts? So why are we accepting proposals that do not follow these principals? Yes I'm referring to both FMIPv4 and FMIPv6, and I have contributed heavily to both drafts, so no bias here ;) I don't understand why certain actions are taken towards some proposals and not others. Why was their a big LMM requirements doc done for one WG document and not for reg reg in MIPv4? All these things need to be considered. Using a separate process to handle each proposal is not only confusing, but will likely lead to no direction for this WG's output. Please follow one process! Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 07:56:59 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25058 for ; Wed, 22 May 2002 07:56:58 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29356; Wed, 22 May 2002 05:57:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA16788; Wed, 22 May 2002 04:56:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MBtprP001549 for ; Wed, 22 May 2002 04:55:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MBtp1S001548 for mobile-ip-dist; Wed, 22 May 2002 04:55:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MBtmrP001541 for ; Wed, 22 May 2002 04:55:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA16604 for ; Wed, 22 May 2002 04:55:54 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25400 for ; Wed, 22 May 2002 04:55:51 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MBto0E017367 for ; Wed, 22 May 2002 13:55:50 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed May 22 13:55:38 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 13:44:37 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F064B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , Vijay Devarapalli Cc: jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Issue #23 and Issue #30 Date: Wed, 22 May 2002 13:55:08 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Francis, I might be missing something, but I'm not sure that your steps below will work. > > => which source address the MN should use to send the > deregistration > > message? > > the global unicast home address. > > => this address is always protected by the HA: it is the > worst choice. > > the deregistration BU is unicast to the HA. this works. > > => with an old draft or with my proposal: > - the MN has just been attached to the home link > - it builds its link-local address and performs DAD for it > - (perhaps in parallel) its sends a RtSol to get prefixes and > a default router > - it gets a RtAdv from any routers on the home link (by application > of the Murphy's law, the first router to answer is never the HA). > - it finds a home prefix in the RtAdv and discovers it is at home > - it builds its addresses from the prefixes: > * if it performs DAD, it fails for the home address > * if it doesn't perform DAD (it was the case when I try > 4 years ago), > see after > - it tries to send a BU to the HA > - as the HA address is not in the neighbor cache it sends > a NbSol with: > * the home address as the source > * the solicited-node multicast of the HA address as the > destination > * the HA address at the target > - the HA receives the NbSol and does a stupid thing with it, > in my case it sends a NbAdv to the previous care-of > address of the MN > with a RH. > - the MN retries > - the MN retries > ... > > Conclusion: it does not work. My fix was simple: I modify the code > to always send the BU from the link-local address. It always works > until someone has the bad idea to use S=0 or a previous equivalent. => If the HA does not defend the MN's link-local address while it's away, how can you send a dereg if someone else took the MN's link-local address? Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 09:27:53 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00965 for ; Wed, 22 May 2002 09:27:52 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29850; Wed, 22 May 2002 07:27:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20250; Wed, 22 May 2002 06:27:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MDQUrP001883 for ; Wed, 22 May 2002 06:26:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MDQUuK001882 for mobile-ip-dist; Wed, 22 May 2002 06:26:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MDQQrP001875 for ; Wed, 22 May 2002 06:26:26 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05878 for ; Wed, 22 May 2002 06:26:33 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26332 for ; Wed, 22 May 2002 07:26:32 -0600 (MDT) Received: from mchandra-u10.cisco.com (mchandra-u10.cisco.com [64.102.48.252]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4MDQOPI025422; Wed, 22 May 2002 06:26:24 -0700 (PDT) Received: (mchandra@localhost) by mchandra-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA13924; Wed, 22 May 2002 09:26:23 -0400 (EDT) Date: Wed, 22 May 2002 09:26:23 -0400 From: "Madhavi W. Chandra" To: "Hesham Soliman (ERA)" Cc: James Kempf , Phil Roberts , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Message-ID: <20020522092623.A13909@cisco.com> References: <4DA6EA82906FD511BE2F00508BCF05380457D55C@Esealnt861.al.sw.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4DA6EA82906FD511BE2F00508BCF05380457D55C@Esealnt861.al.sw.ericsson.se>; from hesham.soliman@era.ericsson.se on Wed, May 22, 2002 at 12:02:56PM +0200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Hesham, On Wed, May 22, 2002 at 12:02:56PM +0200, Hesham Soliman (ERA) wrote: > James, > > Since I disagree with the 'architecture' argument, I have > to comment on this. > > > The GFA constitutes a routing proxy. RFC 3238 gives architectural > > considerations for defining services on application > > proxies, but many of > > the considerations involved in introducing fate-sharing between the > > application proxies and end hosts are difficult to envision for a > > routing proxy. > > => So assuming we agree on the 'proxy' part, why > is it architecturally different from application > proxies? that is, given the impacts on a particular > application. > > > > > One argument I have heard in favor is that the Home Agent functions > > essentially as a routing proxy, so why is introducing a > > routing proxy in > > the foreign network any different? The answer is that the > > Home Agent is > > architecturally necessary to achieve the separation between node > > identifier and routing identifier, while the GFA is just a > > performance > > enhancement. > > => Disagree with the role of the HA. The HA is needed > to allow MNs to be reachable. That's all it's > needed for. It doesn't separate the locator and identifier > because they are both represented by the home address. > Architecturally, that may not be a clean thing to do > but currently there is no other scalable way of > providing reachability. > > Also, regardless of why it's needed, it's already > there. We already have a precedence. BTW, this raises > the issue of HA redundancy. We need to address that > at some stage. Good point. We submitted a draft last year on HA Redundancy...which has expired. We will be revising and resubmitting soon. > While there are other ways of achieving the > > node/routing > > identifier separation, they all have more serious problems > > architecturally and practically than the Home Agent. With > > the GFA, there > > are other ways to achieve the same performance enhancement, > > and these > > are not difficult to implement and probably not particularly more > > difficult to deploy, since they are based on enhanced edge routing. > > Their reliability characterstics essentially match those of > > the access > > routers. > > => Like ? Any existig standard? > > I would also like to add a note, for the WG in general, > not only to James. Can we _pleeeease_ have some consistency > in the way we assess proposals. Let's consider the RFC being > referenced here (1958). Doesn't the quote used by Phil > state that the intelligence should be in the end hosts? > So why are we accepting proposals that do not follow > these principals? > Yes I'm referring to both FMIPv4 and FMIPv6, and I have > contributed heavily to both drafts, so no bias here ;) > > I don't understand why certain actions are taken towards > some proposals and not others. Why was their a big LMM > requirements doc done for one WG document and not > for reg reg in MIPv4? > All these things need to be considered. Using a separate > process to handle each proposal is not only confusing, > but will likely lead to no direction for this WG's output. Another good point. It would helpful to have a requirements document to compare the solutions...especially, given Alan's contributions in this arena. I haven't looked at the LMM draft lately, but perhaps we can 'extrapolate' from it for MIPv4. Thanks, Madhavi > Please follow one process! > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 09:46:55 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01793 for ; Wed, 22 May 2002 09:46:55 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14712; Wed, 22 May 2002 06:45:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09179; Wed, 22 May 2002 06:44:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MDhIrP001942 for ; Wed, 22 May 2002 06:43:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MDhI2N001941 for mobile-ip-dist; Wed, 22 May 2002 06:43:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MDhFrP001934 for ; Wed, 22 May 2002 06:43:15 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23138 for ; Wed, 22 May 2002 06:43:16 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17826 for ; Wed, 22 May 2002 07:43:58 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MDhEs7004600 for ; Wed, 22 May 2002 15:43:15 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed May 22 15:41:17 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 15:30:15 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0653@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Madhavi W. Chandra'" , "Hesham Soliman (ERA)" Cc: James Kempf , Phil Roberts , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Wed, 22 May 2002 15:41:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Mahdavi, > > Good point. We submitted a draft last year on > HA Redundancy...which has expired. We will be revising > and resubmitting soon. => I hope the WG can include this area in its charter. We need solutions for this. I tried to get some interest in Minneapolis last year but the MIPv6 security has taken all our efforts. > Another good point. It would helpful to have a requirements > document to compare the solutions...especially, given Alan's > contributions in this arena. I haven't looked at the LMM draft > lately, but perhaps we can 'extrapolate' from it for MIPv4. => Yes, I think you could getaway with replacing v6 with v4 in most cases! Hesham > > Thanks, > Madhavi > > > Please follow one process! > > > > Hesham > > From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 11:24:22 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09953 for ; Wed, 22 May 2002 11:24:21 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13958; Wed, 22 May 2002 08:22:34 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02805; Wed, 22 May 2002 08:22:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MFLPrP002189 for ; Wed, 22 May 2002 08:21:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MFLOgM002188 for mobile-ip-dist; Wed, 22 May 2002 08:21:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MFLLrP002181 for ; Wed, 22 May 2002 08:21:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15612 for ; Wed, 22 May 2002 08:21:27 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04899 for ; Wed, 22 May 2002 09:21:25 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA18298; Wed, 22 May 2002 08:21:23 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4MFLM721977; Wed, 22 May 2002 08:21:22 -0700 X-mProtect: <200205221521> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpaE19k; Wed, 22 May 2002 08:21:21 PDT Message-ID: <3CEBB771.F5AED5AB@iprg.nokia.com> Date: Wed, 22 May 2002 08:21:21 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IP Working Group CC: "Basavaraj Patil (NTC/Dallas)" , Phil Roberts Subject: [mobile-ip] Revised RFC3012bis Internet Draft availability Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, I have submitted a new revision of the rfc3012bis Internet Draft. You can get it at the following URL: http://people.nokia.net/charliep/txt/mobilechal/mip-chal.txt Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 11:28:59 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10760 for ; Wed, 22 May 2002 11:28:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14373; Wed, 22 May 2002 09:28:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04753; Wed, 22 May 2002 08:28:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MFRorP002273 for ; Wed, 22 May 2002 08:27:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MFRoF2002272 for mobile-ip-dist; Wed, 22 May 2002 08:27:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MFRlrP002265 for ; Wed, 22 May 2002 08:27:47 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17744 for ; Wed, 22 May 2002 08:27:53 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13752 for ; Wed, 22 May 2002 09:27:52 -0600 (MDT) Received: from fedex.cisco.com (IDENT:mirapoint@fedex.cisco.com [171.69.17.28]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4MFRYPI029236; Wed, 22 May 2002 08:27:34 -0700 (PDT) Received: from cisco.com (rtp-vpn2-342.cisco.com [10.82.241.86]) by fedex.cisco.com (Mirapoint) with ESMTP id ABV88782; Wed, 22 May 2002 08:25:01 -0700 (PDT) Message-ID: <3CEBBB68.3077B4C3@cisco.com> Date: Wed, 22 May 2002 08:38:16 -0700 From: Milind Kulkarni X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: James Kempf , Phil Roberts , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 References: <4DA6EA82906FD511BE2F00508BCF05380457D55C@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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit "Hesham Soliman (ERA)" wrote: > > I don't understand why certain actions are taken towards > some proposals and not others. Why was their a big LMM > requirements doc done for one WG document and not > for reg reg in MIPv4? > All these things need to be considered. Using a separate > process to handle each proposal is not only confusing, > but will likely lead to no direction for this WG's output. > > Please follow one process! Couldn't agree with Hesham more! Some proposals need problem statement and/or requirement doc, while some proposals don't need any of that. It is not only confusing but may also give an impression that things are not equal. I hope the WG addresses this confusion. Please elaborate and follow one process. Thanks, Milind > > Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 11:31:47 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11207 for ; Wed, 22 May 2002 11:31:46 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA25413; Wed, 22 May 2002 09:32:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05811; Wed, 22 May 2002 08:31:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MFUVrP002299 for ; Wed, 22 May 2002 08:30:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MFUVfh002298 for mobile-ip-dist; Wed, 22 May 2002 08:30:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MFUSrP002291 for ; Wed, 22 May 2002 08:30:28 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18618 for ; Wed, 22 May 2002 08:30:34 -0700 (PDT) From: Basavaraj.Patil@nokia.com 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 JAA15695 for ; Wed, 22 May 2002 09:30:34 -0600 (MDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g4MFXYx09071 for ; Wed, 22 May 2002 10:33:34 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 22 May 2002 10:30:27 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 22 May 2002 10:29:08 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] WG Last call - RFC3012bis X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 22 May 2002 10:29:08 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A12DD5@daebe007.NOE.Nokia.com> Thread-Topic: WG Last call - RFC3012bis Thread-Index: AcIBpWr25ifgdW2JEdax1wAAhj/HZA== To: X-OriginalArrivalTime: 22 May 2002 15:29:08.0992 (UTC) FILETIME=[6AA05800:01C201A5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4MFUSrP002292 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, This is a WG last call for: Mobile IPv4 Challenge/Response Extensions draft-ietf-mobileip-rfc3012bis-03.txt The draft will be available in the regular registries shortly, but in the meanwhile it is available at: http://people.nokia.net/charliep/txt/mobilechal/mip-chal.txt This draft is a standards track WG document. Please send in your comments by June 3rd, 2002 to the authors or to the WG discussion list. -Basavaraj From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 12:04:57 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14774 for ; Wed, 22 May 2002 12:04:56 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08843; Wed, 22 May 2002 10:04:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02573; Wed, 22 May 2002 09:04:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MG3JrP002531 for ; Wed, 22 May 2002 09:03:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MG3Jcf002530 for mobile-ip-dist; Wed, 22 May 2002 09:03:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MG3FrP002523 for ; Wed, 22 May 2002 09:03:16 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03179 for ; Wed, 22 May 2002 09:03:22 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15635 for ; Wed, 22 May 2002 09:03:22 -0700 (PDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g4MG35x17439; Wed, 22 May 2002 11:03:05 -0500 (CDT) Message-ID: <3CEBC14F.5060406@alcatel.com> Date: Wed, 22 May 2002 11:03:27 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Milind Kulkarni CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 References: <4DA6EA82906FD511BE2F00508BCF05380457D55C@Esealnt861.al.sw.ericsson.se> <3CEBBB68.3077B4C3@cisco.com> Content-Type: multipart/alternative; boundary="------------020708090403030905070401" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --------------020708090403030905070401 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Can we read this as an endorsement of http://ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-05.txt? Regards, Milind Kulkarni wrote: >"Hesham Soliman (ERA)" wrote: > >>I don't understand why certain actions are taken towards >>some proposals and not others. Why was their a big LMM >>requirements doc done for one WG document and not >>for reg reg in MIPv4? >>All these things need to be considered. Using a separate >>process to handle each proposal is not only confusing, >>but will likely lead to no direction for this WG's output. >> >>Please follow one process! >> > >Couldn't agree with Hesham more! Some proposals need problem >statement and/or requirement doc, while some proposals don't >need any of that. It is not only confusing but may also give an >impression that things are not equal. I hope the WG addresses >this confusion. Please elaborate and follow one process. > >Thanks, >Milind > >>Hesham >> -- Behcet --------------020708090403030905070401 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Can we read this as an endorsement of
http://ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-05.txt?

Regards,

Milind Kulkarni wrote:
"Hesham Soliman (ERA)" wrote:
I don't understand why certain actions are taken towards
some proposals and not others. Why was their a big LMM
requirements doc done for one WG document and not
for reg reg in MIPv4?
All these things need to be considered. Using a separate
process to handle each proposal is not only confusing,
but will likely lead to no direction for this WG's output.

Please follow one process!

Couldn't agree with Hesham more! Some proposals need problem 
statement and/or requirement doc, while some proposals don't 
need any of that. It is not only confusing but may also give an 
impression that things are not equal. I hope the WG addresses 
this confusion. Please elaborate and follow one process.

Thanks,
Milind

Hesham

-- 
Behcet

--------------020708090403030905070401-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 13:03:49 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19219 for ; Wed, 22 May 2002 13:03:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22797; Wed, 22 May 2002 10:01:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09107; Wed, 22 May 2002 10:01:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MH06rP002842 for ; Wed, 22 May 2002 10:00:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MH06Wc002841 for mobile-ip-dist; Wed, 22 May 2002 10:00:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MH02rP002834 for ; Wed, 22 May 2002 10:00:02 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28734 for ; Wed, 22 May 2002 10:00:09 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18532 for ; Wed, 22 May 2002 10:00:05 -0700 (PDT) Message-ID: <000801c201b1$da72c8f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "Phil Roberts" , References: <4DA6EA82906FD511BE2F00508BCF05380457D55C@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Wed, 22 May 2002 09:07:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > => So assuming we agree on the 'proxy' part, why > is it architecturally different from application > proxies? that is, given the impacts on a particular > application. > It is different because if an application proxy fails, there is still the possibilty for the two hosts to continue their session since a route will exist between the two, perhaps minus the services provided by the proxy. If a routing proxy fails, the session is terminated. > => Disagree with the role of the HA. The HA is needed > to allow MNs to be reachable. That's all it's > needed for. It doesn't separate the locator and identifier > because they are both represented by the home address. > Architecturally, that may not be a clean thing to do > but currently there is no other scalable way of > providing reachability. > There is still a routing function attached to the home address to get the first packets to the host. But particularly in MIPv6, that function is reduced by route optimization, where the home address is not used for routing until after the first few packets. It is a typical engineering compromise. > Also, regardless of why it's needed, it's already > there. We already have a precedence. BTW, this raises > the issue of HA redundancy. We need to address that > at some stage. > Agree. though I am not sure whether a standard in this area is warrented. > While there are other ways of achieving the > > node/routing > > identifier separation, they all have more serious problems > > architecturally and practically than the Home Agent. With > > the GFA, there > > are other ways to achieve the same performance enhancement, > > and these > > are not difficult to implement and probably not particularly more > > difficult to deploy, since they are based on enhanced edge routing. > > Their reliability characterstics essentially match those of > > the access > > routers. > > => Like ? Any existig standard? > A draft is being prepared on the topic. > I would also like to add a note, for the WG in general, > not only to James. Can we _pleeeease_ have some consistency > in the way we assess proposals. Let's consider the RFC being > referenced here (1958). Doesn't the quote used by Phil > state that the intelligence should be in the end hosts? > So why are we accepting proposals that do not follow > these principals? > Yes I'm referring to both FMIPv4 and FMIPv6, and I have > contributed heavily to both drafts, so no bias here ;) > I do not intend to get into a debate here about whether modifications of network routing protocols or using MIP's host based routing is the right way to do fast handover. I believe the data we and others are collecting about what works will speak for itself. > I don't understand why certain actions are taken towards > some proposals and not others. Why was their a big LMM > requirements doc done for one WG document and not > for reg reg in MIPv4? > All these things need to be considered. Using a separate > process to handle each proposal is not only confusing, > but will likely lead to no direction for this WG's output. > > Please follow one process! > Could not agree with you more here, Hesham. jak From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 13:17:52 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20082 for ; Wed, 22 May 2002 13:17:52 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24812; Wed, 22 May 2002 11:17:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15977; Wed, 22 May 2002 10:17:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MHG0rP002909 for ; Wed, 22 May 2002 10:16:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MHG0Pc002908 for mobile-ip-dist; Wed, 22 May 2002 10:16:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MHFtrP002901 for ; Wed, 22 May 2002 10:15:55 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15339 for ; Wed, 22 May 2002 10:15:59 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26231 for ; Wed, 22 May 2002 11:15:58 -0600 (MDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4MHFvs7018357 for ; Wed, 22 May 2002 19:15:57 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Wed May 22 19:15:57 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4QLM9>; Wed, 22 May 2002 19:15:57 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0667@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , "Hesham Soliman (ERA)" , Phil Roberts , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Wed, 22 May 2002 19:15:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > => So assuming we agree on the 'proxy' part, why > > is it architecturally different from application > > proxies? that is, given the impacts on a particular > > application. > > > > It is different because if an application proxy fails, > there is still > the possibilty for the two hosts to continue their session > since a route > will exist between the two, perhaps minus the services > provided by the > proxy. If a routing proxy fails, the session is terminated. => Sure, but where do you draw the line? And what if a single node has 10 application proxies? What if there were no other applications that the two nodes could use? There is no clear line to draw here. > > I would also like to add a note, for the WG in general, > > not only to James. Can we _pleeeease_ have some consistency > > in the way we assess proposals. Let's consider the RFC being > > referenced here (1958). Doesn't the quote used by Phil > > state that the intelligence should be in the end hosts? > > So why are we accepting proposals that do not follow > > these principals? > > Yes I'm referring to both FMIPv4 and FMIPv6, and I have > > contributed heavily to both drafts, so no bias here ;) > > > > I do not intend to get into a debate here about whether > modifications of > network routing protocols or using MIP's host based routing > is the right > way to do fast handover. I believe the data we and others > are collecting > about what works will speak for itself. => I'm not trying to start the debate, but the point is,RFC 1958 is being quoted, so either we use that quote for all the WG docs ( can of worms) or we don't quote it. I'm happy with either option. Again where do we draw the line between allegedly breaking the architecture of the Internet and performance gain. How much performance gain is the Internet architecture worth ? :) :) Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 16:19:34 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28853 for ; Wed, 22 May 2002 16:19:34 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19509; Wed, 22 May 2002 14:19:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10336; Wed, 22 May 2002 13:19:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MKI0rP003905 for ; Wed, 22 May 2002 13:18:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MKHv5V003904 for mobile-ip-dist; Wed, 22 May 2002 13:17:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MKHsrP003897 for ; Wed, 22 May 2002 13:17:54 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04181 for ; Wed, 22 May 2002 13:18:01 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18330 for ; Wed, 22 May 2002 14:18:00 -0600 (MDT) Message-ID: <008d01c201cd$82239a50$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "Phil Roberts" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0667@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Wed, 22 May 2002 13:16:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > => Sure, but where do you draw the line? And what if > a single node has 10 application proxies? What if > there were no other applications that the two nodes > could use? > There is no clear line to draw here. > The line is drawn where the failure of a network element causes the session between the two hosts to fail. > => I'm not trying to start the debate, but the point > is,RFC 1958 is being quoted, so either we use that > quote for all the WG docs ( can of worms) or we > don't quote it. I'm happy with either option. > > Again where do we draw the line between allegedly > breaking the architecture of the Internet and > performance gain. How much performance gain is > the Internet architecture worth ? :) :) > Like I said, I am not going to debate the issue here. Open a separate thread on the topic if you want to debate. jak From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 18:06:20 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04314 for ; Wed, 22 May 2002 18:06:20 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15561; Wed, 22 May 2002 15:04:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17676; Wed, 22 May 2002 15:04:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MM3brP004148 for ; Wed, 22 May 2002 15:03:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MM3bND004147 for mobile-ip-dist; Wed, 22 May 2002 15:03:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MM3XrP004140 for ; Wed, 22 May 2002 15:03:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22053 for ; Wed, 22 May 2002 15:03:40 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13761 for ; Wed, 22 May 2002 15:03:39 -0700 (PDT) Received: from mkulkarn-u10.cisco.com (mkulkarn-u10.cisco.com [128.107.162.246]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4MM3dHs021320; Wed, 22 May 2002 15:03:39 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by mkulkarn-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA03158; Wed, 22 May 2002 15:03:39 -0700 (PDT) Message-ID: <3CEC15BA.11717EED@cisco.com> Date: Wed, 22 May 2002 15:03:38 -0700 From: Milind Kulkarni X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Behcet Sarikaya CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 References: <4DA6EA82906FD511BE2F00508BCF05380457D55C@Esealnt861.al.sw.ericsson.se> <3CEBBB68.3077B4C3@cisco.com> <3CEBC14F.5060406@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Apples and oranges Behcet! How did you conclude that it's an endorsement? It's completely irrelevant and laughable comment to the present discussion. I would like to stick to the issue at hand: the need to outline and follow uniform process for all proposals. I sincerely hope the WG and chairs address that. Thanks, Milind Behcet Sarikaya wrote: > > Can we read this as an endorsement of > http://ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-05.txt? > > Regards, > > Milind Kulkarni wrote: > > > "Hesham Soliman (ERA)" wrote: > > > >> I don't understand why certain actions are taken towards > >> some proposals and not others. Why was their a big LMM > >> requirements doc done for one WG document and not > >> for reg reg in MIPv4? > >> All these things need to be considered. Using a separate > >> process to handle each proposal is not only confusing, > >> but will likely lead to no direction for this WG's output. > >> Please follow one process! > >> > > Couldn't agree with Hesham more! Some proposals need problem > > statement and/or requirement doc, while some proposals don't > > need any of that. It is not only confusing but may also give an > > impression that things are not equal. I hope the WG addresses > > this confusion. Please elaborate and follow one process. > > Thanks, > > Milind > > > >> Hesham > >> > > -- > Behcet From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 18:22:50 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05072 for ; Wed, 22 May 2002 18:22:49 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA23313; Wed, 22 May 2002 15:21:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24691; Wed, 22 May 2002 15:20:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MMJkrP004246 for ; Wed, 22 May 2002 15:19:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MMJk2L004245 for mobile-ip-dist; Wed, 22 May 2002 15:19:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MMJhrP004238 for ; Wed, 22 May 2002 15:19:43 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00617 for ; Wed, 22 May 2002 15:19:49 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11857 for ; Wed, 22 May 2002 16:19:48 -0600 (MDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g4MMJf425513; Wed, 22 May 2002 17:19:41 -0500 (CDT) Message-ID: <3CEC1994.5020202@alcatel.com> Date: Wed, 22 May 2002 17:20:04 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Milind Kulkarni CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 References: <4DA6EA82906FD511BE2F00508BCF05380457D55C@Esealnt861.al.sw.ericsson.se> <3CEBBB68.3077B4C3@cisco.com> <3CEBC14F.5060406@alcatel.com> <3CEC15BA.11717EED@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I resent the language you used. If your answer is no simply say it. I know the history of events around these two drafts mipv4 regreg and mipv6 regreg, that was the reason why I had asked. Milind Kulkarni wrote: >Apples and oranges Behcet! How did you conclude that >it's an endorsement? It's completely irrelevant and >laughable comment to the present discussion. > >I would like to stick to the issue at hand: the need >to outline and follow uniform process for all proposals. >I sincerely hope the WG and chairs address that. > >Thanks, >Milind > >Behcet Sarikaya wrote: > >>Can we read this as an endorsement of >>http://ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-05.txt? >> >>Regards, >> >>Milind Kulkarni wrote: >> >>>"Hesham Soliman (ERA)" wrote: >>> >>>>I don't understand why certain actions are taken towards >>>>some proposals and not others. Why was their a big LMM >>>>requirements doc done for one WG document and not >>>>for reg reg in MIPv4? >>>>All these things need to be considered. Using a separate >>>>process to handle each proposal is not only confusing, >>>>but will likely lead to no direction for this WG's output. >>>>Please follow one process! >>>> >>>Couldn't agree with Hesham more! Some proposals need problem >>>statement and/or requirement doc, while some proposals don't >>>need any of that. It is not only confusing but may also give an >>>impression that things are not equal. I hope the WG addresses >>>this confusion. Please elaborate and follow one process. >>>Thanks, >>>Milind >>> >>>>Hesham >>>> >>-- >>Behcet >> From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 18:28:44 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05294 for ; Wed, 22 May 2002 18:28:44 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05975; Wed, 22 May 2002 16:29:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27341; Wed, 22 May 2002 15:28:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MMRjrP004298 for ; Wed, 22 May 2002 15:27:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MMRjum004297 for mobile-ip-dist; Wed, 22 May 2002 15:27:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MMRgrP004290 for ; Wed, 22 May 2002 15:27:42 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27142 for ; Wed, 22 May 2002 15:27:48 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28407 for ; Wed, 22 May 2002 15:27:48 -0700 (PDT) Received: from mkulkarn-u10.cisco.com (mkulkarn-u10.cisco.com [128.107.162.246]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4MMRlPI018209; Wed, 22 May 2002 15:27:47 -0700 (PDT) Received: from cisco.com (localhost [127.0.0.1]) by mkulkarn-u10.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) with ESMTP id PAA03184; Wed, 22 May 2002 15:27:46 -0700 (PDT) Message-ID: <3CEC1B62.DD187ACB@cisco.com> Date: Wed, 22 May 2002 15:27:46 -0700 From: Milind Kulkarni X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Behcet Sarikaya CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 References: <4DA6EA82906FD511BE2F00508BCF05380457D55C@Esealnt861.al.sw.ericsson.se> <3CEBBB68.3077B4C3@cisco.com> <3CEBC14F.5060406@alcatel.com> <3CEC15BA.11717EED@cisco.com> <3CEC1994.5020202@alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Behcet Sarikaya wrote: > > I resent the language you used. > If your answer is no simply say it. > > I know the history of events around these two drafts mipv4 regreg and > mipv6 regreg, that was the reason why I had asked. Again, I would appreciate if you can tell us how does that matter to the present discussion? Thanks, Milind > > Milind Kulkarni wrote: > > >Apples and oranges Behcet! How did you conclude that > >it's an endorsement? It's completely irrelevant and > >laughable comment to the present discussion. > > > >I would like to stick to the issue at hand: the need > >to outline and follow uniform process for all proposals. > >I sincerely hope the WG and chairs address that. > > > >Thanks, > >Milind > > > >Behcet Sarikaya wrote: > > > >>Can we read this as an endorsement of > >>http://ietf.org/internet-drafts/draft-ietf-mobileip-hmipv6-05.txt? > >> > >>Regards, > >> > >>Milind Kulkarni wrote: > >> > >>>"Hesham Soliman (ERA)" wrote: > >>> > >>>>I don't understand why certain actions are taken towards > >>>>some proposals and not others. Why was their a big LMM > >>>>requirements doc done for one WG document and not > >>>>for reg reg in MIPv4? > >>>>All these things need to be considered. Using a separate > >>>>process to handle each proposal is not only confusing, > >>>>but will likely lead to no direction for this WG's output. > >>>>Please follow one process! > >>>> > >>>Couldn't agree with Hesham more! Some proposals need problem > >>>statement and/or requirement doc, while some proposals don't > >>>need any of that. It is not only confusing but may also give an > >>>impression that things are not equal. I hope the WG addresses > >>>this confusion. Please elaborate and follow one process. > >>>Thanks, > >>>Milind > >>> > >>>>Hesham > >>>> > >>-- > >>Behcet From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 19:23:58 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07590 for ; Wed, 22 May 2002 19:23:58 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01099; Wed, 22 May 2002 17:24:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28186; Wed, 22 May 2002 16:23:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MNMSrP004601 for ; Wed, 22 May 2002 16:22:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MNMRxN004600 for mobile-ip-dist; Wed, 22 May 2002 16:22:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MNMOrP004590 for ; Wed, 22 May 2002 16:22:24 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27846 for ; Wed, 22 May 2002 16:22:31 -0700 (PDT) Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25682 for ; Wed, 22 May 2002 16:22:31 -0700 (PDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g4MNMPx20944; Wed, 22 May 2002 18:22:25 -0500 (CDT) Message-ID: <3CEC2847.9060902@alcatel.com> Date: Wed, 22 May 2002 18:22:47 -0500 From: Behcet Sarikaya Organization: Alcatel USA User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 References: <4DA6EA82906FD511BE2F00508BCF05380457D55C@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, Your most popular quote of the day: Hesham Soliman (ERA) wrote: > > >I don't understand why certain actions are taken towards >some proposals and not others. Why was their a big LMM >requirements doc done for one WG document and not >for reg reg in MIPv4? >All these things need to be considered. Using a separate >process to handle each proposal is not only confusing, >but will likely lead to no direction for this WG's output. > >Please follow one process! > >Hesham > Was it not the case that LMM requirements applied to both v4 and v6? The present draft > http://ietf.org/internet-drafts/draft-ietf-mobileip-lmm-requirements-01.txt is only for IPv6 however it could be revised easily to be for both versions. I hereby suggest that we kindly request Carl to undertake this revision so that his draft could move to the last call. Then and only then the justice will be served. My 0.02 cents. -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 19:26:46 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07702 for ; Wed, 22 May 2002 19:26:45 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24023; Wed, 22 May 2002 16:25:07 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28504; Wed, 22 May 2002 16:24:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MNNsrP004621 for ; Wed, 22 May 2002 16:23:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MNNroh004620 for mobile-ip-dist; Wed, 22 May 2002 16:23:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MNNorP004613 for ; Wed, 22 May 2002 16:23:50 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26824 for ; Wed, 22 May 2002 16:23:57 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA26349 for ; Wed, 22 May 2002 16:23:57 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA16558; Wed, 22 May 2002 16:23:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4MNNuB15300; Wed, 22 May 2002 16:23:56 -0700 X-mProtect: <200205222323> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGS6ssW; Wed, 22 May 2002 16:23:54 PDT Message-ID: <3CEC2878.C0045BAB@iprg.nokia.com> Date: Wed, 22 May 2002 16:23:36 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 References: <4DA6EA82906FD511BE2F00508BCF05380457D55C@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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, "Hesham Soliman (ERA)" wrote: > I don't understand why certain actions are taken towards > some proposals and not others. Why was their a big LMM > requirements doc done for one WG document and not > for reg reg in MIPv4? > All these things need to be considered. Using a separate > process to handle each proposal is not only confusing, > but will likely lead to no direction for this WG's output. > > Please follow one process! The explanation is simple. The Regional Registration specification for IPv4 started much earlier than any such work for IPv6. You might as well wonder why there isn't a Security Considerations for base IPv4 specification. However, if it actually matters to the discussion, the last time I read the LMM document, I determined that Regional Registration for IPv4 met the requirements very well. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 19:56:40 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08790 for ; Wed, 22 May 2002 19:56:39 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16375; Wed, 22 May 2002 17:57:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA25998; Wed, 22 May 2002 16:56:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MNtKrP004778 for ; Wed, 22 May 2002 16:55:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4MNtKAQ004777 for mobile-ip-dist; Wed, 22 May 2002 16:55:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4MNtHrP004770 for ; Wed, 22 May 2002 16:55:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10274 for ; Wed, 22 May 2002 16:55:24 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA15723 for ; Wed, 22 May 2002 17:56:07 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 19:51:45 -0400 Message-ID: From: Phil Roberts To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] WG process Date: Wed, 22 May 2002 19:51:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > I would also like to add a note, for the WG in general, > not only to James. Can we _pleeeease_ have some consistency > in the way we assess proposals. Let's consider the RFC being > referenced here (1958). Doesn't the quote used by Phil state > that the intelligence should be in the end hosts? So why are > we accepting proposals that do not follow these principals? > Yes I'm referring to both FMIPv4 and FMIPv6, and I have > contributed heavily to both drafts, so no bias here ;) > > I don't understand why certain actions are taken towards > some proposals and not others. Why was their a big LMM > requirements doc done for one WG document and not > for reg reg in MIPv4? > All these things need to be considered. Using a separate > process to handle each proposal is not only confusing, but > will likely lead to no direction for this WG's output. > > Please follow one process! At some level we do follow one process although the steps in each document may be different as circumstances require. Abstractly it seems we have a process of problem statement, requirements, proposals, proposal selection, wg iterations, wg last call. In some cases we have the luxury that the problem statement and requirements are clear enough that we get one proposal and are able to iterate and do a wg last call. In other cases, it's muddy enough that we start from the beginning. In yet other cases it seems clear enough at the time we start that a proposal is fine, yet as we iterate we realize there may be conflicting requirements, disagreements amongst the constituency, and a need to step back and look again. We could force all the steps to occur on everything we consider, but personally optimizations where possible seem productive, even though in some cases we have to backtrack. It is frustrating in a way that when docs take a long time to get through, there are more opportunities for finding problems, or thinking about the original problem. Why was LMM requirements done for v6 and not for v4? Probably a lot of reasons - the ones that seem clear to me are premature selection of a proposal, recognized in a disagreement about requirements. Hope this helps, Phil > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 20:01:20 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08983 for ; Wed, 22 May 2002 20:01:20 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA25762; Wed, 22 May 2002 18:01:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27840; Wed, 22 May 2002 17:01:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N00LrP004834 for ; Wed, 22 May 2002 17:00:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4N00KPP004833 for mobile-ip-dist; Wed, 22 May 2002 17:00:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N00HrP004826 for ; Wed, 22 May 2002 17:00:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA10405 for ; Wed, 22 May 2002 17:00:24 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20563 for ; Wed, 22 May 2002 18:00:23 -0600 (MDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 19:56:45 -0400 Message-ID: From: Phil Roberts To: "'Hesham Soliman (ERA)'" , James Kempf , Phil Roberts , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Wed, 22 May 2002 19:56:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > Since I disagree with the 'architecture' argument, I have > to comment on this. Did you comment on what part of the argument you disagree with? The IAB recommendations themselves? Or that they apply here? I'm sorry if you said that and I missed it. > > Also, regardless of why it's needed, it's already > there. We already have a precedence. Yuk. > BTW, this raises > the issue of HA redundancy. We need to address that > at some stage. Agreed. > > I would also like to add a note, for the WG in general, > not only to James. Can we _pleeeease_ have some consistency > in the way we assess proposals. Let's consider the RFC being > referenced here (1958). Doesn't the quote used by Phil state > that the intelligence should be in the end hosts? So why are > we accepting proposals that do not follow these principals? > Yes I'm referring to both FMIPv4 and FMIPv6, and I have > contributed heavily to both drafts, so no bias here ;) Good questions. There are some interesting questions about to what extent these sorts of things can be done without help at the edge, and how that effects the way we think about architecture. Definitely needs some thought. > > I don't understand why certain actions are taken towards > some proposals and not others. Why was their a big LMM > requirements doc done for one WG document and not > for reg reg in MIPv4? > All these things need to be considered. Using a separate > process to handle each proposal is not only confusing, but > will likely lead to no direction for this WG's output. > > Please follow one process! Responded in a separate thread, so folks can track it. > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed May 22 22:35:35 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14312 for ; Wed, 22 May 2002 22:35:35 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA12376; Wed, 22 May 2002 20:36:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15185; Wed, 22 May 2002 19:35:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N2Y9rP005094 for ; Wed, 22 May 2002 19:34:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4N2Y8qW005093 for mobile-ip-dist; Wed, 22 May 2002 19:34:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N2Y5rP005086 for ; Wed, 22 May 2002 19:34:05 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02855 for ; Wed, 22 May 2002 19:34:12 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA02476 for ; Wed, 22 May 2002 19:34:12 -0700 (PDT) Message-ID: <030501c20201$4db7cff0$8b6015ac@AlperVAIO> From: "Alper E. YEGIN" To: References: Subject: [mobile-ip] RR and BU to HA Date: Wed, 22 May 2002 19:26:52 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, We have a question on the security of BUs... The current draft identifies a need to verify the return routability of CoA when the BU is sent to a CN. But it suggests that one can use IPsec between the MN and the HA when MN is sending a BU, and this should be sufficient.... Shouldn't we be doing a RR on the CoA even if we are using IPsec? alper From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 02:44:39 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28245 for ; Thu, 23 May 2002 02:44:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27852; Thu, 23 May 2002 00:45:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA26110; Wed, 22 May 2002 23:44:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N6hVrP006432 for ; Wed, 22 May 2002 23:43:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4N6hUDm006431 for mobile-ip-dist; Wed, 22 May 2002 23:43:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N6hRrP006424 for ; Wed, 22 May 2002 23:43:27 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4N6hV6U423706; Wed, 22 May 2002 23:43:32 -0700 (PDT) Message-Id: <200205230643.g4N6hV6U423706@jurassic.eng.sun.com> Date: Wed, 22 May 2002 23:45:58 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] RR and BU to HA To: alper@docomolabs-usa.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: GJuM2BDNwLfmC8hv8nwbyQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > The current draft identifies a need to verify the > return routability of CoA when the BU is sent to > a CN. > > But it suggests that one can use IPsec between > the MN and the HA when MN is sending a BU, > and this should be sufficient.... Shouldn't we be > doing a RR on the CoA even if we are using IPsec? > The draft does not specify, but my understanding is that MN would use ESP transport mode with srcaddr=COA for sending BU to HA. As long as there is correct SA between MN-homeaddr and HA and home-addr in HOA dst option matches with the authenticated BU MH home-addr part, there is no problem. In CN case, separate COA RR check is necessary to avoid reflection attack from another malicous MN. However, I see some issues in : 11.6.6. Forwarding from a Previous Care-of Address section, where it says that BU home-addr and HOA-dst option both contain the previous COA address. So, the question is how does HA match the security association in this case ? I assume that the draft assumes the sequence would be: 1. update HA first with your new COA with HoA= MN's home-addr 2. Then send BU to forward packet from previous COA. In this case HA should do a few extra checks to make sure that the new COA already has a valid BCE. But, I am still not sure how would HA do the SA check for homeaddr in this case ( since homeaddr=previous COA), I believe there is no security association with the previous COA and HA. -Samita From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 04:08:51 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29834 for ; Thu, 23 May 2002 04:08:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28732; Thu, 23 May 2002 01:05:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA27108; Thu, 23 May 2002 01:05:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N84JrP006575 for ; Thu, 23 May 2002 01:04:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4N84JTH006574 for mobile-ip-dist; Thu, 23 May 2002 01:04:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N84GrP006567 for ; Thu, 23 May 2002 01:04:16 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15110 for ; Thu, 23 May 2002 01:04:15 -0700 (PDT) From: sinan01@ms27.hinet.net Received: from webmail0-1.hinet.net (webmail0-1.hinet.net [168.95.4.234]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29259 for ; Thu, 23 May 2002 02:04:14 -0600 (MDT) Received: from 163.21.155.253 (localhost [127.0.0.1]) by webmail0-1.hinet.net (8.11.1/8.11.1) with SMTP id g4N847c12437; Thu, 23 May 2002 16:04:07 +0800 (CST) Date: Thu, 23 May 2002 16:04:07 +0800 (CST) Message-Id: <200205230804.g4N847c12437@webmail0-1.hinet.net> Content-Type: multipart/mixed; boundary="----------=_1022141047-12429-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.316 (Entity 5.212) To: chiehhu@mail.haps.tp.edu.tw Cc: mobile-ip@sunroof.eng.sun.com Subject: Fwd: Re: [mobile-ip] RR and BU to HA Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format... ------------=_1022141047-12429-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary > > The current draft identifies a need to verify the > return routability of CoA when the BU is sent to > a CN. > > But it suggests that one can use IPsec between > the MN and the HA when MN is sending a BU, > and this should be sufficient.... Shouldn't we be > doing a RR on the CoA even if we are using IPsec? > The draft does not specify, but my understanding is that MN would use ESP transport mode with srcaddr=COA for sending BU to HA. As long as there is correct SA between MN-homeaddr and HA and home-addr in HOA dst option matches with the authenticated BU MH home-addr part, there is no problem. In CN case, separate COA RR check is necessary to avoid reflection attack from another malicous MN. However, I see some issues in : 11.6.6. Forwarding from a Previous Care-of Address section, where it says that BU home-addr and HOA-dst option both contain the previous COA address. So, the question is how does HA match the security association in this case ? I assume that the draft assumes the sequence would be: 1. update HA first with your new COA with HoA= MN's home-addr 2. Then send BU to forward packet from previous COA. In this case HA should do a few extra checks to make sure that the new COA already has a valid BCE. But, I am still not sure how would HA do the SA check for homeaddr in this case ( since homeaddr=previous COA), I believe there is no security association with the previous COA and HA. -Samita ------------=_1022141047-12429-0 Content-Type: application/octet-stream; name="msg-12271-1.txt" Content-Disposition: inline; filename="msg-12271-1.txt" Content-Transfer-Encoding: base64 DQo+IA0KPiBUaGUgY3VycmVudCBkcmFmdCBpZGVudGlmaWVzIGEgbmVlZCB0 byB2ZXJpZnkgdGhlDQo+IHJldHVybiByb3V0YWJpbGl0eSBvZiBDb0Egd2hl biB0aGUgQlUgaXMgc2VudCB0bw0KPiBhIENOLiANCj4gDQo+IEJ1dCBpdCBz dWdnZXN0cyB0aGF0IG9uZSBjYW4gdXNlIElQc2VjIGJldHdlZW4NCj4gdGhl IE1OIGFuZCB0aGUgSEEgd2hlbiBNTiBpcyBzZW5kaW5nIGEgQlUsDQo+IGFu ZCB0aGlzIHNob3VsZCBiZSBzdWZmaWNpZW50Li4uLiBTaG91bGRuJ3Qgd2Ug YmUNCj4gZG9pbmcgYSBSUiBvbiB0aGUgQ29BIGV2ZW4gaWYgd2UgYXJlIHVz aW5nIElQc2VjPw0KPiANCiANClRoZSBkcmFmdCBkb2VzIG5vdCBzcGVjaWZ5 LCBidXQgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IE1OIHdvdWxkDQp1c2Ug RVNQIHRyYW5zcG9ydCBtb2RlIHdpdGggc3JjYWRkcj1DT0EgZm9yIHNlbmRp bmcgQlUgdG8gSEEuDQpBcyBsb25nIGFzIHRoZXJlIGlzIGNvcnJlY3QgU0Eg YmV0d2VlbiBNTi1ob21lYWRkciBhbmQgSEEgYW5kDQpob21lLWFkZHIgaW4g SE9BIGRzdCBvcHRpb24gbWF0Y2hlcyB3aXRoIHRoZSBhdXRoZW50aWNhdGVk IEJVDQpNSCBob21lLWFkZHIgcGFydCwgdGhlcmUgaXMgbm8gcHJvYmxlbS4g SW4gQ04gY2FzZSwgc2VwYXJhdGUgDQpDT0EgUlIgY2hlY2sgaXMgbmVjZXNz YXJ5IHRvIGF2b2lkIHJlZmxlY3Rpb24gYXR0YWNrIGZyb20gYW5vdGhlcg0K bWFsaWNvdXMgTU4uIA0KDQpIb3dldmVyLCBJIHNlZSBzb21lIGlzc3VlcyBp biA6DQoxMS42LjYuIEZvcndhcmRpbmcgZnJvbSBhIFByZXZpb3VzIENhcmUt b2YgQWRkcmVzcw0KDQoNCnNlY3Rpb24sIHdoZXJlIGl0IHNheXMgdGhhdCBC VSBob21lLWFkZHIgYW5kIEhPQS1kc3Qgb3B0aW9uIGJvdGgNCmNvbnRhaW4g dGhlIHByZXZpb3VzIENPQSBhZGRyZXNzLiBTbywgdGhlIHF1ZXN0aW9uIGlz IGhvdyBkb2VzIEhBDQptYXRjaCB0aGUgc2VjdXJpdHkgYXNzb2NpYXRpb24g aW4gdGhpcyBjYXNlID8gDQpJIGFzc3VtZSB0aGF0IHRoZSBkcmFmdCBhc3N1 bWVzIHRoZSBzZXF1ZW5jZSB3b3VsZCBiZToNCjEuIHVwZGF0ZSBIQSBmaXJz dCB3aXRoIHlvdXIgbmV3IENPQSB3aXRoIEhvQT0gTU4ncyBob21lLWFkZHIN CjIuIFRoZW4gc2VuZCBCVSB0byBmb3J3YXJkIHBhY2tldCBmcm9tIHByZXZp b3VzIENPQS4gDQogICBJbiB0aGlzIGNhc2UgSEEgc2hvdWxkIGRvIGEgZmV3 IGV4dHJhIGNoZWNrcyB0byBtYWtlIHN1cmUgdGhhdCB0aGUNCiAgIG5ldyBD T0EgYWxyZWFkeSBoYXMgYSB2YWxpZCBCQ0UuDQogICANCiAgIEJ1dCwgSSBh bSBzdGlsbCBub3Qgc3VyZSBob3cgd291bGQgSEEgZG8gdGhlIFNBIGNoZWNr IGZvciBob21lYWRkcg0KICAgaW4gdGhpcyBjYXNlICggc2luY2UgaG9tZWFk ZHI9cHJldmlvdXMgQ09BKSwgSSBiZWxpZXZlIHRoZXJlIGlzIG5vDQogICBz ZWN1cml0eSBhc3NvY2lhdGlvbiB3aXRoIHRoZSBwcmV2aW91cyBDT0EgYW5k IEhBLg0KICAgDQogICANCiAgIC1TYW1pdGENCiAgDQoK ------------=_1022141047-12429-0-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 04:21:42 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00093 for ; Thu, 23 May 2002 04:21:41 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16103; Thu, 23 May 2002 02:21:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA29733; Thu, 23 May 2002 01:21:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N8KGrP006626 for ; Thu, 23 May 2002 01:20:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4N8KF06006625 for mobile-ip-dist; Thu, 23 May 2002 01:20:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N8KBrP006618 for ; Thu, 23 May 2002 01:20:12 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA29627 for ; Thu, 23 May 2002 01:20:17 -0700 (PDT) From: sinan01@ms27.hinet.net Received: from webmail0-1.hinet.net (webmail0-1.hinet.net [168.95.4.234]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15674 for ; Thu, 23 May 2002 02:20:16 -0600 (MDT) Received: from 163.21.155.253 (localhost [127.0.0.1]) by webmail0-1.hinet.net (8.11.1/8.11.1) with SMTP id g4N8K6c20503; Thu, 23 May 2002 16:20:06 +0800 (CST) Date: Thu, 23 May 2002 16:20:06 +0800 (CST) Message-Id: <200205230820.g4N8K6c20503@webmail0-1.hinet.net> Content-Type: multipart/mixed; boundary="----------=_1022142006-20495-0" Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.316 (Entity 5.212) To: chiehhu@mail.haps.tp.edu.tw Cc: mobile-ip@sunroof.eng.sun.com Subject: Fwd: Fwd: Re: [mobile-ip] RR and BU to HA Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format... ------------=_1022142006-20495-0 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary > > The current draft identifies a need to verify the > return routability of CoA when the BU is sent to > a CN. > > But it suggests that one can use IPsec between > the MN and the HA when MN is sending a BU, > and this should be sufficient.... Shouldn't we be > doing a RR on the CoA even if we are using IPsec? > The draft does not specify, but my understanding is that MN would use ESP transport mode with srcaddr=COA for sending BU to HA. As long as there is correct SA between MN-homeaddr and HA and home-addr in HOA dst option matches with the authenticated BU MH home-addr part, there is no problem. In CN case, separate COA RR check is necessary to avoid reflection attack from another malicous MN. However, I see some issues in : 11.6.6. Forwarding from a Previous Care-of Address section, where it says that BU home-addr and HOA-dst option both contain the previous COA address. So, the question is how does HA match the security association in this case ? I assume that the draft assumes the sequence would be: 1. update HA first with your new COA with HoA= MN's home-addr 2. Then send BU to forward packet from previous COA. In this case HA should do a few extra checks to make sure that the new COA already has a valid BCE. But, I am still not sure how would HA do the SA check for homeaddr in this case ( since homeaddr=previous COA), I believe there is no security association with the previous COA and HA. -Samita ------------=_1022142006-20495-0 Content-Type: application/octet-stream; name="msg-12271-1.txt" Content-Disposition: inline; filename="msg-12271-1.txt" Content-Transfer-Encoding: base64 DQo+IA0KPiBUaGUgY3VycmVudCBkcmFmdCBpZGVudGlmaWVzIGEgbmVlZCB0 byB2ZXJpZnkgdGhlDQo+IHJldHVybiByb3V0YWJpbGl0eSBvZiBDb0Egd2hl biB0aGUgQlUgaXMgc2VudCB0bw0KPiBhIENOLiANCj4gDQo+IEJ1dCBpdCBz dWdnZXN0cyB0aGF0IG9uZSBjYW4gdXNlIElQc2VjIGJldHdlZW4NCj4gdGhl IE1OIGFuZCB0aGUgSEEgd2hlbiBNTiBpcyBzZW5kaW5nIGEgQlUsDQo+IGFu ZCB0aGlzIHNob3VsZCBiZSBzdWZmaWNpZW50Li4uLiBTaG91bGRuJ3Qgd2Ug YmUNCj4gZG9pbmcgYSBSUiBvbiB0aGUgQ29BIGV2ZW4gaWYgd2UgYXJlIHVz aW5nIElQc2VjPw0KPiANCiANClRoZSBkcmFmdCBkb2VzIG5vdCBzcGVjaWZ5 LCBidXQgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IE1OIHdvdWxkDQp1c2Ug RVNQIHRyYW5zcG9ydCBtb2RlIHdpdGggc3JjYWRkcj1DT0EgZm9yIHNlbmRp bmcgQlUgdG8gSEEuDQpBcyBsb25nIGFzIHRoZXJlIGlzIGNvcnJlY3QgU0Eg YmV0d2VlbiBNTi1ob21lYWRkciBhbmQgSEEgYW5kDQpob21lLWFkZHIgaW4g SE9BIGRzdCBvcHRpb24gbWF0Y2hlcyB3aXRoIHRoZSBhdXRoZW50aWNhdGVk IEJVDQpNSCBob21lLWFkZHIgcGFydCwgdGhlcmUgaXMgbm8gcHJvYmxlbS4g SW4gQ04gY2FzZSwgc2VwYXJhdGUgDQpDT0EgUlIgY2hlY2sgaXMgbmVjZXNz YXJ5IHRvIGF2b2lkIHJlZmxlY3Rpb24gYXR0YWNrIGZyb20gYW5vdGhlcg0K bWFsaWNvdXMgTU4uIA0KDQpIb3dldmVyLCBJIHNlZSBzb21lIGlzc3VlcyBp biA6DQoxMS42LjYuIEZvcndhcmRpbmcgZnJvbSBhIFByZXZpb3VzIENhcmUt b2YgQWRkcmVzcw0KDQoNCnNlY3Rpb24sIHdoZXJlIGl0IHNheXMgdGhhdCBC VSBob21lLWFkZHIgYW5kIEhPQS1kc3Qgb3B0aW9uIGJvdGgNCmNvbnRhaW4g dGhlIHByZXZpb3VzIENPQSBhZGRyZXNzLiBTbywgdGhlIHF1ZXN0aW9uIGlz IGhvdyBkb2VzIEhBDQptYXRjaCB0aGUgc2VjdXJpdHkgYXNzb2NpYXRpb24g aW4gdGhpcyBjYXNlID8gDQpJIGFzc3VtZSB0aGF0IHRoZSBkcmFmdCBhc3N1 bWVzIHRoZSBzZXF1ZW5jZSB3b3VsZCBiZToNCjEuIHVwZGF0ZSBIQSBmaXJz dCB3aXRoIHlvdXIgbmV3IENPQSB3aXRoIEhvQT0gTU4ncyBob21lLWFkZHIN CjIuIFRoZW4gc2VuZCBCVSB0byBmb3J3YXJkIHBhY2tldCBmcm9tIHByZXZp b3VzIENPQS4gDQogICBJbiB0aGlzIGNhc2UgSEEgc2hvdWxkIGRvIGEgZmV3 IGV4dHJhIGNoZWNrcyB0byBtYWtlIHN1cmUgdGhhdCB0aGUNCiAgIG5ldyBD T0EgYWxyZWFkeSBoYXMgYSB2YWxpZCBCQ0UuDQogICANCiAgIEJ1dCwgSSBh bSBzdGlsbCBub3Qgc3VyZSBob3cgd291bGQgSEEgZG8gdGhlIFNBIGNoZWNr IGZvciBob21lYWRkcg0KICAgaW4gdGhpcyBjYXNlICggc2luY2UgaG9tZWFk ZHI9cHJldmlvdXMgQ09BKSwgSSBiZWxpZXZlIHRoZXJlIGlzIG5vDQogICBz ZWN1cml0eSBhc3NvY2lhdGlvbiB3aXRoIHRoZSBwcmV2aW91cyBDT0EgYW5k IEhBLg0KICAgDQogICANCiAgIC1TYW1pdGENCiAgDQoK ------------=_1022142006-20495-0 Content-Type: application/octet-stream; name="msg-20369-1.txt" Content-Disposition: inline; filename="msg-20369-1.txt" Content-Transfer-Encoding: base64 DQo+IA0KPiBUaGUgY3VycmVudCBkcmFmdCBpZGVudGlmaWVzIGEgbmVlZCB0 byB2ZXJpZnkgdGhlDQo+IHJldHVybiByb3V0YWJpbGl0eSBvZiBDb0Egd2hl biB0aGUgQlUgaXMgc2VudCB0bw0KPiBhIENOLiANCj4gDQo+IEJ1dCBpdCBz dWdnZXN0cyB0aGF0IG9uZSBjYW4gdXNlIElQc2VjIGJldHdlZW4NCj4gdGhl IE1OIGFuZCB0aGUgSEEgd2hlbiBNTiBpcyBzZW5kaW5nIGEgQlUsDQo+IGFu ZCB0aGlzIHNob3VsZCBiZSBzdWZmaWNpZW50Li4uLiBTaG91bGRuJ3Qgd2Ug YmUNCj4gZG9pbmcgYSBSUiBvbiB0aGUgQ29BIGV2ZW4gaWYgd2UgYXJlIHVz aW5nIElQc2VjPw0KPiANCiANClRoZSBkcmFmdCBkb2VzIG5vdCBzcGVjaWZ5 LCBidXQgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IE1OIHdvdWxkDQp1c2Ug RVNQIHRyYW5zcG9ydCBtb2RlIHdpdGggc3JjYWRkcj1DT0EgZm9yIHNlbmRp bmcgQlUgdG8gSEEuDQpBcyBsb25nIGFzIHRoZXJlIGlzIGNvcnJlY3QgU0Eg YmV0d2VlbiBNTi1ob21lYWRkciBhbmQgSEEgYW5kDQpob21lLWFkZHIgaW4g SE9BIGRzdCBvcHRpb24gbWF0Y2hlcyB3aXRoIHRoZSBhdXRoZW50aWNhdGVk IEJVDQpNSCBob21lLWFkZHIgcGFydCwgdGhlcmUgaXMgbm8gcHJvYmxlbS4g SW4gQ04gY2FzZSwgc2VwYXJhdGUgDQpDT0EgUlIgY2hlY2sgaXMgbmVjZXNz YXJ5IHRvIGF2b2lkIHJlZmxlY3Rpb24gYXR0YWNrIGZyb20gYW5vdGhlcg0K bWFsaWNvdXMgTU4uIA0KDQpIb3dldmVyLCBJIHNlZSBzb21lIGlzc3VlcyBp biA6DQoxMS42LjYuIEZvcndhcmRpbmcgZnJvbSBhIFByZXZpb3VzIENhcmUt b2YgQWRkcmVzcw0KDQoNCnNlY3Rpb24sIHdoZXJlIGl0IHNheXMgdGhhdCBC VSBob21lLWFkZHIgYW5kIEhPQS1kc3Qgb3B0aW9uIGJvdGgNCmNvbnRhaW4g dGhlIHByZXZpb3VzIENPQSBhZGRyZXNzLiBTbywgdGhlIHF1ZXN0aW9uIGlz IGhvdyBkb2VzIEhBDQptYXRjaCB0aGUgc2VjdXJpdHkgYXNzb2NpYXRpb24g aW4gdGhpcyBjYXNlID8gDQpJIGFzc3VtZSB0aGF0IHRoZSBkcmFmdCBhc3N1 bWVzIHRoZSBzZXF1ZW5jZSB3b3VsZCBiZToNCjEuIHVwZGF0ZSBIQSBmaXJz dCB3aXRoIHlvdXIgbmV3IENPQSB3aXRoIEhvQT0gTU4ncyBob21lLWFkZHIN CjIuIFRoZW4gc2VuZCBCVSB0byBmb3J3YXJkIHBhY2tldCBmcm9tIHByZXZp b3VzIENPQS4gDQogICBJbiB0aGlzIGNhc2UgSEEgc2hvdWxkIGRvIGEgZmV3 IGV4dHJhIGNoZWNrcyB0byBtYWtlIHN1cmUgdGhhdCB0aGUNCiAgIG5ldyBD T0EgYWxyZWFkeSBoYXMgYSB2YWxpZCBCQ0UuDQogICANCiAgIEJ1dCwgSSBh bSBzdGlsbCBub3Qgc3VyZSBob3cgd291bGQgSEEgZG8gdGhlIFNBIGNoZWNr IGZvciBob21lYWRkcg0KICAgaW4gdGhpcyBjYXNlICggc2luY2UgaG9tZWFk ZHI9cHJldmlvdXMgQ09BKSwgSSBiZWxpZXZlIHRoZXJlIGlzIG5vDQogICBz ZWN1cml0eSBhc3NvY2lhdGlvbiB3aXRoIHRoZSBwcmV2aW91cyBDT0EgYW5k IEhBLg0KICAgDQogICANCiAgIC1TYW1pdGENCiAgDQoNCg0KICAgICAgIA== ------------=_1022142006-20495-0-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 05:56:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02635 for ; Thu, 23 May 2002 05:56:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20455; Thu, 23 May 2002 03:57:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14492; Thu, 23 May 2002 02:56:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N9tgrP006758 for ; Thu, 23 May 2002 02:55:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4N9tgkA006757 for mobile-ip-dist; Thu, 23 May 2002 02:55:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4N9tdrP006750 for ; Thu, 23 May 2002 02:55:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA16884 for ; Thu, 23 May 2002 02:55:45 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01736 for ; Thu, 23 May 2002 03:55:44 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4N9tdn10760; Thu, 23 May 2002 11:55:39 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA15917; Thu, 23 May 2002 11:55:39 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4N9tcT19737; Thu, 23 May 2002 11:55:38 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205230955.g4N9tcT19737@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Alper E. YEGIN" cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA In-reply-to: Your message of Wed, 22 May 2002 19:26:52 PDT. <030501c20201$4db7cff0$8b6015ac@AlperVAIO> Date: Thu, 23 May 2002 11:55:38 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: The current draft identifies a need to verify the return routability of CoA when the BU is sent to a CN. => this is an open point. Some believe RR check is simply mandatory, some believe RR check is only one possible way to fulfill security requirements and a suitable IPsec protection should not need an extra RR check (the argument is the RR check is not possible for the HA so "suitable IPsec" includes the trust in the MN to not provide a fake CoA). But it suggests that one can use IPsec between the MN and the HA when MN is sending a BU, and this should be sufficient.... Shouldn't we be doing a RR on the CoA even if we are using IPsec? => I believe the answer is no and I'd like to see how to perform a RR check between the MN and the HA... Thanks Francis.Dupont@enst-bretagne.fr PS: note the MN may (so it MUST) protect the CoA as soon as nobody adds a "NAT traversal" capability to the signaling protocol (I've written an I-D about this kind of problems, it should be published soon). From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 06:29:00 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03292 for ; Thu, 23 May 2002 06:28:59 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29762; Thu, 23 May 2002 04:28:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23150; Thu, 23 May 2002 03:28:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NARmrP006864 for ; Thu, 23 May 2002 03:27:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NARmWd006863 for mobile-ip-dist; Thu, 23 May 2002 03:27:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NARjrP006856 for ; Thu, 23 May 2002 03:27:45 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA29155 for ; Thu, 23 May 2002 03:27:49 -0700 (PDT) From: arvind.sevalkar@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA16989 for ; Thu, 23 May 2002 04:27:48 -0600 (MDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002052316015058:3165 ; Thu, 23 May 2002 16:01:50 +0530 Subject: [mobile-ip] Sending Binding Error Message To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Thu, 23 May 2002 15:57:47 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/23/2002 03:58:10 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/23/2002 04:01:50 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/23/2002 04:01:53 PM, Serialize complete at 05/23/2002 04:01:53 PM Message-ID: X-Priority: 3 (Normal) Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi all, Binding Error message contains home address where in the address from the Home Address destination option of the packet with unrecognized MH message. But in case when packet contains unknown MH type and Home address destination option is not present then put 0 in the home address field of the Binding error message.. Am I right? Regards Arvind From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 06:50:13 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03689 for ; Thu, 23 May 2002 06:50:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA26391; Thu, 23 May 2002 04:50:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28110; Thu, 23 May 2002 03:49:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NAn3rP006982 for ; Thu, 23 May 2002 03:49:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NAn3bv006981 for mobile-ip-dist; Thu, 23 May 2002 03:49:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NAn0rP006974 for ; Thu, 23 May 2002 03:49:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA27983 for ; Thu, 23 May 2002 03:49:05 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11434 for ; Thu, 23 May 2002 04:49:49 -0600 (MDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4NAn3Hs005290; Thu, 23 May 2002 03:49:03 -0700 (PDT) Received: from DBLAIRW2K (rtp-vpn2-66.cisco.com [10.82.240.66]) by mira-sjcm-2.cisco.com (Mirapoint) with SMTP id ACY68632; Thu, 23 May 2002 03:48:51 -0700 (PDT) From: "Dana L. Blair" To: , "'Phil Roberts'" , Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Thu, 23 May 2002 06:48:50 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <000001c1fbd0$e15fb600$5701a8c0@EmadQ> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Emad Qaddoura > Sent: Wednesday, May 15, 2002 1:25 AM > To: 'Phil Roberts'; mobile-ip@sunroof.eng.sun.com > Subject: RE: [mobile-ip] Regional Registration Last Call Resolution > Issue #4 > > > Phil, > > How is the GFA is different from the HA and FA from the stand > point of single point of failure or other reliability issues? I The FA is not a single point of failure but you can have more than one FA advertising to the same subnet. If one FA goes away, the MN will hear an advertisement from the other and can still register. thanks, Dana believe > this can be implementation dependent, i.e. someone can implement GFA as > a cluster. > > I believe the regional registration draft has some complexity > into it, and without some a bake-off like tests, it should remain at the > experimental level. > > Thx. > > > -----Original Message----- > > From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile- > > ip@sunroof.eng.sun.com] On Behalf Of Phil Roberts > > Sent: Tuesday, May 14, 2002 10:25 PM > > To: 'mobile-ip@sunroof.eng.sun.com' > > Subject: [mobile-ip] Regional Registration Last Call Resolution Issue > #4 > > > > Several folks raised the issue of to what extent introducing regional > > registration entities in the visited network violates principles of > the > > Internet architecture, specifically with regard to the introduction of > > single points of failure in the communication path of visiting nodes. > > > > I've excerpted the relevant text from rfc 1958 on the architectural > > principle which is at issue. > > > > "The end-to-end argument is discussed in depth in [Saltzer]. The > > basic argument is that, as a first principle, certain required > end- > > to-end functions can only be performed correctly by the end-systems > > themselves. A specific case is that any network, however carefully > > designed, will be subject to failures of transmission at some > > statistically determined rate. The best way to cope with this is to > > accept it, and give responsibility for the integrity of > communication > > to the end systems. Another specific case is end-to-end security. > > > > To quote from [Saltzer], "The function in question can completely > and > > correctly be implemented only with the knowledge and help of the > > application standing at the endpoints of the communication system. > > Therefore, providing that questioned function as a feature of the > > communication system itself is not possible. (Sometimes an > incomplete > > version of the function provided by the communication system may be > > useful as a performance enhancement.") > > > > This principle has important consequences if we require > applications > > to survive partial network failures. An end-to-end protocol design > > should not rely on the maintenance of state (i.e. information about > > the state of the end-to-end communication) inside the network. Such > > state should be maintained only in the endpoints, in such a way > that > > the state can only be destroyed when the endpoint itself breaks > > (known as fate-sharing). An immediate consequence of this is that > > datagrams are better than classical virtual circuits. The > network's > > job is to transmit datagrams as efficiently and flexibly as > possible." > > > > draft-iab-arch-changes-00.txt provides a discussion of this issue of > > fate-sharing in middleboxes and asserts that the principle is > preserved in > > the case that the middlebox is a partner in the communication when the > > failure can be detected and dealt with.: > > > > "The idea of fate-sharing survives this recursion, but requires > that > > all application state created in middleboxes must be capable of re- > > creation after failure. Additionally, to support this requirement, > > where a function cannot be fulfilled completely, reliably and > > securely by two endpoints of a conversation, the necessary > > middleboxes to fulfil the function should be explicit partners in > > explicit communication with at least one endpoint (or, by recursion > > of the same principle, with an intermediate middlebox). In other > > words, middleboxes should not be invisible, because their failures > > need to be detected and dealt with by their communication > partners." > > > > > > As currently specified it's not immediately obvious how the regional > > registration agents are compatible with the above guidelines. It's > > conceivable that they can be made so, and perhaps it's immediately > obvious > > to others how they are so. > > > > This issue is not insurmountable but the functionality does need to be > > specified in a way that preserves the fate sharing principle and > allows > > for > > one party in the communication to detect and deal with a failure of > one of > > the new registration entities. > From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 06:54:25 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03767 for ; Thu, 23 May 2002 06:54:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28268; Thu, 23 May 2002 04:54:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28979; Thu, 23 May 2002 03:54:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NArerP007031 for ; Thu, 23 May 2002 03:53:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NArdmY007030 for mobile-ip-dist; Thu, 23 May 2002 03:53:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NArarP007023 for ; Thu, 23 May 2002 03:53:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA02526 for ; Thu, 23 May 2002 03:53:41 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13168 for ; Thu, 23 May 2002 04:54:25 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id ACF076A907; Thu, 23 May 2002 13:53:34 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2B5B06A906; Thu, 23 May 2002 13:53:33 +0300 (EEST) Message-ID: <3CECCA6E.8000602@kolumbus.fi> Date: Thu, 23 May 2002 13:54:38 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: arvind.sevalkar@lntinfotech.com Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sending Binding Error Message References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit arvind.sevalkar@lntinfotech.com wrote: > Hi all, > > Binding Error message contains home address where in the address from the > Home Address destination option of the packet with unrecognized MH message. > But in case when packet contains unknown MH type and Home address > destination option is not present then put 0 in the home address field of > the Binding error message.. > Am I right? Yes, though in another thread I believe we ended up in the conclusion that we could include HAOs even to CNs. Is there any case left where a HAO would be missing and we would need to fill in a 0? Hmm... I suppose someone could still send a bad MH message without a HAO so... perhaps we should state that the address should be set to the unspecified address if the offending message does not include a HAO. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 07:30:11 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04769 for ; Thu, 23 May 2002 07:30:11 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14403; Thu, 23 May 2002 05:30:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06420; Thu, 23 May 2002 04:29:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NBT3rP007498 for ; Thu, 23 May 2002 04:29:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NBT3nx007497 for mobile-ip-dist; Thu, 23 May 2002 04:29:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NBSxrP007490 for ; Thu, 23 May 2002 04:28:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06460 for ; Thu, 23 May 2002 04:29:01 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA18097 for ; Thu, 23 May 2002 04:29:00 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04477; Thu, 23 May 2002 07:28:39 -0400 (EDT) Message-Id: <200205231128.HAA04477@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-rfc3012bis-03.txt Date: Thu, 23 May 2002 07:28:39 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : Mobile IPv4 Challenge/Response Extensions Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mobileip-rfc3012bis-03.txt Pages : 19 Date : 22-May-02 Mobile IP, as originally specified, defines an authentication extension (the Mobile-Foreign Authentication extension) by which a mobile node can authenticate itself to a foreign agent. Unfortunately, this extension does not provide ironclad replay protection for the foreign agent, and does not allow for the use of existing techniques (such as CHAP) for authenticating portable computer devices. In this specification, we define extensions for the Mobile IP Agent Advertisements and the Registration Request that allow a foreign agent to use a challenge/response mechanism to authenticate the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-rfc3012bis-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-rfc3012bis-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-rfc3012bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020522145357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-rfc3012bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-rfc3012bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020522145357.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 07:55:16 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05291 for ; Thu, 23 May 2002 07:55:16 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07603; Thu, 23 May 2002 05:55:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA11628; Thu, 23 May 2002 04:54:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NBrkrP007580 for ; Thu, 23 May 2002 04:53:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NBrkXr007579 for mobile-ip-dist; Thu, 23 May 2002 04:53:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NBrhrP007572 for ; Thu, 23 May 2002 04:53:43 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA11438; Thu, 23 May 2002 04:53:48 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05733; Thu, 23 May 2002 04:53:47 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4NBrfn26516; Thu, 23 May 2002 13:53:41 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA17606; Thu, 23 May 2002 13:53:41 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4NBreT20002; Thu, 23 May 2002 13:53:40 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205231153.g4NBreT20002@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Samita Chakrabarti cc: alper@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA In-reply-to: Your message of Wed, 22 May 2002 23:45:58 PDT. <200205230643.g4N6hV6U423706@jurassic.eng.sun.com> Date: Thu, 23 May 2002 13:53:40 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: The draft does not specify, but my understanding is that MN would use ESP transport mode with srcaddr=COA for sending BU to HA. => you have the choice between ESP transport mode with the COA protected (i.e. repeated) and AH transport mode. Tunnel modes give nothing more than complexity. As long as there is correct SA between MN-homeaddr and HA and home-addr in HOA dst option matches with the authenticated BU MH home-addr part, there is no problem. => I disagree: you have the same problem with the COA for the HA. In CN case, separate COA RR check is necessary to avoid reflection attack from another malicous MN. => so the COA RR check should be necessary for HA too??? However, I see some issues in : 11.6.6. Forwarding from a Previous Care-of Address section, where it says that BU home-addr and HOA-dst option both contain the previous COA address. => yes, the previous COA takes the role of the home address. So, the question is how does HA => this HA is on the previous visited link. match the security association in this case ? I assume that the draft assumes the sequence would be: 1. update HA first with your new COA with HoA= MN's home-addr => here the HA is the HA on the home link. 2. Then send BU to forward packet from previous COA. In this case HA should do a few extra checks to make sure that the new COA already has a valid BCE. => this is not the same HA than in 1. But, I am still not sure how would HA do the SA check for homeaddr in this case ( since homeaddr=previous COA), I believe there is no security association with the previous COA and HA. => it should be but the real question is how the SA pair is established... Even if this is done before the movement this is not easy. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 08:07:32 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05644 for ; Thu, 23 May 2002 08:07:32 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10921; Thu, 23 May 2002 05:05:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14415; Thu, 23 May 2002 05:05:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NC4arP007651 for ; Thu, 23 May 2002 05:04:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NC4af0007650 for mobile-ip-dist; Thu, 23 May 2002 05:04:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NC4XrP007643 for ; Thu, 23 May 2002 05:04:33 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14232 for ; Thu, 23 May 2002 05:04:38 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06835 for ; Thu, 23 May 2002 06:04:37 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4NC4Sn28899; Thu, 23 May 2002 14:04:28 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA17808; Thu, 23 May 2002 14:04:28 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4NC4QT20169; Thu, 23 May 2002 14:04:26 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205231204.g4NC4QT20169@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: arvind.sevalkar@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sending Binding Error Message In-reply-to: Your message of Thu, 23 May 2002 13:54:38 +0300. <3CECCA6E.8000602@kolumbus.fi> Date: Thu, 23 May 2002 14:04:26 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > Binding Error message contains home address where in the address from the > Home Address destination option of the packet with unrecognized MH message. > But in case when packet contains unknown MH type and Home address > destination option is not present then put 0 in the home address field of > the Binding error message.. > Am I right? Yes, though in another thread I believe we ended up in the conclusion that we could include HAOs even to CNs. Is there any case left where a HAO would be missing and we would need to fill in a 0? Hmm... I suppose someone could still send a bad MH message without a HAO so... perhaps we should state that the address should be set to the unspecified address if the offending message does not include a HAO. => an idea reading this message: what are the cases where there should not be a HAO? So: - if there should be a HAO and there is not: drop the offending packet - if there should not be a HAO because the home address should be the source of the packet: you have your home address! - other cases (if any)? Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 08:24:28 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06555 for ; Thu, 23 May 2002 08:24:27 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14462; Thu, 23 May 2002 06:24:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18593; Thu, 23 May 2002 05:24:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NCNYrP007733 for ; Thu, 23 May 2002 05:23:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NCNXth007732 for mobile-ip-dist; Thu, 23 May 2002 05:23:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NCNTrP007725 for ; Thu, 23 May 2002 05:23:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04019 for ; Thu, 23 May 2002 05:23:35 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19649 for ; Thu, 23 May 2002 06:24:19 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id F38C66A907; Thu, 23 May 2002 15:23:33 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9DA366A906; Thu, 23 May 2002 15:23:32 +0300 (EEST) Message-ID: <3CECDF85.2090508@kolumbus.fi> Date: Thu, 23 May 2002 15:24:37 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: arvind.sevalkar@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Sending Binding Error Message References: <200205231204.g4NC4QT20169@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > => an idea reading this message: what are the cases where there should not > be a HAO? So: > - if there should be a HAO and there is not: drop the offending packet > - if there should not be a HAO because the home address should be the > source of the packet: you have your home address! > - other cases (if any)? I can't think of other cases -- if there aren't any, I'm fine with the above proposal. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 08:25:50 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06637 for ; Thu, 23 May 2002 08:25:46 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18692; Thu, 23 May 2002 05:24:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18493; Thu, 23 May 2002 05:24:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NCN5rP007723 for ; Thu, 23 May 2002 05:23:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NCN5Sw007722 for mobile-ip-dist; Thu, 23 May 2002 05:23:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NCN2rP007715 for ; Thu, 23 May 2002 05:23:02 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18315 for ; Thu, 23 May 2002 05:23:08 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19422 for ; Thu, 23 May 2002 06:23:49 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4NCN30E023070 for ; Thu, 23 May 2002 14:23:04 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu May 23 14:25:14 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4RKNX>; Thu, 23 May 2002 14:19:43 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F066E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charlie Perkins'" , "Hesham Soliman (ERA)" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Thu, 23 May 2002 14:22:44 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > I don't understand why certain actions are taken towards > > some proposals and not others. Why was their a big LMM > > requirements doc done for one WG document and not > > for reg reg in MIPv4? > > All these things need to be considered. Using a separate > > process to handle each proposal is not only confusing, > > but will likely lead to no direction for this WG's output. > > > > Please follow one process! > > The explanation is simple. The Regional Registration > specification for IPv4 started much earlier than any > such work for IPv6. You might as well wonder why > there isn't a Security Considerations for base IPv4 > specification. > > However, if it actually matters to the discussion, the > last time I read the LMM document, I determined that > Regional Registration for IPv4 met the requirements > very well. => I'm not disagreeing with that and I haven't looked into it to verify it. But my point is, having one process, one direction and one set of requirements will be very helpful and avoid this confusion. Last time I looked at Regional Regv4 it was going through (finished) last call with some 'minor' comments. Now, a year later, we're discussing major (allegedly) architectural problems! Sigh Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 08:31:51 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06917 for ; Thu, 23 May 2002 08:31:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21885; Thu, 23 May 2002 05:30:16 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20338; Thu, 23 May 2002 05:30:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NCTUrP007863 for ; Thu, 23 May 2002 05:29:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NCTUfX007862 for mobile-ip-dist; Thu, 23 May 2002 05:29:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NCTRrP007855 for ; Thu, 23 May 2002 05:29:27 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04719 for ; Thu, 23 May 2002 05:29:33 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16754 for ; Thu, 23 May 2002 06:29:32 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4NCTV0E027089 for ; Thu, 23 May 2002 14:29:31 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu May 23 14:31:52 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4RK56>; Thu, 23 May 2002 14:26:20 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F066F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Phil Roberts'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] WG process Date: Thu, 23 May 2002 14:29:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > At some level we do follow one process although the steps in each > document may be different as circumstances require. Abstractly > it seems we have a process of problem statement, > requirements, proposals, > proposal selection, wg iterations, wg last call. > > In some cases we have the luxury that the problem statement > and requirements > are clear enough that we get one proposal and are able to > iterate and do > a wg last call. In other cases, it's muddy enough that we > start from the > beginning. In yet other cases it seems clear enough at the > time we start > that a proposal is fine, yet as we iterate we realize there may be > conflicting > requirements, disagreements amongst the constituency, and a > need to step > back and look again. We could force all the steps to occur > on everything > we consider, but personally optimizations where possible > seem productive, > even > though in some cases we have to backtrack. It is > frustrating in a way that > when docs take a long time to get through, there are more > opportunities for > finding problems, or thinking about the original problem. => OK. Thanks for the clarification, but I hope that we try to reduce the amount of time it takes to get an RFC out. I think in some cases (not talking about MIPv6) this hasn't been happening and I'm not blaming the chairs for that, it's a collective effort. > > Why was LMM requirements done for v6 and not for v4? > Probably a lot of > reasons - > the ones that seem clear to me are premature selection of a > proposal, > recognized > in a disagreement about requirements. => The requirement that caused the major disagreement, was common for both v4 and v6. I think at the time I made this comment on the list, no less than 4 times and it was never answered. As for the maturity of the selection, I don't agree with your paragraph above, the selection followed WG concencus procedures, as it was requested by the chairs and lasted for 2 weeks. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 09:46:23 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09972 for ; Thu, 23 May 2002 09:46:22 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29839; Thu, 23 May 2002 07:46:49 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16559; Thu, 23 May 2002 06:45:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NDilrP008062 for ; Thu, 23 May 2002 06:44:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NDilf0008061 for mobile-ip-dist; Thu, 23 May 2002 06:44:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NDiirP008054 for ; Thu, 23 May 2002 06:44:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07799 for ; Thu, 23 May 2002 06:44:45 -0700 (PDT) From: arvind.sevalkar@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23303 for ; Thu, 23 May 2002 07:44:43 -0600 (MDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002052319184591:3409 ; Thu, 23 May 2002 19:18:45 +0530 Subject: Re: [mobile-ip] Sending Binding Error Message To: Francis Dupont Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Thu, 23 May 2002 19:14:23 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/23/2002 07:15:05 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/23/2002 07:18:45 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/23/2002 07:18:48 PM, Serialize complete at 05/23/2002 07:18:48 PM Message-ID: X-Priority: 3 (Normal) Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Francis Dupont etagne.fr> cc: arvind.sevalkar@lntinfotech.com, Sent by: mobile-ip@sunroof.eng.sun.com Francis.Dupont@enst-bre Subject: Re: [mobile-ip] Sending Binding tagne.fr Error Message 05/23/2002 05:34 PM In your previous mail you wrote: > Binding Error message contains home address where in the address from the > Home Address destination option of the packet with unrecognized MH message. > But in case when packet contains unknown MH type and Home address > destination option is not present then put 0 in the home address field of > the Binding error message.. > Am I right? Yes, though in another thread I believe we ended up in the conclusion that we could include HAOs even to CNs. Is there any case left where a HAO would be missing and we would need to fill in a 0? Hmm... I suppose someone could still send a bad MH message without a HAO so... perhaps we should state that the address should be set to the unspecified address if the offending message does not include a HAO. => an idea reading this message: what are the cases where there should not be a HAO? So: - if there should be a HAO and there is not: drop the offending packet - if there should not be a HAO because the home address should be the source of the packet: you have your home address! - other cases (if any)? Regards Francis.Dupont@enst-bretagne.fr ===>>> I think if MH type is unknown, then identifying whether HAO should be present or not seems not possible. In such a scenario would it not be better to move the home address field of Binding Error message as a option? I'm sorry I missed the thread where it was previously discussed. Regards Arvind From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 10:04:35 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10964 for ; Thu, 23 May 2002 10:04:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00892; Thu, 23 May 2002 07:02:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20170; Thu, 23 May 2002 07:02:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NE0qrP008174 for ; Thu, 23 May 2002 07:00:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NE0qI8008173 for mobile-ip-dist; Thu, 23 May 2002 07:00:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NE0mrP008166 for ; Thu, 23 May 2002 07:00:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28606 for ; Thu, 23 May 2002 07:00:53 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29540 for ; Thu, 23 May 2002 07:00:52 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4NE0k0E022454 for ; Thu, 23 May 2002 16:00:51 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu May 23 15:57:51 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4RQ2R>; Thu, 23 May 2002 15:54:41 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0674@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , "Hesham Soliman (ERA)" , Phil Roberts , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Thu, 23 May 2002 15:57:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > => Sure, but where do you draw the line? And what if > > a single node has 10 application proxies? What if > > there were no other applications that the two nodes > > could use? > > There is no clear line to draw here. > > > > The line is drawn where the failure of a network element causes the > session between the two hosts to fail. => Then there is no difference between an ALG and a HA/GFA. > > > => I'm not trying to start the debate, but the point > > is,RFC 1958 is being quoted, so either we use that > > quote for all the WG docs ( can of worms) or we > > don't quote it. I'm happy with either option. > > > > Again where do we draw the line between allegedly > > breaking the architecture of the Internet and > > performance gain. How much performance gain is > > the Internet architecture worth ? :) :) > > > > Like I said, I am not going to debate the issue here. Open > a separate thread on the topic if you want to debate. => You brought the issue of architecctural violations weeks ago. If you don't want to debate it, then the issue should be dropped. Unless someone else supports it, but I haven't seen this on the list. Hesham > > jak > > > From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 10:09:54 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11168 for ; Thu, 23 May 2002 10:09:53 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07532; Thu, 23 May 2002 08:09:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21789; Thu, 23 May 2002 07:09:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NE8nrP008274 for ; Thu, 23 May 2002 07:08:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NE8mKk008273 for mobile-ip-dist; Thu, 23 May 2002 07:08:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NE8jrP008266 for ; Thu, 23 May 2002 07:08:45 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21721 for ; Thu, 23 May 2002 07:08:50 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04124 for ; Thu, 23 May 2002 07:08:50 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4NE8mPI016897; Thu, 23 May 2002 07:08:48 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABS48220; Thu, 23 May 2002 07:05:48 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA04174; Thu, 23 May 2002 07:08:47 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15596.63471.720071.829041@thomasm-u1.cisco.com> Date: Thu, 23 May 2002 07:08:47 -0700 (PDT) To: "Alper E. YEGIN" Cc: Subject: [mobile-ip] RR and BU to HA In-Reply-To: <030501c20201$4db7cff0$8b6015ac@AlperVAIO> References: <030501c20201$4db7cff0$8b6015ac@AlperVAIO> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alper E. YEGIN writes: > Hello, > > We have a question on the security of BUs... > > The current draft identifies a need to verify the > return routability of CoA when the BU is sent to > a CN. > > But it suggests that one can use IPsec between > the MN and the HA when MN is sending a BU, > and this should be sufficient.... Shouldn't we be > doing a RR on the CoA even if we are using IPsec? Alper, I don't think it's necessary. A normal security association decides, for example, whether to pass data through the stack/forwarding-path given the credentials. Since the home agent "owns" the source subnet, I don't think it's much of a stretch to say that it can decide based upon presented credential whether a MN can move bindings around as well. That is, the credential itself could imply "allow pass/forward/rebind". This is distinctly different than the correspondent node case which has absolutely no relationship with the subnet in question (in general). In that case the credential would need to be more specific; where you could imply it above, it would need to be specific if you want to guard against inside attacks (eg, attacks authenticated but malicious MN's). On the CN insufficient authz could lead to a hijacking attack since it doesn't "own" the subnet and has no way to know who that address/prefix was delegated to. This isn't the case on the HA since where the worst that could happen is a depletion of IP addresses attack on that subnet, and even that would be pretty easy to defend against. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 10:22:41 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11918 for ; Thu, 23 May 2002 10:22:41 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14582; Thu, 23 May 2002 08:22:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25108; Thu, 23 May 2002 07:22:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NEL7rP008380 for ; Thu, 23 May 2002 07:21:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NEL7HD008379 for mobile-ip-dist; Thu, 23 May 2002 07:21:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NEL4rP008372 for ; Thu, 23 May 2002 07:21:04 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24810; Thu, 23 May 2002 07:21:09 -0700 (PDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13837; Thu, 23 May 2002 08:21:08 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g4NEL6PI022215; Thu, 23 May 2002 07:21:06 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABS48373; Thu, 23 May 2002 07:18:06 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA04177; Thu, 23 May 2002 07:21:05 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15596.64209.772618.6875@thomasm-u1.cisco.com> Date: Thu, 23 May 2002 07:21:05 -0700 (PDT) To: Samita Chakrabarti Cc: alper@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA In-Reply-To: <200205230643.g4N6hV6U423706@jurassic.eng.sun.com> References: <200205230643.g4N6hV6U423706@jurassic.eng.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Samita Chakrabarti writes: > > > > > The current draft identifies a need to verify the > > return routability of CoA when the BU is sent to > > a CN. > > > > But it suggests that one can use IPsec between > > the MN and the HA when MN is sending a BU, > > and this should be sufficient.... Shouldn't we be > > doing a RR on the CoA even if we are using IPsec? > > > > The draft does not specify, but my understanding is that MN would > use ESP transport mode with srcaddr=COA for sending BU to HA. > As long as there is correct SA between MN-homeaddr and HA and > home-addr in HOA dst option matches with the authenticated BU > MH home-addr part, there is no problem. In CN case, separate > COA RR check is necessary to avoid reflection attack from another > malicous MN. > > However, I see some issues in : > 11.6.6. Forwarding from a Previous Care-of Address > > > section, where it says that BU home-addr and HOA-dst option both > contain the previous COA address. So, the question is how does HA > match the security association in this case ? SA's are matched by the incoming SPI and (somewhat uselessly, IMO) the *destination* IP address (ie, the HA). The SA lookup logic itself shouldn't depend on the source address (ie, COA) being the same packet to packet [*]. > I assume that the draft assumes the sequence would be: > 1. update HA first with your new COA with HoA= MN's home-addr > 2. Then send BU to forward packet from previous COA. > In this case HA should do a few extra checks to make sure that the > new COA already has a valid BCE. > > But, I am still not sure how would HA do the SA check for homeaddr > in this case ( since homeaddr=previous COA), I believe there is no > security association with the previous COA and HA. The incoming COA should have never played a part in the decision [**]. It's ex/implicit authorization from the *credential* which established whether a node is allowed to rebind itself to another location. Mike [*] there is obviously the access control aspect of IPsec here too, but a wildcarded filter on the source would allow it to pass [**] other than internal for policy reasons, of course. From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 11:01:02 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13452 for ; Thu, 23 May 2002 11:01:02 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12886; Thu, 23 May 2002 09:01:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12710; Thu, 23 May 2002 08:00:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NExSrP008523 for ; Thu, 23 May 2002 07:59:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NExSNQ008522 for mobile-ip-dist; Thu, 23 May 2002 07:59:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NExPrP008515 for ; Thu, 23 May 2002 07:59:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04454 for ; Thu, 23 May 2002 07:59:31 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11495 for ; Thu, 23 May 2002 08:59:30 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4NExJHs013572; Thu, 23 May 2002 07:59:19 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABS48867; Thu, 23 May 2002 07:56:18 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA04190; Thu, 23 May 2002 07:59:18 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15597.965.981185.730673@thomasm-u1.cisco.com> Date: Thu, 23 May 2002 07:59:17 -0700 (PDT) To: Francis Dupont Cc: Samita Chakrabarti , alper@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA In-Reply-To: <200205231153.g4NBreT20002@givry.rennes.enst-bretagne.fr> References: <200205230643.g4N6hV6U423706@jurassic.eng.sun.com> <200205231153.g4NBreT20002@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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont writes: > The draft does not specify, but my understanding is that MN would > use ESP transport mode with srcaddr=COA for sending BU to HA. > > => you have the choice between ESP transport mode with the COA > protected (i.e. repeated) and AH transport mode. Tunnel modes > give nothing more than complexity. I hope this is not to imply that a tunnel mode SA's aren't sufficient to protect BU's. It should be, and should be allowed. If you already have a tunnel mode SA back to your home agent (because it's, say, at the edge of your home network which is walled off), it would be pretty wasteful to force the use of a transport mode SA as well. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 11:36:17 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14916 for ; Thu, 23 May 2002 11:36:16 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03118; Thu, 23 May 2002 08:34:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14920; Thu, 23 May 2002 08:34:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NFXJrP008671 for ; Thu, 23 May 2002 08:33:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NFXJkQ008670 for mobile-ip-dist; Thu, 23 May 2002 08:33:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NFXGrP008663 for ; Thu, 23 May 2002 08:33:16 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22615 for ; Thu, 23 May 2002 08:33:21 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29561 for ; Thu, 23 May 2002 09:33:21 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4NFX6Hs006381; Thu, 23 May 2002 08:33:06 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABS49458; Thu, 23 May 2002 08:30:05 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA04193; Thu, 23 May 2002 08:33:05 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15597.2993.450025.939279@thomasm-u1.cisco.com> Date: Thu, 23 May 2002 08:33:05 -0700 (PDT) To: Francis Dupont Cc: "Alper E. YEGIN" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA In-Reply-To: <200205230955.g4N9tcT19737@givry.rennes.enst-bretagne.fr> References: <030501c20201$4db7cff0$8b6015ac@AlperVAIO> <200205230955.g4N9tcT19737@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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont writes: > The current draft identifies a need to verify the > return routability of CoA when the BU is sent to > a CN. > > => this is an open point. Some believe RR check is simply > mandatory, some believe RR check is only one possible way > to fulfill security requirements and a suitable IPsec protection > should not need an extra RR check (the argument is the RR check > is not possible for the HA so "suitable IPsec" includes the trust > in the MN to not provide a fake CoA). Francis, I thought of another way of thinking why it's not necessary. IPsec as an access control mechanism, protects a host (transport) or router (tunnel) from unauthorized traversal past the access control point, either up the stack or through the forwarding plane. Thus, unauthorized packets are not allowed, say, to do HTTP GET's on web servers which are behind that access control point. If you have credentials to burrow through (ie, make an SA), you're at liberty to send whatever packets you care to, subject to the hole's restrictions. We can view (re)binding the same way as HTTP. That is, if you have sufficient authz to create a hole in the IPsec firewall -- on the HA presumably -- you are at liberty to send binding packets through the hole, just like you might be able to send packets to any other server through the hole. In this case, the home agent is quite similar to any other server; indeed, it is providing a service: mobility tunneling. Mike From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 11:37:14 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14975 for ; Thu, 23 May 2002 11:37:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03901; Thu, 23 May 2002 08:35:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15532; Thu, 23 May 2002 08:35:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NFYkrP008701 for ; Thu, 23 May 2002 08:34:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NFYjuW008700 for mobile-ip-dist; Thu, 23 May 2002 08:34:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NFYfrP008693 for ; Thu, 23 May 2002 08:34:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12294 for ; Thu, 23 May 2002 08:34:47 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25176 for ; Thu, 23 May 2002 08:34:46 -0700 (PDT) Received: from fokus.gmd.de (ekina [193.175.135.180]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g4NFYjE05176 for ; Thu, 23 May 2002 17:34:45 +0200 (MEST) Message-ID: <3CED0C15.D65DCDB2@fokus.gmd.de> Date: Thu, 23 May 2002 17:34:45 +0200 From: John Williams Floroiu Organization: GMD FOKUS - CC MOBIS X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] are L2 triggers "secure" ? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, I would like to rise a question regarding the tunnel based handover (section 3.2 in draft-ietf-mobileip-fast-mipv6-04.txt). I believe the use of L2 triggers might introduce some security holes as long as their "safety" cannot be correctly assess by the layer 3. I am not a L2 technology expert, therefore I am not sure how L2 triggers are actually implemented. However, taking as an example the scenario described in fig. 8 (p.25), and trying to extrapolate somehow the functionality of WaveLAN (which is not the only but anyway the most widely considered case study), I could imagine the situation described below occurring. An attacker spoofing the MAC address of a legitimate MN may force itself to attach to a different access point (nAP) than the one the MN is currently using (oAP). This event happening at the nAP is most probably the source of a L2-TT trigger nAR is going to receive, and the effect is that the incoming MN traffic is going to be mis-routed, since the reception of L2-TT at nAR triggers the initiation of the handover between (a false) nAR and oAR --- well I do not really know how nAR could learn the address of oAR in general, again, maybe some technologies which I do not know about support this. The bottom line is that an attacker spoofing the identity --- MAC address or whatever ID appearing in the radio control messages, like WaveLAN beacons --- of a legitimate mobile terminal, can produce fake L2 triggers by attaching to false access points, and mount in this way DoS attacks against MNs. John. From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 11:38:31 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15053 for ; Thu, 23 May 2002 11:38:31 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02772; Thu, 23 May 2002 09:38:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16390; Thu, 23 May 2002 08:37:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NFb9rP008802 for ; Thu, 23 May 2002 08:37:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NFb9sj008801 for mobile-ip-dist; Thu, 23 May 2002 08:37:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NFb6rP008792 for ; Thu, 23 May 2002 08:37:06 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16117 for ; Thu, 23 May 2002 08:37:12 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26965 for ; Thu, 23 May 2002 08:37:11 -0700 (PDT) Message-ID: <00e001c2026f$6e7ac440$516015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "'Charlie Perkins'" Cc: References: <4DA6EA82906FD511BE2F00508BCF0538044F066E@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Thu, 23 May 2002 08:35:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham, > => I'm not disagreeing with that and I haven't > looked into it to verify it. But my point is, > having one process, one direction and one > set of requirements will be very helpful > and avoid this confusion. > Last time I looked at Regional Regv4 it was > going through (finished) last call with some 'minor' > comments. Now, a year later, we're discussing > major (allegedly) architectural problems! > There's a learing process involved here. Issues that don't look like a problem become more relevent in light of subsequent events. Real world example: airport security in the light of 9/11. There has been a lot of focus over the last year on the architectural implications of proxies, in particular, application proxies. Sally Floyd's draft and Brian Carpenter's revision of the Internet architecture draft to talk about proxies, along with publications by Internet pioneers such as Dave Clark discussing modifications to end to end as the Internet evolves have all lead to a closer look at what the effects of proxies are on the Internet architecture and how to maintain the spirit of end to end as that architecture evolves. So expecting the WG and WG chairs to have anticipated this debate last year is probably a little much to ask. We learn as we go along. jak From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 11:45:59 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15239 for ; Thu, 23 May 2002 11:45:59 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA11127; Thu, 23 May 2002 09:46:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA20451; Thu, 23 May 2002 08:45:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NFilrP008890 for ; Thu, 23 May 2002 08:44:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NFikqP008889 for mobile-ip-dist; Thu, 23 May 2002 08:44:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NFihrP008882 for ; Thu, 23 May 2002 08:44:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27192 for ; Thu, 23 May 2002 08:44:49 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10333 for ; Thu, 23 May 2002 09:45:33 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4NFil0E017071 for ; Thu, 23 May 2002 17:44:47 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu May 23 17:47:07 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 17:33:43 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F067C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , "Hesham Soliman (ERA)" , "'Charlie Perkins'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Thu, 23 May 2002 17:44:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > There's a learing process involved here. Issues that don't > look like a > problem become more relevent in light of subsequent events. > Real world > example: airport security in the light of 9/11. > > There has been a lot of focus over the last year on the > architectural > implications of proxies, in particular, application proxies. Sally > Floyd's draft and Brian Carpenter's revision of the Internet > architecture draft to talk about proxies, along with publications by > Internet pioneers such as Dave Clark discussing > modifications to end to > end as the Internet evolves have all lead to a closer look > at what the > effects of proxies are on the Internet architecture and how > to maintain > the spirit of end to end as that architecture evolves. > > So expecting the WG and WG chairs to have anticipated this > debate last > year is probably a little much to ask. We learn as we go along. > => I understand that we learn as we go and I never claimed to not be part of that learning process, all I'm asking for is: - Consistency - Respect of (soft) deadlines set by WG concensus calls, last calls ...etc - Accelerating the process of moving proposals forward. It is a real shame that a draft like regional has been in last call for a year or even more now. There will be RFCs that will come out and then later be corrected/deprecated or whatever. We will always be learning...we can't stop progressing drafts until we stop learning. Hesham From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 11:48:03 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15396 for ; Thu, 23 May 2002 11:48:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09323; Thu, 23 May 2002 09:48:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21235; Thu, 23 May 2002 08:47:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NFlArP008934 for ; Thu, 23 May 2002 08:47:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NFlAuB008933 for mobile-ip-dist; Thu, 23 May 2002 08:47:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NFl7rP008926 for ; Thu, 23 May 2002 08:47:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA28029 for ; Thu, 23 May 2002 08:47:13 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA08256 for ; Thu, 23 May 2002 09:47:11 -0600 (MDT) Message-ID: <010901c20270$cc94ed20$516015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "Phil Roberts" , References: <4DA6EA82906FD511BE2F00508BCF0538044F0674@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] Regional Registration Last Call Resolution Issue #4 Date: Thu, 23 May 2002 08:44:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > => You brought the issue of architecctural violations > weeks ago. If you don't want to debate it, then > the issue should be dropped. Unless someone else > supports it, but I haven't seen this on the list. > Phil brought the issue up w.r.t. to the GFA, and I agree and have debated it here. I've never claimed any architectural violation for any of the fast handover algorithms. jak From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 11:58:13 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15760 for ; Thu, 23 May 2002 11:58:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15773; Thu, 23 May 2002 09:58:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25124; Thu, 23 May 2002 08:57:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NFuorP009067 for ; Thu, 23 May 2002 08:56:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NFuoEL009066 for mobile-ip-dist; Thu, 23 May 2002 08:56:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NFulrP009059; Thu, 23 May 2002 08:56:47 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22287; Thu, 23 May 2002 08:56:53 -0700 (PDT) Received: from hermes.fm.intel.com (fmr01.intel.com [192.55.52.18]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17348; Thu, 23 May 2002 08:56:53 -0700 (PDT) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by hermes.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.46 2002/05/09 18:12:26 root Exp $) with ESMTP id g4NFvTw26121; Thu, 23 May 2002 15:57:29 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxv041-1.fm.intel.com [132.233.48.109]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.20 2002/05/13 20:36:03 root Exp $) with SMTP id g4NG04r29131; Thu, 23 May 2002 16:00:04 GMT Received: from FMSMSX018.fm.intel.com ([132.233.42.197]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002052308565717824 ; Thu, 23 May 2002 08:56:57 -0700 Received: by fmsmsx018.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 08:56:47 -0700 Message-ID: From: "Liu, Changwen" To: mobile-ip@sunroof.eng.sun.com, NGtrans List Subject: [mobile-ip] New draft: draft-liu-mobileip-mipv6tomipv4-00.txt Date: Thu, 23 May 2002 08:56:37 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: To all, I've submitted a draft named "Connecting Mobile IPv6 Nodes Across IPv4 Clouds Back To IPv6 Domains With Mobile IPv4" that updates my previous draft "Mobile IPv6 over Mobile IPv4". The new draft specifies a mechanism for Mobile IPv6 nodes of any IPv6 site to continue utilizing Mobile IPv6 services when they roam into IPv4 domains. The draft can be retrieved from http://www.ietf.org/internet-drafts/draft-liu-mobileip-mipv6tomipv4-00.txt Your feedbacks and comments on the draft are appreciated. Thanks in advance. Regards, changwen From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 12:31:52 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17237 for ; Thu, 23 May 2002 12:31:52 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11115; Thu, 23 May 2002 10:32:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08280; Thu, 23 May 2002 09:31:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NGUerP009416 for ; Thu, 23 May 2002 09:30:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NGUd7D009415 for mobile-ip-dist; Thu, 23 May 2002 09:30:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NGUarP009408 for ; Thu, 23 May 2002 09:30:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08649 for ; Thu, 23 May 2002 09:30:43 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10411 for ; Thu, 23 May 2002 10:31:27 -0600 (MDT) Message-ID: <016101c20276$91c29480$516015ac@T23KEMPF> From: "James Kempf" To: "John Williams Floroiu" , References: <3CED0C15.D65DCDB2@fokus.gmd.de> Subject: Re: [mobile-ip] are L2 triggers "secure" ? Date: Thu, 23 May 2002 09:26:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I don't recall if the FMIPv6 draft specifically mentions this, but in the low latency MIPv4 draft we do mention that the MAC layer needs to be secure in order to use tunnels. In FMIPv6, this is true both for Prereg and Postreg/BETH, since tunnels are used for both. Perhaps the draft needs changing. In addition, you are correct that 802.11 security won't currently allow secure tunnels. However, it should also be noted that on 802.11 including 802.1x, ARP and ND are not secure either. There is no way to prevent a host from stealing a MAC address on 802.11, unlike switched Ethernet where 802.1x ties a switch port to the MAC address and won't allow the host to change it. jak ----- Original Message ----- From: "John Williams Floroiu" To: Sent: Thursday, May 23, 2002 8:34 AM Subject: [mobile-ip] are L2 triggers "secure" ? > Hi, > > I would like to rise a question regarding the tunnel based handover (section 3.2 in > draft-ietf-mobileip-fast-mipv6-04.txt). I believe the use of L2 > triggers might introduce some security holes as long as their "safety" cannot be correctly assess by the layer 3. > > I am not a L2 technology expert, therefore I am not sure how L2 triggers are actually implemented. However, taking as an > example the scenario described in fig. 8 (p.25), and trying to extrapolate somehow the functionality of WaveLAN (which > is not the only but anyway the most widely considered case study), I could imagine the situation described below > occurring. > > An attacker spoofing the MAC address of a legitimate MN may force itself to attach to a different access point (nAP) > than the one the MN is currently using (oAP). This event happening at the nAP is most probably the source of a L2-TT > trigger nAR is going to receive, and the effect is that the incoming MN traffic is going to be mis-routed, since the > reception of L2-TT at nAR triggers the initiation of the handover between (a false) nAR and oAR --- well I do not really > know how nAR could learn the address of oAR in general, again, maybe some technologies which I do not know about support > this. > > The bottom line is that an attacker spoofing the identity --- MAC address or whatever ID appearing in the radio control > messages, like WaveLAN beacons --- of a legitimate mobile terminal, can produce fake L2 triggers by attaching to false > access points, and mount in this way DoS attacks against MNs. > > John. > From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 13:15:14 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18772 for ; Thu, 23 May 2002 13:15:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA28432; Thu, 23 May 2002 11:14:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29406; Thu, 23 May 2002 10:14:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NHD7rP009534 for ; Thu, 23 May 2002 10:13:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NHD7fP009533 for mobile-ip-dist; Thu, 23 May 2002 10:13:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NHD3rP009526 for ; Thu, 23 May 2002 10:13:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25390 for ; Thu, 23 May 2002 10:13:10 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27679 for ; Thu, 23 May 2002 11:13:09 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4NHCkn09693; Thu, 23 May 2002 19:12:46 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA23460; Thu, 23 May 2002 19:12:46 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4NHCjT21473; Thu, 23 May 2002 19:12:46 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205231712.g4NHCjT21473@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: Samita Chakrabarti , alper@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA In-reply-to: Your message of Thu, 23 May 2002 07:59:17 PDT. <15597.965.981185.730673@thomasm-u1.cisco.com> Date: Thu, 23 May 2002 19:12:45 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > The draft does not specify, but my understanding is that MN would > use ESP transport mode with srcaddr=COA for sending BU to HA. > > => you have the choice between ESP transport mode with the COA > protected (i.e. repeated) and AH transport mode. Tunnel modes > give nothing more than complexity. I hope this is not to imply that a tunnel mode SA's aren't sufficient to protect BU's. It should be, and should be allowed. => there are allowed but when there is no already available SA and the SA will be setup only to protect the BU then a transport mode should be used. If you already have a tunnel mode SA back to your home agent (because it's, say, at the edge of your home network which is walled off), it would be pretty wasteful to force the use of a transport mode SA as well. => we agree: MAY for tunnel, SHOULD for transport. BTW I don't know how to encode this in a policy (:-). Regards Francis.Dupont@enst-bretagne.fr PS: my main target in this discussion is to not go backward, i.e., to get *no* requirement for a RR check when IPsec protects the BU. From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 13:18:39 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18941 for ; Thu, 23 May 2002 13:18:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00888; Thu, 23 May 2002 11:18:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02504; Thu, 23 May 2002 10:18:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NHHSrP009602 for ; Thu, 23 May 2002 10:17:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NHHSek009601 for mobile-ip-dist; Thu, 23 May 2002 10:17:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NHHOrP009594 for ; Thu, 23 May 2002 10:17:24 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01696 for ; Thu, 23 May 2002 10:17:29 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07965 for ; Thu, 23 May 2002 11:17:29 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA27262; Thu, 23 May 2002 10:17:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4NHHSI28850; Thu, 23 May 2002 10:17:28 -0700 X-mProtect: <200205231717> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdakN91e; Thu, 23 May 2002 10:17:26 PDT Message-ID: <3CED2426.2D62F3E8@iprg.nokia.com> Date: Thu, 23 May 2002 10:17:26 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: John Williams Floroiu CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] are L2 triggers "secure" ? References: <3CED0C15.D65DCDB2@fokus.gmd.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello John, I believe that any Fast Handover message (perhaps including Context Transfer options) used by a mobile node to "confirm" its arrival at the new access router MUST contain authentication data. Regards, Charlie P. John Williams Floroiu wrote: > > Hi, > > I would like to rise a question regarding the tunnel based handover (section 3.2 in > draft-ietf-mobileip-fast-mipv6-04.txt). I believe the use of L2 > triggers might introduce some security holes as long as their "safety" cannot be correctly assess by the layer 3. > > I am not a L2 technology expert, therefore I am not sure how L2 triggers are actually implemented. However, taking as an > example the scenario described in fig. 8 (p.25), and trying to extrapolate somehow the functionality of WaveLAN (which > is not the only but anyway the most widely considered case study), I could imagine the situation described below > occurring. > > An attacker spoofing the MAC address of a legitimate MN may force itself to attach to a different access point (nAP) > than the one the MN is currently using (oAP). This event happening at the nAP is most probably the source of a L2-TT > trigger nAR is going to receive, and the effect is that the incoming MN traffic is going to be mis-routed, since the > reception of L2-TT at nAR triggers the initiation of the handover between (a false) nAR and oAR --- well I do not really > know how nAR could learn the address of oAR in general, again, maybe some technologies which I do not know about support > this. > > The bottom line is that an attacker spoofing the identity --- MAC address or whatever ID appearing in the radio control > messages, like WaveLAN beacons --- of a legitimate mobile terminal, can produce fake L2 triggers by attaching to false > access points, and mount in this way DoS attacks against MNs. > > John. From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 13:29:38 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19313 for ; Thu, 23 May 2002 13:29:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05713; Thu, 23 May 2002 10:27:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07490; Thu, 23 May 2002 10:27:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NHQPrP009701 for ; Thu, 23 May 2002 10:26:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NHQPI1009700 for mobile-ip-dist; Thu, 23 May 2002 10:26:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NHQMrP009693 for ; Thu, 23 May 2002 10:26:22 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06956 for ; Thu, 23 May 2002 10:26:26 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14997 for ; Thu, 23 May 2002 11:27:10 -0600 (MDT) Received: from fokus.gmd.de (ekina [193.175.135.180]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g4NHQLE20407; Thu, 23 May 2002 19:26:22 +0200 (MEST) Message-ID: <3CED263D.34390ACE@fokus.gmd.de> Date: Thu, 23 May 2002 19:26:21 +0200 From: John Williams Floroiu Organization: GMD FOKUS - CC MOBIS X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] are L2 triggers "secure" ? References: <3CED0C15.D65DCDB2@fokus.gmd.de> <016101c20276$91c29480$516015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James, > In FMIPv6, this is true both for Prereg > and Postreg/BETH, since tunnels are used for both. Perhaps the draft > needs changing. sorry, but who exactly are "Prereg" and "Postreg", I could only find HI, HACK and HTT. > [...] switched > Ethernet where 802.1x ties a switch port to the MAC address and won't > allow the host to change it. okay, but this applies I guess to wired infrastructures rather than wireless ones. John. From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 13:43:38 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19925 for ; Thu, 23 May 2002 13:43:37 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14991; Thu, 23 May 2002 11:43:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14878; Thu, 23 May 2002 10:43:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NHgXrP009800 for ; Thu, 23 May 2002 10:42:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NHgXnY009799 for mobile-ip-dist; Thu, 23 May 2002 10:42:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NHgTrP009792 for ; Thu, 23 May 2002 10:42:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12135 for ; Thu, 23 May 2002 10:42:35 -0700 (PDT) Received: from hosting-network.com (NODE1.HOSTING-NETWORK.COM [66.216.6.1] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA21621 for ; Thu, 23 May 2002 10:42:34 -0700 (PDT) Received: (qmail 8726 invoked from network); 23 May 2002 17:42:33 -0000 Received: from unknown (HELO dell8100rjm) (12.251.150.156) by node-28.hosting-network.com with SMTP; 23 May 2002 17:42:33 -0000 Reply-To: From: "Robert J Marks" To: "'Charles E. Perkins'" , "'John Williams Floroiu'" Cc: Subject: RE: [mobile-ip] are L2 triggers "secure" ? Date: Thu, 23 May 2002 12:42:21 -0500 Organization: Marks Mobile Consulting, LLC Message-ID: <000601c20281$3116cdd0$6501a8c0@dell8100rjm> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-reply-to: <3CED2426.2D62F3E8@iprg.nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, I believe it depends upon the capabilities and requirements of the access network. I do not think that all access networks require authentication data in a "handoff confirmed" message. Bob Charles E. Perkins wrote: > > Hello John, > > I believe that any Fast Handover message (perhaps including > Context Transfer options) used by a mobile node to "confirm" > its arrival at the new access router MUST contain authentication > data. > > Regards, > Charlie P. > > > John Williams Floroiu wrote: > > > > Hi, > > > > I would like to rise a question regarding the tunnel based > handover (section 3.2 in > > draft-ietf-mobileip-fast-mipv6-04.txt). I believe the use of L2 > > triggers might introduce some security holes as long as > their "safety" cannot be correctly assess by the layer 3. > > > > I am not a L2 technology expert, therefore I am not sure > how L2 triggers are actually implemented. However, taking as an > > example the scenario described in fig. 8 (p.25), and trying > to extrapolate somehow the functionality of WaveLAN (which > > is not the only but anyway the most widely considered case > study), I could imagine the situation described below > > occurring. > > > > An attacker spoofing the MAC address of a legitimate MN may > force itself to attach to a different access point (nAP) > > than the one the MN is currently using (oAP). This event > happening at the nAP is most probably the source of a L2-TT > > trigger nAR is going to receive, and the effect is that the > incoming MN traffic is going to be mis-routed, since the > > reception of L2-TT at nAR triggers the initiation of the > handover between (a false) nAR and oAR --- well I do not really > > know how nAR could learn the address of oAR in general, > again, maybe some technologies which I do not know about support > > this. > > > > The bottom line is that an attacker spoofing the identity > --- MAC address or whatever ID appearing in the radio control > > messages, like WaveLAN beacons --- of a legitimate mobile > terminal, can produce fake L2 triggers by attaching to false > > access points, and mount in this way DoS attacks against MNs. > > > > John. > From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 13:50:57 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20247 for ; Thu, 23 May 2002 13:50:56 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18763; Thu, 23 May 2002 11:50:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18583; Thu, 23 May 2002 10:50:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NHo6rP009887 for ; Thu, 23 May 2002 10:50:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NHo6NK009886 for mobile-ip-dist; Thu, 23 May 2002 10:50:06 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NHo3rP009879 for ; Thu, 23 May 2002 10:50:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09359 for ; Thu, 23 May 2002 10:50:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA17953 for ; Thu, 23 May 2002 11:50:06 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA29090; Thu, 23 May 2002 10:50:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4NHo5X11979; Thu, 23 May 2002 10:50:05 -0700 X-mProtect: <200205231750> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdE0w2z7; Thu, 23 May 2002 10:50:03 PDT Message-ID: <3CED2BCC.859AB84C@iprg.nokia.com> Date: Thu, 23 May 2002 10:50:04 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: bob@marksmob.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] are L2 triggers "secure" ? References: <000601c20281$3116cdd0$6501a8c0@dell8100rjm> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Robert J Marks wrote: > Hello Bob, Maybe the layer-2 messages don't require authentication, but I reckon the layer-3 messages do. The only way otherwise would be if every router within the access network had very rigid controls and filters on every layer-3 packet, which seems un-IP-like to me. Regards, Charlie P. > Hi Charlie, > > I believe it depends upon the capabilities and requirements > of the access network. I do not think that all access networks > require authentication data in a "handoff confirmed" message. > > Bob > > Charles E. Perkins wrote: > > > > Hello John, > > > > I believe that any Fast Handover message (perhaps including > > Context Transfer options) used by a mobile node to "confirm" > > its arrival at the new access router MUST contain authentication > > data. > > > > Regards, > > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 14:11:55 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21204 for ; Thu, 23 May 2002 14:11:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11663; Thu, 23 May 2002 12:12:29 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28081; Thu, 23 May 2002 11:09:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NI8prP010036 for ; Thu, 23 May 2002 11:08:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NI8p5P010035 for mobile-ip-dist; Thu, 23 May 2002 11:08:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NI8mrP010028 for ; Thu, 23 May 2002 11:08:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24127 for ; Thu, 23 May 2002 11:08:53 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08520 for ; Thu, 23 May 2002 12:08:52 -0600 (MDT) Received: from fokus.gmd.de (ekina [193.175.135.180]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g4NI8cE24677; Thu, 23 May 2002 20:08:39 +0200 (MEST) Message-ID: <3CED3026.6A29A8D7@fokus.gmd.de> Date: Thu, 23 May 2002 20:08:38 +0200 From: John Williams Floroiu Organization: GMD FOKUS - CC MOBIS X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: "Charles E. Perkins" CC: bob@marksmob.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] are L2 triggers "secure" ? References: <000601c20281$3116cdd0$6501a8c0@dell8100rjm> <3CED2BCC.859AB84C@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charles, > Maybe the layer-2 messages don't require authentication, but > I reckon the layer-3 messages do. [...] True, but in case of tunnel-based handover the layer 3 messages are exchanged only between ARs. It can be assumed they are secure (they can be made secure), but the L2 triggers themselves may not. Could layer 3 rely on layer 2 security (when deciding a handover) ? Encryption in WaveLAN - which proved to be quite easy breakable - is the first example coming into my mind. Regards, John. From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 14:13:53 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21357 for ; Thu, 23 May 2002 14:13:52 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01481; Thu, 23 May 2002 11:12:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29175; Thu, 23 May 2002 11:12:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NIBOrP010087 for ; Thu, 23 May 2002 11:11:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NIBOtO010086 for mobile-ip-dist; Thu, 23 May 2002 11:11:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NIBMrP010079 for ; Thu, 23 May 2002 11:11:22 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08019 for ; Thu, 23 May 2002 14:11:27 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g4NIBSqp018473 for ; Thu, 23 May 2002 14:11:28 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g4NIBSBI018472 for mobile-ip@sunroof.eng.sun.com; Thu, 23 May 2002 14:11:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NBo6rP007558 for ; Thu, 23 May 2002 04:50:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10876 for ; Thu, 23 May 2002 04:50:12 -0700 (PDT) Received: from mail47.fg.online.no (mail47-s.fg.online.no [148.122.161.47]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04350 for ; Thu, 23 May 2002 04:50:11 -0700 (PDT) Received: from FRNI (tilt.birdstep.org [194.143.101.14]) by mail47.fg.online.no (8.9.3/8.9.3) with ESMTP id NAA17149 for ; Thu, 23 May 2002 13:50:09 +0200 (MET DST) From: "Frode B. Nilsen" To: Subject: [mobile-ip] Registration with co-located CoA via FA (question triggered by NAT traversal draft) Date: Thu, 23 May 2002 13:48:15 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The latest NAT traversal draft (draft-ietf-mobileip-nat-traversal-02.txt) includes a discussion on how to handle the case when the MN makes a registration via a FA (eg. in response to a R-bit in an AA) using a co-located CoA (as opposed to an advertised CoA from the FA). Technicall this is possible, of course, but I had never though of the case before and asked myself the following questions: (1) Is this case within the scope of RFC3220? (2) In what deployment scenarios would this case be natural and/or preferrable? Taking a closer look at RFC3220 I find the following somewhat contradicting statements: [QUOTE BEGIN] ...... Section 2.1.1 Mobility Agent Advertisement Extension ----------------------------------------------------- ...... R Registration required. Registration with this foreign agent (or another foreign agent on this link) is required even when using a co-located care-of address. ....... Section 3.1 Registration Overview --------------------------------- ...... - If a mobile node is otherwise using a co-located care-of address, the mobile node MUST register directly with its home agent. [QUOTE END] So, I am still a bit confused about (1) and would like other peoples view on the interpretation here. This question should be pertinent for people making MIP client sw but also for FA implementators. Any comments on (2) would also be appreciated. FrodeN From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 14:41:38 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22479 for ; Thu, 23 May 2002 14:41:38 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17523; Thu, 23 May 2002 11:40:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27610; Thu, 23 May 2002 11:39:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NIcprP010335 for ; Thu, 23 May 2002 11:38:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NIcpKb010334 for mobile-ip-dist; Thu, 23 May 2002 11:38:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NIcmrP010327 for ; Thu, 23 May 2002 11:38:48 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4NIcr6U577440; Thu, 23 May 2002 11:38:53 -0700 (PDT) Message-Id: <200205231838.g4NIcr6U577440@jurassic.eng.sun.com> Date: Thu, 23 May 2002 11:41:19 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] RR and BU to HA To: Francis.Dupont@enst-bretagne.fr Cc: alper@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Mk0sCgIlcaXktYYeHMjQCQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > As long as there is correct SA between MN-homeaddr and HA and > home-addr in HOA dst option matches with the authenticated BU > MH home-addr part, there is no problem. > > => I disagree: you have the same problem with the COA for the HA. > > In CN case, separate COA RR check is necessary to avoid reflection > attack from another malicous MN. > > => so the COA RR check should be necessary for HA too??? > Can you explain the scenarios of threats when the MN is using IPsec with non-null authentication to send BU to a home-agent (HA) ? > So, the question is how does HA > > => this HA is on the previous visited link. > By HA, I mean home-agent. You are probably interpreting HA as "home-address" here. -Samita > match the security association in this case ? > I assume that the draft assumes the sequence would be: > 1. update HA first with your new COA with HoA= MN's home-addr > > => here the HA is the HA on the home link. > > 2. Then send BU to forward packet from previous COA. > In this case HA should do a few extra checks to make sure that the > new COA already has a valid BCE. > > => this is not the same HA than in 1. > > But, I am still not sure how would HA do the SA check for homeaddr > in this case ( since homeaddr=previous COA), I believe there is no > security association with the previous COA and HA. > > => it should be but the real question is how the SA pair is established... > Even if this is done before the movement this is not easy. > > Regards > > Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 15:04:40 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23242 for ; Thu, 23 May 2002 15:04:40 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13428; Thu, 23 May 2002 13:05:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08821; Thu, 23 May 2002 12:04:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NJ3MrP010453 for ; Thu, 23 May 2002 12:03:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NJ3MGE010452 for mobile-ip-dist; Thu, 23 May 2002 12:03:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NJ3JrP010445 for ; Thu, 23 May 2002 12:03:19 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4NJ3O6U590471; Thu, 23 May 2002 12:03:24 -0700 (PDT) Message-Id: <200205231903.g4NJ3O6U590471@jurassic.eng.sun.com> Date: Thu, 23 May 2002 12:05:50 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] RR and BU to HA To: mat@cisco.com Cc: alper@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mywENOxCki77PVjot6OqfA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > However, I see some issues in : > > 11.6.6. Forwarding from a Previous Care-of Address > > > > > > section, where it says that BU home-addr and HOA-dst option both > > contain the previous COA address. So, the question is how does HA > > match the security association in this case ? > > SA's are matched by the incoming SPI and (somewhat > uselessly, IMO) the *destination* IP address (ie, > the HA). The SA lookup logic itself shouldn't > depend on the source address (ie, COA) being the > same packet to packet [*]. > Ok. Since the receiver (HA) would identify SA from , so, you're saying, that the same MN would be using the same SPI while changing care-of-addresses. So, as long as the SPI is authenticated, we should be safe ? Thanks. -Samita From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 15:33:10 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23909 for ; Thu, 23 May 2002 15:33:10 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA27927; Thu, 23 May 2002 13:33:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18479; Thu, 23 May 2002 12:32:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NJTQrP010529 for ; Thu, 23 May 2002 12:29:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NJTQqI010528 for mobile-ip-dist; Thu, 23 May 2002 12:29:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NJTNrP010521 for ; Thu, 23 May 2002 12:29:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25420 for ; Thu, 23 May 2002 12:29:29 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA10472 for ; Thu, 23 May 2002 13:29:27 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4NJTKn24608; Thu, 23 May 2002 21:29:20 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA25517; Thu, 23 May 2002 21:29:21 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4NJTKT22069; Thu, 23 May 2002 21:29:21 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205231929.g4NJTKT22069@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Samita Chakrabarti cc: alper@docomolabs-usa.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA In-reply-to: Your message of Thu, 23 May 2002 11:41:19 PDT. <200205231838.g4NIcr6U577440@jurassic.eng.sun.com> Date: Thu, 23 May 2002 21:29:20 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > As long as there is correct SA between MN-homeaddr and HA and > home-addr in HOA dst option matches with the authenticated BU > MH home-addr part, there is no problem. > > => I disagree: you have the same problem with the COA for the HA. > > In CN case, separate COA RR check is necessary to avoid reflection > attack from another malicous MN. > > => so the COA RR check should be necessary for HA too??? Can you explain the scenarios of threats when the MN is using IPsec with non-null authentication to send BU to a home-agent (HA) ? => the only remaining threat is: - the MN puts the address of V in the COA - the HA trusts the MN which has protected the COA with IPsec (so only a malicious MN can perform this attack) - the traffic for the MN intercepted by the HA and the traffic for the MN genuine to the HA flood the victim V (the second kind of traffic is the CN reflexion attack but both: - the HA has no way to verify the COA: it must trust the MN - packets forwarded by the HA is added to genuine packets) Hence my conclusion: - either we drop Mobile IPv6 until AAA infrastructure is available - or we accept the HA trusts its MNs (this can be viewed as the authorization to use a service, cf. Mike Thomas' message). > So, the question is how does HA > > => this HA is on the previous visited link. > By HA, I mean home-agent. You are probably interpreting HA as "home-address" here. => no, if you'd like to register your previous care-of address in a HA on the previous visited link in order to get "flying" packets to this previous care-of, then you have two HAs... Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 15:51:07 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24371 for ; Thu, 23 May 2002 15:51:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06921; Thu, 23 May 2002 13:51:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14188; Thu, 23 May 2002 12:50:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NJnCrP010601 for ; Thu, 23 May 2002 12:49:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NJnCjc010600 for mobile-ip-dist; Thu, 23 May 2002 12:49:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NJn8rP010593 for ; Thu, 23 May 2002 12:49:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23271 for ; Thu, 23 May 2002 12:49:10 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18933 for ; Thu, 23 May 2002 13:49:09 -0600 (MDT) Message-ID: <005b01c20292$4b0dedc0$796015ac@T23KEMPF> From: "James Kempf" To: "John Williams Floroiu" Cc: References: <3CED0C15.D65DCDB2@fokus.gmd.de> <016101c20276$91c29480$516015ac@T23KEMPF> <3CED263D.34390ACE@fokus.gmd.de> Subject: Re: [mobile-ip] are L2 triggers "secure" ? Date: Thu, 23 May 2002 12:44:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > In FMIPv6, this is true both for Prereg > > and Postreg/BETH, since tunnels are used for both. Perhaps the draft > > needs changing. > > sorry, but who exactly are "Prereg" and "Postreg", I could only find HI, HACK and HTT. > Sorry. Prereg means the mobile and old access router exchange a PrxyRtSol/PrxyRtAdv or the network sends a PrxyRtAdv and the mobile sends a F-BU when it has completed CoA change. PostReg == BETH, i.e. the HI, HACK, HTT and means just use a tunnel in response to a trigger on the old or new access router. > > [...] switched > > Ethernet where 802.1x ties a switch port to the MAC address and won't > > allow the host to change it. > > okay, but this applies I guess to wired infrastructures rather than wireless ones. > Rightl, that was my point. 802.11 is not a secure link layer. jak From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 15:57:23 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24515 for ; Thu, 23 May 2002 15:57:23 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10413; Thu, 23 May 2002 13:56:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16742; Thu, 23 May 2002 12:56:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NJu6rP010662 for ; Thu, 23 May 2002 12:56:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NJu52v010661 for mobile-ip-dist; Thu, 23 May 2002 12:56:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NJu2rP010654 for ; Thu, 23 May 2002 12:56:02 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25690 for ; Thu, 23 May 2002 12:56:09 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27045 for ; Thu, 23 May 2002 12:56:09 -0700 (PDT) Message-ID: <008301c20293$43795b70$796015ac@T23KEMPF> From: "James Kempf" To: "John Williams Floroiu" , "Charles E. Perkins" Cc: , References: <000601c20281$3116cdd0$6501a8c0@dell8100rjm> <3CED2BCC.859AB84C@iprg.nokia.com> <3CED3026.6A29A8D7@fokus.gmd.de> Subject: Re: [mobile-ip] are L2 triggers "secure" ? Date: Thu, 23 May 2002 12:51:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit John, > True, but in case of tunnel-based handover the layer 3 messages are exchanged only between ARs. It can be assumed they > are secure (they can be made secure), but the L2 triggers themselves may not. Could layer 3 rely on layer 2 security > (when deciding a handover) ? Encryption in WaveLAN - which proved to be quite easy breakable - is the first example > coming into my mind. > 802.11 link level security is not strong enough to provide secure tunnel based handover. The cellular protocols do have strong enough security. BTW, note that in the FMIPv6 draft, the mobile initiated method also requires a tunnel. The tunnel is set up when the F-BU is sent by the mobile node (there are possible optimizations). So this is not just an issue with "tunnel based" handover. jak From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 16:01:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24687 for ; Thu, 23 May 2002 16:01:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12451; Thu, 23 May 2002 14:02:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19253; Thu, 23 May 2002 13:01:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NJxgrP010715 for ; Thu, 23 May 2002 12:59:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NJxg6j010714 for mobile-ip-dist; Thu, 23 May 2002 12:59:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NJxYrP010701 for ; Thu, 23 May 2002 12:59:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06186 for ; Thu, 23 May 2002 12:59:40 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23839 for ; Thu, 23 May 2002 13:59:39 -0600 (MDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 93ADC16FF; Thu, 23 May 2002 13:04:05 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id D9C0117F9; Thu, 23 May 2002 15:59:37 -0400 (EDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id PAA0001790973; Thu, 23 May 2002 15:59:37 -0400 (EDT) Message-ID: <3CED4A29.BDE34919@hp.com> Date: Thu, 23 May 2002 15:59:37 -0400 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.78 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont Cc: Vijay Devarapalli , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205181347.g4IDlJT99517@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis Dupont wrote: > => for simplicity IMHO the S bit should be removed (reserve its position > (set to 1) and put it into the for further study class) I would agree with the removal of the S bit, preferring instead to define this multiple address behavior in another draft. I don't see any reason to keep it and have it only defined as 1 for now though. -Brian From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 16:37:06 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26343 for ; Thu, 23 May 2002 16:37:06 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02420; Thu, 23 May 2002 14:37:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10180; Thu, 23 May 2002 13:36:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NKZgrP010943 for ; Thu, 23 May 2002 13:35:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NKZg83010942 for mobile-ip-dist; Thu, 23 May 2002 13:35:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NKZbrP010925 for ; Thu, 23 May 2002 13:35:37 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA17995 for ; Thu, 23 May 2002 13:35:44 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01365 for ; Thu, 23 May 2002 14:35:43 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA08048; Thu, 23 May 2002 13:35:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4NKZgN06633; Thu, 23 May 2002 13:35:42 -0700 X-mProtect: <200205232035> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdr5fDtU; Thu, 23 May 2002 13:35:40 PDT Message-ID: <3CED529D.832FED37@iprg.nokia.com> Date: Thu, 23 May 2002 13:35:41 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian Haley CC: Francis Dupont , Vijay Devarapalli , jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205181347.g4IDlJT99517@givry.rennes.enst-bretagne.fr> <3CED4A29.BDE34919@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, It seems to me that the behavior is already simple enough, and it makes a big difference if the mobile node has several home addresses. Taking it away burdens the already burdened handover time. The consequence would be a very strong discouragement for any mobile node to use the IPv6 feature of having multiple prefixes for the same link (in this case, that means the home link). Furthermore, I think the home agent should _always_ defend the link-local address of the mobile node (regardless of the setting of the 'S' bit, or its existence) while the mobile node has a registered care-of address. Anything else leads to cramps. Regards, Charlie P. Brian Haley wrote: > > Francis Dupont wrote: > > > => for simplicity IMHO the S bit should be removed (reserve its position > > > (set to 1) and put it into the for further study class) > > I would agree with the removal of the S bit, preferring instead to define this > multiple address behavior in another draft. I don't see any reason to keep it > and have it only defined as 1 for now though. > > -Brian From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 17:00:29 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27108 for ; Thu, 23 May 2002 17:00:29 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15193; Thu, 23 May 2002 15:00:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18128; Thu, 23 May 2002 14:00:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NKxDrP011302 for ; Thu, 23 May 2002 13:59:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NKxDgs011301 for mobile-ip-dist; Thu, 23 May 2002 13:59:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NKxArP011294 for ; Thu, 23 May 2002 13:59:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12956 for ; Thu, 23 May 2002 13:59:15 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13824 for ; Thu, 23 May 2002 15:00:00 -0600 (MDT) Message-ID: <073001c2029d$3dbf1850$686015ac@docomocarl> From: "Carl Williams" To: "Hesham Soliman \(ERA\)" , "'Phil Roberts'" , References: <4DA6EA82906FD511BE2F00508BCF0538044F066F@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] WG process Date: Thu, 23 May 2002 14:03:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > > > Why was LMM requirements done for v6 and not for v4? > > Probably a lot of > > reasons - > > the ones that seem clear to me are premature selection of a > > proposal, > > recognized > > in a disagreement about requirements. > > => The requirement that caused the major disagreement, > was common for both v4 and v6. I think at the time > I made this comment on the list, no less than 4 > times and it was never answered. > The requirements resulted from a discussion over concerns of the current proposed working group LMM (MIPv6) documents. An analysis was done and requirements collected as a result. Requirements may be similar between MIPv4 and MIpv6 but there may be different requirements for the different protocols. Carl > As for the maturity of the selection, I don't > agree with your paragraph above, the selection > followed WG concencus procedures, as it was > requested by the chairs and lasted for 2 > weeks. > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 17:34:19 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28278 for ; Thu, 23 May 2002 17:34:14 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02110; Thu, 23 May 2002 15:35:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28745; Thu, 23 May 2002 14:34:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NLXArP011431 for ; Thu, 23 May 2002 14:33:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NLXA78011430 for mobile-ip-dist; Thu, 23 May 2002 14:33:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NLX6rP011423 for ; Thu, 23 May 2002 14:33:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29668 for ; Thu, 23 May 2002 14:33:12 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02227 for ; Thu, 23 May 2002 15:33:11 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA11201; Thu, 23 May 2002 14:33:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4NLXAi10543; Thu, 23 May 2002 14:33:10 -0700 X-mProtect: <200205232133> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnQvCFV; Thu, 23 May 2002 14:33:08 PDT Message-ID: <3CED6015.E7A39399@iprg.nokia.com> Date: Thu, 23 May 2002 14:33:09 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Vijay Devarapalli , jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Francis, I have to type and run, so I may not be able to participate much before next week. But... Francis Dupont wrote: > => this address is always protected by the HA: it is the worst choice. > > the deregistration BU is unicast to the HA. this works. > > => with an old draft or with my proposal: > - the MN has just been attached to the home link > - it builds its link-local address and performs DAD for it Here is where I think your procedure is broken. If the home agent has been defending the mobile node's link-local address, then it would typically do so until the care-of address expires. (*) Thus, the mobile node DOES NOT have to do DAD. It can use the link-local address it has been "using" all along. > - (perhaps in parallel) its sends a RtSol to get prefixes and > a default router > - it gets a RtAdv from any routers on the home link (by application > of the Murphy's law, the first router to answer is never the HA). > - it finds a home prefix in the RtAdv and discovers it is at home > - it builds its addresses from the prefixes: > * if it performs DAD, it fails for the home address > * if it doesn't perform DAD (it was the case when I try 4 years ago), > see after This isn't necessarily so. If a renumbering event has happened, then the mobile node should have been notified by way of the Binding Request mechanism. If no event, no problem! > - it tries to send a BU to the HA > - as the HA address is not in the neighbor cache it sends a NbSol with: > * the home address as the source > * the solicited-node multicast of the HA address as the destination > * the HA address at the target This can be fixed by either (a) keeping the home agent's information in the Neighbor Cache (b) using the anycast address (c) special-case code > - the HA receives the NbSol and does a stupid thing with it, > in my case it sends a NbAdv to the previous care-of address of the MN > with a RH. We can specify that the home agent doesn't do wrong things with such packets. In fact, I reckon we should do so. Any home agent problem should be fixed in a Mobile IPv6 draft somewhere along the line... > - the MN retries > - the MN retries > ... > > Conclusion: it does not work. My fix was simple: I modify the code > to always send the BU from the link-local address. It always works > until someone has the bad idea to use S=0 or a previous equivalent. I think it can and should be made to work. If I don't answer until next week, please forgive... Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 17:57:22 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28896 for ; Thu, 23 May 2002 17:57:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14656; Thu, 23 May 2002 15:57:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16898; Thu, 23 May 2002 14:57:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NLtxrP012293 for ; Thu, 23 May 2002 14:55:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NLtxMg012292 for mobile-ip-dist; Thu, 23 May 2002 14:55:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NLturP012285 for ; Thu, 23 May 2002 14:55:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16526 for ; Thu, 23 May 2002 14:56:01 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA17631 for ; Thu, 23 May 2002 15:56:00 -0600 (MDT) Received: from talaria.fm.intel.com (talaria.fm.intel.com [10.1.192.39]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.46 2002/05/09 18:12:26 root Exp $) with ESMTP id g4NLsfN12148 for ; Thu, 23 May 2002 21:54:41 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxv043-1.fm.intel.com [132.233.48.128]) by talaria.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.20 2002/05/13 20:36:03 root Exp $) with SMTP id g4NLxHd06079 for ; Thu, 23 May 2002 21:59:17 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs043.fm.intel.com (NAVGW 2.5.1.16) with SMTP id M2002052314545910690 for ; Thu, 23 May 2002 14:54:59 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 14:55:59 -0700 Message-ID: From: "Liu, Changwen" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] New draft: draft-liu-mobileip-mipv6tomipv4-00.txt Date: Thu, 23 May 2002 14:55:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: To all, I've submitted a draft named "Connecting Mobile IPv6 Nodes Across IPv4 Clouds Back To IPv6 Domains With Mobile IPv4" that updates my previous draft "Mobile IPv6 over Mobile IPv4". The new draft specifies a mechanism for Mobile IPv6 nodes of any IPv6 site to continue utilizing Mobile IPv6 services when they roam into IPv4 domains. The draft can be retrieved from http://www.ietf.org/internet-drafts/draft-liu-mobileip-mipv6tomipv4-00.txt Your feedbacks and comments on the draft are appreciated. Thanks in advance. Regards, changwen From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 18:19:48 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29257 for ; Thu, 23 May 2002 18:19:48 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05843; Thu, 23 May 2002 16:19:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24719; Thu, 23 May 2002 15:19:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NMIKrP012513 for ; Thu, 23 May 2002 15:18:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NMIJED012512 for mobile-ip-dist; Thu, 23 May 2002 15:18:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NMIGrP012505 for ; Thu, 23 May 2002 15:18:16 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15247 for ; Thu, 23 May 2002 15:18:22 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA13875 for ; Thu, 23 May 2002 15:18:22 -0700 (PDT) Message-ID: <00b101c202a6$5ab62b70$8b6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Charles E. Perkins" , "John Williams Floroiu" Cc: References: <3CED0C15.D65DCDB2@fokus.gmd.de> <3CED2426.2D62F3E8@iprg.nokia.com> Subject: Re: [mobile-ip] are L2 triggers "secure" ? Date: Thu, 23 May 2002 15:08:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Any signal that cause a change in routing needs to be secured. In the case BETH, these are all L2 signals between the MN and the network, in the rest of FMIP6, it's a blend of L3 and some L2... And all of these needs to be authenticated.. alper ----- Original Message ----- From: "Charles E. Perkins" To: "John Williams Floroiu" Cc: Sent: Thursday, May 23, 2002 10:17 AM Subject: Re: [mobile-ip] are L2 triggers "secure" ? > Hello John, > > I believe that any Fast Handover message (perhaps including > Context Transfer options) used by a mobile node to "confirm" > its arrival at the new access router MUST contain authentication > data. > > Regards, > Charlie P. > > > John Williams Floroiu wrote: > > > > Hi, > > > > I would like to rise a question regarding the tunnel based handover (section 3.2 in > > draft-ietf-mobileip-fast-mipv6-04.txt). I believe the use of L2 > > triggers might introduce some security holes as long as their "safety" cannot be correctly assess by the layer 3. > > > > I am not a L2 technology expert, therefore I am not sure how L2 triggers are actually implemented. However, taking as an > > example the scenario described in fig. 8 (p.25), and trying to extrapolate somehow the functionality of WaveLAN (which > > is not the only but anyway the most widely considered case study), I could imagine the situation described below > > occurring. > > > > An attacker spoofing the MAC address of a legitimate MN may force itself to attach to a different access point (nAP) > > than the one the MN is currently using (oAP). This event happening at the nAP is most probably the source of a L2-TT > > trigger nAR is going to receive, and the effect is that the incoming MN traffic is going to be mis-routed, since the > > reception of L2-TT at nAR triggers the initiation of the handover between (a false) nAR and oAR --- well I do not really > > know how nAR could learn the address of oAR in general, again, maybe some technologies which I do not know about support > > this. > > > > The bottom line is that an attacker spoofing the identity --- MAC address or whatever ID appearing in the radio control > > messages, like WaveLAN beacons --- of a legitimate mobile terminal, can produce fake L2 triggers by attaching to false > > access points, and mount in this way DoS attacks against MNs. > > > > John. > From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 19:14:06 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00060 for ; Thu, 23 May 2002 19:14:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10383; Thu, 23 May 2002 16:12:29 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA13642; Thu, 23 May 2002 16:12:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NNBErP012689 for ; Thu, 23 May 2002 16:11:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NNBEkO012688 for mobile-ip-dist; Thu, 23 May 2002 16:11:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NNBArP012681 for ; Thu, 23 May 2002 16:11:10 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA11957 for ; Thu, 23 May 2002 16:11:17 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA27888 for ; Thu, 23 May 2002 17:11:16 -0600 (MDT) Message-ID: <013901c202ae$1ff1a390$8b6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Francis Dupont" Cc: References: <200205230955.g4N9tcT19737@givry.rennes.enst-bretagne.fr> Subject: Re: [mobile-ip] RR and BU to HA Date: Thu, 23 May 2002 16:03:59 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Francis, > In your previous mail you wrote: > > The current draft identifies a need to verify the > return routability of CoA when the BU is sent to > a CN. > > => this is an open point. Some believe RR check is simply > mandatory, some believe RR check is only one possible way > to fulfill security requirements and a suitable IPsec protection > should not need an extra RR check (the argument is the RR check > is not possible for the HA so "suitable IPsec" includes the trust > in the MN to not provide a fake CoA). Yes, this is the question: does a "suitable IPsec" include the trust in the MN to not provide a fake CoA? But, if such a trust between MN and HA was sufficient, a "home test" that goes through HA should have been sufficient for sending BU to CN. Home agent could verify that the MN is authenticated and authorized before passing the test packet on. Am I missing something?? > > But it suggests that one can use IPsec between > the MN and the HA when MN is sending a BU, > and this should be sufficient.... Shouldn't we be > doing a RR on the CoA even if we are using IPsec? > > => I believe the answer is no and I'd like to see how to perform a RR > check between the MN and the HA... After HA receives the IPsec'ed BU, we can add one more round-trip between the HA and the CoA. This can verify that the MN is really reachable at the CoA before binding cache entry is modified. alper From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 19:20:18 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00140 for ; Thu, 23 May 2002 19:20:18 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19878; Thu, 23 May 2002 17:21:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16916; Thu, 23 May 2002 16:20:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NNJOrP012775 for ; Thu, 23 May 2002 16:19:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4NNJOH1012774 for mobile-ip-dist; Thu, 23 May 2002 16:19:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4NNJLrP012767 for ; Thu, 23 May 2002 16:19:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA05427 for ; Thu, 23 May 2002 16:19:27 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA08167 for ; Thu, 23 May 2002 16:19:27 -0700 (PDT) Message-ID: <014b01c202af$450df470$8b6015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Michael Thomas" Cc: References: <030501c20201$4db7cff0$8b6015ac@AlperVAIO> <15596.63471.720071.829041@thomasm-u1.cisco.com> Subject: Re: [mobile-ip] RR and BU to HA Date: Thu, 23 May 2002 16:12:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Mike, > > We have a question on the security of BUs... > > > > The current draft identifies a need to verify the > > return routability of CoA when the BU is sent to > > a CN. > > > > But it suggests that one can use IPsec between > > the MN and the HA when MN is sending a BU, > > and this should be sufficient.... Shouldn't we be > > doing a RR on the CoA even if we are using IPsec? > > Alper, > > I don't think it's necessary. A normal security > association decides, for example, whether to pass > data through the stack/forwarding-path given the > credentials. Since the home agent "owns" the > source subnet, I don't think it's much of a > stretch to say that it can decide based upon > presented credential whether a MN can move > bindings around as well. That is, the credential > itself could imply "allow pass/forward/rebind". Yes, this means that MN is authorized to change the binding cache, but it doesn't say if the MN is authorized to change the care-of address to a given IP address... Because we don't know if the MN is the host using this CoA or not. We seem to care about this for when BU is sent to the CN, but ignore it with HA. > > This is distinctly different than the > correspondent node case which has absolutely no > relationship with the subnet in question (in > general). In that case the credential would need > to be more specific; where you could imply it > above, it would need to be specific if you want to > guard against inside attacks (eg, attacks > authenticated but malicious MN's). On the CN > insufficient authz could lead to a hijacking > attack since it doesn't "own" the subnet and has > no way to know who that address/prefix was > delegated to. This isn't the case on the HA since > where the worst that could happen is a depletion > of IP addresses attack on that subnet, and even > that would be pretty easy to defend against. > > Mike > alper From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 20:13:42 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01289 for ; Thu, 23 May 2002 20:13:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA14269; Thu, 23 May 2002 18:13:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA01053; Thu, 23 May 2002 17:13:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O0CNrP012951 for ; Thu, 23 May 2002 17:12:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4O0CMpP012950 for mobile-ip-dist; Thu, 23 May 2002 17:12:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O0CJrP012943 for ; Thu, 23 May 2002 17:12:19 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09770 for ; Thu, 23 May 2002 17:12:26 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04621 for ; Thu, 23 May 2002 17:12:26 -0700 (PDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4O0COHs027735; Thu, 23 May 2002 17:12:24 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABS63242; Thu, 23 May 2002 17:09:24 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA04251; Thu, 23 May 2002 17:12:24 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15597.34151.931880.576634@thomasm-u1.cisco.com> Date: Thu, 23 May 2002 17:12:23 -0700 (PDT) To: "Alper E. YEGIN" Cc: "Michael Thomas" , Subject: Re: [mobile-ip] RR and BU to HA In-Reply-To: <014b01c202af$450df470$8b6015ac@AlperVAIO> References: <030501c20201$4db7cff0$8b6015ac@AlperVAIO> <15596.63471.720071.829041@thomasm-u1.cisco.com> <014b01c202af$450df470$8b6015ac@AlperVAIO> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alper E. YEGIN writes: > > I don't think it's necessary. A normal security > > association decides, for example, whether to pass > > data through the stack/forwarding-path given the > > credentials. Since the home agent "owns" the > > source subnet, I don't think it's much of a > > stretch to say that it can decide based upon > > presented credential whether a MN can move > > bindings around as well. That is, the credential > > itself could imply "allow pass/forward/rebind". > > Yes, this means that MN is authorized to change > the binding cache, but it doesn't say if the MN is > authorized to change the care-of address to a > given IP address... Because we don't know if the MN > is the host using this CoA or not. We seem to care about > this for when BU is sent to the CN, but ignore it with HA. Let's see: the home agent knows which identity is bound to a particular *home* address, and it expects that anybody who is trying to change the binding for that home address to a new CoA must prove that it has keying material from the identity bound to that home address. Ie, it must ship an IPsec integrity protected BU meesage over an SA that was created using that identity. What's the problem here? Mike From owner-mobile-ip@sunroof.eng.sun.com Thu May 23 20:37:24 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01819 for ; Thu, 23 May 2002 20:37:24 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21177; Thu, 23 May 2002 18:38:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29064; Thu, 23 May 2002 17:37:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O0aHrP013039 for ; Thu, 23 May 2002 17:36:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4O0aHbR013038 for mobile-ip-dist; Thu, 23 May 2002 17:36:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O0aErP013031 for ; Thu, 23 May 2002 17:36:14 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4O0aI6U669888; Thu, 23 May 2002 17:36:18 -0700 (PDT) Message-Id: <200205240036.g4O0aI6U669888@jurassic.eng.sun.com> Date: Thu, 23 May 2002 17:38:44 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] RR and BU to HA To: Francis.Dupont@enst-bretagne.fr Cc: mobile-ip@sunroof.eng.sun.com, alper@docomolabs-usa.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: K40mg7yMflThFzH49ZwjrQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > => so the COA RR check should be necessary for HA too??? > > Can you explain the scenarios of threats when the MN is using IPsec with > non-null authentication to send BU to a home-agent (HA) ? > > => the only remaining threat is: > - the MN puts the address of V in the COA > - the HA trusts the MN which has protected the COA with IPsec > (so only a malicious MN can perform this attack) > - the traffic for the MN intercepted by the HA and the traffic for the MN > genuine to the HA flood the victim V > (the second kind of traffic is the CN reflexion attack but both: > - the HA has no way to verify the COA: it must trust the MN > - packets forwarded by the HA is added to genuine packets) Ok. Yes in this case, the threat exists. But this can only happen when the genuine MN already has registered with the HA at that time, so that the packets for the malicous MN gets tunneled to the genuine MN. If the genuine MN does not have a BCE, then it's not MIPv6 really, as there is no tunnel to the COA V. Security comes at a cost. For more security, MN-HA tunnel could be IPsec secured while security association may depend on home-addr. We could also restrict that a MN must not use more than *one* home-adress per COA. Thus the implementation can check (while processing BU), if there is already an existing BCE with a different home-addr for the same COA, then discard the packet. (implementation specific) > Hence my conclusion: > - either we drop Mobile IPv6 until AAA infrastructure is available This is not a good idea. Instead the draft can recommend using AAA infrastructure for tighter security. > - or we accept the HA trusts its MNs (this can be viewed as the > authorization to use a service, cf. Mike Thomas' message). > Yes. This is much better option. Having RR on MN-HA registration would be a overkill, MIPv6 has already too many signaling messages. > => no, if you'd like to register your previous care-of address in a HA > on the previous visited link in order to get "flying" packets to this > previous care-of, then you have two HAs... We don't necessarily need two HAs. A MN can move from one visited link to another and direct it's HA to forward 'flying packets' for it's old COA to this new COA. Although, I think mostly MNs would be okay without this COA packet forwarding in practice. Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 00:39:21 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08010 for ; Fri, 24 May 2002 00:39:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07068; Thu, 23 May 2002 22:39:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA20046; Thu, 23 May 2002 21:38:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O4bprP013607 for ; Thu, 23 May 2002 21:37:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4O4bpBI013606 for mobile-ip-dist; Thu, 23 May 2002 21:37:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O4bmrP013599 for ; Thu, 23 May 2002 21:37:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA20711 for ; Thu, 23 May 2002 21:37:54 -0700 (PDT) Received: from cwc.ucsd.edu (cwc.ucsd.edu [132.239.228.42]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA26391 for ; Thu, 23 May 2002 21:37:54 -0700 (PDT) Received: from cts4.ucsd.edu (cts4.ucsd.edu [132.239.134.16]) by cwc.ucsd.edu (8.12.1/8.11.3) with ESMTP id g4O4bcVl018729 for ; Thu, 23 May 2002 21:37:38 -0700 (PDT) Date: Thu, 23 May 2002 21:37:53 -0700 (PDT) From: Joseph Soma Reddy X-X-Sender: To: Subject: [mobile-ip] draft on Macrodiversity in IPCN Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello, We have done some work on the topic of macrodiversity and soft handoffs in IP cellular networks. Since the draft has graphs and a few equations, I couldnt present it as an Internet Draft. But you can download it(pdf and ps) from http://cwc.ucsd.edu/~soma Feedback and comments are appreciated. Thanks, Joseph ----------------- Title: Macrodiversity in IP Cellular Networks Abstract: Several proposals have been made to handle fast handoffs in an IP based cellular network. All these proposals focus on the problem of routing packets in a fast and efficient manner. However, handoffs can also be used to exploit macrodiversity and increase coverage and capacity as is done in current cdma networks via soft handoffs. We show that soft handoffs are not suitable for IP cellular networks and propose a new method to exploit macrodiversity via fast hard handoffs. Our method does not suffer the disadvantages of soft handoffs in IP cellular networks. We show through simulations that our scheme achieves coverage gains approaching those obtained by soft handoffs. ------------------------ From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 02:33:25 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18545 for ; Fri, 24 May 2002 02:33:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01772; Thu, 23 May 2002 23:31:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA16188; Thu, 23 May 2002 23:31:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O6UKrP013870 for ; Thu, 23 May 2002 23:30:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4O6UKLw013869 for mobile-ip-dist; Thu, 23 May 2002 23:30:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O6UHrP013859 for ; Thu, 23 May 2002 23:30:17 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA15693 for ; Thu, 23 May 2002 23:30:20 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA14756 for ; Fri, 24 May 2002 00:30:19 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id PAA16477; Fri, 24 May 2002 15:30:17 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA03538; Fri, 24 May 2002 15:30:16 +0900 (JST) Date: Fri, 24 May 2002 15:28:13 +0900 (JST) Message-Id: <20020524.152813.119663858.keiichi@iij.ad.jp> To: arvind.sevalkar@lntinfotech.com Cc: Francis.Dupont@enst-bretagne.fr, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issue #25 From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: References: X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, From: arvind.sevalkar > But is it really necessary to send Binding Acknowledgement with routing > header when there is no binding in cache. Because routing header is > included when there is an entry in the binding cache some implementation > checks routing header for binding in binding cache. > We can simply do one thing when there is a binding in the Binding cache > then we will send BA with routing header and when there is no Binding in > the Binding cache then we will send BA to the Home address without routing > header. > So BA will be sent to HA without RH header in two cases. > 1>BU successful and which is for deleting Binding cache entry. > 2>BU failed and there is no entry in Binding cache, in case when first time > MN sends BU to CN and that fails. I agree with this approach. The HA and the CN just check if they have a valid binding cache entry for the MN before sending packets to the internet. If they have, they add a rthdr type 2 to all the outgoing packets to the MN. If they don't have, just sent it to as is (not inserting a rthdr type 2). Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 03:36:36 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19348 for ; Fri, 24 May 2002 03:36:36 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23271; Fri, 24 May 2002 00:35:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05194; Fri, 24 May 2002 00:34:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O7XWrP014014 for ; Fri, 24 May 2002 00:33:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4O7XWxI014013 for mobile-ip-dist; Fri, 24 May 2002 00:33:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O7XRrP014006 for ; Fri, 24 May 2002 00:33:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA12475 for ; Fri, 24 May 2002 00:33:21 -0700 (PDT) Received: from muminmamman.lifix.fi ([213.15.142.68]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA08725 for ; Fri, 24 May 2002 01:33:20 -0600 (MDT) Received: from ban by muminmamman.lifix.fi with local (Exim 3.33 #1 (Debian)) id 17B9ZY-0007rG-00; Fri, 24 May 2002 10:33:12 +0300 Date: Fri, 24 May 2002 10:33:12 +0300 From: Bjorn Andersson To: "Frode B. Nilsen" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Registration with co-located CoA via FA (question triggered by NAT traversal draft) Message-ID: <20020524073312.GA29997@lifix.fi> Mail-Followup-To: Bjorn Andersson , "Frode B. Nilsen" , mobile-ip@sunroof.eng.sun.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.25i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: On Thu, May 23 2002, at 13:48:15 +0200, Frode B. Nilsen wrote: > Taking a closer look at RFC3220 I find the following somewhat contradicting > statements: > > [QUOTE BEGIN] > ...... > Section 2.1.1 Mobility Agent Advertisement Extension > ----------------------------------------------------- > ...... > R Registration required. Registration with this foreign agent (or another > foreign agent on this link) is required even when using a co-located care-of > address. > ....... > Section 3.1 Registration Overview > --------------------------------- > ...... > - If a mobile node is otherwise using a co-located care-of address, the mobile > node MUST register directly with its home agent. > [QUOTE END] However, the previous statement in section 3.1 says: "- If a mobile node is using a co-located care-of address, and receives an Agent Advertisement from a foreign agent on link on which it is using this care-of address, the node SHOULD register via that foreign agent (or via another agent on this link) if the 'R' bit is set in the ed Agent Advertisement message." The sentence you quoted says "otherwise", i.e. if there is no foreign agent advertisnig the 'R' bit. I don't see any contradiction. Bjorn -- Bjorn Andersson +358 50 341 2556 Lifix Systems Oy PGP id 5AFC144B Innopoli 2, Tekniikantie 14, FIN-02150 Espoo From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 04:26:16 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20125 for ; Fri, 24 May 2002 04:26:16 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13159; Fri, 24 May 2002 01:24:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20179; Fri, 24 May 2002 01:24:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O8NerP014221 for ; Fri, 24 May 2002 01:23:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4O8Nel4014220 for mobile-ip-dist; Fri, 24 May 2002 01:23:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O8NarP014213 for ; Fri, 24 May 2002 01:23:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20075 for ; Fri, 24 May 2002 01:23:41 -0700 (PDT) Received: from mailgw.local.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23631 for ; Fri, 24 May 2002 02:24:26 -0600 (MDT) Received: from fredrikj (a20.local.ipunplugged.com [192.168.4.190]) by mailgw.local.ipunplugged.com (8.12.3/8.12.3) with SMTP id g4O8P73O015141; Fri, 24 May 2002 10:25:07 +0200 From: "Fredrik Johansson" To: "Ahmad Muhanna" , "MobileIP" Cc: , "'Tony Johansson'" Subject: RE: [mobile-ip] draft-ietf-mobileip-aaa-nai-01.txt Date: Fri, 24 May 2002 10:23:24 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0111_01C2030D.092BD180" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <6B49EDFE974BD51197D70002A56079D801AFCD0D@zrc2c013.us.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal X-RAVMilter-Version: 8.3.3(snapshot 20020312) (mailgw) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0111_01C2030D.092BD180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: [mobile-ip] draft-ietf-mobileip-aaa-nai-01.txtHi Ahmad, Sorry for the late response. I have no ptoblem with changing the text. I have updated the draft to say: "A mobile node that recieves this extension in a registration reply message MUST provide it in every registration request when re-authentication is needed. If the mobile node requests a specific home agent and it has the information available it MUST provide this extension in its initial registration request" Regards, /Fredrik -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Ahmad Muhanna Sent: den 17 maj 2002 19:44 To: 'Fredrik Johansson'; MobileIP Cc: 'bob@marksmob.com'; 'Tony Johansson' Subject: RE: [mobile-ip] draft-ietf-mobileip-aaa-nai-01.txt Hello Fredrik, I know that you would like to address backward compatibility at the network side rather in this draft. However, If we can come up with something neat here, it would be a plus. What do you think about replacing paragraph 3 in section 4 by the proposed text below. Section 4: " A mobile node MUST provide this in every registration request sent when re-authenticating, or when requesting a specific IP address at initial authentication." Proposed text: " After receiving this extension in a registration reply message, the Mobile Node MUST provide it in every registration request when re-authenticating is needed. If the Mobile Node requests a specific IP address and this extension is available, the Mobile Node MUST provide this extension in its initial registration request. " Regards; Ahmad Muhanna > > > Hi All, > > We have submitted a new version of the above mentioned draft, > if you want > access to it before it gets published, it can be found at > > http://stargate.ipunplugged.com/ietf/draft-ietf-mobileip-aaa-n > ai-01.txt > > /Fredrik > > ------=_NextPart_000_0111_01C2030D.092BD180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] = draft-ietf-mobileip-aaa-nai-01.txt
Hi=20 Ahmad,
 
Sorry=20 for the late response.
 
I have=20 no ptoblem with changing the text. I have updated the = draft = to=20 say:

     "A mobile = node that=20 recieves this extension in a registration reply=20
      message MUST provide it in every = registration=20 request when
      re-authentication is = needed. If=20 the mobile node requests a specific = home
      agent=20 and it has the information available it MUST provide this=20
      extension in its initial registration = request"
 
Regards,
/Fredrik
    =
-----Original Message-----
From:=20 owner-mobile-ip@sunroof.eng.sun.com=20 [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Ahmad=20 Muhanna
Sent: den 17 maj 2002 19:44
To: 'Fredrik=20 Johansson'; MobileIP
Cc: 'bob@marksmob.com'; 'Tony=20 Johansson'
Subject: RE: [mobile-ip]=20 draft-ietf-mobileip-aaa-nai-01.txt

Hello Fredrik,
I know that = you would=20 like to address backward compatibility at the network side rather in = this=20 draft.
However, If we can come up with = something neat=20 here, it would be a plus.

What do you think about replacing paragraph 3 in = section 4 by=20 the proposed text below.

Section 4:

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

Proposed text:

"  After receiving this extension in a = registration reply=20 message, the Mobile Node
   MUST = provide it=20 in every registration request when re-authenticating is needed.=20
   If the Mobile Node requests a = specific IP=20 address and this extension is available,
  =20 the Mobile Node MUST provide this extension in its initial = registration=20 request.
"

Regards;
Ahmad = Muhanna


>
>
>=20 Hi All,
>
> = We have=20 submitted a new version of the above mentioned draft,
> if you want
> access to it = before it=20 gets published, it can be found at
>=20
> http://stargate.ipunplugged.com/ietf/draft-ietf-mobileip-= aaa-n=20
> ai-01.txt
> =
> /Fredrik
>
>=20

------=_NextPart_000_0111_01C2030D.092BD180-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 04:34:31 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20267 for ; Fri, 24 May 2002 04:34:30 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA16435; Fri, 24 May 2002 01:32:46 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21732; Fri, 24 May 2002 01:32:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O8W5rP014292 for ; Fri, 24 May 2002 01:32:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4O8W51V014291 for mobile-ip-dist; Fri, 24 May 2002 01:32:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O8W2rP014284 for ; Fri, 24 May 2002 01:32:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA18659 for ; Fri, 24 May 2002 01:32:05 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA01448 for ; Fri, 24 May 2002 02:32:03 -0600 (MDT) Received: from fokus.gmd.de (ekina [193.175.135.180]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g4O8VwE25323; Fri, 24 May 2002 10:31:59 +0200 (MEST) Message-ID: <3CEDFA7E.D3DD4166@fokus.gmd.de> Date: Fri, 24 May 2002 10:31:58 +0200 From: John Williams Floroiu Organization: GMD FOKUS - CC MOBIS X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com, "Alper E. YEGIN" , "Charles E. Perkins" Subject: Re: [mobile-ip] are L2 triggers "secure" ? References: <000601c20281$3116cdd0$6501a8c0@dell8100rjm> <3CED2BCC.859AB84C@iprg.nokia.com> <3CED3026.6A29A8D7@fokus.gmd.de> <008301c20293$43795b70$796015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James, > 802.11 link level security is not strong enough to provide secure tunnel > based handover. The cellular protocols do have strong enough security. > > BTW, note that in the FMIPv6 draft, the mobile initiated method also > requires a tunnel. The tunnel is set up when the F-BU is sent by the > mobile node (there are possible optimizations). So this is not just an > issue with "tunnel based" handover. True, but the difference however is that F-BU and F-BACK are "layer 3 secured". The anticipated handover method sets up the tunnel after exchanging F-BU and F-BACK --- which can be trusted by layer 3 --- with MN. With tunnel-based handover, the handover is initiated by L2 triggers, and the problem I see is whether layer 3 could trust layer 2 security (and for some technologies it obviously cannot). HI, HACK and HTT are "layer 3 secured" but they are exchanged between the ARs, which is not relevant in this context because they make no guarantee about the MN's legitimacy. L2 triggers are obviously a very efficient method to initiate handovers, but imho they need to always be accompanied by secure layer 3 exchange which necessarily involve the MN. If this would be the case, then tunnel-based handover would resemble very much the anticipated handover from the perspective of the control message exchange. John. From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 05:52:19 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21718 for ; Fri, 24 May 2002 05:52:18 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00597; Fri, 24 May 2002 03:52:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13956; Fri, 24 May 2002 02:51:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O9nmrP014475 for ; Fri, 24 May 2002 02:49:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4O9nmTB014474 for mobile-ip-dist; Fri, 24 May 2002 02:49:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4O9nirP014467 for ; Fri, 24 May 2002 02:49:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA03725 for ; Fri, 24 May 2002 02:49:50 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29753 for ; Fri, 24 May 2002 03:49:49 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4O9nHn22631; Fri, 24 May 2002 11:49:17 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA05827; Fri, 24 May 2002 11:49:17 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4O9nGT24634; Fri, 24 May 2002 11:49:16 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205240949.g4O9nGT24634@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E. Perkins" cc: Brian Haley , Vijay Devarapalli , jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Thu, 23 May 2002 13:35:41 PDT. <3CED529D.832FED37@iprg.nokia.com> Date: Fri, 24 May 2002 11:49:16 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: It seems to me that the behavior is already simple enough, and it makes a big difference if the mobile node has several home addresses. => we have first to understand why the MN has several home addresses: for instance, if the MN has several home addresses because multi-homing then the MN should use different HAs too: multiple paths are better when they don't go through a single point of failure. Taking it away burdens the already burdened handover time. => IMHO we should get the mobility stuff ready and only after try to optimize/accelerate it. And the S bit is cleary today an overoptimization. The consequence would be a very strong discouragement for any mobile node to use the IPv6 feature of having multiple prefixes for the same link (in this case, that means the home link). => why? the MN can register their home addresses in parallel: - this takes near the same time - this makes multiple paths available at the same price. Furthermore, I think the home agent should _always_ defend the link-local address of the mobile node (regardless of the setting of the 'S' bit, or its existence) while the mobile node has a registered care-of address. => I STRONGLY object because this leads to cramps when the MN comes back on the link. Anything else leads to cramps. => I disagree: it is too late to change DAD in DIIDD (Duplicate Interface ID Detection) and this kind of actions is *not* in the mobile-ip charter. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 06:27:27 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22223 for ; Fri, 24 May 2002 06:27:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02831; Fri, 24 May 2002 03:25:50 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA19097; Fri, 24 May 2002 03:25:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OAOmrP014607 for ; Fri, 24 May 2002 03:24:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OAOmZM014606 for mobile-ip-dist; Fri, 24 May 2002 03:24:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OAOirP014599 for ; Fri, 24 May 2002 03:24:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18315 for ; Fri, 24 May 2002 03:24:49 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA02495 for ; Fri, 24 May 2002 03:24:48 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4OAObn27065; Fri, 24 May 2002 12:24:37 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA06452; Fri, 24 May 2002 12:24:37 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4OAOaT24778; Fri, 24 May 2002 12:24:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205241024.g4OAOaT24778@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Charles E. Perkins" cc: Vijay Devarapalli , jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Thu, 23 May 2002 14:33:09 PDT. <3CED6015.E7A39399@iprg.nokia.com> Date: Fri, 24 May 2002 12:24:36 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Francis Dupont wrote: > => this address is always protected by the HA: it is the worst choice. > > the deregistration BU is unicast to the HA. this works. > > => with an old draft or with my proposal: > - the MN has just been attached to the home link > - it builds its link-local address and performs DAD for it Here is where I think your procedure is broken. => my procedure is the strict application of RFC 2462 (5.3 & 5.4). If the home agent has been defending the mobile node's link-local address, then it would typically do so until the care-of address expires. => this is why I have a problem (:-). (*) Thus, the mobile node DOES NOT have to do DAD. It can use the link-local address it has been "using" all along. => this is in full contradiction with RFC 2462! > - (perhaps in parallel) its sends a RtSol to get prefixes and > a default router > - it gets a RtAdv from any routers on the home link (by application > of the Murphy's law, the first router to answer is never the HA). > - it finds a home prefix in the RtAdv and discovers it is at home > - it builds its addresses from the prefixes: > * if it performs DAD, it fails for the home address > * if it doesn't perform DAD (it was the case when I try 4 years ago), > see after This isn't necessarily so. If a renumbering event has happened, then the mobile node should have been notified by way of the Binding Request mechanism. If no event, no problem! => perhaps you have missed my point: I claim the MN must deregister before performing DAD and if DAD is successful using the home address. > - it tries to send a BU to the HA > - as the HA address is not in the neighbor cache it sends a NbSol with: > * the home address as the source > * the solicited-node multicast of the HA address as the destination > * the HA address at the target This can be fixed by either (a) keeping the home agent's information in the Neighbor Cache => how? the only way to get a neighbor cache entry in the reachable state is to receive a neighbor advertisement from the HA, so the MN should send a neighbor solicitation... The question is: with which source address? (b) using the anycast address => don't joke: you can not do something useful with the anycast address. (c) special-case code => special-case code should be recommended only when the standard procedure is not available. BTW there is one: perform DAD for the HA address: the HA will defend its address and by a side effect provide its link-layer address... But: - I don't want this procedure becomes the default - in last drafts this procedure was incorrectly "fixed" to use unicast probes. > - the HA receives the NbSol and does a stupid thing with it, > in my case it sends a NbAdv to the previous care-of address of the MN > with a RH. We can specify that the home agent doesn't do wrong things with such packets. => this is hard without opening a security hole. In fact, I reckon we should do so. Any home agent problem should be fixed in a Mobile IPv6 draft somewhere along the line... => I prefer to avoid problems than to fix them. > - the MN retries > - the MN retries > ... > > Conclusion: it does not work. My fix was simple: I modify the code > to always send the BU from the link-local address. It always works > until someone has the bad idea to use S=0 or a previous equivalent. I think it can and should be made to work. => is to defend only registered addresses too simple? Regards Francis.Dupont@enst-bretagne.fr PS: my code was before the security introduction so I got only the ND joke. If the MN returning at home has to re-establish a SA pair it has to get a working source address to speak with the HA and the link-layer address is a good candidate (IMHO this situation should be avoided by using longer lifetimes for SAs than for bindings but there are many other reasons to make an address locally usable for the MN as soon as it is attached). PPS: about scoped address and IKE: IMHO it is safe if the addresses in IKE ID (and soon TS :-) payloads are in a larger zone, i.e., a forbidden case is to run IKE with global addresses to setup SAs with link-local address selectors. From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 08:15:10 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25129 for ; Fri, 24 May 2002 08:15:10 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06481; Fri, 24 May 2002 06:14:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA25541; Fri, 24 May 2002 05:13:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OCD7rP014870 for ; Fri, 24 May 2002 05:13:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OCD7A4014869 for mobile-ip-dist; Fri, 24 May 2002 05:13:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OCD4rP014862 for ; Fri, 24 May 2002 05:13:04 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA05204 for ; Fri, 24 May 2002 05:13:09 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19460 for ; Fri, 24 May 2002 06:13:08 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4OCD2n10417; Fri, 24 May 2002 14:13:03 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA08193; Fri, 24 May 2002 14:13:02 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4OCCwT25055; Fri, 24 May 2002 14:13:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205241213.g4OCCwT25055@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Alper E. YEGIN" cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA In-reply-to: Your message of Thu, 23 May 2002 16:03:59 PDT. <013901c202ae$1ff1a390$8b6015ac@AlperVAIO> Date: Fri, 24 May 2002 14:12:58 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => this is an open point. Some believe RR check is simply > mandatory, some believe RR check is only one possible way > to fulfill security requirements and a suitable IPsec protection > should not need an extra RR check (the argument is the RR check > is not possible for the HA so "suitable IPsec" includes the trust > in the MN to not provide a fake CoA). Yes, this is the question: does a "suitable IPsec" include the trust in the MN to not provide a fake CoA? => I believe it does. But, if such a trust between MN and HA was sufficient, a "home test" that goes through HA should have been sufficient for sending BU to CN. => no because this "home test" assumes the CN trusts the HA and it has no more reasons to trust it than the MN. > => I believe the answer is no and I'd like to see how to perform a RR > check between the MN and the HA... After HA receives the IPsec'ed BU, we can add one more round-trip between the HA and the CoA. This can verify that the MN is really reachable at the CoA before binding cache entry is modified. => yes, we can do something similar to the case where the sequence number is wrong using the sequence number as a value the MN must repeat. Exceptions to this extra check (which is not the 5.5.5 RR) should be the return to home (H@ = Co@) and renew (old Co@ = new Co@). Is this check worth an extra round-trip? Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 08:22:08 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25263 for ; Fri, 24 May 2002 08:22:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23127; Fri, 24 May 2002 06:22:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA26863; Fri, 24 May 2002 05:21:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OCLJrP014988 for ; Fri, 24 May 2002 05:21:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OCLJUm014987 for mobile-ip-dist; Fri, 24 May 2002 05:21:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OCLGrP014980 for ; Fri, 24 May 2002 05:21:16 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14393 for ; Fri, 24 May 2002 05:21:21 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09659 for ; Fri, 24 May 2002 06:21:20 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4OCL3n11534; Fri, 24 May 2002 14:21:03 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA08377; Fri, 24 May 2002 14:21:03 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4OCL3T25138; Fri, 24 May 2002 14:21:03 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205241221.g4OCL3T25138@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Michael Thomas cc: "Alper E. YEGIN" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA In-reply-to: Your message of Thu, 23 May 2002 17:12:23 PDT. <15597.34151.931880.576634@thomasm-u1.cisco.com> Date: Fri, 24 May 2002 14:21:03 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: Let's see: the home agent knows which identity is bound to a particular *home* address, and it expects that anybody who is trying to change the binding for that home address to a new CoA must prove that it has keying material from the identity bound to that home address. Ie, it must ship an IPsec integrity protected BU meesage over an SA that was created using that identity. What's the problem here? => the issue is with the COA. I believe the check proposed by Alper is a good idea and as it is initiated or not by the HA, it is managed by the HA: it is a good option for IPsec protection. Regards Francis.Dupont@enst-bretagne.fr PS: 11.6.1 has a "The mobile node MUST store this information and use the next Sequence Number value for the next Binding Update it sends" at the reception of BA with status 141 "Sequence number out of window" so the bad sequence when the COA changes for something else than the home address is a suitable procedure (and with ESP this sequence number is not visible to eavesdroppers). From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 08:33:37 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25596 for ; Fri, 24 May 2002 08:33:36 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18664; Fri, 24 May 2002 05:32:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28811; Fri, 24 May 2002 05:31:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OCV9rP015105 for ; Fri, 24 May 2002 05:31:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OCV9Cx015104 for mobile-ip-dist; Fri, 24 May 2002 05:31:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OCV6rP015097 for ; Fri, 24 May 2002 05:31:06 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28732; Fri, 24 May 2002 05:31:11 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13705; Fri, 24 May 2002 06:31:10 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4OCV4n12960; Fri, 24 May 2002 14:31:08 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA08582; Fri, 24 May 2002 14:31:05 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4OCV4T25194; Fri, 24 May 2002 14:31:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205241231.g4OCV4T25194@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Samita Chakrabarti cc: mobile-ip@sunroof.eng.sun.com, alper@docomolabs-usa.com Subject: Re: [mobile-ip] RR and BU to HA In-reply-to: Your message of Thu, 23 May 2002 17:38:44 PDT. <200205240036.g4O0aI6U669888@jurassic.eng.sun.com> Date: Fri, 24 May 2002 14:31:04 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > => the only remaining threat is: > - the MN puts the address of V in the COA > - the HA trusts the MN which has protected the COA with IPsec > (so only a malicious MN can perform this attack) > - the traffic for the MN intercepted by the HA and the traffic for the MN > genuine to the HA flood the victim V > (the second kind of traffic is the CN reflexion attack but both: > - the HA has no way to verify the COA: it must trust the MN > - packets forwarded by the HA is added to genuine packets) Ok. Yes in this case, the threat exists. But this can only happen when the genuine MN already has registered with the HA at that time, so that the packets for the malicous MN gets tunneled to the genuine MN. If the genuine MN does not have a BCE, then it's not MIPv6 really, as there is no tunnel to the COA V. => no, I assume the MN itself is malicious. We could also restrict that a MN must not use more than *one* home-adress per COA. => I don't believe this is necessary and/or desirable. > Hence my conclusion: > - either we drop Mobile IPv6 until AAA infrastructure is available This is not a good idea. Instead the draft can recommend using AAA infrastructure for tighter security. => until I read Alper's message, I believe the only proof of the COA we can get was RR as in 5.5.5 and AAA. But we can use at the cost of an extra exchange a simple return-routability check... So I've changed a bit my opinion. > - or we accept the HA trusts its MNs (this can be viewed as the > authorization to use a service, cf. Mike Thomas' message). Yes. This is much better option. Having RR on MN-HA registration would be a overkill, MIPv6 has already too many signaling messages. => my proposed implementation of Alper's idea has a clear security/number of exchanges trade-off and the choice to initiate the check is in the hands of the HA, the trusting entity. So as an option I "vote" for it. > => no, if you'd like to register your previous care-of address in a HA > on the previous visited link in order to get "flying" packets to this > previous care-of, then you have two HAs... We don't necessarily need two HAs. A MN can move from one visited link to another and direct it's HA to forward 'flying packets' for it's old COA to this new COA. Although, I think mostly MNs would be okay without this COA packet forwarding in practice. => argh, I should have specified the `flying packets' are between the HA and the old COA. IMHO we should forget this `smooth' hand-off for this time. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 10:18:39 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29739 for ; Fri, 24 May 2002 10:18:39 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA07644; Fri, 24 May 2002 07:16:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18266; Fri, 24 May 2002 07:16:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OEFvrP015298 for ; Fri, 24 May 2002 07:15:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OEFu3b015297 for mobile-ip-dist; Fri, 24 May 2002 07:15:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OEFrrP015290 for ; Fri, 24 May 2002 07:15:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12456 for ; Fri, 24 May 2002 07:15:57 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13682 for ; Fri, 24 May 2002 08:15:57 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4OEFhQ10688; Fri, 24 May 2002 09:15:43 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 09:15:58 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D801AFCD5A@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'Fredrik Johansson'" , MobileIP Cc: bob@marksmob.com, "'Tony Johansson'" Subject: RE: [mobile-ip] draft-ietf-mobileip-aaa-nai-01.txt Date: Fri, 24 May 2002 09:15:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2032D.830B4240" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2032D.830B4240 Content-Type: text/plain; charset="iso-8859-1" Hi Fredrik, It looks perfect. Regards; Ahmad Muhanna Hi Ahmad, Sorry for the late response. I have no ptoblem with changing the text. I have updated the draft to say: "A mobile node that recieves this extension in a registration reply message MUST provide it in every registration request when re-authentication is needed. If the mobile node requests a specific home agent and it has the information available it MUST provide this extension in its initial registration request" Regards, /Fredrik Hello Fredrik, I know that you would like to address backward compatibility at the network side rather in this draft. However, If we can come up with something neat here, it would be a plus. What do you think about replacing paragraph 3 in section 4 by the proposed text below. Section 4: " A mobile node MUST provide this in every registration request sent when re-authenticating, or when requesting a specific IP address at initial authentication." Proposed text: " After receiving this extension in a registration reply message, the Mobile Node MUST provide it in every registration request when re-authenticating is needed. If the Mobile Node requests a specific IP address and this extension is available, the Mobile Node MUST provide this extension in its initial registration request. " Regards; Ahmad Muhanna > > > Hi All, > > We have submitted a new version of the above mentioned draft, > if you want > access to it before it gets published, it can be found at > > http://stargate.ipunplugged.com/ietf/draft-ietf-mobileip-aaa-n > ai-01.txt > > /Fredrik > > ------_=_NextPart_001_01C2032D.830B4240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] draft-ietf-mobileip-aaa-nai-01.txt

Hi Fredrik,
It looks perfect.

Regards;
Ahmad Muhanna


Hi Ahmad,
 
Sorry for the late response.
 
I have no ptoblem with changing the text. I have = updated the draft to say:

     "A mobile node that = recieves this extension in a registration reply
      message MUST provide = it in every registration request when
      re-authentication is = needed. If the mobile node requests a specific home
      agent and it has the = information available it MUST provide this
      extension in its = initial registration request"
 
Regards,
/Fredrik
   


Hello Fredrik,
I know that you would like to address backward = compatibility at the network side rather in this draft.
However, If we can come up with something neat here, = it would be a plus.
What do you think about replacing paragraph 3 in = section 4 by the proposed text below.
Section 4:
"  A mobile node MUST provide this in = every registration request sent
   when re-authenticating, or when = requesting a specific IP address at
   initial authentication."
Proposed text:
"  After receiving this extension in a = registration reply message, the Mobile Node
   MUST provide it in every registration = request when re-authenticating is needed.
   If the Mobile Node requests a specific = IP address and this extension is available,
   the Mobile Node MUST provide this = extension in its initial registration request.
"
Regards;
Ahmad Muhanna


>
>
> Hi All,
>
> We have submitted a new version of the above = mentioned draft,
> if you want
> access to it before it gets published, it can = be found at
>
> http://stargate.ipunplugged.com/ietf/draft-ietf-mobile= ip-aaa-n
> ai-01.txt
>
> /Fredrik
>
>

------_=_NextPart_001_01C2032D.830B4240-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 10:40:38 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00366 for ; Fri, 24 May 2002 10:40:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28277; Fri, 24 May 2002 08:40:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18755; Fri, 24 May 2002 07:40:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OEdOrP015406 for ; Fri, 24 May 2002 07:39:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OEdOWl015405 for mobile-ip-dist; Fri, 24 May 2002 07:39:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OEdKrP015398 for ; Fri, 24 May 2002 07:39:20 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4OEdLg00237; Fri, 24 May 2002 16:39:21 +0200 (MEST) Date: Fri, 24 May 2002 16:38:23 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Issue #23 and Issue #30 To: Francis Dupont Cc: Vijay Devarapalli , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200205220848.g4M8mIT15108@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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Conclusion: it does not work. My fix was simple: I modify the code > to always send the BU from the link-local address. It always works > until someone has the bad idea to use S=0 or a previous equivalent. But, based on RFC 2373 saying that interface IDs are unique on the link, one could argue that S=0 is the architecturally correct setting. Thus assuming that : can be claimed and used by the HA while fe80: is claimed and used by the MN at home seems to violate that architectural statement in RFC 2373. BTW: Section 6.1.7 points to section 10.2 for a description of how the (S) bit is used, but 10.2 doesn't appear to contain such text. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 10:42:10 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00465 for ; Fri, 24 May 2002 10:42:10 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19086; Fri, 24 May 2002 07:40:32 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18758; Fri, 24 May 2002 07:40:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OEckrP015396 for ; Fri, 24 May 2002 07:38:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OEck50015395 for mobile-ip-dist; Fri, 24 May 2002 07:38:46 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OEccrP015388 for ; Fri, 24 May 2002 07:38:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA18233 for ; Fri, 24 May 2002 07:38:38 -0700 (PDT) From: arvind.sevalkar@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA23537 for ; Fri, 24 May 2002 08:38:37 -0600 (MDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002052420123817:4236 ; Fri, 24 May 2002 20:12:38 +0530 Subject: Re: [mobile-ip] issue #25 To: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= Cc: Francis.Dupont@enst-bretagne.fr, mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Fri, 24 May 2002 20:07:56 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/24/2002 08:08:56 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/24/2002 08:12:38 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/24/2002 08:12:43 PM, Serialize complete at 05/24/2002 08:12:43 PM Message-ID: X-Priority: 3 (Normal) Content-type: text/plain; charset=iso-2022-jp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Keiichi SHIMA / $BEg7D0l(B To: arvind.sevalkar@lntinfotech.com Sent by: cc: Francis.Dupont@enst-bretagne.fr, owner-mobile-ip@sunroof.e mobile-ip@sunroof.eng.sun.com ng.sun.com Subject: Re: [mobile-ip] issue #25 05/24/2002 11:58 AM Hi, From: arvind.sevalkar > But is it really necessary to send Binding Acknowledgement with routing > header when there is no binding in cache. Because routing header is > included when there is an entry in the binding cache some implementation > checks routing header for binding in binding cache. > We can simply do one thing when there is a binding in the Binding cache > then we will send BA with routing header and when there is no Binding in > the Binding cache then we will send BA to the Home address without routing > header. > So BA will be sent to HA without RH header in two cases. > 1>BU successful and which is for deleting Binding cache entry. > 2>BU failed and there is no entry in Binding cache, in case when first time > MN sends BU to CN and that fails. I agree with this approach. The HA and the CN just check if they have a valid binding cache entry for the MN before sending packets to the internet. If they have, they add a rthdr type 2 to all the outgoing packets to the MN. If they don't have, just sent it to as is (not inserting a rthdr type 2). ==>> I think this is logical also If HA or CN has binding in binding cache then send BA with routing header otherwise don't. why to add special code for sending BA with routing header, when there is no binding in the binding cache? What is the need of it? Arvind From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 10:56:52 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00935 for ; Fri, 24 May 2002 10:56:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07721; Fri, 24 May 2002 08:56:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23421; Fri, 24 May 2002 07:56:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OEt1rP015549 for ; Fri, 24 May 2002 07:55:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OEt1e2015548 for mobile-ip-dist; Fri, 24 May 2002 07:55:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OEsvrP015541 for ; Fri, 24 May 2002 07:54:57 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4OEsxg01523; Fri, 24 May 2002 16:55:00 +0200 (MEST) Date: Fri, 24 May 2002 16:54:02 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] RR and BU to HA To: "Alper E. YEGIN" Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <030501c20201$4db7cff0$8b6015ac@AlperVAIO> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > But it suggests that one can use IPsec between > the MN and the HA when MN is sending a BU, > and this should be sufficient.... Shouldn't we be > doing a RR on the CoA even if we are using IPsec? [I'm assuming that IPsec authentication ensures that the MN is not being spoofed.] A possible way to look at this is to compare the relationship between the nodes. The HA and MN have some form of trust relationship and some form of business relationship (whether or not money changes hands). The CN and MN are not assumed to have any such relationship. Thus if a MN misbehaves by sending BUs to its HA that have a bogus CoA (for the purposes of launching a DoS attack against that CoA) the victim can contact the HA's adminstration/ISP to alert them of this attack and they can take appropriate action against the MN usingv the above relationship. Contrast this with the CN case where the MN, using a bogus CoA, can cause a CN with high bandwidth to flood the victim. If the victim contacts the CN they are not likely to be able to do anything about the misbehaving MN due to the lack of a relationship. Also, if the HA was indeed required to to a CoA RR check, it doesn't prevent misbehavior. The HA and MN might be run by the same administation (i.e. my HA at home and my MN on the road), in which case the HA might just ignore the requirement to do the CoA RR check, or the HA might pretend that the HA exists when in fact there is no HA. So requiring the HA doing a CoA RR check doesn't seem to remove the need for adminstrative measures that treat the HA+MN as one unit when it comes to misbehavior. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 11:41:21 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02969 for ; Fri, 24 May 2002 11:41:20 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24663; Fri, 24 May 2002 08:39:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15888; Fri, 24 May 2002 08:39:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OFc5rP015751 for ; Fri, 24 May 2002 08:38:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OFc5cM015750 for mobile-ip-dist; Fri, 24 May 2002 08:38:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OFc1rP015743 for ; Fri, 24 May 2002 08:38:01 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08809 for ; Fri, 24 May 2002 08:38:06 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01548 for ; Fri, 24 May 2002 09:38:05 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4OFbpn13797; Fri, 24 May 2002 17:37:51 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA12408; Fri, 24 May 2002 17:37:51 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4OFboT26345; Fri, 24 May 2002 17:37:51 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205241537.g4OFboT26345@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: arvind.sevalkar@lntinfotech.com cc: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issue #25 In-reply-to: Your message of Fri, 24 May 2002 20:07:56 +0530. Date: Fri, 24 May 2002 17:37:50 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: I think this is logical also If HA or CN has binding in binding cache then send BA with routing header otherwise don't. why to add special code for sending BA with routing header, when there is no binding in the binding cache? What is the need of it? => to provide the home address when the BU had one. So the logic (in the I-D 17 and all previous I-Ds) is to put a RH in the BA when the corresponding BU had a HAO (this moves the question to when the BU should have a HAO? :-). Francis.Dupont@enst-bretagne.fr PS: rationale: the MN sends a BU from the CO@ for H@, it receives a BA: - what is the destination address in the header (answer: CO@) - what is the destination address seen, for instance, by IPsec (answer: H@x) So if the CO@ is not the H@, the BA must have a RH, and the BU must have had a HAO. (This should be rewritten in better English and inserted into the next draft, shouldn't it?) From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 12:01:24 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03750 for ; Fri, 24 May 2002 12:01:23 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14657; Fri, 24 May 2002 10:01:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22575; Fri, 24 May 2002 09:00:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OFwPrP015856 for ; Fri, 24 May 2002 08:58:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OFwPCu015855 for mobile-ip-dist; Fri, 24 May 2002 08:58:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OFwMrP015848 for ; Fri, 24 May 2002 08:58:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21923 for ; Fri, 24 May 2002 08:58:27 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04892 for ; Fri, 24 May 2002 08:58:26 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 925216A906; Fri, 24 May 2002 18:58:20 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 0F3E56A904; Fri, 24 May 2002 18:58:15 +0300 (EEST) Message-ID: <3CEE6359.1050606@kolumbus.fi> Date: Fri, 24 May 2002 18:59:21 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Alper E. YEGIN" Cc: Francis Dupont , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA References: <200205230955.g4N9tcT19737@givry.rennes.enst-bretagne.fr> <013901c202ae$1ff1a390$8b6015ac@AlperVAIO> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alper E. YEGIN wrote: > But, if such a trust between MN and HA was sufficient, a "home > test" that goes through HA should have been sufficient for > sending BU to CN. Home agent could verify that the MN is > authenticated and authorized before passing the test packet on. > Am I missing something?? One difference that was mentioned was the trust, or at least relationship, between the MN-HA which doesn't exist between the CN and either of the two other nodes. Another difference is that the MN-HA security is end-to-end and directly observable by the end-points. In the case above, the CN would have to not just trust the HA, but also the _path_ towards the HA. For these reasons the care-of tests are necessary in the CN case. It isn't clear that the same reasons apply in the HA case. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 12:03:40 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03850 for ; Fri, 24 May 2002 12:03:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00740; Fri, 24 May 2002 10:04:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23501; Fri, 24 May 2002 09:03:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OG2NrP015940 for ; Fri, 24 May 2002 09:02:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OG2N99015939 for mobile-ip-dist; Fri, 24 May 2002 09:02:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OG2GrP015924 for ; Fri, 24 May 2002 09:02:16 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16022 for ; Fri, 24 May 2002 09:02:21 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07330 for ; Fri, 24 May 2002 09:02:20 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4OG0Rn16650; Fri, 24 May 2002 18:00:31 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA12821; Fri, 24 May 2002 18:00:27 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4OG0RT26451; Fri, 24 May 2002 18:00:27 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205241600.g4OG0RT26451@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Vijay Devarapalli , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Fri, 24 May 2002 16:38:23 +0200. Date: Fri, 24 May 2002 18:00:27 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > Conclusion: it does not work. My fix was simple: I modify the code > to always send the BU from the link-local address. It always works > until someone has the bad idea to use S=0 or a previous equivalent. But, based on RFC 2373 saying that interface IDs are unique on the link, => but can you argue that for a mobile node which is not attached to the home link? RFC 2373 (last draft has the same text) says: - IIDs in unicasts are used to identify interfaces on a link. - They are required to be unique on that link. Is it equivalent to "IIDs in unicast are used to identify in an unique way interfaces on a link"? one could argue that S=0 is the architecturally correct setting. Thus assuming that : can be claimed and used by the HA => : doesn't identify the interface of the HA. The HA service is a proxy service so the rule to apply is the same than for anycasts. while fe80: is claimed and used by the MN at home seems to violate that architectural statement in RFC 2373. => a simple question: is it forbidden for two routers to provide a neighbor discovery proxy service for the same address? Of course not so I believe your concern is not about the use but the claim, i.e., about DAD. But as DAD is not DIIDD I can't see a real objection to allow a proxy server to perform a DAD on an address it serves. Regards Francis.Dupont@enst-bretagne.fr PS: IMHO a DIIDD should have been better than current DAD (more architecturally correct for instance :-) but it is far too late to fix that. From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 12:14:52 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04239 for ; Fri, 24 May 2002 12:14:52 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15853; Fri, 24 May 2002 10:14:46 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19955; Fri, 24 May 2002 09:14:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OGDOrP016069 for ; Fri, 24 May 2002 09:13:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OGDOWh016068 for mobile-ip-dist; Fri, 24 May 2002 09:13:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OGDLrP016061 for ; Fri, 24 May 2002 09:13:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26722 for ; Fri, 24 May 2002 09:13:27 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14163 for ; Fri, 24 May 2002 09:13:26 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 3B6506A907; Fri, 24 May 2002 19:13:25 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A13286A904; Fri, 24 May 2002 19:13:22 +0300 (EEST) Message-ID: <3CEE66E4.6080509@kolumbus.fi> Date: Fri, 24 May 2002 19:14:28 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Erik Nordmark Cc: "Alper E. YEGIN" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > So requiring the HA doing a CoA RR check doesn't seem to remove the > need for adminstrative measures that treat the HA+MN as one unit > when it comes to misbehavior. This is true, and I agree. It considers HA+MN from an outside viewpoint. There may be another aspect if you look at things from the inside, e.g. from the point of view of e.g. an ISP operating a HA. While they have a contractual relationship with the MN's owner, they might still wish to _prevent_ forged CoAs rather just to send a bill/police to the MN's owner afterwards, if someone complains. Still, the ISP could cut the MN's access off immediately when a complaint is received. So I'm not sure a test is worth the trouble. Certainly not as a mandatory thing for everyone. I think Francis was saying that we already do something similar in the sequence number resync case. Actually, it seems that the HA could implement a CoA test using existing protocol mechanisms, if they wanted. Just complain about a wrong sequence number, and require the MN to resync. The right sequence number will not be received if the CoA was wrong. (Of course, with some effort you could guess the sequence number with repeated trials, but at this point the HA would probably notice that something funny is going on anyway.) In conclusion, we have the following options: (1) Declare that we never need such tests. End of story. (2) Declare that we always need such tests, and add this to the protocol. (3) Declare that you are allowed to run such tests, if your policy requires it. You could alternatively implement this with (a) existing mechanisms or (b) design new mechanisms. My personal preference is either (1) or (3a). I don't think we should spend too many cycles on specifying this or roundtrips on doing it. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 12:22:51 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04449 for ; Fri, 24 May 2002 12:22:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20797; Fri, 24 May 2002 10:22:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22976; Fri, 24 May 2002 09:22:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OGM1rP016172 for ; Fri, 24 May 2002 09:22:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OGM1C1016171 for mobile-ip-dist; Fri, 24 May 2002 09:22:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OGLvrP016164 for ; Fri, 24 May 2002 09:21:58 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29327 for ; Fri, 24 May 2002 09:22:03 -0700 (PDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20333 for ; Fri, 24 May 2002 10:22:03 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g4OGLmuF029205; Fri, 24 May 2002 09:21:48 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABS73275; Fri, 24 May 2002 09:18:58 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA04621; Fri, 24 May 2002 09:21:58 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15598.26790.75865.974384@thomasm-u1.cisco.com> Date: Fri, 24 May 2002 09:21:58 -0700 (PDT) To: Jari Arkko Cc: Erik Nordmark , "Alper E. YEGIN" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA In-Reply-To: <3CEE66E4.6080509@kolumbus.fi> References: <3CEE66E4.6080509@kolumbus.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko writes: > In conclusion, we have the following options: > > (1) Declare that we never need such tests. End of story. > (2) Declare that we always need such tests, and add this > to the protocol. > (3) Declare that you are allowed to run such tests, if your > policy requires it. You could alternatively implement this > with (a) existing mechanisms or (b) design new mechanisms. Jari -- I vote for (1). Nothing would prevent us from implementing (3) at a later date if it were perceived to be necessary. Indeed, keeping our options open here may actually be a benefit for mobility since being able to project a new binding where you aren't currently reachable -- but assumely will be soon -- could be advantageous for MN's trying to keep connectivity. Mike From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 12:25:34 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04561 for ; Fri, 24 May 2002 12:25:33 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22499; Fri, 24 May 2002 10:25:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24223; Fri, 24 May 2002 09:25:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OGONrP016246 for ; Fri, 24 May 2002 09:24:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OGOMcP016243 for mobile-ip-dist; Fri, 24 May 2002 09:24:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OGOJrP016235 for ; Fri, 24 May 2002 09:24:19 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26824 for ; Fri, 24 May 2002 09:24:25 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20587 for ; Fri, 24 May 2002 09:24:24 -0700 (PDT) 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 MAA10694 for ; Fri, 24 May 2002 12:24:23 -0400 (EDT) From: "Dr. Subrata Goswami" To: Subject: RE: [mobile-ip] RR and BU to HA Date: Fri, 24 May 2002 09:27:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <3CEE66E4.6080509@kolumbus.fi> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit If the CoA is not being used, then the HA does not have a BCE for it, which implies that the MN can use the CoA if it wants without bothering any other MN. The question would be does the HA allow a CoA to be shared between multiple MN's ? Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Jari Arkko Sent: Friday, May 24, 2002 9:14 AM To: Erik Nordmark Cc: Alper E. YEGIN; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA Erik Nordmark wrote: > So requiring the HA doing a CoA RR check doesn't seem to remove the > need for adminstrative measures that treat the HA+MN as one unit > when it comes to misbehavior. This is true, and I agree. It considers HA+MN from an outside viewpoint. There may be another aspect if you look at things from the inside, e.g. from the point of view of e.g. an ISP operating a HA. While they have a contractual relationship with the MN's owner, they might still wish to _prevent_ forged CoAs rather just to send a bill/police to the MN's owner afterwards, if someone complains. Still, the ISP could cut the MN's access off immediately when a complaint is received. So I'm not sure a test is worth the trouble. Certainly not as a mandatory thing for everyone. I think Francis was saying that we already do something similar in the sequence number resync case. Actually, it seems that the HA could implement a CoA test using existing protocol mechanisms, if they wanted. Just complain about a wrong sequence number, and require the MN to resync. The right sequence number will not be received if the CoA was wrong. (Of course, with some effort you could guess the sequence number with repeated trials, but at this point the HA would probably notice that something funny is going on anyway.) In conclusion, we have the following options: (1) Declare that we never need such tests. End of story. (2) Declare that we always need such tests, and add this to the protocol. (3) Declare that you are allowed to run such tests, if your policy requires it. You could alternatively implement this with (a) existing mechanisms or (b) design new mechanisms. My personal preference is either (1) or (3a). I don't think we should spend too many cycles on specifying this or roundtrips on doing it. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 12:31:14 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04763 for ; Fri, 24 May 2002 12:31:14 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23603; Fri, 24 May 2002 09:29:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25821; Fri, 24 May 2002 09:29:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OGStrP016374 for ; Fri, 24 May 2002 09:28:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OGStOU016373 for mobile-ip-dist; Fri, 24 May 2002 09:28:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OGSqrP016363 for ; Fri, 24 May 2002 09:28:52 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28838 for ; Fri, 24 May 2002 09:28:57 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24544 for ; Fri, 24 May 2002 10:28:57 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4OGT9Q24677; Fri, 24 May 2002 11:29:09 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 11:28:55 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D2403E61B81@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: mobile-ip@sunroof.eng.sun.com Cc: charliep@iprg.nokia.com Subject: [mobile-ip] Requested changes in RFC3220 Date: Fri, 24 May 2002 11:28:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20340.17A38D60" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20340.17A38D60 Content-Type: text/plain; charset="iso-8859-1" Hi all, Sometime ago we had an email discussion on processing of RRQ at the HA and the possible fields in the RRP. The result of the email discussion was some "proposed text" for the updated version of RFC3220 (RFC3220bis). I have tried to capture the proposed text below (paragraph 5 of section 3.8.3.2). We also added an additional restriction in the 4th paragraph of section 3.8.3.2 of RFC 3220. I have exchanged email with Charlie and we are in agreement with these changes in this section. Please review and comment if necessary. The changes are in the 4th and the 5th paragraph of section 3.8.3.2. " 3.8.3.2. Registration Reply Fields ...... If the Home Address field of the Registration Request is nonzero, it MUST be copied into the Home Address field of the Registration Reply message. If the non-zero unicast address in the Home Address field does not belong to the subnet of the Home Agent, then the Home Agent MUST reject the registration with an error code of 130. Otherwise ... If the Home Agent field in the Registration Request contains a unicast address of this home agent, then that field MUST be copied into the Home Agent field of the Registration Reply. Otherwise, the home agent MUST set the Home Agent field in the Registration Reply to its unicast address. In this latter case, if the destination IP address of the Registration Request is the unicast IP address of this Home Agent, the Home Agent MAY accept the Registration Request. If the destination IP address of the Registration Request is not the unicast IP address of this Home Agent, the home agent MUST reject the Registration Request with a suitable code(e.g., Code 136) to prevent the mobile node from possibly being simultaneously registered with two or more Home Agents. " Regards, Kuntal ------_=_NextPart_001_01C20340.17A38D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Requested changes in RFC3220

Hi all,
Sometime ago we had an email discussion on = processing of RRQ at the HA and the possible fields in the RRP. The = result of the email discussion was some "proposed text" for = the updated version of RFC3220 (RFC3220bis). I have tried to capture = the proposed text below (paragraph 5 of section 3.8.3.2). We also added = an additional restriction in the 4th paragraph of section 3.8.3.2 of = RFC 3220. I have exchanged email with Charlie and we are in agreement = with these changes in this section. Please review and comment if = necessary.

The changes are in the 4th and the 5th paragraph of = section 3.8.3.2.

"
3.8.3.2. Registration Reply Fields

   ......

   If the Home Address field of the = Registration Request is nonzero, it
   MUST be copied into the Home Address = field of the Registration Reply
   message. If the non-zero unicast = address in the Home Address field
   does not belong to the subnet of the = Home Agent, then the Home Agent
   MUST reject the registration with an = error code of 130. Otherwise ...
  

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


Regards,
Kuntal

------_=_NextPart_001_01C20340.17A38D60-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 12:46:16 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05258 for ; Fri, 24 May 2002 12:46:16 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02001; Fri, 24 May 2002 09:44:43 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01265; Fri, 24 May 2002 09:44:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OGhfrP016481 for ; Fri, 24 May 2002 09:43:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OGhfkD016480 for mobile-ip-dist; Fri, 24 May 2002 09:43:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OGhcrP016473 for ; Fri, 24 May 2002 09:43:38 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04912 for ; Fri, 24 May 2002 09:43:44 -0700 (PDT) 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 KAA02994 for ; Fri, 24 May 2002 10:43:43 -0600 (MDT) 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 MAA14707 for ; Fri, 24 May 2002 12:43:42 -0400 (EDT) From: "Dr. Subrata Goswami" To: Subject: RE: [mobile-ip] RR and BU to HA Date: Fri, 24 May 2002 09:47:05 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Is there a possibility of similar spoofing in the Home Address (HoA) field in RR/BU ? How should the CN/HA treat a BU/RR with a "spoofed" HoA ? Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Dr. Subrata Goswami Sent: Friday, May 24, 2002 9:28 AM To: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RR and BU to HA If the CoA is not being used, then the HA does not have a BCE for it, which implies that the MN can use the CoA if it wants without bothering any other MN. The question would be does the HA allow a CoA to be shared between multiple MN's ? Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com]On Behalf Of Jari Arkko Sent: Friday, May 24, 2002 9:14 AM To: Erik Nordmark Cc: Alper E. YEGIN; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA Erik Nordmark wrote: > So requiring the HA doing a CoA RR check doesn't seem to remove the > need for adminstrative measures that treat the HA+MN as one unit > when it comes to misbehavior. This is true, and I agree. It considers HA+MN from an outside viewpoint. There may be another aspect if you look at things from the inside, e.g. from the point of view of e.g. an ISP operating a HA. While they have a contractual relationship with the MN's owner, they might still wish to _prevent_ forged CoAs rather just to send a bill/police to the MN's owner afterwards, if someone complains. Still, the ISP could cut the MN's access off immediately when a complaint is received. So I'm not sure a test is worth the trouble. Certainly not as a mandatory thing for everyone. I think Francis was saying that we already do something similar in the sequence number resync case. Actually, it seems that the HA could implement a CoA test using existing protocol mechanisms, if they wanted. Just complain about a wrong sequence number, and require the MN to resync. The right sequence number will not be received if the CoA was wrong. (Of course, with some effort you could guess the sequence number with repeated trials, but at this point the HA would probably notice that something funny is going on anyway.) In conclusion, we have the following options: (1) Declare that we never need such tests. End of story. (2) Declare that we always need such tests, and add this to the protocol. (3) Declare that you are allowed to run such tests, if your policy requires it. You could alternatively implement this with (a) existing mechanisms or (b) design new mechanisms. My personal preference is either (1) or (3a). I don't think we should spend too many cycles on specifying this or roundtrips on doing it. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 13:31:28 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06300 for ; Fri, 24 May 2002 13:31:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01264; Fri, 24 May 2002 11:31:01 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23208; Fri, 24 May 2002 10:30:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OHTbrP016579 for ; Fri, 24 May 2002 10:29:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OHTabK016578 for mobile-ip-dist; Fri, 24 May 2002 10:29:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OHTXrP016571 for ; Fri, 24 May 2002 10:29:33 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22806 for ; Fri, 24 May 2002 10:29:37 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05930 for ; Fri, 24 May 2002 11:29:36 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 0B8FA6A906; Fri, 24 May 2002 20:29:36 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A13C86A904; Fri, 24 May 2002 20:29:34 +0300 (EEST) Message-ID: <3CEE78C0.4070604@kolumbus.fi> Date: Fri, 24 May 2002 20:30:40 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Dr. Subrata Goswami" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dr. Subrata Goswami wrote: > Is there a possibility of similar spoofing in the Home Address (HoA) field > in RR/BU ? How should the CN/HA treat a BU/RR with a "spoofed" HoA ? I'm not sure I understand the question, but if you are asking for the basic spoofing attack of claiming a wrong home address, then in the CN case we make a home address test. In the HA case we must make sure that the right SA is used together with the right home address, to prevent another mobile for the same HA taking over your address. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 13:35:04 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06449 for ; Fri, 24 May 2002 13:35:03 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03084; Fri, 24 May 2002 11:35:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAB25068; Fri, 24 May 2002 10:34:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OHY3rP016650 for ; Fri, 24 May 2002 10:34:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OHY35u016649 for mobile-ip-dist; Fri, 24 May 2002 10:34:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OHXxrP016642 for ; Fri, 24 May 2002 10:33:59 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20428 for ; Fri, 24 May 2002 10:34:04 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08348 for ; Fri, 24 May 2002 11:34:03 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id CA7DF6A906; Fri, 24 May 2002 20:34:02 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5F4296A904; Fri, 24 May 2002 20:34:00 +0300 (EEST) Message-ID: <3CEE79CA.5090901@kolumbus.fi> Date: Fri, 24 May 2002 20:35:06 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Dr. Subrata Goswami" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dr. Subrata Goswami wrote: > If the CoA is not being used, then the HA does not have a BCE for it, which > implies that the MN can use the CoA if it wants without bothering any other > MN. The question would be does the HA allow a CoA to be shared between > multiple MN's ? I don't see a reason to prohibit the same CoA for several MNs. Anyway, as long as the MN doesn't register its current address in the home agent, it looks exacly like any IPv6 address and the same rules apply on duplicate address detection etc. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 14:26:01 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08689 for ; Fri, 24 May 2002 14:26:00 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04100; Fri, 24 May 2002 12:25:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24219; Fri, 24 May 2002 11:25:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OIOnrP016861 for ; Fri, 24 May 2002 11:24:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OIOnt8016860 for mobile-ip-dist; Fri, 24 May 2002 11:24:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OIOjrP016853 for ; Fri, 24 May 2002 11:24:45 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4OIOm6U851520; Fri, 24 May 2002 11:24:48 -0700 (PDT) Message-Id: <200205241824.g4OIOm6U851520@jurassic.eng.sun.com> Date: Fri, 24 May 2002 11:27:14 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] RR and BU to HA To: jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com, Erik.Nordmark@sun.com, alper@docomolabs-usa.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: KhfGkd24pmcOJ8sMo5WeTA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Erik Nordmark wrote: > > > > So requiring the HA doing a CoA RR check doesn't seem to remove the > > need for adminstrative measures that treat the HA+MN as one unit > > when it comes to misbehavior. > > This is true, and I agree. > > It considers HA+MN from an outside viewpoint. There > may be another aspect if you look at things from the > inside, e.g. from the point of view of e.g. an ISP operating > a HA. While they have a contractual relationship with the MN's > owner, they might still wish to _prevent_ forged CoAs rather > just to send a bill/police to the MN's owner afterwards, if > someone complains. Still, the ISP could cut the MN's access > off immediately when a complaint is received. So I'm not sure > a test is worth the trouble. Certainly not as a mandatory thing > for everyone. Exactly. The above comments have explained the rational why there is no strong reason to have RR COA test for MN-HA registration. I agree, it is unnecessary to impose mandatory RR COA check between MN-HA for the home registration. I wonder, if it makes sense to have a recommendation for HA to dis-allow *multiple* home-addresses per globally unique COA, when a BCE already exists for that COA associating with a different Home-addr. [This will prevent the case when malicous MN tries to put victim MN's COA in the home-registration to fool HA] > > In conclusion, we have the following options: > > (1) Declare that we never need such tests. End of story. Let's try 1) and move forward. -Samita From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 14:26:22 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08715 for ; Fri, 24 May 2002 14:26:22 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27141; Fri, 24 May 2002 11:24:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23806; Fri, 24 May 2002 11:24:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OINnrP016844 for ; Fri, 24 May 2002 11:23:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OINnVg016843 for mobile-ip-dist; Fri, 24 May 2002 11:23:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OINgrP016836 for ; Fri, 24 May 2002 11:23:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10488 for ; Fri, 24 May 2002 11:23:47 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19011 for ; Fri, 24 May 2002 12:23:45 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4OINdmG004392 for ; Fri, 24 May 2002 20:23:44 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri May 24 20:23:38 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 20:12:35 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0690@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Jari Arkko'" , Erik Nordmark Cc: "Alper E. YEGIN" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RR and BU to HA Date: Fri, 24 May 2002 20:23:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > In conclusion, we have the following options: > > (1) Declare that we never need such tests. End of story. > (2) Declare that we always need such tests, and add this > to the protocol. > (3) Declare that you are allowed to run such tests, if your > policy requires it. You could alternatively implement this > with (a) existing mechanisms or (b) design new mechanisms. > => Can we have option 4 ? ;) 4) Leave it as is. I can't find anything wrong with Erik's analysis actually, we have to treat the MN-HA as one unit. option 1) will open the door for reflection attacks which breaks the 'do no harm' policy. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 14:40:17 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09792 for ; Fri, 24 May 2002 14:40:17 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA04244; Fri, 24 May 2002 11:38:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29743; Fri, 24 May 2002 11:38:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OIbdrP017042 for ; Fri, 24 May 2002 11:37:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OIbddN017041 for mobile-ip-dist; Fri, 24 May 2002 11:37:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OIbZrP017034 for ; Fri, 24 May 2002 11:37:35 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15796 for ; Fri, 24 May 2002 11:37:40 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03695 for ; Fri, 24 May 2002 11:37:39 -0700 (PDT) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4OIbXmG005600 for ; Fri, 24 May 2002 20:37:38 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Fri May 24 20:37:33 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 20:26:29 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0692@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Jari Arkko'" , Erik Nordmark Cc: "Alper E. YEGIN" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RR and BU to HA Date: Fri, 24 May 2002 20:37:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jari, After writing my email I realised that it might be misunderstood. I thought you were referring to removing the CoA tests for CNs as well. If that's what you meant then my answer is correct. But if you were only considering the HA then I agree with 1). 3a is ok, but it might be too much work... Hesham > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Friday, May 24, 2002 6:14 PM > To: Erik Nordmark > Cc: Alper E. YEGIN; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] RR and BU to HA > > > Erik Nordmark wrote: > > > > So requiring the HA doing a CoA RR check doesn't seem to > remove the > > need for adminstrative measures that treat the HA+MN as one unit > > when it comes to misbehavior. > > This is true, and I agree. > > It considers HA+MN from an outside viewpoint. There > may be another aspect if you look at things from the > inside, e.g. from the point of view of e.g. an ISP operating > a HA. While they have a contractual relationship with the MN's > owner, they might still wish to _prevent_ forged CoAs rather > just to send a bill/police to the MN's owner afterwards, if > someone complains. Still, the ISP could cut the MN's access > off immediately when a complaint is received. So I'm not sure > a test is worth the trouble. Certainly not as a mandatory thing > for everyone. > > I think Francis was saying that we already do something similar > in the sequence number resync case. Actually, it seems that the > HA could implement a CoA test using existing protocol mechanisms, > if they wanted. Just complain about a wrong sequence number, > and require the MN to resync. The right sequence number will not > be received if the CoA was wrong. (Of course, with some effort > you could guess the sequence number with repeated trials, but > at this point the HA would probably notice that something funny > is going on anyway.) > > In conclusion, we have the following options: > > (1) Declare that we never need such tests. End of story. > (2) Declare that we always need such tests, and add this > to the protocol. > (3) Declare that you are allowed to run such tests, if your > policy requires it. You could alternatively implement this > with (a) existing mechanisms or (b) design new mechanisms. > > My personal preference is either (1) or (3a). I don't think > we should spend too many cycles on specifying this or roundtrips > on doing it. > > Jari > From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 14:46:53 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10166 for ; Fri, 24 May 2002 14:46:52 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14640; Fri, 24 May 2002 12:46:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03488; Fri, 24 May 2002 11:46:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OIk5rP017133 for ; Fri, 24 May 2002 11:46:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OIk4U5017132 for mobile-ip-dist; Fri, 24 May 2002 11:46:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OIk1rP017125 for ; Fri, 24 May 2002 11:46:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23309 for ; Fri, 24 May 2002 11:46:06 -0700 (PDT) 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 MAA16226 for ; Fri, 24 May 2002 12:46:53 -0600 (MDT) 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 OAA08152 for ; Fri, 24 May 2002 14:46:05 -0400 (EDT) From: "Dr. Subrata Goswami" To: Subject: FW: [mobile-ip] RR and BU to HA Date: Fri, 24 May 2002 11:49:27 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Is there a possibility of similar spoofing in the Home Address (HoA) field in RR/BU ? How should the CN/HA treat a BU/RR with a "spoofed" HoA ? Jari: I'm not sure I understand the question, but if you are asking for the basic spoofing attack of claiming a wrong home address, then in the CN case we make a home address test. In the HA case we must make sure that the right SA is used together with the right home address, to prevent another mobile for the same HA taking over your address. Subrata: That is solved when an SA exists. Setting up the SA is another open issue. Is the SA approach going to scale to large number of MN's ? In the absences of IPSec SA, it is possible for an MN to highjack a HoA. This can be made a little more difficult if the HA checks that HoA has not changed the L2 MAC address (This probably would be a new requirement). It would not be easy for an MN to spoof both the HoA and L2 MAC at the same time. From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 15:14:54 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11050 for ; Fri, 24 May 2002 15:14:53 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00493; Fri, 24 May 2002 13:15:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA00157; Fri, 24 May 2002 12:14:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OJD8rP017240 for ; Fri, 24 May 2002 12:13:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OJD8mE017239 for mobile-ip-dist; Fri, 24 May 2002 12:13:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OJD4rP017226 for ; Fri, 24 May 2002 12:13:04 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01070 for ; Fri, 24 May 2002 12:13:10 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17916 for ; Fri, 24 May 2002 12:13:09 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 598FB176B; Fri, 24 May 2002 14:13:09 -0500 (CDT) Received: from anw.zk3.dec.com (anw4.zk3.dec.com [16.140.48.4]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 34A4813C7; Fri, 24 May 2002 14:13:08 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id PAA0002298288; Fri, 24 May 2002 15:13:06 -0400 (EDT) Message-ID: <3CEE90C2.7010903@hp.com> Date: Fri, 24 May 2002 15:13:06 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles E. Perkins" Cc: Francis Dupont , Vijay Devarapalli , jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> <3CED6015.E7A39399@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit There seems to be a contension of whether the HA has to proxy for the link-local address. The interesting thing is, that I believe there is a problem in both arguments. If the link-local address is not defended by the HA, any other node on the link may be able to configure that link-local address and using the DAD optimization in 2462, can even configure global addresses. This is bad. The solution seems to be to prohibit the DAD optimization, but that doesn't fully help as the link-local address was allowed. So this still doesn't look right. On the oter hand, if the link-local address is defended by the HA, the other nodes will not be able to configure the link-local or global addresses. So everything seems OK, but there are problems with this scenario as well. The problems are in the same category of the mobile returning home. If the mobile is active when it returns home, it knows that it's home when it recieves the RA contining the home prefix. At this time the mobile can unregister, but it needs the link-address of the HA. It can get that if the RAs contain the link-address option. The RA will cause a creating of a STALE neighbor cache entry on the MN, that the mobile can use. Since the entry is STALE, the unregistration packet will be sent and the entry will be transitioned to DELAY state. On the BAck, since the binding no-longer exists, normal ND will work correctly. If the mobile is inactive when it returns home (and the binding was not deleted for whatever reason) the problem is bigger. The MN will try to configure the link-local address as part of standard IPv6 initialization (it has no idea it's home yet because it doesn't have an interface up yet, so it hasn't seen an RA to tell it that it's home), but will fail because the HA will defend the link-local address. A possible workaround (a big hack :) to this is once DAD fails, the MN can try to un-register with the HA using the following procedure: 1. Send a RS to all-routers multicast from the :: address. 2. Wait for the RA with the H bit set. * for this to work the RA must contain the "Link Address" option. this will create a stale cache entry on MN 3. Send the unregistration using the :: address with the HOA listing the last known home address (that the mobile usually stores). 4. Imidiately start the DAD procedure again. As I said, this is a big hack. I don't know what the security implications are and if IPSec can be used to verify this, so I leave that to someone who knows more about IPSec and security. Just my thoughts on the issue. -vlad +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 15:53:46 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12370 for ; Fri, 24 May 2002 15:53:45 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15067; Fri, 24 May 2002 13:53:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14504; Fri, 24 May 2002 12:53:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OJqYrP017403 for ; Fri, 24 May 2002 12:52:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OJqYSf017402 for mobile-ip-dist; Fri, 24 May 2002 12:52:34 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OJqVrP017395 for ; Fri, 24 May 2002 12:52:31 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4OJqb6U870446; Fri, 24 May 2002 12:52:37 -0700 (PDT) Message-Id: <200205241952.g4OJqb6U870446@jurassic.eng.sun.com> Date: Fri, 24 May 2002 12:55:02 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Requested changes in RFC3220 To: chowdury@nortelnetworks.com, charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: muyqGZODFzDJGkR4Zxk0VA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Sometime ago we had an email discussion on processing of RRQ at the HA and > the possible fields in the RRP. The result of the email discussion was some > "proposed text" for the updated version of RFC3220 (RFC3220bis). I have There have been discussion in mailing list regarding the dst IP-address of regReply from the Foreign agent to the mobile node. As per Charlie's request, I have run by the proposed text for section 3.7.2.3 twice in this list. I understand your proposed text is for the home-agent reply field. > tried to capture the proposed text below (paragraph 5 of section 3.8.3.2). > We also added an additional restriction in the 4th paragraph of section > 3.8.3.2 of RFC 3220. I have exchanged email with Charlie and we are in > agreement with these changes in this section. Please review and comment if > necessary. > > The changes are in the 4th and the 5th paragraph of section 3.8.3.2. > > " > 3.8.3.2. Registration Reply Fields > > ...... > > If the Home Address field of the Registration Request is nonzero, it > MUST be copied into the Home Address field of the Registration Reply > message. If the non-zero unicast address in the Home Address field > does not belong to the subnet of the Home Agent, then the Home Agent > MUST reject the registration with an error code of 130. Otherwise ... > I think this is too restricitve check and will break some implementations. In the deployment scenario, a home-agent may support mobile nodes that are never home and they are always roaming (cell phones). In most cases, they use private-addresses for which home-agent doesn't have a particular subnet, but home-agent allocates those private addresses to it's subscribed MNs, and keep track of them through it's database. So, those deployment and implementations will break if you put MUST there. Actually, I don't see a need for any change in the draft for this purpose. > > If the Home Agent field in the Registration Request contains a > unicast address of this home agent, then that field MUST be > copied into the Home Agent field of the Registration Reply. > Otherwise, the home agent MUST set the Home Agent field in the > Registration Reply to its unicast address. In this latter case, > if the destination IP address of the Registration Request is the > unicast IP address of this Home Agent, the Home Agent MAY accept > the Registration Request. If the destination IP address of the > Registration Request is not the unicast IP address of this Home > Agent, the home agent MUST reject the Registration Request with > a suitable code(e.g., Code 136) to prevent the mobile node from > possibly being simultaneously registered with two or more Home > Agents. > " This paragraph looks fine. Cheers, -Samita From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 16:09:51 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12769 for ; Fri, 24 May 2002 16:09:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11687; Fri, 24 May 2002 13:08:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19470; Fri, 24 May 2002 13:08:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OK6ArP017472 for ; Fri, 24 May 2002 13:06:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OK6Aut017471 for mobile-ip-dist; Fri, 24 May 2002 13:06:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OK68rP017464 for ; Fri, 24 May 2002 13:06:08 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21365 for ; Fri, 24 May 2002 16:06:14 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g4OK6Fqp019414 for ; Fri, 24 May 2002 16:06:15 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g4OK6FEn019413 for mobile-ip@sunroof.eng.sun.com; Fri, 24 May 2002 16:06:15 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OIk5rP017134 for ; Fri, 24 May 2002 11:46:05 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03185 for ; Fri, 24 May 2002 11:46:10 -0700 (PDT) Received: from changeofhabit.mr.itd.umich.edu (changeofhabit.mr.itd.umich.edu [141.211.144.17]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05122 for ; Fri, 24 May 2002 11:46:05 -0700 (PDT) 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 OAA08147 for ; Fri, 24 May 2002 14:46:04 -0400 (EDT) From: "Dr. Subrata Goswami" To: Subject: FW: [mobile-ip] RR and BU to HA Date: Fri, 24 May 2002 11:49:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit If the CoA is not being used, then the HA does not have a BCE for it, which implies that the MN can use the CoA if it wants without bothering any other MN. The question would be does the HA allow a CoA to be shared between multiple MN's ? I don't see a reason to prohibit the same CoA for several MNs. Anyway, as long as the MN doesn't register its current address in the home agent, it looks exacly like any IPv6 address and the same rules apply on duplicate address detection etc. Yes, but DAD happens in the local subnet. It is the spoofing that is problem - does the HA do a DAD for CoA ? Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 16:35:28 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13589 for ; Fri, 24 May 2002 16:35:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01459; Fri, 24 May 2002 14:35:30 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28794; Fri, 24 May 2002 13:35:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OKWtrP017662 for ; Fri, 24 May 2002 13:32:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OKWtkT017661 for mobile-ip-dist; Fri, 24 May 2002 13:32:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OKWqrP017654 for ; Fri, 24 May 2002 13:32:52 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27974 for ; Fri, 24 May 2002 13:32:58 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00279 for ; Fri, 24 May 2002 14:32:57 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA07459; Fri, 24 May 2002 13:32:56 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4OKWuc08981; Fri, 24 May 2002 13:32:56 -0700 X-mProtect: <200205242032> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7DUMnT; Fri, 24 May 2002 13:32:54 PDT Message-ID: <3CEEA376.FEB49067@iprg.nokia.com> Date: Fri, 24 May 2002 13:32:54 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: "Charles E. Perkins" , Francis Dupont , jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> <3CED6015.E7A39399@iprg.nokia.com> <3CEE90C2.7010903@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Vlad, Vladislav Yasevich wrote: > If the link-local address is not defended by the HA, > any other node on the link may be able to configure that > link-local address and using the DAD optimization in 2462, > can even configure global addresses. This is bad. > The solution seems to be to prohibit the DAD optimization, but > that doesn't fully help as the link-local address was allowed. > So this still doesn't look right. great, that you agree the link local address needs to be defended. > If the mobile is inactive when it returns home (and the binding was > not deleted for whatever reason) the problem is bigger. it might help if we can know why the binding still exists. the only reason I can think of is, the binding lifetime was more than the period during which the MN was inactive. this might be an extreme case (?). Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 17:13:23 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14738 for ; Fri, 24 May 2002 17:13:23 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA17480; Fri, 24 May 2002 15:13:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11329; Fri, 24 May 2002 14:13:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OLBCrP017808 for ; Fri, 24 May 2002 14:11:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4OLBBcd017807 for mobile-ip-dist; Fri, 24 May 2002 14:11:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4OLB8rP017800 for ; Fri, 24 May 2002 14:11:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02267 for ; Fri, 24 May 2002 14:11:13 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24627 for ; Fri, 24 May 2002 15:12:00 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4OLBCQ11706; Fri, 24 May 2002 16:11:13 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 24 May 2002 16:10:59 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D2403EBD6BC@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Samita Chakrabarti , charliep@iprg.nokia.com Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Requested changes in RFC3220 Date: Fri, 24 May 2002 16:10:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20367.7C429B90" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20367.7C429B90 Content-Type: text/plain; charset="iso-8859-1" Samita, Yes, the proposed text applies to registration reply from the Home Agent. Regarding your concern about this text: > If the Home Address field of the Registration Request is nonzero, it > MUST be copied into the Home Address field of the Registration Reply > message. If the non-zero unicast address in the Home Address field > does not belong to the subnet of the Home Agent, then the Home Agent > MUST reject the registration with an error code of 130. Otherwise ... I think the mobile nodes that are never home (always roaming) can be something other than cell phones, but that is not the point. The intent of the proposed change is to ensure that the mobile node has a way to determine whether it is on it's home subnet. When the mobile node requests for a nonzero unicast IP address as it's Home Address and the registration is successful then it knows that it is on it's home subnet. If the registration fails, then it should request for a dynamic Home Address perhaps with dynamic Home Agent assignment in the RRQ. However I see your point about private address support. Would you be agreeable if we change the text like this: " If the Home Address field of the Registration Request is nonzero, it MUST be copied into the Home Address field of the Registration Reply message. If the Home Agent cannot support the nonzero unicast address in the Home Address field of the Registration Request, then the Home Agent MUST reject the registration with an error code of 129. Otherwise ...... " Regards, Kuntal Kuntal/Charlie: > Sometime ago we had an email discussion on processing of RRQ at the HA and > the possible fields in the RRP. The result of the email discussion was some > "proposed text" for the updated version of RFC3220 (RFC3220bis). I have There have been discussion in mailing list regarding the dst IP-address of regReply from the Foreign agent to the mobile node. As per Charlie's request, I have run by the proposed text for section 3.7.2.3 twice in this list. I understand your proposed text is for the home-agent reply field. > tried to capture the proposed text below (paragraph 5 of section 3.8.3.2). > We also added an additional restriction in the 4th paragraph of section > 3.8.3.2 of RFC 3220. I have exchanged email with Charlie and we are in > agreement with these changes in this section. Please review and comment if > necessary. > > The changes are in the 4th and the 5th paragraph of section 3.8.3.2. > > " > 3.8.3.2. Registration Reply Fields > > ...... > > If the Home Address field of the Registration Request is nonzero, it > MUST be copied into the Home Address field of the Registration Reply > message. If the non-zero unicast address in the Home Address field > does not belong to the subnet of the Home Agent, then the Home Agent > MUST reject the registration with an error code of 130. Otherwise ... > I think this is too restricitve check and will break some implementations. In the deployment scenario, a home-agent may support mobile nodes that are never home and they are always roaming (cell phones). In most cases, they use private-addresses for which home-agent doesn't have a particular subnet, but home-agent allocates those private addresses to it's subscribed MNs, and keep track of them through it's database. So, those deployment and implementations will break if you put MUST there. Actually, I don't see a need for any change in the draft for this purpose. > > If the Home Agent field in the Registration Request contains a > unicast address of this home agent, then that field MUST be > copied into the Home Agent field of the Registration Reply. > Otherwise, the home agent MUST set the Home Agent field in the > Registration Reply to its unicast address. In this latter case, > if the destination IP address of the Registration Request is the > unicast IP address of this Home Agent, the Home Agent MAY accept > the Registration Request. If the destination IP address of the > Registration Request is not the unicast IP address of this Home > Agent, the home agent MUST reject the Registration Request with > a suitable code(e.g., Code 136) to prevent the mobile node from > possibly being simultaneously registered with two or more Home > Agents. > " This paragraph looks fine. Cheers, -Samita ------_=_NextPart_001_01C20367.7C429B90 Content-Type: text/html; charset="iso-8859-1" RE: [mobile-ip] Requested changes in RFC3220

Samita,
Yes, the proposed text applies to registration reply from the Home Agent.

Regarding your concern about this text:

>    If the Home Address field of the Registration Request is nonzero, it
>    MUST be copied into the Home Address field of the Registration Reply
>    message. If the non-zero unicast address in the Home Address field
>    does not belong to the subnet of the Home Agent, then the Home Agent
>    MUST reject the registration with an error code of 130. Otherwise ...

I think the mobile nodes that are never home (always roaming) can be something
other than cell phones, but that is not the point. The intent of the proposed
change is to ensure that the mobile node has a way to determine whether it is on
it's home subnet. When the mobile node requests for a nonzero unicast IP address
as it's Home Address and the registration is successful then it knows that it is
on it's home subnet. If the registration fails, then it should request for a
dynamic Home Address perhaps with dynamic Home Agent assignment in the
RRQ.
However I see your point about private address support. Would you be agreeable
if we change the text like this:

"    If the Home Address field of the Registration Request is nonzero, it
     MUST be copied into the Home Address field of the Registration Reply
     message. If the Home Agent cannot support the nonzero unicast address
     in the Home Address field of the Registration Request, then the Home
     Agent MUST reject the registration with an error code of 129. Otherwise
     ......
"

Regards,
Kuntal



Kuntal/Charlie:

> Sometime ago we had an email discussion on processing of RRQ at the HA and
> the possible fields in the RRP. The result of the email discussion was some
> "proposed text" for the updated version of RFC3220 (RFC3220bis). I have



There have been discussion in mailing list regarding the dst IP-address
of regReply from the Foreign agent to the mobile node.
As per Charlie's request, I have run by the proposed text for
section 3.7.2.3 twice in this list. I understand your proposed text is for
the home-agent reply field.



> tried to capture the proposed text below (paragraph 5 of section 3.8.3.2).
> We also added an additional restriction in the 4th paragraph of section
> 3.8.3.2 of RFC 3220. I have exchanged email with Charlie and we are in
> agreement with these changes in this section. Please review and comment if
> necessary.
>
> The changes are in the 4th and the 5th paragraph of section 3.8.3.2.
>
> "
> 3.8.3.2. Registration Reply Fields
>
>    ......
>
>    If the Home Address field of the Registration Request is nonzero, it
>    MUST be copied into the Home Address field of the Registration Reply
>    message. If the non-zero unicast address in the Home Address field
>    does not belong to the subnet of the Home Agent, then the Home Agent
>    MUST reject the registration with an error code of 130. Otherwise ...
> 

I think this is too restricitve check and will break some implementations.

In the deployment scenario, a home-agent may support mobile nodes that
are never home and they are always roaming (cell phones). In most cases,
they use private-addresses for which home-agent doesn't have a particular
subnet, but home-agent allocates those private addresses to it's subscribed
MNs, and keep track of them through it's database.

So, those deployment and implementations will break if you put MUST there.
Actually, I don't see a need for any change in the draft for this purpose.
 
>
>    If the Home Agent field in the Registration Request contains a
>    unicast address of this home agent, then that field MUST be
>    copied into the Home Agent field of the Registration Reply.
>    Otherwise, the home agent MUST set the Home Agent field in the
>    Registration Reply to its unicast address. In this latter case,
>    if the destination IP address of the Registration Request is the
>    unicast IP address of this Home Agent, the Home Agent MAY accept
>    the Registration Request. If the destination IP address of the
>    Registration Request is not the unicast IP address of this Home
>    Agent, the home agent MUST reject the Registration Request with
>    a suitable code(e.g., Code 136) to prevent the mobile node from
>    possibly being simultaneously registered with two or more Home
>    Agents.
> "

This paragraph looks fine.

Cheers,
-Samita


------_=_NextPart_001_01C20367.7C429B90-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 24 19:53:41 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20453 for ; Fri, 24 May 2002 19:53:41 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA10242; Fri, 24 May 2002 16:53:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA00643; Fri, 24 May 2002 16:52:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ONporP018158 for ; Fri, 24 May 2002 16:51:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4ONpnO6018157 for mobile-ip-dist; Fri, 24 May 2002 16:51:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ONpkrP018150 for ; Fri, 24 May 2002 16:51:46 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4ONpr6U919424; Fri, 24 May 2002 16:51:53 -0700 (PDT) Message-Id: <200205242351.g4ONpr6U919424@jurassic.eng.sun.com> Date: Fri, 24 May 2002 16:54:19 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: RE: [mobile-ip] Requested changes in RFC3220 To: chowdury@nortelnetworks.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: jUcOLlQgJ+e6d3JhIH0BWA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > However I see your point about private address support. Would you be > agreeable > if we change the text like this: > > " If the Home Address field of the Registration Request is nonzero, it > MUST be copied into the Home Address field of the Registration Reply > message. If the Home Agent cannot support the nonzero unicast address > in the Home Address field of the Registration Request, then the Home > Agent MUST reject the registration with an error code of 129. Otherwise > > ...... > " > This looks better to me. Thanks. -Samita > Kuntal/Charlie: > > > Sometime ago we had an email discussion on processing of RRQ at the HA and > > the possible fields in the RRP. The result of the email discussion was > some > > "proposed text" for the updated version of RFC3220 (RFC3220bis). I have > > > > There have been discussion in mailing list regarding the dst IP-address > of regReply from the Foreign agent to the mobile node. > As per Charlie's request, I have run by the proposed text for > section 3.7.2.3 twice in this list. I understand your proposed text is for > the home-agent reply field. > > > > > tried to capture the proposed text below (paragraph 5 of section 3.8.3.2). > > We also added an additional restriction in the 4th paragraph of section > > 3.8.3.2 of RFC 3220. I have exchanged email with Charlie and we are in > > agreement with these changes in this section. Please review and comment if > > necessary. > > > > The changes are in the 4th and the 5th paragraph of section 3.8.3.2. > > > > " > > 3.8.3.2. Registration Reply Fields > > > > ...... > > > > If the Home Address field of the Registration Request is nonzero, it > > MUST be copied into the Home Address field of the Registration Reply > > message. If the non-zero unicast address in the Home Address field > > does not belong to the subnet of the Home Agent, then the Home Agent > > MUST reject the registration with an error code of 130. Otherwise ... > > > > I think this is too restricitve check and will break some implementations. > > In the deployment scenario, a home-agent may support mobile nodes that > are never home and they are always roaming (cell phones). In most cases, > they use private-addresses for which home-agent doesn't have a particular > subnet, but home-agent allocates those private addresses to it's subscribed > MNs, and keep track of them through it's database. > > So, those deployment and implementations will break if you put MUST there. > Actually, I don't see a need for any change in the draft for this purpose. > > > > > If the Home Agent field in the Registration Request contains a > > unicast address of this home agent, then that field MUST be > > copied into the Home Agent field of the Registration Reply. > > Otherwise, the home agent MUST set the Home Agent field in the > > Registration Reply to its unicast address. In this latter case, > > if the destination IP address of the Registration Request is the > > unicast IP address of this Home Agent, the Home Agent MAY accept > > the Registration Request. If the destination IP address of the > > Registration Request is not the unicast IP address of this Home > > Agent, the home agent MUST reject the Registration Request with > > a suitable code(e.g., Code 136) to prevent the mobile node from > > possibly being simultaneously registered with two or more Home > > Agents. > > " > > This paragraph looks fine. > > Cheers, > -Samita > > From owner-mobile-ip@sunroof.eng.sun.com Sat May 25 05:41:59 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18721 for ; Sat, 25 May 2002 05:41:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08634; Sat, 25 May 2002 02:41:30 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07567; Sat, 25 May 2002 02:41:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4P9ePrP018810 for ; Sat, 25 May 2002 02:40:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4P9eOtY018809 for mobile-ip-dist; Sat, 25 May 2002 02:40:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4P9eLrP018802 for ; Sat, 25 May 2002 02:40:21 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07385 for ; Sat, 25 May 2002 02:40:27 -0700 (PDT) From: arvind.sevalkar@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03729 for ; Sat, 25 May 2002 02:40:26 -0700 (PDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002052515142954:4348 ; Sat, 25 May 2002 15:14:29 +0530 Subject: Re: [mobile-ip] issue #25 To: Francis Dupont Cc: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= , mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Sat, 25 May 2002 15:09:47 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/25/2002 03:10:46 PM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/25/2002 03:14:29 PM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/25/2002 03:14:33 PM, Serialize complete at 05/25/2002 03:14:33 PM Message-ID: X-Priority: 3 (Normal) Content-type: text/plain; charset=iso-2022-jp Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Francis Dupont cc: Keiichi SHIMA / $BEg7D0l(B Sent by: , owner-mobile-ip@sunroof.e mobile-ip@sunroof.eng.sun.com ng.sun.com Subject: Re: [mobile-ip] issue #25 05/24/2002 09:07 PM I think this is logical also If HA or CN has binding in binding cache then send BA with routing header otherwise don't. why to add special code for sending BA with routing header, when there is no binding in the binding cache? What is the need of it? => to provide the home address when the BU had one. So the logic (in the I-D 17 and all previous I-Ds) is to put a RH in the BA when the corresponding BU had a HAO (this moves the question to when the BU should have a HAO? :-). Francis.Dupont@enst-bretagne.fr PS: rationale: the MN sends a BU from the CO@ for H@, it receives a BA: - what is the destination address in the header (answer: CO@) - what is the destination address seen, for instance, by IPsec (answer: H@x) So if the CO@ is not the H@, the BA must have a RH, and the BU must have had a HAO. (This should be rewritten in better English and inserted into the next draft, shouldn't it?) ==>> I am satisfied with this, BU to CN or HA should have HAO and BA should have RH except when BU is for deleting the Binding cache entry. Arvind From owner-mobile-ip@sunroof.eng.sun.com Sat May 25 12:57:36 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26511 for ; Sat, 25 May 2002 12:57:35 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03288; Sat, 25 May 2002 10:58:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15891; Sat, 25 May 2002 09:57:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4PGuFrP019180 for ; Sat, 25 May 2002 09:56:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4PGuFpo019179 for mobile-ip-dist; Sat, 25 May 2002 09:56:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4PGuCrP019172 for ; Sat, 25 May 2002 09:56:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15833 for ; Sat, 25 May 2002 09:56:17 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16345 for ; Sat, 25 May 2002 09:56:16 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4PGtin12190; Sat, 25 May 2002 18:55:45 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA20705; Sat, 25 May 2002 18:55:45 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4PGtiT31689; Sat, 25 May 2002 18:55:44 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205251655.g4PGtiT31689@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Hesham Soliman (ERA)" cc: "'Jari Arkko'" , Erik Nordmark , "Alper E. YEGIN" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA In-reply-to: Your message of Fri, 24 May 2002 20:23:37 +0200. <4DA6EA82906FD511BE2F00508BCF0538044F0690@Esealnt861.al.sw.ericsson.se> Date: Sat, 25 May 2002 18:55:44 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > In conclusion, we have the following options: > > (1) Declare that we never need such tests. End of story. > (2) Declare that we always need such tests, and add this > to the protocol. > (3) Declare that you are allowed to run such tests, if your > policy requires it. You could alternatively implement this > with (a) existing mechanisms or (b) design new mechanisms. > => Can we have option 4 ? ;) 4) Leave it as is. => my concern is current specs are not clear at all about this issue. option 1) will open the door for reflection attacks which breaks the 'do no harm' policy. => so you are for >1? Regards Francis.Dupont@enst-bretagne.fr PS: I vote for 1 and if we got too many objections for 3a with no test as the default policy. From owner-mobile-ip@sunroof.eng.sun.com Sat May 25 13:09:01 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26768 for ; Sat, 25 May 2002 13:09:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19910; Sat, 25 May 2002 10:08:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17043; Sat, 25 May 2002 10:08:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4PH7drP019253 for ; Sat, 25 May 2002 10:07:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4PH7d5c019252 for mobile-ip-dist; Sat, 25 May 2002 10:07:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4PH7arP019245 for ; Sat, 25 May 2002 10:07:36 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06058 for ; Sat, 25 May 2002 10:07:41 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18276 for ; Sat, 25 May 2002 10:07:40 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA14533; Sat, 25 May 2002 10:07:40 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4PH7dT22684; Sat, 25 May 2002 10:07:39 -0700 X-mProtect: <200205251707> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdi1QlaB; Sat, 25 May 2002 10:07:36 PDT Message-ID: <3CEFC4CB.92A5D2B1@iprg.nokia.com> Date: Sat, 25 May 2002 10:07:23 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> <3CED6015.E7A39399@iprg.nokia.com> <3CEE90C2.7010903@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Vlad, I think the home agent MUST proxy for the mobile node's link address while the mobile node has a valid binding. I think the home agent should stop defending the link-local address when the binding expires. I also think the home agent should accept packets with source address == mobile's home address as long as they are addressed to the home agent. Why not? Vladislav Yasevich wrote: > If the mobile is inactive when it returns home (and the binding was > not deleted for whatever reason) the problem is bigger. > The MN will try to configure the link-local address as part of > standard IPv6 initialization (it has no idea it's home yet because it > doesn't have an interface up yet, so it hasn't seen an RA to tell it > that it's home), but will fail because the HA will defend the link-local > address. I don't think the HA should do this. > A possible workaround (a big hack :) to this is once DAD fails, the MN > can try to un-register with the HA using the following procedure: > 1. Send a RS to all-routers multicast from the :: address. > 2. Wait for the RA with the H bit set. > * for this to work the RA must contain the "Link Address" option. > this will create a stale cache entry on MN > 3. Send the unregistration using the :: address with the HOA listing > the last known home address (that the mobile usually stores). In this situation, the mobile node SHOULD know its home address. Otherwise, how could it tell if it is at home? It has to know something. And then it could send the Binding Update to the home agent directly (with lifetime zero). > As I said, this is a big hack. I don't know what the security implications > are and if IPSec can be used to verify this, so I leave that to someone who > knows more about IPSec and security. Maybe we could make a special case for when the home agent receives a Router Solitication (on link!) with the source address == the mobile node's home address. But the mobile node SHOULD NOT forget the home agent's layer-2 address (assuming it needs it for framing). The security issues are the same as the security issues for Neighbor Discovery in general. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Sat May 25 13:27:38 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26936 for ; Sat, 25 May 2002 13:27:37 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23160; Sat, 25 May 2002 10:27:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18984; Sat, 25 May 2002 10:27:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4PHQMrP019354 for ; Sat, 25 May 2002 10:26:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4PHQLPK019353 for mobile-ip-dist; Sat, 25 May 2002 10:26:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4PHQIrP019346 for ; Sat, 25 May 2002 10:26:18 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20390 for ; Sat, 25 May 2002 10:26:21 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08403 for ; Sat, 25 May 2002 11:27:09 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4PHPsn13568; Sat, 25 May 2002 19:25:58 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA20866; Sat, 25 May 2002 19:25:55 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4PHPsT31794; Sat, 25 May 2002 19:25:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205251725.g4PHPsT31794@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vladislav Yasevich cc: "Charles E. Perkins" , Vijay Devarapalli , jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Fri, 24 May 2002 15:13:06 EDT. <3CEE90C2.7010903@hp.com> Date: Sat, 25 May 2002 19:25:54 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: If the mobile is active when it returns home, it knows that it's home when it recieves the RA contining the home prefix. At this time the mobile can unregister, but it needs the link-address of the HA. It can get that if the RAs contain the link-address option. The RA will cause a creating of a STALE neighbor cache entry on the MN, that the mobile can use. => you've made three implicit assumptions: - there is a link-layer address extension in the RA (a router MAY omit it) - the RA is sent by the HA (again the one router per link... :-) - and the HA address is in a prefix information with the R bit. If one of these assumptions is false, you are in trouble. Since the entry is STALE, the unregistration packet will be sent => no because the unregistration packet is not sent to the link-local address of the HA (another assumption: the MN creates neighbor cache entries for global addresses at the reception of a RA). and the entry will be transitioned to DELAY state. On the BAck, since the binding no-longer exists, normal ND will work correctly. ... A possible workaround (a big hack :) to this is once DAD fails, the MN can try to un-register with the HA using the following procedure: => possible workarounds (without modification to neighbor discovery) were discussed some years ago: - one is to perform DAD for the HA address (look at an old I-D). It works but is not very HA friendly (:-). - one is to use a RFC 3041 IID. It works but the MN MUST perform a DAD to check its temporary IID so this solution introduces a mandatory delay (I used it as an argument for a MAY for the previous solution). 1. Send a RS to all-routers multicast from the :: address. => the MN should do that when it is attached to a new link. 2. Wait for the RA with the H bit set. => please add "from the HA"! * for this to work the RA must contain the "Link Address" option. this will create a stale cache entry on MN 3. Send the unregistration using the :: address with the HOA listing the last known home address (that the mobile usually stores). => you MUST NOT do that (unspecified source address is forbidden in this case: this constraint gave the two old working proposals). 4. Imidiately start the DAD procedure again. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun May 26 08:35:52 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22334 for ; Sun, 26 May 2002 08:35:51 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01104; Sun, 26 May 2002 06:35:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA02855; Sun, 26 May 2002 05:35:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4QCYPrP020343 for ; Sun, 26 May 2002 05:34:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4QCYPVZ020342 for mobile-ip-dist; Sun, 26 May 2002 05:34:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4QCYMrP020335 for ; Sun, 26 May 2002 05:34:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29336 for ; Sun, 26 May 2002 05:34:27 -0700 (PDT) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01486 for ; Sun, 26 May 2002 05:34:22 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g4QCXvn28711; Sun, 26 May 2002 14:33:57 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA26130; Sun, 26 May 2002 14:33:57 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g4QCXuT33566; Sun, 26 May 2002 14:33:56 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200205261233.g4QCXuT33566@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: Vladislav Yasevich , "Charles E. Perkins" , jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 In-reply-to: Your message of Fri, 24 May 2002 13:32:54 PDT. <3CEEA376.FEB49067@iprg.nokia.com> Date: Sun, 26 May 2002 14:33:56 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: great, that you agree the link local address needs to be defended. => as I said this position is an artificial conversion of DAD in DIIDD and should be discussed in the IPv6 WG for its pros and cons, not in the mobile-ip WG. Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sun May 26 23:26:25 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02295 for ; Sun, 26 May 2002 23:26:23 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA15357; Sun, 26 May 2002 21:26:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA19884; Sun, 26 May 2002 20:26:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R3OvrP021332 for ; Sun, 26 May 2002 20:24:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4R3Ova4021331 for mobile-ip-dist; Sun, 26 May 2002 20:24:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R3OrrP021324 for ; Sun, 26 May 2002 20:24:53 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA18387 for ; Sun, 26 May 2002 20:24:58 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA15012 for ; Sun, 26 May 2002 21:24:57 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id MAA26145; Mon, 27 May 2002 12:24:52 +0900 (JST) Received: from localhost (keiichi01.osaka.iij.ad.jp [192.168.65.66]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA05780; Mon, 27 May 2002 12:24:51 +0900 (JST) Date: Mon, 27 May 2002 12:24:28 +0900 (JST) Message-Id: <20020527.122428.72231218.keiichi@iij.ad.jp> To: Francis.Dupont@enst-bretagne.fr Cc: arvind.sevalkar@lntinfotech.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issue #25 From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <200205241537.g4OFboT26345@givry.rennes.enst-bretagne.fr> References: <200205241537.g4OFboT26345@givry.rennes.enst-bretagne.fr> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: From: Francis Dupont Content-Transfer-Encoding: 7bit > > I think this is logical also If HA or CN has binding in binding cache then > send BA with routing header otherwise don't. > why to add special code for sending BA with routing header, when there is > no binding in the binding cache? What is the need of it? > > => to provide the home address when the BU had one. > So the logic (in the I-D 17 and all previous I-Ds) is to put a RH in the BA > when the corresponding BU had a HAO (this moves the question to when > the BU should have a HAO? :-). I have missed one point... A rthdr must be added at least for the home registration. Otherwise, the HA can't send a BA back to the MN. So I agree with you Francis, we must add a rthdr to BAs. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Mon May 27 01:01:35 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03605 for ; Mon, 27 May 2002 01:01:35 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA07435; Sun, 26 May 2002 22:01:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA04586; Sun, 26 May 2002 22:00:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R504rP021448 for ; Sun, 26 May 2002 22:00:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4R504hN021447 for mobile-ip-dist; Sun, 26 May 2002 22:00:04 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R501rP021440 for ; Sun, 26 May 2002 22:00:01 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA04434 for ; Sun, 26 May 2002 22:00:05 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA08459 for ; Sun, 26 May 2002 23:00:04 -0600 (MDT) Message-ID: <00d601c2053b$1ebfc990$236015ac@T23KEMPF> From: "James Kempf" To: "John Williams Floroiu" Cc: , "Alper E. YEGIN" , "Charles E. Perkins" References: <000601c20281$3116cdd0$6501a8c0@dell8100rjm> <3CED2BCC.859AB84C@iprg.nokia.com> <3CED3026.6A29A8D7@fokus.gmd.de> <008301c20293$43795b70$796015ac@T23KEMPF> <3CEDFA7E.D3DD4166@fokus.gmd.de> Subject: Re: [mobile-ip] are L2 triggers "secure" ? Date: Sun, 26 May 2002 21:58:13 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > True, but the difference however is that F-BU and F-BACK are "layer 3 secured". The anticipated handover method sets up > the tunnel after exchanging F-BU and F-BACK --- which can be trusted by layer 3 --- with MN. > Are they? I don't believe there was anything in draft-ietf-mobileip-fast-ipv6-XX.txt the last time I looked that mentioned how they would be secured. There was some discussion on the list a while back in the middle of the IPv6 security debate about how to secure F-BU and F-BACK. Should return routability be used as with forwarding from previous care of address? Or something else? Additionally, the PrxyRtSol and PrxyRtAdv contain Layer 2 addresses for the next access point or router. If the network can spoof these, then it is possible to cause a handover to something that is not a legitimate router. In 802.11, it is relatively easy to spoof the link layer. The MAC address can be spoofed, as I mentioned previously, or, even easier, someone could set up a bogus access point. > With tunnel-based handover, the handover is initiated by L2 triggers, and the problem I see is whether layer 3 could > trust layer 2 security (and for some technologies it obviously cannot). HI, HACK and HTT are "layer 3 secured" but they > are exchanged between the ARs, which is not relevant in this context because they make no guarantee about the MN's > legitimacy. > The handover is initiated with L2 triggers in anticpated handover as well. Something needs to give the mobile node an identifier for the next access router. Unless the mobile node can talk to two access points at once, so it can perform router solicitation on the new one while the old one is still delivering traffic, the information on the new access point must come from layer 2. > L2 triggers are obviously a very efficient method to initiate handovers, but imho they need to always be accompanied by > secure layer 3 exchange which necessarily involve the MN. If this would be the case, then tunnel-based handover would > resemble very much the anticipated handover from the perspective of the control message exchange. > If the layer 2 is secure, there is no need to involve the MN at the time the wireless signal is fading around handover (it may be involved before or after). As I've stated numerous times on this list, traffic with the MN around a handover is subject to the unavoidable probability that it will be cut off prior to completing, resulting in the need for the MN to recover with standard MIP on the new access point, making the expected performance of anticipated handover less reliable relative to tunnel-based handover. For those wireless link layers that provide the right kind of security, like the cellular protocols, there is no reason to penalize them by requiring anticipated handover. And security on the local link is exactly what layer 2 security should be all about. jak From owner-mobile-ip@sunroof.eng.sun.com Mon May 27 04:17:02 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13870 for ; Mon, 27 May 2002 04:17:02 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11409; Mon, 27 May 2002 02:17:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA12668; Mon, 27 May 2002 01:16:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R8GArP021725 for ; Mon, 27 May 2002 01:16:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4R8GAUF021724 for mobile-ip-dist; Mon, 27 May 2002 01:16:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R8G5rP021717 for ; Mon, 27 May 2002 01:16:06 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4R8G4g14390; Mon, 27 May 2002 10:16:04 +0200 (MEST) Date: Mon, 27 May 2002 10:15:05 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Issue #23 and Issue #30 To: Francis Dupont Cc: Erik Nordmark , Vijay Devarapalli , jari.arkko@piuha.net, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200205241600.g4OG0RT26451@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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > => but can you argue that for a mobile node which is not attached to > the home link? RFC 2373 (last draft has the same text) says: > - IIDs in unicasts are used to identify interfaces on a link. > - They are required to be unique on that link. > Is it equivalent to "IIDs in unicast are used to identify in an unique > way interfaces on a link"? A logical conclusion of the statement that an interface ID identifies interfaces *and* that they are unique on a link, means that an interface ID can only be used by one interface at a time. But an alternative way to look at this is that the use of "proxy ND" doesn't really *assign* the interface ID to the proxying node - instead it remains assigned to the mobile node's interface. If you follow that path then it seems like a node could proxy for some addresses but not other addresses using the same interface ID. However, due to the MAY for DAD in certain cases in RFC 2462 it seems inconsistent when the HA doesn't respond to DAD queries for the link-local address while it responds to DAD queries for other address(es) derived from the same interface ID. > PS: IMHO a DIIDD should have been better than current DAD (more > architecturally correct for instance :-) but it is far too late > to fix that. Agreed. I think the thing to do is to clarify RFC 2373 and RFC 2462 to make it clear that it isn't DIIDD. Erik From owner-mobile-ip@sunroof.eng.sun.com Mon May 27 04:50:02 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14315 for ; Mon, 27 May 2002 04:50:01 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19425; Mon, 27 May 2002 01:49:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19456; Mon, 27 May 2002 01:49:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R8m2rP021813 for ; Mon, 27 May 2002 01:48:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4R8m2eB021812 for mobile-ip-dist; Mon, 27 May 2002 01:48:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R8lxrP021805 for ; Mon, 27 May 2002 01:47:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA01337 for ; Mon, 27 May 2002 01:48:03 -0700 (PDT) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18252 for ; Mon, 27 May 2002 01:48:02 -0700 (PDT) Received: from fokus.gmd.de (ekina [193.175.135.180]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with ESMTP id g4R8lvt26210; Mon, 27 May 2002 10:47:58 +0200 (MEST) Message-ID: <3CF1F2BD.A5B7CB9B@fokus.gmd.de> Date: Mon, 27 May 2002 10:47:57 +0200 From: John Williams Floroiu Organization: GMD FOKUS - CC MOBIS X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.4.17 i686) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] are L2 triggers "secure" ? References: <000601c20281$3116cdd0$6501a8c0@dell8100rjm> <3CED2BCC.859AB84C@iprg.nokia.com> <3CED3026.6A29A8D7@fokus.gmd.de> <008301c20293$43795b70$796015ac@T23KEMPF> <3CEDFA7E.D3DD4166@fokus.gmd.de> <00d601c2053b$1ebfc990$236015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James, > > True, but the difference however is that F-BU and F-BACK are "layer 3 > secured". [...] > Are they? I don't believe there was anything in > draft-ietf-mobileip-fast-ipv6-XX.txt the last time I looked that > mentioned how they would be secured. Well, okay it is not mentioned HOW, but I remember I saw a statement saying that they should be. > Additionally, the PrxyRtSol and PrxyRtAdv contain Layer 2 addresses for > the next access point or router. If the network can spoof these, then it > is possible to cause a handover to something that is not a legitimate > router. In 802.11, it is relatively easy to spoof the link layer. The > MAC address can be spoofed, as I mentioned previously, or, even easier, > someone could set up a bogus access point. > >> [...] > > The handover is initiated with L2 triggers in anticpated handover as > well. Something needs to give the mobile node an identifier for the next > access router. Unless the mobile node can talk to two access points at > once, so it can perform router solicitation on the new one while the old > one is still delivering traffic, the information on the new access point > must come from layer 2. I agree, PrRtAdv and RtSolPr contain layer 2 information or originate themselves from layer 2 triggers. However if PrRtAdv and RtSolPr (as well as HI-HACK) were authenticated at layer 3, it wouldn't be possible to force a MN perform a bogus handover. In 802.11, a MN may be fooled by bogus beacons to attempt a number of handovers to nowhere or to attackers themselves, but these handovers won't succeed since the targets won't be able to authenticate the layer 3 control message exchange. This raises however another interesting question: how would a 802.11 adapter perform under a flood of bogus beacons ? Even if encryption is used, an attacker can still achieve quite easily a computational DoS. > >> [...] > > If the layer 2 is secure, there is no need to involve the MN at the time > the wireless signal is fading around handover (it may be involved before > or after). As I've stated numerous times on this list, traffic with the > MN around a handover is subject to the unavoidable probability that it > will be cut off prior to completing, resulting in the need for the MN to > recover with standard MIP on the new access point, making the expected > performance of anticipated handover less reliable relative to > tunnel-based handover. For those wireless link layers that provide the > right kind of security, like the cellular protocols, there is no reason > to penalize them by requiring anticipated handover. And security on the > local link is exactly what layer 2 security should be all about. Okay, but for cellular protocols in particular we don't have to bother too much about Mobile IP fast handover, have we ? Regards, John. From owner-mobile-ip@sunroof.eng.sun.com Mon May 27 04:59:51 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14701 for ; Mon, 27 May 2002 04:59:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10189; Mon, 27 May 2002 02:58:58 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA21104; Mon, 27 May 2002 01:58:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R8vtrP021890 for ; Mon, 27 May 2002 01:57:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4R8vtVW021889 for mobile-ip-dist; Mon, 27 May 2002 01:57:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4R8vorP021882 for ; Mon, 27 May 2002 01:57:51 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g4R8vmg18468; Mon, 27 May 2002 10:57:48 +0200 (MEST) Date: Mon, 27 May 2002 10:56:47 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Issue #23 and Issue #30 To: Vladislav Yasevich Cc: "Charles E. Perkins" , Francis Dupont , Vijay Devarapalli , jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3CEE90C2.7010903@hp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > If the mobile is active when it returns home, it knows that it's > home when it recieves the RA contining the home prefix. At this > time the mobile can unregister, but it needs the link-address of > the HA. It can get that if the RAs contain the link-address option. > The RA will cause a creating of a STALE neighbor cache entry on > the MN, that the mobile can use. Since the entry is STALE, the > unregistration packet will be sent and the entry will be transitioned > to DELAY state. On the BAck, since the binding no-longer exists, normal > ND will work correctly. I haven't though about all the implementation details, but if there was a way for the ND packets to bypass the binding cache lookup, it seems like this complexity of needing the HAs link-layer address can be avoided. The ND packets shouldn't go outside of a link (whether that link is a "wire" or a tunnel), thus applying MIPv6 checks that might add a routing header or a home address option sounds odd. This might be as simple as the ND code passing SO_DONTROUTE to ipv6_output causing a bypass of the BCEs. Of course, this doesn't make the "returning home" problem completely go away. But it allows the MN at home to send a NS and get an NA back from the HA I think. (Unless the HA is confused by itself proxying for the HoA?) Erik From owner-mobile-ip@sunroof.eng.sun.com Mon May 27 10:28:43 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19502 for ; Mon, 27 May 2002 10:28:42 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA07922; Mon, 27 May 2002 08:28:20 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12438; Mon, 27 May 2002 07:28:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4REQcrP022400 for ; Mon, 27 May 2002 07:26:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4REQbCs022399 for mobile-ip-dist; Mon, 27 May 2002 07:26:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4REQYrP022392 for ; Mon, 27 May 2002 07:26:34 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA12360 for ; Mon, 27 May 2002 07:26:37 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21989 for ; Mon, 27 May 2002 08:27:29 -0600 (MDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4REQUmG010803 for ; Mon, 27 May 2002 16:26:35 +0200 (MEST) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon May 27 16:26:21 2002 +0200 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id <2JB4497Z>; Mon, 27 May 2002 16:26:21 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F069C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , John Williams Floroiu Cc: mobile-ip@sunroof.eng.sun.com, "Alper E. YEGIN" , "Charles E. Perkins" Subject: RE: [mobile-ip] are L2 triggers "secure" ? Date: Mon, 27 May 2002 16:26:10 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > True, but the difference however is that F-BU and F-BACK > are "layer 3 > secured". The anticipated handover method sets up > > the tunnel after exchanging F-BU and F-BACK --- which can > be trusted > by layer 3 --- with MN. > > > > Are they? I don't believe there was anything in > draft-ietf-mobileip-fast-ipv6-XX.txt the last time I looked that > mentioned how they would be secured. => Clearly the draft needs to state the security requirements for F-BU. But of course they will be secured, otherwise FMIPv6 will not become an RFC. I don't think anyone disagrees with that. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon May 27 10:35:15 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19661 for ; Mon, 27 May 2002 10:35:15 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06602; Mon, 27 May 2002 07:34:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13329; Mon, 27 May 2002 07:34:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4REXqrP022462 for ; Mon, 27 May 2002 07:33:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4REXqc3022461 for mobile-ip-dist; Mon, 27 May 2002 07:33:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4REXmrP022454 for ; Mon, 27 May 2002 07:33:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22791 for ; Mon, 27 May 2002 07:33:52 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23460 for ; Mon, 27 May 2002 07:33:51 -0700 (PDT) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g4REXj6n024994 for ; Mon, 27 May 2002 16:33:50 +0200 (MEST) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon May 27 16:33:26 2002 +0200 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 27 May 2002 16:22:20 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F069D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , "Hesham Soliman (ERA)" Cc: "'Jari Arkko'" , Erik Nordmark , "Alper E. YEGIN" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RR and BU to HA Date: Mon, 27 May 2002 16:33:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > > In conclusion, we have the following options: > > > > (1) Declare that we never need such tests. End of story. > > (2) Declare that we always need such tests, and add this > > to the protocol. > > (3) Declare that you are allowed to run such tests, if your > > policy requires it. You could alternatively > implement this > > with (a) existing mechanisms or (b) design new > mechanisms. > > > > => Can we have option 4 ? ;) > 4) Leave it as is. > > => my concern is current specs are not clear at all about > this issue. => I'm reviewing the spec right now and I agree with you. I think something that reflects the contents of Erik's email and parts of Jari's (above) email should be included in the spec to explain the motivation. > option 1) will open the door for reflection attacks > which breaks the 'do no harm' policy. > > => so you are for >1? => Actually, in a later email, I explained that I misunderstood Jari's email to mean (1)remove COT for CNs, so of course I hastily replied with a 'no'. But since it was only related to the HA, then I think (1) is fine. Also 3a is ok but more complex of course. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon May 27 23:41:13 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29294 for ; Mon, 27 May 2002 23:41:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07109; Mon, 27 May 2002 20:40:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA19141; Mon, 27 May 2002 20:40:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4S3d9rP023226 for ; Mon, 27 May 2002 20:39:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4S3d9K3023225 for mobile-ip-dist; Mon, 27 May 2002 20:39:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4S3curP023192 for ; Mon, 27 May 2002 20:38:56 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA21155 for ; Mon, 27 May 2002 20:39:01 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA06677 for ; Mon, 27 May 2002 20:39:01 -0700 (PDT) Message-ID: <011201c205f8$f706c700$516015ac@T23KEMPF> From: "James Kempf" To: "John Williams Floroiu" Cc: References: <000601c20281$3116cdd0$6501a8c0@dell8100rjm> <3CED2BCC.859AB84C@iprg.nokia.com> <3CED3026.6A29A8D7@fokus.gmd.de> <008301c20293$43795b70$796015ac@T23KEMPF> <3CEDFA7E.D3DD4166@fokus.gmd.de> <00d601c2053b$1ebfc990$236015ac@T23KEMPF> <3CF1F2BD.A5B7CB9B@fokus.gmd.de> Subject: Re: [mobile-ip] are L2 triggers "secure" ? Date: Mon, 27 May 2002 20:37:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I agree, PrRtAdv and RtSolPr contain layer 2 information or originate themselves from layer 2 triggers. However if > PrRtAdv and RtSolPr (as well as HI-HACK) were authenticated at layer 3, it wouldn't be possible to force a MN perform a > bogus handover. > OK, I think I understand your point. In the anticipated case, failure of the HI/HACK is reported via the PrRtAdv (presuming it is delayed until the HACK returns, the draft specifies that it may be sent prior to the return if stateless addrconfig is used instead of stateful, this probably ought to change). The mobile then aborts the handover, presuming the layer 2 protocol allows it. > In 802.11, a MN may be fooled by bogus beacons to attempt a number of handovers to nowhere or to attackers themselves, > but these handovers won't succeed since the targets won't be able to authenticate the layer 3 control message exchange. > This raises however another interesting question: how would a 802.11 adapter perform under a flood of bogus beacons ? > Even if encryption is used, an attacker can still achieve quite easily a computational DoS. > Good question. I believe the protocol requires the mobile host to maintain a list of BSSids. A flood of bogus beacons might be used to perform a state attack, in which the host's BSSid state list is essentially filled. I don't know the protocol well enough to say whether it contains anything to prevent this from happening. > Okay, but for cellular protocols in particular we don't have to bother too much about Mobile IP fast handover, have we ? > We do if you are concerned, as I am, about removing the deep radio access networks in the current generation of cellular protocols. There are several new radio protocols that would lend themselves to putting Mobile IP directly on top of the radio in cellular systems, and Motorola has done it for low latency MIPv4 on a representative of the current generation, with an experimental implementation on the IS-2000 (3GPP2) cellular protocol. The fast handover designs are supposed to work for existing protocols and new ones. jak From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 00:41:50 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29904 for ; Tue, 28 May 2002 00:41:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20139; Mon, 27 May 2002 22:40:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA16817; Mon, 27 May 2002 21:34:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4S4XurP023444 for ; Mon, 27 May 2002 21:33:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4S4Xui8023443 for mobile-ip-dist; Mon, 27 May 2002 21:33:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4S4XrrP023436 for ; Mon, 27 May 2002 21:33:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA16768 for ; Mon, 27 May 2002 21:33:57 -0700 (PDT) Received: from hotmail.com (oe70.law4.hotmail.com [216.33.148.166]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA20885 for ; Mon, 27 May 2002 22:33:56 -0600 (MDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 27 May 2002 21:33:56 -0700 X-Originating-IP: [138.15.109.61] Reply-To: "Eunsoo Shim" From: "Eunsoo Shim" To: "James Kempf" , "John Williams Floroiu" Cc: References: <000601c20281$3116cdd0$6501a8c0@dell8100rjm> <3CED2BCC.859AB84C@iprg.nokia.com> <3CED3026.6A29A8D7@fokus.gmd.de> <008301c20293$43795b70$796015ac@T23KEMPF> <3CEDFA7E.D3DD4166@fokus.gmd.de> <00d601c2053b$1ebfc990$236015ac@T23KEMPF> <3CF1F2BD.A5B7CB9B@fokus.gmd.de> <011201c205f8$f706c700$516015ac@T23KEMPF> Subject: Re: [mobile-ip] are L2 triggers "secure" ? Date: Tue, 28 May 2002 00:34:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 28 May 2002 04:33:56.0242 (UTC) FILETIME=[E0E13F20:01C20600] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, Using the CAR discovery protocol, the mobile host can check the IP address (or identifier) of the access router associated to the base station or any device sending the bogus beacons. Furthermore the CAR discovery will be able to tell the mobile host whether the access router, if any, is authenticated and authorized to participate in the CAR discovery process, which is a good guidance about whether to take the BSSid seriously or ignore it. If the CAR discovery protocol cannot find the associated access router for the BSSid, the mobile host may take a cautious step in keeping trying to hand over following the beacon. The CAR discovery protocol is a complimentary protocol for the low-latency handoff protocol and may provide a reasonable solution for the security concern pointed in the discussion below. Thanks. Eunsoo ----- Original Message ----- From: "James Kempf" To: "John Williams Floroiu" Cc: Sent: Monday, May 27, 2002 11:37 PM Subject: Re: [mobile-ip] are L2 triggers "secure" ? > > > In 802.11, a MN may be fooled by bogus beacons to attempt a number of > handovers to nowhere or to attackers themselves, > > but these handovers won't succeed since the targets won't be able to > authenticate the layer 3 control message exchange. > > This raises however another interesting question: how would a 802.11 > adapter perform under a flood of bogus beacons ? > > Even if encryption is used, an attacker can still achieve quite easily > a computational DoS. > > > > Good question. I believe the protocol requires the mobile host to > maintain a list of BSSids. A flood of bogus beacons might be used to > perform a state attack, in which the host's BSSid state list is > essentially filled. I don't know the protocol well enough to say > whether it contains anything to prevent this from happening. > From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 12:10:16 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23396 for ; Tue, 28 May 2002 12:10:16 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13180; Tue, 28 May 2002 10:11:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13751; Tue, 28 May 2002 09:09:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SG8rrP024068 for ; Tue, 28 May 2002 09:08:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SG8rqO024067 for mobile-ip-dist; Tue, 28 May 2002 09:08:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SG8orP024060 for ; Tue, 28 May 2002 09:08:50 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13482 for ; Tue, 28 May 2002 09:08:54 -0700 (PDT) From: Gaurav.Puri@lntinfotech.com Received: from ltitlout.lntinfotech.com ([203.199.54.8]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12165 for ; Tue, 28 May 2002 10:09:47 -0600 (MDT) Received: from Bangalore.lntinfotech.com ([172.29.4.3]) by ltitlout.lntinfotech.com (Lotus Domino Release 5.0.8) with ESMTP id 2002052821545008:7835 ; Tue, 28 May 2002 21:54:50 +0530 Subject: [mobile-ip] Issue #23 and Issue #30 ( "S" bit funda) To: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 28 May 2002 21:35:59 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/28/2002 09:36:00 PM, Itemize by SMTP Server on LTITLOUT/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/28/2002 09:54:50 PM, Serialize by Router on LTITLOUT/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/28/2002 09:54:53 PM, Serialize complete at 05/28/2002 09:54:53 PM Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: hello, From the draft it is clear that DAD is done on the link local address of MN. If "S" bit is not set(i.e S bit 0), do we need to perform DAD on all possible MN's addresses( formed using all on link prefixes) or doing proxy for all those addresses is sufficient ? IMHO, If DAD is successful for link local address, that implies that it will be successful for all possible MN's addresses as last 64 bits will be same in all the addresses. please clarify cheers gaurav From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 12:19:38 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23743 for ; Tue, 28 May 2002 12:19:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00346; Tue, 28 May 2002 10:19:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17660; Tue, 28 May 2002 09:19:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SGIerP024133 for ; Tue, 28 May 2002 09:18:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SGIetH024132 for mobile-ip-dist; Tue, 28 May 2002 09:18:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SGIbrP024125 for ; Tue, 28 May 2002 09:18:37 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23912 for ; Tue, 28 May 2002 09:18:41 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16210 for ; Tue, 28 May 2002 10:18:40 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4SGIdmG018904 for ; Tue, 28 May 2002 18:18:39 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 18:18:39 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F06A4@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] comments on MIPv6 draft-17 Date: Tue, 28 May 2002 18:18:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi, I've read the draft and have the following comments/questions. 1. General comments: - In general I think the draft has redundant text and in some cases, significant overlaps between sections. It's good to have some overlap, but in many cases it is too repetetive. I'll try to mention specific examples in my editorial comments. But this could be something to consider before the final draft is done. The draft is very large so it is good to remove as much as possible while maintaining a good level of clarity. 2. Specific technical comments - I wonder if it's worth referencing some way of creating the nonce, or making a recommendation on how to do it. Mike Thomas' last draft had a reference. It might be good to do that, since it (the nonce) is a pretty significant part of RR. - I don't understand why MAX_RR_BINDING_LIFE is fixed to 300 seconds. I would appreciate a reference or a reason. The attack that Pekka sent a few months ago should not require the 5 min limit. It simply requires that the BCE cannot be refreshed without performing RR. In fact there is probably more hazard in allowing the updates within the 5 min than if we extend (or remove) the upper time limit. - Busy CNs will struggle with maintaining the Nonce and Kbu lifetimes for several (hundreds or thousands?) of MNs. Do you think this is a valid concern? If so we need to add some recommendation on how to do this. I haven't read the state machines in the appendix yet, so my answer might be there. - I might have missed this in an earlier discussion, but why us the checksum needed for the MH? It should always be authenticated. - Section 6.1.3: Why is the HA tunnelling the HOT a SHOULD? It seems that this is one of the assumptions that the protocol is based on (see the security design section). Shouldn't this be a MUST? Not making this a MUST will allow attacker on the MNs link to do some nasty stuff. - It seems like there was a concious decision to separate the 'reserved' fields in all messages (e.g. section 6.1.5 (HoT) and 6.1.6), why is that? - Why are certain values skipped for the BA status codes? e.g. between 133 and 137. I suggest we place them in order. It looks like some magic is attached to those missing numbers :) - I think that setting the A flag has to be a MUST or at the very minimum a SHOULD. It is very clear to me that the protocol is much weaker and non-deterministic without mandating the Ack. I would suggest that we mandate it. There are several examples in the draft the provide a good reason for mandating the BA. - I don't really get this unique identifier option, but more on that later. - Either we explain how the Mobile Prefix sol and adv can be done securely (using PKI and dynamic SA establishment), or remove them from the draft. I don't think we should keep them and say that they must be authenticated 'if possible'. what does that mean? Either they must be authenticated or not. I think that they must be. - Section 8.1,what is the point of mandating the HAO when the spec says that it must not be received without a BCE, and the entire RO is a 'should'.? The HAO should follow the same recommendation as RO. - In section 8.1: I think we should add a line that if RR is supported, the CN MUST be able to return a BA in response to a BU. - Section 9.1: Remove all the references to mobile routers. E.g. the fifth bullet. Also remove the sixth bullet, the prefix length does not exist anymore. - Section 9.2.2: First sentence, 'MAY' is unnecessay. If the MN has a BCE, it's pretty strange that it doesn't use RO and decide to not include the HAO. - Section 9.4.1: Shouldn't the order of the last 2 bullets be reversed.(Half editorial). - Section 9.4.1: Perhaps we should add some text to specify that 'normally' the CoA nonce index and Home Nonce index are the same, and that sending both is a precaution for changing the nonce while RR is in progress. Or am I missing something? - Section 9.6, first paragraph. I thin we should replace the first SHOULD with MUST. There is no point in having a binding cache if it doesn't get chacked. - Section 9.7: Remove the third paragraph, it no longer applies. - Section 9.7: Fourth paragraph: Do we need to say how persistent is 'persistent'? or Specify a default rate? - Section 10.1: Last sentence in the second paragraph, says ' it SHOULD NOT be deleted by the HA ...' In section 9.5, the same action was a 'MUST NOT'. Either MUST NOT, or SHOULD NOT (accompanied with 'MUST inform the MN') are ok with me. - Section 10.1: Remove '(or has recently)' from the fourth paragraph. - Section 10.1: it would be good to show the order of HAs in the HA list (last bullet in 10.1 doesn't say in what order). - Section 10.1: In response to the question in the draft, I'd say that as long as the HA discovery is in the draft, we have to keep the preference. I think HA discovery is a nice idea. - Fifth bullet in 10.2: Shouldn't DAD be done for all addresses? RFC 3041 might be a problem here if we only do DAD on link-local addresses. - Page 93: Bullet starting with 'However, if the 'S' bit .....'. This strikes me as a problem when renumbering the Home network is going on. If the HA always chooses the smallest lifetime, doesn't that mean it will always be choosing the lifetime of the prefix being deprecated? Some clarification would be good. - Section 10.4: I don't think ND says anything about 'gratuitous' NAs. We should replace that with Proxy NA or some other terminology used in IPv6. - Somewhere in section 10 it should be mentioned that if the S bit is cleared (request the HA to act on behalf of all the MNs HoAs) then the HA should create an SA in the SAD for each one of those home addresses. - Page 96: In the four bullets there, I have the following comments: - Second bullet, the llA should be there IF the link layer has link layer addresses. - A pedantic question: What happens if ND is secured with pre-configured SAs. Shouldn't the HA be configured to act on behalf of MNs and send secure ND messages? - Remove the last paragraph before 10.5 (the part about the R bit). - Section 10.5: Second paragraph, remove all reference to prefix length. - General comment on multicast: I lost the emails that Dave Thaler sent on the topic and haven't had time to look them up. But I thought I'd remind the authors to look them up and see if they are applicable. - Section 10.7: Second paragrpah, Again, why is ESP optional here ? What is the default behaviour? - Section 10.9.3: 'If a security association ....' -- No ifs pleasejust make sure it's secure (MUST). This goes for the entire section. - Page 108: Remove any reference to previous-CoA. - Section 11.1: Te bullet starting with, 'A flag when set, indicates that future Binding Updates .....' What does this mean?? The MN will keep an entry in the BUL anyway for a CN that doesn't accept BUs? - Page 113: Last bullet, 'other implementation stragies maybe more appropriate' Like what? I don't think we need to state this do we? I would suggest removing this approach and making the standard more concretein what it says. - Page 115: 'The segments left in the RH is either 0 or 1'. Zero? why is Zero ok? - Chapter 11.2.4 assumes that the MN can send BUs to a 'router' in the local domain. I'm not sure we can keep this in the spec without specifying how to secure this BU. - Section 11.3.3/4: Same comment on securing the messages. - Add somewhere in Section 11 that the MN MUST NOT let BCEs in CNs or HA timeout after the MN has moved. I.e. It MUST deregister. - Remove section 11.6.6. 3. Editorial comments This is not an exhaustive list, but I assume the draft will be revised and grammar ...etc will be checked again. - secion 5.5: Second sentence 'without creating major new ..' Should be changed to '..new major...' or reworded. - Same section: All the references to, e.g., [1] ...are they going to be RFCs ? Otherwise they can't be referenced. - Section 5.5.1: Second sentence: '...to accept only...' reword. - Section 5.5.9: Second sentence, remove 'only' - Section 6.1.1: Last paragraph Add 'the' after 'Mobility Header are' in the first sentence. - Why are sections 6.2.2 and 6.2.3 needed? can't we refer to 2460? The less text the better for this spec. - In 6.2.4 and 6.2.5 and other sections, please write either 'Type', 'Length' ...etc in the option format or 'Type = X', 'Length = Y', but not just the numbers. - Page 56: Repeated text: 'A packet MUST NOT contain.... associated with each encapsulating IP header' - Section 6.4: Second paragraph: 'This uses...' Replace 'This' with 'The Routing Header' or 'The new RH' .... - Section 9.4.2: Last sentence in the second last paragraph, add 'of' before 'its lifetime'. - Section 9.6: Third paragraph, first sentence, add 'in' before '6.4'. That's all I have for now. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 12:21:41 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23799 for ; Tue, 28 May 2002 12:21:41 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01949; Tue, 28 May 2002 10:21:51 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18568; Tue, 28 May 2002 09:21:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SGKqrP024165 for ; Tue, 28 May 2002 09:20:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SGKqnR024164 for mobile-ip-dist; Tue, 28 May 2002 09:20:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SGKmrP024154 for ; Tue, 28 May 2002 09:20:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18249 for ; Tue, 28 May 2002 09:20:52 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01292 for ; Tue, 28 May 2002 10:20:51 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id D783C33F7; Tue, 28 May 2002 11:20:50 -0500 (CDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 359E8E38; Tue, 28 May 2002 11:20:50 -0500 (CDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id MAA0000813433; Tue, 28 May 2002 12:12:46 -0400 (EDT) Message-ID: <3CF3AC7D.2FC34D79@hp.com> Date: Tue, 28 May 2002 12:12:46 -0400 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.79 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: Charlie Perkins Cc: Vladislav Yasevich , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> <3CED6015.E7A39399@iprg.nokia.com> <3CEE90C2.7010903@hp.com> <3CEFC4CB.92A5D2B1@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie Perkins wrote: > Hello Vlad, > > I think the home agent MUST proxy for the mobile node's > link address while the mobile node has a valid binding. > I think the home agent should stop defending the link-local > address when the binding expires. I also think the home agent > should accept packets with source address == mobile's > home address as long as they are addressed to the home agent. > Why not? In this case the MN can't use it's home address because it can't configure it since DAD failed (i.e. it just booted and doesn't know where it is). > > If the mobile is inactive when it returns home (and the binding was > > not deleted for whatever reason) the problem is bigger. > > The MN will try to configure the link-local address as part of > > standard IPv6 initialization (it has no idea it's home yet because it > > doesn't have an interface up yet, so it hasn't seen an RA to tell it > > that it's home), but will fail because the HA will defend the link-local > > address. > > I don't think the HA should do this. Can you please explain what you meant by this? Above you said the HA MUST proxy for the MN's home address, doesn't that assume defend as well? > > A possible workaround (a big hack :) to this is once DAD fails, the MN > > can try to un-register with the HA using the following procedure: > > 1. Send a RS to all-routers multicast from the :: address. > > 2. Wait for the RA with the H bit set. > > * for this to work the RA must contain the "Link Address" option. > > this will create a stale cache entry on MN > > 3. Send the unregistration using the :: address with the HOA listing > > the last known home address (that the mobile usually stores). > > In this situation, the mobile node SHOULD know its home address. > Otherwise, how could it tell if it is at home? It has to know something. > And then it could send the Binding Update to the home agent > directly (with lifetime zero). The MN doesn't know it's home until it hears an RA, but in order to hear it it's got to configure it's link-local address first. It would have to be in promisc mode otherwise. > But the mobile node SHOULD NOT forget the home agent's > layer-2 address (assuming it needs it for framing). But the MN might not have the HA's L2 address if it's doing DHAAD, I don't believe the spec says it should keep the HA address in NV storage? -Brian From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 13:22:26 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25665 for ; Tue, 28 May 2002 13:22:24 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28174; Tue, 28 May 2002 10:21:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12267; Tue, 28 May 2002 10:21:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SHKfrP024452 for ; Tue, 28 May 2002 10:20:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SHKfLa024451 for mobile-ip-dist; Tue, 28 May 2002 10:20:41 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SHKcrP024444 for ; Tue, 28 May 2002 10:20:38 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17580 for ; Tue, 28 May 2002 10:20:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27509 for ; Tue, 28 May 2002 10:20:39 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA09054; Tue, 28 May 2002 10:20:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4SHKRc29580; Tue, 28 May 2002 10:20:27 -0700 X-mProtect: <200205281720> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdZ8uTkD; Tue, 28 May 2002 10:07:16 PDT Message-ID: <3CF3B943.E9556B4A@iprg.nokia.com> Date: Tue, 28 May 2002 10:07:15 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: arvind.sevalkar@lntinfotech.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issue #25 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi Arvind, arvind.sevalkar@lntinfotech.com wrote: > ==>> > I am satisfied with this, BU to CN or HA should have HAO and BA should have > RH except when BU is for deleting the Binding cache entry. a small addition to this. the BA should have a routing header when the BU for deleting the Binding Cache entry is sent from a visited link. otherwise the BA would not reach the MN. the routing header is not present only when the MN returns home and sends a deregistration BU. Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 13:42:28 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26309 for ; Tue, 28 May 2002 13:42:27 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11588; Tue, 28 May 2002 11:43:33 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22217; Tue, 28 May 2002 10:42:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SHfPrP024640 for ; Tue, 28 May 2002 10:41:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SHfPXG024639 for mobile-ip-dist; Tue, 28 May 2002 10:41:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SHfMrP024632 for ; Tue, 28 May 2002 10:41:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21670 for ; Tue, 28 May 2002 10:41:25 -0700 (PDT) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09455 for ; Tue, 28 May 2002 10:41:25 -0700 (PDT) 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 ESMTP id NAA00727 for ; Tue, 28 May 2002 13:41:24 -0400 (EDT) From: "Dr. Subrata Goswami" To: Subject: RE: [mobile-ip] Issue #23 and Issue #30 Date: Tue, 28 May 2002 10:45:18 -0700 Message-ID: <000701c2066f$6efff580$6600a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3CF3AC7D.2FC34D79@hp.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit To hear the RA (which is multicasted to a well known address), the interface does not really need to have an IP address, does it ? Also, why does the mobile need to remember the link-layer address of the HA ? What happens when the HA NIC is changed? Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Brian Haley Sent: Tuesday, May 28, 2002 9:13 AM To: Charlie Perkins Cc: Vladislav Yasevich; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 Charlie Perkins wrote: > Hello Vlad, > > I think the home agent MUST proxy for the mobile node's > link address while the mobile node has a valid binding. > I think the home agent should stop defending the link-local > address when the binding expires. I also think the home agent > should accept packets with source address == mobile's > home address as long as they are addressed to the home agent. > Why not? In this case the MN can't use it's home address because it can't configure it since DAD failed (i.e. it just booted and doesn't know where it is). > > If the mobile is inactive when it returns home (and the binding was > > not deleted for whatever reason) the problem is bigger. > > The MN will try to configure the link-local address as part of > > standard IPv6 initialization (it has no idea it's home yet because it > > doesn't have an interface up yet, so it hasn't seen an RA to tell it > > that it's home), but will fail because the HA will defend the link-local > > address. > > I don't think the HA should do this. Can you please explain what you meant by this? Above you said the HA MUST proxy for the MN's home address, doesn't that assume defend as well? > > A possible workaround (a big hack :) to this is once DAD fails, the MN > > can try to un-register with the HA using the following procedure: > > 1. Send a RS to all-routers multicast from the :: address. > > 2. Wait for the RA with the H bit set. > > * for this to work the RA must contain the "Link Address" option. > > this will create a stale cache entry on MN > > 3. Send the unregistration using the :: address with the HOA listing > > the last known home address (that the mobile usually stores). > > In this situation, the mobile node SHOULD know its home address. > Otherwise, how could it tell if it is at home? It has to know something. > And then it could send the Binding Update to the home agent > directly (with lifetime zero). The MN doesn't know it's home until it hears an RA, but in order to hear it it's got to configure it's link-local address first. It would have to be in promisc mode otherwise. > But the mobile node SHOULD NOT forget the home agent's > layer-2 address (assuming it needs it for framing). But the MN might not have the HA's L2 address if it's doing DHAAD, I don't believe the spec says it should keep the HA address in NV storage? -Brian From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 14:18:00 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27124 for ; Tue, 28 May 2002 14:17:59 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29365; Tue, 28 May 2002 12:18:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24981; Tue, 28 May 2002 11:17:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SIGorP025079 for ; Tue, 28 May 2002 11:16:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SIGo5A025078 for mobile-ip-dist; Tue, 28 May 2002 11:16:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SIGkrP025068 for ; Tue, 28 May 2002 11:16:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10359 for ; Tue, 28 May 2002 11:16:49 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA14390 for ; Tue, 28 May 2002 12:16:48 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA13452; Tue, 28 May 2002 11:16:48 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4SIGlt12140; Tue, 28 May 2002 11:16:47 -0700 X-mProtect: <200205281816> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7k355V; Tue, 28 May 2002 11:16:45 PDT Message-ID: <3CF3C98E.74548D2@iprg.nokia.com> Date: Tue, 28 May 2002 11:16:46 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian Haley CC: Vladislav Yasevich , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> <3CED6015.E7A39399@iprg.nokia.com> <3CEE90C2.7010903@hp.com> <3CEFC4CB.92A5D2B1@iprg.nokia.com> <3CF3AC7D.2FC34D79@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Brian, My model may be different than yours. My assumptions: 1) The mobile node owns its home address until the lifetime expires. 2) The home agent proxies for the mobile's home address while it has a valid binding. 3) The mobile node knows how long the home address is valid. 4) The mobile node does not have to reconfigure its home address if it's valid (its lifetime has not expired). 5) The home agent defends the mobile node's link-local address while the mobile node is away from home. Under these circumstances, the mobile node does not have to do DAD when it returns to the home network. It just has to inform the home agent that it has arrived back on its home network. Before going into other cases, please let me know if this much is agreeable to you. Under these assumptions, I think the problems you suggest do not appear: Brian Haley wrote: > > Charlie Perkins wrote: > > > Hello Vlad, > > > > I think the home agent MUST proxy for the mobile node's > > link address while the mobile node has a valid binding. > > I think the home agent should stop defending the link-local > > address when the binding expires. I also think the home agent > > should accept packets with source address == mobile's > > home address as long as they are addressed to the home agent. > > Why not? > > In this case the MN can't use it's home address because it can't configure > it since DAD failed (i.e. it just booted and doesn't know where it is). The mobile node should be able to use its home address as long as it knows it is valid. If the mobile node does NOT know its home address and tries to autoconfigure it, then the solution depends on whether you agree with my aforementioned assumptions. > > > If the mobile is inactive when it returns home (and the binding was > > > not deleted for whatever reason) the problem is bigger. > > > The MN will try to configure the link-local address as part of > > > standard IPv6 initialization (it has no idea it's home yet because it > > > doesn't have an interface up yet, so it hasn't seen an RA to tell it > > > that it's home), but will fail because the HA will defend the link-local > > > address. > > > > I don't think the HA should do this. > > Can you please explain what you meant by this? Above you said the HA MUST > proxy for the MN's home address, doesn't that assume defend as well? Do you still have this question, given my above assumptions? > The MN doesn't know it's home until it hears an RA, but in order to hear > it it's got to configure it's link-local address first. It would have to be in > promisc mode otherwise. I do not know why a mobile node should be unable to hear any packets just because it has not completed autoconfiguration. It should still recognize multicast packets... why not? > > But the mobile node SHOULD NOT forget the home agent's > > layer-2 address (assuming it needs it for framing). > > But the MN might not have the HA's L2 address if it's doing DHAAD, I don't > believe the spec says it should keep the HA address in NV storage? Perhaps the specification should say this, but a specification does not usually mandate storage requirements for a protocol implementation. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 14:20:28 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27222 for ; Tue, 28 May 2002 14:20:27 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03742; Tue, 28 May 2002 11:20:04 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26849; Tue, 28 May 2002 11:19:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SIJBrP025126 for ; Tue, 28 May 2002 11:19:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SIJBfb025125 for mobile-ip-dist; Tue, 28 May 2002 11:19:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SIJ7rP025114 for ; Tue, 28 May 2002 11:19:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12020 for ; Tue, 28 May 2002 11:19:10 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15775 for ; Tue, 28 May 2002 12:19:08 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA13764; Tue, 28 May 2002 11:19:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4SIJ6l16169; Tue, 28 May 2002 11:19:06 -0700 X-mProtect: <200205281819> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdj9TfAY; Tue, 28 May 2002 11:19:04 PDT Message-ID: <3CF3CA19.402B02EE@iprg.nokia.com> Date: Tue, 28 May 2002 11:19:05 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gaurav.Puri@lntinfotech.com CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 ( "S" bit funda) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Gaurav, Gaurav.Puri@lntinfotech.com wrote: > > hello, > From the draft it is clear that DAD is done on the link local address of > MN. > If "S" bit is not set(i.e S bit 0), do we need to perform DAD on all > possible MN's addresses( formed using all on link prefixes) > or doing proxy for all those addresses is sufficient ? > IMHO, If DAD is successful for link local address, that implies that it > will be successful for all possible MN's addresses as last 64 bits will be > same in all the addresses. I agree with you. I think the home agent just has to do DAD for the link-local address, and that should be good enough for all prefixes. However, Francis is carrying on some discussion on the IPv6 mailing list which is relevant to this matter. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 14:30:06 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27413 for ; Tue, 28 May 2002 14:30:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03240; Tue, 28 May 2002 11:29:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02607; Tue, 28 May 2002 11:29:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SIRtrP025238 for ; Tue, 28 May 2002 11:27:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SIRt97025237 for mobile-ip-dist; Tue, 28 May 2002 11:27:55 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SIRprP025230 for ; Tue, 28 May 2002 11:27:51 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16747 for ; Tue, 28 May 2002 11:27:54 -0700 (PDT) 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 MAA24174 for ; Tue, 28 May 2002 12:27:54 -0600 (MDT) 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 ESMTP id OAA10093; Tue, 28 May 2002 14:27:51 -0400 (EDT) From: "Dr. Subrata Goswami" To: "'Charles E. Perkins'" Cc: Subject: RE: [mobile-ip] Issue #23 and Issue #30 Date: Tue, 28 May 2002 11:31:43 -0700 Message-ID: <000801c20675$ec1a1db0$6600a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3CF3C98E.74548D2@iprg.nokia.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charles, a simple question. Why do you want to defend the link-local address ? -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Charles E. Perkins Sent: Tuesday, May 28, 2002 11:17 AM To: Brian Haley Cc: Vladislav Yasevich; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 Hello Brian, My model may be different than yours. My assumptions: 1) The mobile node owns its home address until the lifetime expires. 2) The home agent proxies for the mobile's home address while it has a valid binding. 3) The mobile node knows how long the home address is valid. 4) The mobile node does not have to reconfigure its home address if it's valid (its lifetime has not expired). 5) The home agent defends the mobile node's link-local address while the mobile node is away from home. Under these circumstances, the mobile node does not have to do DAD when it returns to the home network. It just has to inform the home agent that it has arrived back on its home network. Before going into other cases, please let me know if this much is agreeable to you. Under these assumptions, I think the problems you suggest do not appear: Brian Haley wrote: > > Charlie Perkins wrote: > > > Hello Vlad, > > > > I think the home agent MUST proxy for the mobile node's > > link address while the mobile node has a valid binding. > > I think the home agent should stop defending the link-local > > address when the binding expires. I also think the home agent > > should accept packets with source address == mobile's > > home address as long as they are addressed to the home agent. > > Why not? > > In this case the MN can't use it's home address because it can't configure > it since DAD failed (i.e. it just booted and doesn't know where it is). The mobile node should be able to use its home address as long as it knows it is valid. If the mobile node does NOT know its home address and tries to autoconfigure it, then the solution depends on whether you agree with my aforementioned assumptions. > > > If the mobile is inactive when it returns home (and the binding was > > > not deleted for whatever reason) the problem is bigger. > > > The MN will try to configure the link-local address as part of > > > standard IPv6 initialization (it has no idea it's home yet because it > > > doesn't have an interface up yet, so it hasn't seen an RA to tell it > > > that it's home), but will fail because the HA will defend the link-local > > > address. > > > > I don't think the HA should do this. > > Can you please explain what you meant by this? Above you said the HA MUST > proxy for the MN's home address, doesn't that assume defend as well? Do you still have this question, given my above assumptions? > The MN doesn't know it's home until it hears an RA, but in order to hear > it it's got to configure it's link-local address first. It would have to be in > promisc mode otherwise. I do not know why a mobile node should be unable to hear any packets just because it has not completed autoconfiguration. It should still recognize multicast packets... why not? > > But the mobile node SHOULD NOT forget the home agent's > > layer-2 address (assuming it needs it for framing). > > But the MN might not have the HA's L2 address if it's doing DHAAD, I don't > believe the spec says it should keep the HA address in NV storage? Perhaps the specification should say this, but a specification does not usually mandate storage requirements for a protocol implementation. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 14:41:18 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27652 for ; Tue, 28 May 2002 14:41:18 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02621; Tue, 28 May 2002 12:41:26 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23454; Tue, 28 May 2002 11:41:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SIdRrP025321 for ; Tue, 28 May 2002 11:39:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SIdRZL025320 for mobile-ip-dist; Tue, 28 May 2002 11:39:27 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SIdNrP025313 for ; Tue, 28 May 2002 11:39:24 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22738 for ; Tue, 28 May 2002 11:39:27 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09457 for ; Tue, 28 May 2002 11:39:27 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA14722; Tue, 28 May 2002 11:39:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4SIdOu08756; Tue, 28 May 2002 11:39:24 -0700 X-mProtect: <200205281839> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdiAcdHF; Tue, 28 May 2002 11:39:22 PDT Message-ID: <3CF3CEDB.14C6D166@iprg.nokia.com> Date: Tue, 28 May 2002 11:39:23 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Dr. Subrata Goswami" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <000801c20675$ec1a1db0$6600a8c0@SGOSWAMIPCL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Dr. Goswami, If the home agent defends the link-local address, then presumably it simultaneously defends all global addresses that would be formed by replacing the link-local prefix by any of the advertised prefixes on the link. In fact, the home agent is supposed to keep track of all those prefixes anyway, even the ones that it is not the default router for. Regards, Charlie P. "Dr. Subrata Goswami" wrote: > > Charles, a simple question. Why do you want to defend the link-local > address ? > > -----Original Message----- > From: owner-mobile-ip@sunroof.eng.sun.com > [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Charles E. > Perkins > Sent: Tuesday, May 28, 2002 11:17 AM > To: Brian Haley > Cc: Vladislav Yasevich; mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > Hello Brian, > > My model may be different than yours. > > My assumptions: > 1) The mobile node owns its home address until the lifetime expires. > 2) The home agent proxies for the mobile's home address while > it has a valid binding. > 3) The mobile node knows how long the home address is valid. > 4) The mobile node does not have to reconfigure its home address > if it's valid (its lifetime has not expired). > 5) The home agent defends the mobile node's link-local address > while the mobile node is away from home. > > Under these circumstances, the mobile node does not have to do > DAD when it returns to the home network. It just has to inform > the home agent that it has arrived back on its home network. > > Before going into other cases, please let me know if this much > is agreeable to you. > > Under these assumptions, I think the problems you suggest > do not appear: > > Brian Haley wrote: > > > > Charlie Perkins wrote: > > > > > Hello Vlad, > > > > > > I think the home agent MUST proxy for the mobile node's > > > link address while the mobile node has a valid binding. > > > I think the home agent should stop defending the link-local > > > address when the binding expires. I also think the home agent > > > should accept packets with source address == mobile's > > > home address as long as they are addressed to the home agent. > > > Why not? > > > > In this case the MN can't use it's home address because it can't > configure > > it since DAD failed (i.e. it just booted and doesn't know where it > is). > > The mobile node should be able to use its home address as long as > it knows it is valid. If the mobile node does NOT know its home > address and tries to autoconfigure it, then the solution depends > on whether you agree with my aforementioned assumptions. > > > > > If the mobile is inactive when it returns home (and the binding > was > > > > not deleted for whatever reason) the problem is bigger. > > > > The MN will try to configure the link-local address as part of > > > > standard IPv6 initialization (it has no idea it's home yet because > it > > > > doesn't have an interface up yet, so it hasn't seen an RA to tell > it > > > > that it's home), but will fail because the HA will defend the > link-local > > > > address. > > > > > > I don't think the HA should do this. > > > > Can you please explain what you meant by this? Above you said the HA > MUST > > proxy for the MN's home address, doesn't that assume defend as well? > > Do you still have this question, given my above assumptions? > > > The MN doesn't know it's home until it hears an RA, but in order to > hear > > it it's got to configure it's link-local address first. It would have > to be in > > promisc mode otherwise. > > I do not know why a mobile node should be unable to hear any > packets just because it has not completed autoconfiguration. > It should still recognize multicast packets... why not? > > > > But the mobile node SHOULD NOT forget the home agent's > > > layer-2 address (assuming it needs it for framing). > > > > But the MN might not have the HA's L2 address if it's doing DHAAD, I > don't > > believe the spec says it should keep the HA address in NV storage? > > Perhaps the specification should say this, but a specification does > not usually mandate storage requirements for a protocol implementation. > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 15:02:05 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28059 for ; Tue, 28 May 2002 15:02:05 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14978; Tue, 28 May 2002 13:02:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29971; Tue, 28 May 2002 12:01:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SJ0OrP025430 for ; Tue, 28 May 2002 12:00:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SJ0OoP025429 for mobile-ip-dist; Tue, 28 May 2002 12:00:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SJ0LrP025422 for ; Tue, 28 May 2002 12:00:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA17665 for ; Tue, 28 May 2002 12:00:25 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05386 for ; Tue, 28 May 2002 13:00:23 -0600 (MDT) Message-ID: <00ba01c20678$dd938530$b36015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Jari Arkko" , "Erik Nordmark" Cc: References: <3CEE66E4.6080509@kolumbus.fi> Subject: Re: [mobile-ip] RR and BU to HA Date: Tue, 28 May 2002 11:52:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > In conclusion, we have the following options: > > (1) Declare that we never need such tests. End of story. > (2) Declare that we always need such tests, and add this > to the protocol. > (3) Declare that you are allowed to run such tests, if your > policy requires it. You could alternatively implement this > with (a) existing mechanisms or (b) design new mechanisms. Earlier, it wasn't clear whether this policy difference between processing BUs at the CN vs at the HA was a design choice with an explanation. It seems like there are explanations on this. Therefore I don't mind going with (1), as long as we put one or two sentences in the draft reasoning this design. And if people think that this might be an issue for an highly-secure deployment, they can write a separate draft to fix it (like 3a). alper From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 15:27:32 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28383 for ; Tue, 28 May 2002 15:27:31 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29458; Tue, 28 May 2002 13:27:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09658; Tue, 28 May 2002 12:27:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SJQTrP025533 for ; Tue, 28 May 2002 12:26:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SJQTi7025532 for mobile-ip-dist; Tue, 28 May 2002 12:26:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SJQQrP025525 for ; Tue, 28 May 2002 12:26:26 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27879 for ; Tue, 28 May 2002 12:26:30 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28685 for ; Tue, 28 May 2002 13:26:30 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA17358; Tue, 28 May 2002 12:26:28 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4SJQQW28974; Tue, 28 May 2002 12:26:26 -0700 X-mProtect: <200205281926> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeG5Ejc; Tue, 28 May 2002 12:26:24 PDT Message-ID: <3CF3D9E1.A7D724C6@iprg.nokia.com> Date: Tue, 28 May 2002 12:26:25 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Dr. Subrata Goswami" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <000801c20675$ec1a1db0$6600a8c0@SGOSWAMIPCL> <3CF3CEDB.14C6D166@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello again, I should clarify: My expectation is that the home agent should ONLY defend the mobile node's link-local address, not its other addresses. Then, by implication, the other addresses will be unavailable to nodes on the link because they can't form the link-local address to start with. Regards, Charlie P. "Charles E. Perkins" wrote: > > Hello Dr. Goswami, > > If the home agent defends the link-local address, then > presumably it simultaneously defends all global addresses > that would be formed by replacing the link-local prefix > by any of the advertised prefixes on the link. > > In fact, the home agent is supposed to keep track of all > those prefixes anyway, even the ones that it is not the > default router for. > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 15:32:13 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28577 for ; Tue, 28 May 2002 15:32:13 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12158; Tue, 28 May 2002 13:32:21 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11656; Tue, 28 May 2002 12:32:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SJVLrP025598 for ; Tue, 28 May 2002 12:31:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SJVKNB025597 for mobile-ip-dist; Tue, 28 May 2002 12:31:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SJVHrP025590 for ; Tue, 28 May 2002 12:31:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29876 for ; Tue, 28 May 2002 12:31:21 -0700 (PDT) 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 NAA01651 for ; Tue, 28 May 2002 13:31:21 -0600 (MDT) 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 ESMTP id PAA23261 for ; Tue, 28 May 2002 15:31:20 -0400 (EDT) From: "Dr. Subrata Goswami" Cc: Subject: RE: [mobile-ip] Issue #23 and Issue #30 Date: Tue, 28 May 2002 12:35:13 -0700 Message-ID: <000b01c2067e$ca1e6230$6600a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3CF3D9E1.A7D724C6@iprg.nokia.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Charlie for the answer. Why is it necessary to defend all the possible global addresses that can be formed from the post-fix of the link-local address (this number can be very large ) ? Subrata -----Original Message----- From: charliep@darkstar.iprg.nokia.com [mailto:charliep@darkstar.iprg.nokia.com] On Behalf Of Charles E. Perkins Sent: Tuesday, May 28, 2002 12:26 PM To: Dr. Subrata Goswami Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 Hello again, I should clarify: My expectation is that the home agent should ONLY defend the mobile node's link-local address, not its other addresses. Then, by implication, the other addresses will be unavailable to nodes on the link because they can't form the link-local address to start with. Regards, Charlie P. "Charles E. Perkins" wrote: > > Hello Dr. Goswami, > > If the home agent defends the link-local address, then > presumably it simultaneously defends all global addresses > that would be formed by replacing the link-local prefix > by any of the advertised prefixes on the link. > > In fact, the home agent is supposed to keep track of all > those prefixes anyway, even the ones that it is not the > default router for. > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 15:41:08 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28864 for ; Tue, 28 May 2002 15:41:08 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07064; Tue, 28 May 2002 13:41:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03400; Tue, 28 May 2002 12:41:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SJeIrP025701 for ; Tue, 28 May 2002 12:40:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SJeIDZ025700 for mobile-ip-dist; Tue, 28 May 2002 12:40:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SJeFrP025693 for ; Tue, 28 May 2002 12:40:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13633 for ; Tue, 28 May 2002 12:40:19 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06536 for ; Tue, 28 May 2002 13:40:18 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA17980; Tue, 28 May 2002 12:40:17 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4SJeGp11190; Tue, 28 May 2002 12:40:16 -0700 X-mProtect: <200205281940> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOtvrwU; Tue, 28 May 2002 12:40:14 PDT Message-ID: <3CF3DD1F.F70B54F9@iprg.nokia.com> Date: Tue, 28 May 2002 12:40:15 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Dr. Subrata Goswami" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <000b01c2067e$ca1e6230$6600a8c0@SGOSWAMIPCL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Subrata, "Dr. Subrata Goswami" wrote: > > Thanks Charlie for the answer. Why is it necessary to defend all the > possible global addresses that can be formed from the post-fix of the > link-local address (this number can be very large ) ? Well, to my understanding, it is not necessary! Do you know a reason why it would be needed? Regards, Charlie P. > > Subrata > > -----Original Message----- > From: charliep@darkstar.iprg.nokia.com > [mailto:charliep@darkstar.iprg.nokia.com] On Behalf Of Charles E. > Perkins > Sent: Tuesday, May 28, 2002 12:26 PM > To: Dr. Subrata Goswami > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > Hello again, > > I should clarify: My expectation is that the home agent should > ONLY defend the mobile node's link-local address, not its other > addresses. Then, by implication, the other addresses will be > unavailable to nodes on the link because they can't form the > link-local address to start with. > > Regards, > Charlie P. > > "Charles E. Perkins" wrote: > > > > Hello Dr. Goswami, > > > > If the home agent defends the link-local address, then > > presumably it simultaneously defends all global addresses > > that would be formed by replacing the link-local prefix > > by any of the advertised prefixes on the link. > > > > In fact, the home agent is supposed to keep track of all > > those prefixes anyway, even the ones that it is not the > > default router for. > > > > Regards, > > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 15:46:48 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29075 for ; Tue, 28 May 2002 15:46:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19413; Tue, 28 May 2002 13:46:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05860; Tue, 28 May 2002 12:46:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SJk8rP025763 for ; Tue, 28 May 2002 12:46:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SJk8hh025762 for mobile-ip-dist; Tue, 28 May 2002 12:46:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SJk5rP025755 for ; Tue, 28 May 2002 12:46:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16461 for ; Tue, 28 May 2002 12:46:09 -0700 (PDT) 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 NAA28109 for ; Tue, 28 May 2002 13:47:03 -0600 (MDT) 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 ESMTP id PAA26144 for ; Tue, 28 May 2002 15:46:06 -0400 (EDT) From: "Dr. Subrata Goswami" Cc: Subject: RE: [mobile-ip] Issue #23 and Issue #30 Date: Tue, 28 May 2002 12:49:59 -0700 Message-ID: <000d01c20680$da3df7f0$6600a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3CF3DD1F.F70B54F9@iprg.nokia.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, I can not think of any at this point. Eliminating the requirement (of link-local address defence by HA) would simplify HA design. Subrata -----Original Message----- From: charliep@darkstar.iprg.nokia.com [mailto:charliep@darkstar.iprg.nokia.com] On Behalf Of Charles E. Perkins Sent: Tuesday, May 28, 2002 12:40 PM To: Dr. Subrata Goswami Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 Hello Subrata, "Dr. Subrata Goswami" wrote: > > Thanks Charlie for the answer. Why is it necessary to defend all the > possible global addresses that can be formed from the post-fix of the > link-local address (this number can be very large ) ? Well, to my understanding, it is not necessary! Do you know a reason why it would be needed? Regards, Charlie P. > > Subrata > > -----Original Message----- > From: charliep@darkstar.iprg.nokia.com > [mailto:charliep@darkstar.iprg.nokia.com] On Behalf Of Charles E. > Perkins > Sent: Tuesday, May 28, 2002 12:26 PM > To: Dr. Subrata Goswami > Cc: mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > Hello again, > > I should clarify: My expectation is that the home agent should > ONLY defend the mobile node's link-local address, not its other > addresses. Then, by implication, the other addresses will be > unavailable to nodes on the link because they can't form the > link-local address to start with. > > Regards, > Charlie P. > > "Charles E. Perkins" wrote: > > > > Hello Dr. Goswami, > > > > If the home agent defends the link-local address, then > > presumably it simultaneously defends all global addresses > > that would be formed by replacing the link-local prefix > > by any of the advertised prefixes on the link. > > > > In fact, the home agent is supposed to keep track of all > > those prefixes anyway, even the ones that it is not the > > default router for. > > > > Regards, > > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 16:17:03 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29710 for ; Tue, 28 May 2002 16:16:57 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29491; Tue, 28 May 2002 14:17:05 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01136; Tue, 28 May 2002 13:16:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SKEZrP025963 for ; Tue, 28 May 2002 13:14:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SKEZEv025962 for mobile-ip-dist; Tue, 28 May 2002 13:14:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SKEUrP025955 for ; Tue, 28 May 2002 13:14:30 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28589 for ; Tue, 28 May 2002 13:14:35 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09171 for ; Tue, 28 May 2002 13:14:34 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 27C805791; Tue, 28 May 2002 16:14:34 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 3E46B116E; Tue, 28 May 2002 15:14:33 -0500 (CDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id QAA0000852598; Tue, 28 May 2002 16:14:32 -0400 (EDT) Message-ID: <3CF3E528.67F526E2@hp.com> Date: Tue, 28 May 2002 16:14:32 -0400 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.79 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: "Charles E. Perkins" Cc: Vladislav Yasevich , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> <3CED6015.E7A39399@iprg.nokia.com> <3CEE90C2.7010903@hp.com> <3CEFC4CB.92A5D2B1@iprg.nokia.com> <3CF3AC7D.2FC34D79@hp.com> <3CF3C98E.74548D2@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie, "Charles E. Perkins" wrote: > My assumptions: > 1) The mobile node owns its home address until the lifetime expires. > 2) The home agent proxies for the mobile's home address while > it has a valid binding. > 3) The mobile node knows how long the home address is valid. > 4) The mobile node does not have to reconfigure its home address > if it's valid (its lifetime has not expired). I guess I agree with these, but I'm a little confused by the different meanings of "valid" above. I would say: When a MN is at home, it's global address is valid for as long as the prefix it used to construct it is valid (and it's actively defending the address (i.e. running)). When away from home, it's global home address is only valid if it has a binding with a HA that is defending/proxying for the address. If a MN cannot register a binding with it's HA and the lifetime has expired, it's global home address cannot be considered valid and should not be used until a BU/BAck has successfully taken place. > 5) The home agent defends the mobile node's link-local address > while the mobile node is away from home. This is separate issue from the above. The goal here is to defend the interface-id of the MN so that another node doesn't autoconfigure a global address that the MN hasn't yet configured on the home link using it (ala DAD optimization in RFC 2462). > > The MN doesn't know it's home until it hears an RA, but in order to hear > > it it's got to configure it's link-local address first. It would have to be in > > promisc mode otherwise. > > I do not know why a mobile node should be unable to hear any > packets just because it has not completed autoconfiguration. > It should still recognize multicast packets... why not? Yes, that seems correct, it just can't send a RS to speed-up the process if it can't configure it's link-local address (I think? It's been a while since I looked at this...). > > > But the mobile node SHOULD NOT forget the home agent's > > > layer-2 address (assuming it needs it for framing). > > > > But the MN might not have the HA's L2 address if it's doing DHAAD, I don't > > believe the spec says it should keep the HA address in NV storage? > > Perhaps the specification should say this, but a specification does > not usually mandate storage requirements for a protocol implementation. The Mobile IPv6 draft says MNs and HAs "MUST use non-volatile memory" to store sequence numbers :) -Brian From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 16:20:59 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29931 for ; Tue, 28 May 2002 16:20:58 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09574; Tue, 28 May 2002 13:20:26 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03085; Tue, 28 May 2002 13:20:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SKJLrP026078 for ; Tue, 28 May 2002 13:19:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SKJLVi026077 for mobile-ip-dist; Tue, 28 May 2002 13:19:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SKJIrP026070 for ; Tue, 28 May 2002 13:19:18 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02486 for ; Tue, 28 May 2002 13:19:22 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA09582 for ; Tue, 28 May 2002 14:19:21 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 4EEC76A905; Tue, 28 May 2002 23:19:15 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C5E4F6A904; Tue, 28 May 2002 23:19:13 +0300 (EEST) Message-ID: <3CF3E685.5030403@kolumbus.fi> Date: Tue, 28 May 2002 23:20:21 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Alper E. YEGIN" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] RR and BU to HA References: <3CEE66E4.6080509@kolumbus.fi> <00ba01c20678$dd938530$b36015ac@AlperVAIO> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Alper E. YEGIN wrote: > Earlier, it wasn't clear whether this policy difference between processing > BUs at the CN vs at the HA was a design choice with an explanation. > It seems like there are explanations on this. Therefore I don't mind > going with (1), as long as we put one or two sentences in the draft > reasoning this design. And if people think that this might be an issue > for an highly-secure deployment, they can write a separate draft to > fix it (like 3a). Ok, looks like most people agree on this. I'm writing a new version of the security considerations sections. It contains the following text: ... The above mechanisms do not show that the care-of address given in the Binding Update is correct. This opens the possibility for Denial-of-Service attacks against third parties. However, since the mobile node and home agent have a security association, the home agent can always identify an ill-behaving mobile node. This allows the home agent operator to discontinue the mobile node's service, and possibly take further actions based on the business relationship with the mobile node's owner. Does this work for everyone? Jari From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 16:46:10 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00741 for ; Tue, 28 May 2002 16:46:09 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA24301; Tue, 28 May 2002 13:45:44 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13137; Tue, 28 May 2002 13:45:38 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SKiBrP026494 for ; Tue, 28 May 2002 13:44:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SKiBrR026493 for mobile-ip-dist; Tue, 28 May 2002 13:44:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SKi8rP026486 for ; Tue, 28 May 2002 13:44:08 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12530 for ; Tue, 28 May 2002 13:44:12 -0700 (PDT) Received: from harumscarum.mr.itd.umich.edu (harumscarum.mr.itd.umich.edu [141.211.125.17]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22522 for ; Tue, 28 May 2002 14:43:58 -0600 (MDT) 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 ESMTP id QAA07039 for ; Tue, 28 May 2002 16:43:56 -0400 (EDT) From: "Dr. Subrata Goswami" Cc: Subject: RE: [mobile-ip] Issue #23 and Issue #30 Date: Tue, 28 May 2002 13:47:49 -0700 Message-ID: <001001c20688$ee9227f0$6600a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <3CF3E528.67F526E2@hp.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit The link-local address does not have to be based on the IID, see the following excerpt from RFC 2462. " If a node determines that its tentative link-local address is not unique, autoconfiguration stops and manual configuration of the interface is required. To simplify recovery in this case, it should be possible for an administrator to supply an alternate interface identifier that overrides the default identifier in such a way that the autoconfiguration mechanism can then be applied using the new (presumably unique) interface identifier. Alternatively, link-local and other addresses will need to be configured manually." Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Brian Haley Sent: Tuesday, May 28, 2002 1:15 PM To: Charles E. Perkins Cc: Vladislav Yasevich; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 Hi Charlie, "Charles E. Perkins" wrote: > My assumptions: > 1) The mobile node owns its home address until the lifetime expires. > 2) The home agent proxies for the mobile's home address while > it has a valid binding. > 3) The mobile node knows how long the home address is valid. > 4) The mobile node does not have to reconfigure its home address > if it's valid (its lifetime has not expired). I guess I agree with these, but I'm a little confused by the different meanings of "valid" above. I would say: When a MN is at home, it's global address is valid for as long as the prefix it used to construct it is valid (and it's actively defending the address (i.e. running)). When away from home, it's global home address is only valid if it has a binding with a HA that is defending/proxying for the address. If a MN cannot register a binding with it's HA and the lifetime has expired, it's global home address cannot be considered valid and should not be used until a BU/BAck has successfully taken place. > 5) The home agent defends the mobile node's link-local address > while the mobile node is away from home. This is separate issue from the above. The goal here is to defend the interface-id of the MN so that another node doesn't autoconfigure a global address that the MN hasn't yet configured on the home link using it (ala DAD optimization in RFC 2462). > > The MN doesn't know it's home until it hears an RA, but in order to hear > > it it's got to configure it's link-local address first. It would have to be in > > promisc mode otherwise. > > I do not know why a mobile node should be unable to hear any > packets just because it has not completed autoconfiguration. > It should still recognize multicast packets... why not? Yes, that seems correct, it just can't send a RS to speed-up the process if it can't configure it's link-local address (I think? It's been a while since I looked at this...). > > > But the mobile node SHOULD NOT forget the home agent's > > > layer-2 address (assuming it needs it for framing). > > > > But the MN might not have the HA's L2 address if it's doing DHAAD, I don't > > believe the spec says it should keep the HA address in NV storage? > > Perhaps the specification should say this, but a specification does > not usually mandate storage requirements for a protocol implementation. The Mobile IPv6 draft says MNs and HAs "MUST use non-volatile memory" to store sequence numbers :) -Brian From owner-mobile-ip@sunroof.eng.sun.com Tue May 28 19:11:01 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03819 for ; Tue, 28 May 2002 19:11:01 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA29480; Tue, 28 May 2002 17:11:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28098; Tue, 28 May 2002 16:10:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SN9srP026687 for ; Tue, 28 May 2002 16:09:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4SN9sFr026686 for mobile-ip-dist; Tue, 28 May 2002 16:09:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4SN9prP026679 for ; Tue, 28 May 2002 16:09:51 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA29456 for ; Tue, 28 May 2002 16:09:55 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA01582 for ; Tue, 28 May 2002 17:09:54 -0600 (MDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g4SN9bi28994; Tue, 28 May 2002 18:09:37 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g4SN9bY19561; Tue, 28 May 2002 18:09:37 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA14495; Tue, 28 May 2002 18:09:36 -0500 (CDT) Received: from ericsson.com (letmein2-037.exu.ericsson.se [138.85.130.37]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id SAA21486; Tue, 28 May 2002 18:09:35 -0500 (CDT) Message-ID: <3CF40D52.5A30B679@ericsson.com> Date: Tue, 28 May 2002 16:05:54 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Fredrik Johansson , MobileIP CC: Charlie Perkins , Phil Roberts , Basavaraj Patil , Kevin Purser , Johan Johansson Subject: [mobile-ip] Re: Address to use in the SA between FA-HA References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit All, I agree with Fredrik. Thus, always use the CoA. I haven't seen any objection to this, so can I assume that this is the consensus? If no objections / comments I will assume that this is the case and don't make any changes regarding this to the Diameter MIPv4 application draft. Regards, /Tony Fredrik Johansson wrote: > Hi, > > RFC 3220 doesn't define which address to use when creating the SA between > the FA and HA. I have always assumed that it was the care-of-address in the > registration request header, but considering the case when a mobile > registers with an FA just because it has set the 'R'-bit in its > advertisement. The rfc doesn't say which Ip address to use in this case, the > CoA or the source address of the incoming reguest. > > This will cause interoperability problems within mobile ip itself, and also > affects other protocols such as Diameter. The best would be to always use > the CoA since the incoming request may not always have a source address > (e.g. when coming via a Diameter Request). > > /Fredrik From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 03:44:02 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06321 for ; Wed, 29 May 2002 03:44:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11915; Wed, 29 May 2002 00:43:08 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA16143; Wed, 29 May 2002 00:42:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4T7fvrP027517 for ; Wed, 29 May 2002 00:41:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4T7fvUw027516 for mobile-ip-dist; Wed, 29 May 2002 00:41:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4T7frrP027509 for ; Wed, 29 May 2002 00:41:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27565 for ; Wed, 29 May 2002 00:41:56 -0700 (PDT) Received: from Mistralsoftware.com (ptil-245-146-ban.primus-india.net [203.196.146.245] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA23239 for ; Wed, 29 May 2002 01:41:52 -0600 (MDT) Received: from kalyana [192.168.13.46] by mistralsoftware.com [192.168.10.12] with SMTP (MDaemon.PRO.v5.0.0.R) for ; Wed, 29 May 2002 13:23:52 +0530 Message-ID: <005801c206e4$42c4f770$2e0da8c0@kalyana> From: "Kalyan" To: "Hesham Soliman \(ERA\)" , References: <4DA6EA82906FD511BE2F00508BCF0538044F06A4@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] comments on MIPv6 draft-17 Date: Wed, 29 May 2002 13:11:35 +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.00.2919.6600 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-MDRemoteIP: 192.168.13.46 X-Return-Path: kalyan@mistralsoftware.com X-MDaemon-Deliver-To: mobile-ip@sunroof.eng.sun.com Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi , In section 6.4.1,You had clearly mentioned that the segments left field is always equal to 1. Then why does a node check for either '0' or '1' in the segments left field of the routing header type 2, while processing a packet received for one of its addresses. Any info regarding this is welcome. Regards, Kalyan. ----- Original Message ----- From: "Hesham Soliman (ERA)" To: Sent: Tuesday, May 28, 2002 9:48 PM Subject: [mobile-ip] comments on MIPv6 draft-17 > Hi, > > I've read the draft and have the following comments/questions. > > 1. General comments: > > - In general I think the draft has redundant text and in > some cases, significant overlaps between sections. It's > good to have some overlap, but in many cases it is too > repetetive. I'll try to mention specific examples in my > editorial comments. But this could be something to consider > before the final draft is done. The draft is very large > so it is good to remove as much as possible while maintaining > a good level of clarity. > > 2. Specific technical comments > > - I wonder if it's worth referencing some way of creating > the nonce, or making a recommendation on how to do it. Mike > Thomas' last draft had a reference. It might be good to do > that, since it (the nonce) is a pretty significant part of RR. > > - I don't understand why MAX_RR_BINDING_LIFE is fixed > to 300 seconds. I would appreciate a reference or a reason. > The attack that Pekka sent a few months ago should not > require the 5 min limit. It simply requires that the BCE > cannot be refreshed without performing RR. In fact there > is probably more hazard in allowing the updates within > the 5 min than if we extend (or remove) the upper time > limit. > > - Busy CNs will struggle with maintaining the Nonce > and Kbu lifetimes for several (hundreds or thousands?) > of MNs. Do you think this is a valid concern? If so > we need to add some recommendation on how to do this. > I haven't read the state machines in the appendix > yet, so my answer might be there. > > - I might have missed this in an earlier discussion, > but why us the checksum needed for the MH? > It should always be authenticated. > > - Section 6.1.3: Why is the HA tunnelling the HOT a SHOULD? > It seems that this is one of the assumptions that the > protocol is based on (see the security design section). > Shouldn't this be a MUST? Not making this a MUST will > allow attacker on the MNs link to do some nasty stuff. > > - It seems like there was a concious decision to separate > the 'reserved' fields in all messages (e.g. section > 6.1.5 (HoT) and 6.1.6), why is that? > > - Why are certain values skipped for the BA status > codes? e.g. between 133 and 137. I suggest we place them > in order. It looks like some magic is attached to those > missing numbers :) > > - I think that setting the A flag has to be a MUST > or at the very minimum a SHOULD. It is very clear to > me that the protocol is much weaker and non-deterministic > without mandating the Ack. I would suggest that we mandate > it. There are several examples in the draft the provide > a good reason for mandating the BA. > > - I don't really get this unique identifier option, but > more on that later. > > - Either we explain how the Mobile Prefix sol and adv > can be done securely (using PKI and dynamic SA establishment), > or remove them from the draft. I don't think we should > keep them and say that they must be authenticated 'if possible'. > what does that mean? Either they must be authenticated > or not. I think that they must be. > > - Section 8.1,what is the point of mandating the HAO > when the spec says that it must not be received > without a BCE, and the entire RO is a 'should'.? > The HAO should follow the same recommendation as RO. > > - In section 8.1: I think we should add a line that > if RR is supported, the CN MUST be able to return > a BA in response to a BU. > > - Section 9.1: Remove all the references to mobile routers. > E.g. the fifth bullet. Also remove the sixth bullet, > the prefix length does not exist anymore. > > - Section 9.2.2: First sentence, 'MAY' is unnecessay. > If the MN has a BCE, it's pretty strange that it doesn't > use RO and decide to not include the HAO. > > - Section 9.4.1: Shouldn't the order of the last 2 bullets > be reversed.(Half editorial). > > - Section 9.4.1: Perhaps we should add some text to specify that > 'normally' the CoA nonce index and Home Nonce index are the same, > and that sending both is a precaution for changing the nonce while > RR is in progress. Or am I missing something? > > - Section 9.6, first paragraph. I thin we should replace > the first SHOULD with MUST. There is no point in having a > binding cache if it doesn't get chacked. > > - Section 9.7: Remove the third paragraph, it no longer > applies. > > - Section 9.7: Fourth paragraph: Do we need to say how > persistent is 'persistent'? or Specify a default rate? > > - Section 10.1: Last sentence in the second paragraph, says > ' it SHOULD NOT be deleted by the HA ...' In section 9.5, > the same action was a 'MUST NOT'. Either MUST NOT, or SHOULD > NOT (accompanied with 'MUST inform the MN') are ok with me. > > - Section 10.1: Remove '(or has recently)' from the fourth > paragraph. > > - Section 10.1: it would be good to show the order of > HAs in the HA list (last bullet in 10.1 doesn't say > in what order). > > - Section 10.1: In response to the question in the draft, I'd > say that as long as the HA discovery is in the draft, > we have to keep the preference. I think HA discovery is > a nice idea. > > - Fifth bullet in 10.2: Shouldn't DAD be done for all addresses? > RFC 3041 might be a problem here if we only do DAD > on link-local addresses. > > - Page 93: Bullet starting with 'However, if the 'S' bit > .....'. This strikes me as a problem when renumbering > the Home network is going on. If the HA always chooses > the smallest lifetime, doesn't that mean it will always > be choosing the lifetime of the prefix being deprecated? > Some clarification would be good. > > - Section 10.4: I don't think ND says anything about > 'gratuitous' NAs. We should replace that with Proxy NA > or some other terminology used in IPv6. > > - Somewhere in section 10 it should be mentioned that > if the S bit is cleared (request the HA to act on behalf > of all the MNs HoAs) then the HA should create an SA in the > SAD for each one of those home addresses. > > - Page 96: In the four bullets there, I have the following > comments: > - Second bullet, the llA should be there IF the link > layer has link layer addresses. > - A pedantic question: What happens if ND is secured > with pre-configured SAs. Shouldn't the HA be configured > to act on behalf of MNs and send secure ND messages? > > - Remove the last paragraph before 10.5 (the part about the R bit). > > - Section 10.5: Second paragraph, remove all reference to prefix > length. > > - General comment on multicast: I lost the emails that Dave > Thaler sent on the topic and haven't had time to look them > up. But I thought I'd remind the authors to look them > up and see if they are applicable. > > - Section 10.7: Second paragrpah, Again, why is ESP > optional here ? What is the default behaviour? > > - Section 10.9.3: 'If a security association ....' > -- > No ifs pleasejust make sure it's secure (MUST). > This goes for the entire section. > > - Page 108: Remove any reference to previous-CoA. > > - Section 11.1: Te bullet starting with, 'A flag when > set, indicates that future Binding Updates .....' > What does this mean?? The MN will keep an entry in > the BUL anyway for a CN that doesn't accept BUs? > > - Page 113: Last bullet, 'other implementation > stragies maybe more appropriate' Like what? > I don't think we need to state this do we? > I would suggest removing this approach and > making the standard more concretein what it > says. > > - Page 115: 'The segments left in the RH is either > 0 or 1'. Zero? why is Zero ok? > > - Chapter 11.2.4 assumes that the MN can send > BUs to a 'router' in the local domain. I'm > not sure we can keep this in the spec without > specifying how to secure this BU. > > - Section 11.3.3/4: Same comment on securing the messages. > > - Add somewhere in Section 11 that the MN MUST NOT > let BCEs in CNs or HA timeout after the MN has > moved. I.e. It MUST deregister. > > - Remove section 11.6.6. > > 3. Editorial comments > > This is not an exhaustive list, but I assume the > draft will be revised and grammar ...etc will be > checked again. > > - secion 5.5: Second sentence 'without creating major new ..' > Should be changed to '..new major...' or reworded. > > - Same section: All the references to, e.g., [1] ...are > they going to be RFCs ? Otherwise they can't be referenced. > > - Section 5.5.1: Second sentence: '...to accept only...' > reword. > > - Section 5.5.9: Second sentence, remove 'only' > > - Section 6.1.1: Last paragraph Add 'the' after > 'Mobility Header are' in the first sentence. > > - Why are sections 6.2.2 and 6.2.3 needed? > can't we refer to 2460? The less text the > better for this spec. > > - In 6.2.4 and 6.2.5 and other sections, please > write either 'Type', 'Length' ...etc in the > option format or 'Type = X', 'Length = Y', > but not just the numbers. > > - Page 56: Repeated text: 'A packet MUST NOT contain.... > associated with each encapsulating IP header' > > - Section 6.4: Second paragraph: 'This uses...' > Replace 'This' with 'The Routing Header' or > 'The new RH' .... > > - Section 9.4.2: Last sentence in the second last > paragraph, add 'of' before 'its lifetime'. > > - Section 9.6: Third paragraph, first sentence, add > 'in' before '6.4'. > > > > That's all I have for now. > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 07:16:56 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10432 for ; Wed, 29 May 2002 07:16:55 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA21485; Wed, 29 May 2002 04:16:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18835; Wed, 29 May 2002 04:16:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TBFcrP027777 for ; Wed, 29 May 2002 04:15:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TBFctX027776 for mobile-ip-dist; Wed, 29 May 2002 04:15:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TBFZrP027769 for ; Wed, 29 May 2002 04:15:35 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA14552 for ; Wed, 29 May 2002 04:15:24 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09628 for ; Wed, 29 May 2002 05:15:23 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4TBFJ6p020034; Wed, 29 May 2002 13:15:19 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 13:15:19 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F06AA@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins'" , Brian Haley Cc: Vladislav Yasevich , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Issue #23 and Issue #30 Date: Wed, 29 May 2002 13:15:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Charlie, > My model may be different than yours. > > My assumptions: > 1) The mobile node owns its home address until the lifetime expires. > 2) The home agent proxies for the mobile's home address while > it has a valid binding. > 3) The mobile node knows how long the home address is valid. > 4) The mobile node does not have to reconfigure its home address > if it's valid (its lifetime has not expired). > 5) The home agent defends the mobile node's link-local address > while the mobile node is away from home. > > Under these circumstances, the mobile node does not have to do > DAD when it returns to the home network. It just has to inform > the home agent that it has arrived back on its home network. > > Before going into other cases, please let me know if this much > is agreeable to you. > => I agree with these assumptions. I don't see big issues with this, provided that the HA removes 'proxying for the MN' upon reception of the BU and before sending a BA. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 07:21:10 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10485 for ; Wed, 29 May 2002 07:21:10 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12278; Wed, 29 May 2002 04:20:45 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA20019; Wed, 29 May 2002 04:20:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TBK1rP027842 for ; Wed, 29 May 2002 04:20:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TBK1vX027841 for mobile-ip-dist; Wed, 29 May 2002 04:20:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TBJvrP027834 for ; Wed, 29 May 2002 04:19:58 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15286 for ; Wed, 29 May 2002 04:20:01 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11983 for ; Wed, 29 May 2002 04:20:01 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4TBJvmG016766; Wed, 29 May 2002 13:19:57 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 13:19:57 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F06AB@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins'" , "Dr. Subrata Goswami" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Issue #23 and Issue #30 Date: Wed, 29 May 2002 13:19:52 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > I should clarify: My expectation is that the home agent should > ONLY defend the mobile node's link-local address, not its other > addresses. Then, by implication, the other addresses will be > unavailable to nodes on the link because they can't form the > link-local address to start with. > => I think the HA must defend all addresses, including the link-local one. This is related to RFC3041 and Francis' discussion on the IPv6 list. A node implementing RFC 3041 might form a global address that belongs to one of the other MN's Home addresses. Hence, if the HA does not defend all addresses, a MN might 'lose' one of its home addresses to another node on the home link. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 07:41:29 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11554 for ; Wed, 29 May 2002 07:41:28 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA01907; Wed, 29 May 2002 04:41:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA24183; Wed, 29 May 2002 04:40:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TBeArP027949 for ; Wed, 29 May 2002 04:40:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TBe90D027948 for mobile-ip-dist; Wed, 29 May 2002 04:40:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TBe6rP027941 for ; Wed, 29 May 2002 04:40:06 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18416 for ; Wed, 29 May 2002 04:40:10 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA20268; Wed, 29 May 2002 04:39:29 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4TBdAmG024172; Wed, 29 May 2002 13:39:10 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 13:39:10 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F06AE@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Jari Arkko'" , "Alper E. YEGIN" Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] RR and BU to HA Date: Wed, 29 May 2002 13:39:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Works for me. You could add a sentence saying that if the MN and HA are owned by a single administrator (home network case), then this approach would result in treating them as a single entity... which is reasonable. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 11:42:48 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21734 for ; Wed, 29 May 2002 11:42:47 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03239; Wed, 29 May 2002 08:42:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05977; Wed, 29 May 2002 08:41:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TFearP028389 for ; Wed, 29 May 2002 08:40:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TFea8v028388 for mobile-ip-dist; Wed, 29 May 2002 08:40:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TFeWrP028381; Wed, 29 May 2002 08:40:32 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05529; Wed, 29 May 2002 08:40:37 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17590; Wed, 29 May 2002 08:40:37 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA05094; Wed, 29 May 2002 08:40:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4TFeat18376; Wed, 29 May 2002 08:40:36 -0700 X-mProtect: <200205291540> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGk3fbX; Wed, 29 May 2002 08:40:34 PDT Message-ID: <3CF4F673.607A7AA0@iprg.nokia.com> Date: Wed, 29 May 2002 08:40:35 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <4DA6EA82906FD511BE2F00508BCF0538044F06AB@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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, I CC:'d the IPv6 mailing list... "Hesham Soliman (ERA)" wrote: > => I think the HA must defend all addresses, including > the link-local one. This is related to RFC3041 and > Francis' discussion on the IPv6 list. A node implementing > RFC 3041 might form a global address that belongs to one of > the other MN's Home addresses. Hence, if the HA does not > defend all addresses, a MN might 'lose' one of its > home addresses to another node on the home link. I'd rather prohibit such behavior. I don't see the need for it. I am surprised that RFC 3041 would allow such behavior. Can you point out the offending part of the specification? What was the justification for enabling this? Aren't there "enough" random numbers in 2^64 to avoid clobbering addresses used by other nodes? sheesh... Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 11:59:51 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22319 for ; Wed, 29 May 2002 11:59:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00554; Wed, 29 May 2002 10:00:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA13571; Wed, 29 May 2002 08:59:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TFwsrP028507 for ; Wed, 29 May 2002 08:58:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TFwsa3028506 for mobile-ip-dist; Wed, 29 May 2002 08:58:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TFworP028499 for ; Wed, 29 May 2002 08:58:50 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA21865 for ; Wed, 29 May 2002 08:58:55 -0700 (PDT) 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 JAA29483 for ; Wed, 29 May 2002 09:58:54 -0600 (MDT) 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 ESMTP id LAA24563 for ; Wed, 29 May 2002 11:58:53 -0400 (EDT) From: "Dr. Subrata Goswami" Cc: Subject: RE: [mobile-ip] Issue #23 and Issue #30 Date: Wed, 29 May 2002 09:02:45 -0700 Message-ID: <000201c2072a$460e0520$6701a8c0@SGOSWAMIPCL> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <4DA6EA82906FD511BE2F00508BCF0538044F06AB@Esealnt861.al.sw.ericsson.se> Importance: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit If a mobile doing RFC 3041 changes its IID (say after rebooting for some reason) in a foreign network it has to do the following. 1. Forms a new link-local address based on the new IID. 2. Sends a BU to the HA with the new IID (is there an option for this ?). 3. The HA realizes that the IID has changed (security implications ?). 4. The HA starts defending the new link-local address. It would be simple if the requirement to defend the l-l address is dropped. Moreover, a stateful (DHCP based) assignment of a HoA would not use the IID anyway. Subrata -----Original Message----- From: owner-mobile-ip@sunroof.eng.sun.com [mailto:owner-mobile-ip@sunroof.eng.sun.com] On Behalf Of Hesham Soliman (ERA) Sent: Wednesday, May 29, 2002 4:20 AM To: 'Charles E. Perkins'; Dr. Subrata Goswami Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Issue #23 and Issue #30 > I should clarify: My expectation is that the home agent should > ONLY defend the mobile node's link-local address, not its other > addresses. Then, by implication, the other addresses will be > unavailable to nodes on the link because they can't form the > link-local address to start with. > => I think the HA must defend all addresses, including the link-local one. This is related to RFC3041 and Francis' discussion on the IPv6 list. A node implementing RFC 3041 might form a global address that belongs to one of the other MN's Home addresses. Hence, if the HA does not defend all addresses, a MN might 'lose' one of its home addresses to another node on the home link. Hesham From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 12:04:09 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22518 for ; Wed, 29 May 2002 12:04:08 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03147; Wed, 29 May 2002 10:04:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15872; Wed, 29 May 2002 09:03:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TG3IrP028585 for ; Wed, 29 May 2002 09:03:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TG3HrB028584 for mobile-ip-dist; Wed, 29 May 2002 09:03:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TG3ErP028577 for ; Wed, 29 May 2002 09:03:14 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15493 for ; Wed, 29 May 2002 09:03:19 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03001 for ; Wed, 29 May 2002 10:04:16 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4TG3IZ26316; Wed, 29 May 2002 11:03:18 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 11:03:07 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D2403FA224F@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Tony Johansson , Fredrik Johansson , MobileIP Cc: Charlie Perkins , Phil Roberts , Basavaraj Patil , Kevin Purser , Johan Johansson , "Jayshree Bharatia" Subject: RE: [mobile-ip] Re: Address to use in the SA between FA-HA Date: Wed, 29 May 2002 11:03:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2072A.513A95D0" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2072A.513A95D0 Content-Type: text/plain; charset="iso-8859-1" Hello Tony, This may have a minor impact on 3GPP2, because we use RADIUS for Mobile IPv4 support. The FA-HA security key calculation includes the "FA IP address", however the definition of the "FA IP address" is not clear in the current 3GPP2 standard. Although I don't anticipate any major problem, I have started a discussion thread in 3GPP2 and I will let you know ASAP. Regards, Kuntal > -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Tuesday, May 28, 2002 6:06 PM > To: Fredrik Johansson; MobileIP > Cc: Charlie Perkins; Phil Roberts; Basavaraj Patil; Kevin > Purser; Johan > Johansson > Subject: [mobile-ip] Re: Address to use in the SA between FA-HA > > > All, > > I agree with Fredrik. Thus, always use the CoA. > > I haven't seen any objection to this, so can I assume that this is the > consensus? If no objections / comments I will assume that > this is the case and > don't make any changes regarding this to the Diameter MIPv4 > application draft. > > Regards, > > /Tony > > Fredrik Johansson wrote: > > > Hi, > > > > RFC 3220 doesn't define which address to use when creating > the SA between > > the FA and HA. I have always assumed that it was the > care-of-address in the > > registration request header, but considering the case when a mobile > > registers with an FA just because it has set the 'R'-bit in its > > advertisement. The rfc doesn't say which Ip address to use > in this case, the > > CoA or the source address of the incoming reguest. > > > > This will cause interoperability problems within mobile ip > itself, and also > > affects other protocols such as Diameter. The best would be > to always use > > the CoA since the incoming request may not always have a > source address > > (e.g. when coming via a Diameter Request). > > > > /Fredrik > > ------_=_NextPart_001_01C2072A.513A95D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: Address to use in the SA between = FA-HA

Hello Tony,
This may have a minor impact on 3GPP2, because we = use RADIUS for Mobile IPv4 support. The FA-HA security key calculation = includes the "FA IP address", however the definition of the = "FA IP address" is not clear in the current 3GPP2 standard. = Although I don't anticipate any major problem, I have started a = discussion thread in 3GPP2 and I will let you know ASAP.

Regards,
Kuntal


> -----Original Message-----
> From: Tony Johansson [mailto:tony.johansson@ericss= on.com]
> Sent: Tuesday, May 28, 2002 6:06 PM
> To: Fredrik Johansson; MobileIP
> Cc: Charlie Perkins; Phil Roberts; Basavaraj = Patil; Kevin
> Purser; Johan
> Johansson
> Subject: [mobile-ip] Re: Address to use in the = SA between FA-HA
>
>
> All,
>
> I agree with Fredrik. Thus, always use the = CoA.
>
> I haven't seen any objection to this, so can I = assume that this is the
> consensus? If no objections / comments I will = assume that
> this is the case and
> don't make any changes regarding this to the = Diameter MIPv4
> application draft.
>
> Regards,
>
> /Tony
>
> Fredrik Johansson wrote:
>
> > Hi,
> >
> > RFC 3220 doesn't define which address to = use when creating
> the SA between
> > the FA and HA. I have always assumed that = it was the
> care-of-address in the
> > registration request header, but = considering the case when a mobile
> > registers with an FA just because it has = set the 'R'-bit in its
> > advertisement. The rfc doesn't say which = Ip address to use
> in this case, the
> > CoA or the source address of the incoming = reguest.
> >
> > This will cause interoperability problems = within mobile ip
> itself, and also
> > affects other protocols such as Diameter. = The best would be
> to always use
> > the CoA since the incoming request may not = always have a
> source address
> > (e.g. when coming via a Diameter = Request).
> >
> > /Fredrik
>
>

------_=_NextPart_001_01C2072A.513A95D0-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 12:44:28 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24100 for ; Wed, 29 May 2002 12:44:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00930; Wed, 29 May 2002 10:44:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02541; Wed, 29 May 2002 09:44:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TGhZrP028746 for ; Wed, 29 May 2002 09:43:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TGhZ9o028745 for mobile-ip-dist; Wed, 29 May 2002 09:43:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TGhWrP028738 for ; Wed, 29 May 2002 09:43:32 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA02024 for ; Wed, 29 May 2002 09:43:37 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16293 for ; Wed, 29 May 2002 09:43:36 -0700 (PDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2CACD454F; Wed, 29 May 2002 12:43:36 -0400 (EDT) Received: from anw.zk3.dec.com (anw4.zk3.dec.com [16.140.48.4]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 89E811322; Wed, 29 May 2002 09:43:34 -0700 (PDT) Received: from hp.com by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id MAA0002388956; Wed, 29 May 2002 12:43:32 -0400 (EDT) Message-ID: <3CF50534.7070101@hp.com> Date: Wed, 29 May 2002 12:43:32 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Charles E. Perkins" , Francis Dupont , jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> <3CED6015.E7A39399@iprg.nokia.com> <3CEE90C2.7010903@hp.com> <3CEEA376.FEB49067@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Vijay, hopefully you'll get this... we are vhaving e-mail problems...] Vijay Devarapalli wrote: > > great, that you agree the link local address needs to be defended. That's what it looks like. ;) > > >>If the mobile is inactive when it returns home (and the binding was >>not deleted for whatever reason) the problem is bigger. > > > it might help if we can know why the binding still exists. the only > reason I can think of is, the binding lifetime was more than the > period during which the MN was inactive. this might be an extreme > case (?). Hmm. Multiple cases: 1. Mobile did not shutdown gracefully. 2. Mobile lost the interface before shuttding down. 3. Packet was lost. ... (i.e. I can't think of any more right now, but you get the poin?) these are just some of the reason. -vlad +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 12:50:39 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24346 for ; Wed, 29 May 2002 12:50:38 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05296; Wed, 29 May 2002 10:50:50 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06026; Wed, 29 May 2002 09:50:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TGnorP028823 for ; Wed, 29 May 2002 09:49:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TGnnah028822 for mobile-ip-dist; Wed, 29 May 2002 09:49:49 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TGnkrP028815 for ; Wed, 29 May 2002 09:49:46 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05441 for ; Wed, 29 May 2002 09:49:51 -0700 (PDT) Received: from fep03-svc.swip.net (fep03.swip.net [130.244.199.131]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04572 for ; Wed, 29 May 2002 10:49:50 -0600 (MDT) Received: from ipunplugged.com ([213.100.60.194]) by fep03-svc.swip.net with ESMTP id <20020529164949.IAWZ12461.fep03-svc.swip.net@ipunplugged.com>; Wed, 29 May 2002 18:49:49 +0200 Message-ID: <3CF50720.10906@ipunplugged.com> Date: Wed, 29 May 2002 18:51:44 +0200 From: Johan Johansson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MobileIP CC: Kuntal Chowdhury , Tony Johansson , Fredrik Johansson , Charlie Perkins , Phil Roberts , Basavaraj Patil , Kevin Purser , Jayshree Bharatia Subject: Re: [mobile-ip] Re: Address to use in the SA between FA-HA References: <23BDB0046F3ED51185CD0002A5608D2403FA224F@zrc2c009.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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit All, Please note that this is an issue neither with RADIUS nor with Diameter but with MobileIP itself. I find it puzzling that nobody from the core MobileIP community has voiced an opinon in the matter since surely this must be resolved for any two implementations to be able to communicate under several possible scenarios, including the scenario Fredrik described and a NATed FA with a separate control traffic interface. Discussions by the 3GPP2 wg is certainly interesting but as far as I can tell, and *do please* tell me if I am wrong, the MobileIP standard still needs to be fixed. j Kuntal Chowdhury wrote: > Hello Tony, > This may have a minor impact on 3GPP2, because we use RADIUS for > Mobile IPv4 support. The FA-HA security key calculation includes the > "FA IP address", however the definition of the "FA IP address" is not > clear in the current 3GPP2 standard. Although I don't anticipate any > major problem, I have started a discussion thread in 3GPP2 and I will > let you know ASAP. > > Regards, > Kuntal > > > > -----Original Message----- > > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > > Sent: Tuesday, May 28, 2002 6:06 PM > > To: Fredrik Johansson; MobileIP > > Cc: Charlie Perkins; Phil Roberts; Basavaraj Patil; Kevin > > Purser; Johan > > Johansson > > Subject: [mobile-ip] Re: Address to use in the SA between FA-HA > > > > > > All, > > > > I agree with Fredrik. Thus, always use the CoA. > > > > I haven't seen any objection to this, so can I assume that this is the > > consensus? If no objections / comments I will assume that > > this is the case and > > don't make any changes regarding this to the Diameter MIPv4 > > application draft. > > > > Regards, > > > > /Tony > > > > Fredrik Johansson wrote: > > > > > Hi, > > > > > > RFC 3220 doesn't define which address to use when creating > > the SA between > > > the FA and HA. I have always assumed that it was the > > care-of-address in the > > > registration request header, but considering the case when a mobile > > > registers with an FA just because it has set the 'R'-bit in its > > > advertisement. The rfc doesn't say which Ip address to use > > in this case, the > > > CoA or the source address of the incoming reguest. > > > > > > This will cause interoperability problems within mobile ip > > itself, and also > > > affects other protocols such as Diameter. The best would be > > to always use > > > the CoA since the incoming request may not always have a > > source address > > > (e.g. when coming via a Diameter Request). > > > > > > /Fredrik > > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 12:55:53 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24580 for ; Wed, 29 May 2002 12:55:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08072; Wed, 29 May 2002 10:56:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07829; Wed, 29 May 2002 09:55:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TGsPrP028904 for ; Wed, 29 May 2002 09:54:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TGsPP4028903 for mobile-ip-dist; Wed, 29 May 2002 09:54:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TGsMrP028896 for ; Wed, 29 May 2002 09:54:22 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08285 for ; Wed, 29 May 2002 09:54:27 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA07697 for ; Wed, 29 May 2002 10:54:27 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 6F9D7416D; Wed, 29 May 2002 11:54:26 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 58568DAB; Wed, 29 May 2002 09:54:25 -0700 (PDT) Received: from hp.com by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id MAA0000894242; Wed, 29 May 2002 12:54:24 -0400 (EDT) Message-ID: <3CF507C0.7010602@hp.com> Date: Wed, 29 May 2002 12:54:24 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Perkins Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> <3CED6015.E7A39399@iprg.nokia.com> <3CEE90C2.7010903@hp.com> <3CEFC4CB.92A5D2B1@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie Charlie Perkins wrote: > Hello Vlad, > > I think the home agent MUST proxy for the mobile node's > link address while the mobile node has a valid binding. > I think the home agent should stop defending the link-local > address when the binding expires. I also think the home agent > should accept packets with source address == mobile's > home address as long as they are addressed to the home agent. > Why not? We seem to agree on this point. > > Vladislav Yasevich wrote: > >>If the mobile is inactive when it returns home (and the binding was >>not deleted for whatever reason) the problem is bigger. >>The MN will try to configure the link-local address as part of >>standard IPv6 initialization (it has no idea it's home yet because it >>doesn't have an interface up yet, so it hasn't seen an RA to tell it >>that it's home), but will fail because the HA will defend the link-local >>address. > > > I don't think the HA should do this. Why not. The HA has a valid binding and has recieve a NS packet in DAD format for the link-local address HA is proxying for. Why shouldn't the HA reply? > > >>A possible workaround (a big hack :) to this is once DAD fails, the MN >>can try to un-register with the HA using the following procedure: >> 1. Send a RS to all-routers multicast from the :: address. >> 2. Wait for the RA with the H bit set. >> * for this to work the RA must contain the "Link Address" option. >> this will create a stale cache entry on MN >> 3. Send the unregistration using the :: address with the HOA listing >> the last known home address (that the mobile usually stores). > > > In this situation, the mobile node SHOULD know its home address. > Otherwise, how could it tell if it is at home? It has to know something. > And then it could send the Binding Update to the home agent > directly (with lifetime zero). I thought that the mobile always knows it's home address. I must at least know it's home prefix for Dynamic HA Discovery and forming an address from that is easy (assuming addrconf). To send the BU to the home agent, it needs the link-level address. The way to get that address is either through NS/NA exchange or from the RA. We can't do the NS/NA exchange since DAD on the link-local address failed and we don't have any other ones yet. So we need the RA. > > >>As I said, this is a big hack. I don't know what the security implications >>are and if IPSec can be used to verify this, so I leave that to someone who >>knows more about IPSec and security. > > > Maybe we could make a special case for when the home agent > receives a Router Solitication (on link!) with the source address > == the mobile node's home address. Well, we don't really care what the source address is for the RS. The unspecified address (::) will trigger a multicast RA which is all we want right now. > > But the mobile node SHOULD NOT forget the home agent's > layer-2 address (assuming it needs it for framing). It can't do that. This address will change every time you change a NIC or change the default HA. -vlad +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 13:03:04 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24943 for ; Wed, 29 May 2002 13:03:03 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16824; Wed, 29 May 2002 11:03:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10613; Wed, 29 May 2002 10:03:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TH2ArP028998 for ; Wed, 29 May 2002 10:02:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TH2AkP028997 for mobile-ip-dist; Wed, 29 May 2002 10:02:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TH26rP028990 for ; Wed, 29 May 2002 10:02:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10363 for ; Wed, 29 May 2002 10:02:10 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26625 for ; Wed, 29 May 2002 11:02:10 -0600 (MDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g4TH1hi03769; Wed, 29 May 2002 12:01:43 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g4TH1hY17074; Wed, 29 May 2002 12:01:43 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA21617; Wed, 29 May 2002 12:01:43 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA06121; Wed, 29 May 2002 12:01:41 -0500 (CDT) Message-ID: <3CF50899.231B90FC@ericsson.com> Date: Wed, 29 May 2002 09:58:01 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Kuntal Chowdhury CC: Fredrik Johansson , MobileIP , Charlie Perkins , Phil Roberts , Basavaraj Patil , Kevin Purser , Johan Johansson , Jayshree Bharatia Subject: Re: [mobile-ip] Re: Address to use in the SA between FA-HA References: <23BDB0046F3ED51185CD0002A5608D2403FA224F@zrc2c009.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Kuntal, I'm sorry if I confused you. The issue is how the 'R'-bit text description in RFC3220 should be interpreted, see Fredrik's description below and the previous mail thread regarding the 'R'-bit... Regards, /Tony Kuntal Chowdhury wrote: > > > Hello Tony, > This may have a minor impact on 3GPP2, because we use RADIUS for > Mobile IPv4 support. The FA-HA security key calculation includes the > "FA IP address", however the definition of the "FA IP address" is not > clear in the current 3GPP2 standard. Although I don't anticipate any > major problem, I have started a discussion thread in 3GPP2 and I will > let you know ASAP. > > Regards, > Kuntal > > > -----Original Message----- > > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > > Sent: Tuesday, May 28, 2002 6:06 PM > > To: Fredrik Johansson; MobileIP > > Cc: Charlie Perkins; Phil Roberts; Basavaraj Patil; Kevin > > Purser; Johan > > Johansson > > Subject: [mobile-ip] Re: Address to use in the SA between FA-HA > > > > > > All, > > > > I agree with Fredrik. Thus, always use the CoA. > > > > I haven't seen any objection to this, so can I assume that this is > the > > consensus? If no objections / comments I will assume that > > this is the case and > > don't make any changes regarding this to the Diameter MIPv4 > > application draft. > > > > Regards, > > > > /Tony > > > > Fredrik Johansson wrote: > > > > > Hi, > > > > > > RFC 3220 doesn't define which address to use when creating > > the SA between > > > the FA and HA. I have always assumed that it was the > > care-of-address in the > > > registration request header, but considering the case when a > mobile > > > registers with an FA just because it has set the 'R'-bit in its > > > advertisement. The rfc doesn't say which Ip address to use > > in this case, the > > > CoA or the source address of the incoming reguest. > > > > > > This will cause interoperability problems within mobile ip > > itself, and also > > > affects other protocols such as Diameter. The best would be > > to always use > > > the CoA since the incoming request may not always have a > > source address > > > (e.g. when coming via a Diameter Request). > > > > > > /Fredrik > > > > From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 13:06:47 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25093 for ; Wed, 29 May 2002 13:06:47 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19074; Wed, 29 May 2002 11:06:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12542; Wed, 29 May 2002 10:06:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TH5XrP029085 for ; Wed, 29 May 2002 10:05:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TH5WQf029084 for mobile-ip-dist; Wed, 29 May 2002 10:05:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TH5TrP029077 for ; Wed, 29 May 2002 10:05:29 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12143 for ; Wed, 29 May 2002 10:05:34 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15469 for ; Wed, 29 May 2002 11:05:34 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id C0FA7302D; Wed, 29 May 2002 10:13:14 -0700 (PDT) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id E4C7D1016; Wed, 29 May 2002 12:05:32 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id NAA0001483511; Wed, 29 May 2002 13:05:31 -0400 (EDT) Message-ID: <3CF50A5B.6050006@hp.com> Date: Wed, 29 May 2002 13:05:31 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:0.9.9) Gecko/20020318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles E. Perkins" Cc: Brian Haley , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> <3CED6015.E7A39399@iprg.nokia.com> <3CEE90C2.7010903@hp.com> <3CEFC4CB.92A5D2B1@iprg.nokia.com> <3CF3AC7D.2FC34D79@hp.com> <3CF3C98E.74548D2@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie I'll coment only on your assumptions since Brian already addresses your comments. Charles E. Perkins wrote: > Hello Brian, > > My model may be different than yours. > > My assumptions: > 1) The mobile node owns its home address until the lifetime expires. > 2) The home agent proxies for the mobile's home address while > it has a valid binding. > 3) The mobile node knows how long the home address is valid. > 4) The mobile node does not have to reconfigure its home address > if it's valid (its lifetime has not expired). > 5) The home agent defends the mobile node's link-local address > while the mobile node is away from home. These assumptions are correct; however, you are making an assumption that the valid and prefered timers on the home address continue ticking even when the mobile is powered off. When the mobile comes up, it has no idea how long it's home address would be considered valid. It generally knows a home prefix, but it uses the timer values from RAs to set the time-outs. It might be able to figure out (and store in NV ram) the approximate time when the prefix whould expire and then compare that time to current to see if the address whould have still been valid. However that assumes that a clock on the mobile whould be somewhat accurate. As you can see, that's a lot of assumptions to make. ;) -vlad +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 13:37:43 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26127 for ; Wed, 29 May 2002 13:37:42 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08562; Wed, 29 May 2002 10:37:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25682; Wed, 29 May 2002 10:37:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4THa8rP029210 for ; Wed, 29 May 2002 10:36:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4THa81H029209 for mobile-ip-dist; Wed, 29 May 2002 10:36:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4THa3rP029202 for ; Wed, 29 May 2002 10:36:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28746 for ; Wed, 29 May 2002 10:36:06 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13880 for ; Wed, 29 May 2002 11:36:03 -0600 (MDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g4THZjl13451; Wed, 29 May 2002 12:35:45 -0500 (CDT) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g4THZj921782; Wed, 29 May 2002 12:35:45 -0500 (CDT) Received: from qpop.exu.ericsson.se (qpop [138.85.75.72]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA22907; Wed, 29 May 2002 12:35:44 -0500 (CDT) Received: from ericsson.com ([138.85.159.114]) by qpop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA06637; Wed, 29 May 2002 12:35:43 -0500 (CDT) Message-ID: <3CF51093.18C53136@ericsson.com> Date: Wed, 29 May 2002 10:32:03 -0700 From: Tony Johansson X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Johan Johansson CC: MobileIP , Kuntal Chowdhury , Fredrik Johansson , Charlie Perkins , Phil Roberts , Basavaraj Patil , Kevin Purser , Jayshree Bharatia Subject: Re: [mobile-ip] Re: Address to use in the SA between FA-HA References: <23BDB0046F3ED51185CD0002A5608D2403FA224F@zrc2c009.us.nortel.com> <3CF50720.10906@ipunplugged.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Johan, Johan Johansson wrote: > All, > > Please note that this is an issue neither with RADIUS nor with Diameter > but with MobileIP itself. I agree. However, depending on how the 'R'-bit should be interpreted in RFC3220 it may cause additional functionality to Diameter and RADIUS as previously mentioned. So, we really need to get some consensus on this thread asap. Regards, /Tony From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 14:43:44 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28331 for ; Wed, 29 May 2002 14:43:43 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18538; Wed, 29 May 2002 11:42:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21652; Wed, 29 May 2002 11:42:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TIfVrP029344 for ; Wed, 29 May 2002 11:41:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TIfVjr029343 for mobile-ip-dist; Wed, 29 May 2002 11:41:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TIfSrP029336 for ; Wed, 29 May 2002 11:41:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28695 for ; Wed, 29 May 2002 11:41:32 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA16055 for ; Wed, 29 May 2002 12:41:30 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4TIfYZ10062; Wed, 29 May 2002 13:41:34 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 29 May 2002 13:41:23 -0500 Message-ID: <23BDB0046F3ED51185CD0002A5608D2403FA271A@zrc2c009.us.nortel.com> From: "Kuntal Chowdhury" To: Tony Johansson Cc: Fredrik Johansson , MobileIP , Charlie Perkins , Phil Roberts , Basavaraj Patil , Kevin Purser , Johan Johansson , "Jayshree Bharatia" Subject: RE: [mobile-ip] Re: Address to use in the SA between FA-HA Date: Wed, 29 May 2002 13:41:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20740.6BDECC60" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20740.6BDECC60 Content-Type: text/plain; charset="iso-8859-1" Hello Tony, I don't anticipate any objection to using FA-CoA for FA-HA SA. However, that may require 3GPP2 to do some text editing in the current standard (NAS-IPv4 attribute in the RADIUS Access-Request = FA-CoA). I will keep you informed about the outcome of 3GPP2 discussion if necessary. Regards, Kuntal > -----Original Message----- > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > Sent: Wednesday, May 29, 2002 11:58 AM > To: Chowdhury, Kuntal [RICH1:2H18:EXCH] > Cc: Fredrik Johansson; MobileIP; Charlie Perkins; Phil Roberts; > Basavaraj Patil; Kevin Purser; Johan Johansson; Bharatia, Jayshree > [RICH1:2H13:EXCH] > Subject: Re: [mobile-ip] Re: Address to use in the SA between FA-HA > > > Hello Kuntal, > > I'm sorry if I confused you. The issue is how the 'R'-bit text > description in RFC3220 should be interpreted, see Fredrik's > description > below and the previous mail thread regarding the 'R'-bit... > > Regards, > > /Tony > > Kuntal Chowdhury wrote: > > > > > > > Hello Tony, > > This may have a minor impact on 3GPP2, because we use RADIUS for > > Mobile IPv4 support. The FA-HA security key calculation includes the > > "FA IP address", however the definition of the "FA IP > address" is not > > clear in the current 3GPP2 standard. Although I don't anticipate any > > major problem, I have started a discussion thread in 3GPP2 > and I will > > let you know ASAP. > > > > Regards, > > Kuntal > > > > > -----Original Message----- > > > From: Tony Johansson [mailto:tony.johansson@ericsson.com] > > > Sent: Tuesday, May 28, 2002 6:06 PM > > > To: Fredrik Johansson; MobileIP > > > Cc: Charlie Perkins; Phil Roberts; Basavaraj Patil; Kevin > > > Purser; Johan > > > Johansson > > > Subject: [mobile-ip] Re: Address to use in the SA between FA-HA > > > > > > > > > All, > > > > > > I agree with Fredrik. Thus, always use the CoA. > > > > > > I haven't seen any objection to this, so can I assume that this is > > the > > > consensus? If no objections / comments I will assume that > > > this is the case and > > > don't make any changes regarding this to the Diameter MIPv4 > > > application draft. > > > > > > Regards, > > > > > > /Tony > > > > > > Fredrik Johansson wrote: > > > > > > > Hi, > > > > > > > > RFC 3220 doesn't define which address to use when creating > > > the SA between > > > > the FA and HA. I have always assumed that it was the > > > care-of-address in the > > > > registration request header, but considering the case when a > > mobile > > > > registers with an FA just because it has set the 'R'-bit in its > > > > advertisement. The rfc doesn't say which Ip address to use > > > in this case, the > > > > CoA or the source address of the incoming reguest. > > > > > > > > This will cause interoperability problems within mobile ip > > > itself, and also > > > > affects other protocols such as Diameter. The best would be > > > to always use > > > > the CoA since the incoming request may not always have a > > > source address > > > > (e.g. when coming via a Diameter Request). > > > > > > > > /Fredrik > > > > > > > > ------_=_NextPart_001_01C20740.6BDECC60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: Address to use in the SA between = FA-HA

Hello Tony,
I don't anticipate any objection to using FA-CoA for = FA-HA SA. However, that may require 3GPP2 to do some text editing in = the current standard (NAS-IPv4 attribute in the RADIUS Access-Request = =3D FA-CoA). I will keep you informed about the outcome of 3GPP2 = discussion if necessary.

Regards,
Kuntal


> -----Original Message-----
> From: Tony Johansson [mailto:tony.johansson@ericss= on.com]
> Sent: Wednesday, May 29, 2002 11:58 AM
> To: Chowdhury, Kuntal [RICH1:2H18:EXCH]
> Cc: Fredrik Johansson; MobileIP; Charlie = Perkins; Phil Roberts;
> Basavaraj Patil; Kevin Purser; Johan Johansson; = Bharatia, Jayshree
> [RICH1:2H13:EXCH]
> Subject: Re: [mobile-ip] Re: Address to use in = the SA between FA-HA
>
>
> Hello Kuntal,
>
> I'm sorry if I confused you. The issue is how = the 'R'-bit text
> description in RFC3220 should be interpreted, = see Fredrik's
> description
> below and the previous mail thread regarding = the 'R'-bit...
>
> Regards,
>
> /Tony
>
> Kuntal Chowdhury wrote:
>
> >
> >
> > Hello Tony,
> > This may have a minor impact on 3GPP2, = because we use RADIUS for
> > Mobile IPv4 support. The FA-HA security = key calculation includes the
> > "FA IP address", however the = definition of the "FA IP
> address" is not
> > clear in the current 3GPP2 standard. = Although I don't anticipate any
> > major problem, I have started a discussion = thread in 3GPP2
> and I will
> > let you know ASAP.
> >
> > Regards,
> > Kuntal
> >
> > > -----Original Message-----
> > > From: Tony Johansson [mailto:tony.johansson@ericss= on.com]
> > > Sent: Tuesday, May 28, 2002 6:06 = PM
> > > To: Fredrik Johansson; = MobileIP
> > > Cc: Charlie Perkins; Phil Roberts; = Basavaraj Patil; Kevin
> > > Purser; Johan
> > > Johansson
> > > Subject: [mobile-ip] Re: Address to = use in the SA between FA-HA
> > >
> > >
> > > All,
> > >
> > > I agree with Fredrik. Thus, always = use the CoA.
> > >
> > > I haven't seen any objection to this, = so can I assume that this is
> > the
> > > consensus? If no objections / = comments I will assume that
> > > this is the case and
> > > don't make any changes regarding this = to the Diameter MIPv4
> > > application draft.
> > >
> > > Regards,
> > >
> > > /Tony
> > >
> > > Fredrik Johansson wrote:
> > >
> > > > Hi,
> > > >
> > > > RFC 3220 doesn't define which = address to use when creating
> > > the SA between
> > > > the FA and HA. I have always = assumed that it was the
> > > care-of-address in the
> > > > registration request header, but = considering the case when a
> > mobile
> > > > registers with an FA just = because it has set the 'R'-bit in its
> > > > advertisement. The rfc doesn't = say which Ip address to use
> > > in this case, the
> > > > CoA or the source address of the = incoming reguest.
> > > >
> > > > This will cause interoperability = problems within mobile ip
> > > itself, and also
> > > > affects other protocols such as = Diameter. The best would be
> > > to always use
> > > > the CoA since the incoming = request may not always have a
> > > source address
> > > > (e.g. when coming via a Diameter = Request).
> > > >
> > > > /Fredrik
> > >
> > >
>
>

------_=_NextPart_001_01C20740.6BDECC60-- From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 15:06:30 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29335 for ; Wed, 29 May 2002 15:06:30 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26959; Wed, 29 May 2002 13:06:41 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10234; Wed, 29 May 2002 12:06:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TJ5erP029436 for ; Wed, 29 May 2002 12:05:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TJ5esw029435 for mobile-ip-dist; Wed, 29 May 2002 12:05:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TJ5arP029428 for ; Wed, 29 May 2002 12:05:36 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07403 for ; Wed, 29 May 2002 12:05:41 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA26290 for ; Wed, 29 May 2002 13:05:40 -0600 (MDT) Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LQF6733Z; Wed, 29 May 2002 15:05:38 -0400 Message-ID: <007901c20743$d0cffc90$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" , Cc: "MobileIP" Subject: [mobile-ip] Question on RFC 3220 - Agent Advertisement messages in Manets Date: Wed, 29 May 2002 15:05:36 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie, Suppose one wishes to use MIP with a MANET. Futhermore, suppose one performs an agent advertisement solicitation. This will normally result in a specially formatted route advertisment which would work fine provided you had an actual subnet! In the case of a mesh or MANET with no local topologically correct prefixing the only solution is to have all nodes flood these advertisements over the entire MANET network right? Yuck! Why couldn't the Agent Advertisement be optionally unicast back to the solicitor MN. Thanks, Phil -- Phillip D. Neumiller (pneumiller@meshnetworks.com) My PGP key can be imported from the following URL: http://pgpkeys.mit.edu From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 15:20:06 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29818 for ; Wed, 29 May 2002 15:20:05 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02359; Wed, 29 May 2002 13:21:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16347; Wed, 29 May 2002 12:20:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TJJBrP029515 for ; Wed, 29 May 2002 12:19:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TJJB04029514 for mobile-ip-dist; Wed, 29 May 2002 12:19:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TJJ7rP029507 for ; Wed, 29 May 2002 12:19:07 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12400 for ; Wed, 29 May 2002 12:19:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09960 for ; Wed, 29 May 2002 12:19:11 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA18374; Wed, 29 May 2002 12:19:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4TJJAr17305; Wed, 29 May 2002 12:19:10 -0700 X-mProtect: <200205291919> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBsMwux; Wed, 29 May 2002 12:19:08 PDT Message-ID: <3CF529AC.BB84FD3E@iprg.nokia.com> Date: Wed, 29 May 2002 12:19:08 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> <3CED6015.E7A39399@iprg.nokia.com> <3CEE90C2.7010903@hp.com> <3CEFC4CB.92A5D2B1@iprg.nokia.com> <3CF3AC7D.2FC34D79@hp.com> <3CF3C98E.74548D2@iprg.nokia.com> <3CF50A5B.6050006@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Vlad, Vladislav Yasevich wrote: > These assumptions are correct; however, you are making an assumption > that the valid and prefered timers on the home address continue ticking > even when the mobile is powered off. When the mobile comes up, it has > no idea how long it's home address would be considered valid. > It generally knows a home prefix, but it uses the timer values from > RAs to set the time-outs. > > It might be able to figure out (and store in NV ram) the approximate > time when the prefix whould expire and then compare that time to current > to see if the address whould have still been valid. However that assumes > that a clock on the mobile whould be somewhat accurate. If the mobile device is turned off, and remembers its home address, but forgets the lifetime information, or has screwed up its clock, then I agree it has to run through the whole rigamarole again. I'd like to suggest that we first get a solution to the problem for devices that are not so forgetful, and then see what steps need to be taken for the more amnesiac devices. I would very much hope to avoid making trouble for the devices that have better memories. For the amnesiac devices, maybe the simplest thing to do it to let DAD fail for the link-local address, since the home agent is defending it. Then, the amnesiac mobile node can get another address. If it wants to reclaim its former address, it can do so by deregistering the previous care-of address. I'm not so clear on how an amnesiac device can forget everything, but still remember its security parameters with the home agent, and still remember its previous care-of address, but on the other hand I don't think this is the common case. For truly amnesiac devices, using a new home address should be O.K. For devices that remember their DNS name, and thus might need a stable resolution, I reckon they can remember enough other stuff to make the simpler method work. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 15:29:39 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00201 for ; Wed, 29 May 2002 15:29:38 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15512; Wed, 29 May 2002 12:29:15 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20670; Wed, 29 May 2002 12:29:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TJSPrP029609 for ; Wed, 29 May 2002 12:28:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TJSP26029608 for mobile-ip-dist; Wed, 29 May 2002 12:28:25 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TJSLrP029601 for ; Wed, 29 May 2002 12:28:22 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15402 for ; Wed, 29 May 2002 12:28:26 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23187 for ; Wed, 29 May 2002 12:28:26 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA18785; Wed, 29 May 2002 12:28:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4TJSPs28509; Wed, 29 May 2002 12:28:25 -0700 X-mProtect: <200205291928> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd54hE8U; Wed, 29 May 2002 12:28:22 PDT Message-ID: <3CF52BD6.4556561B@iprg.nokia.com> Date: Wed, 29 May 2002 12:28:22 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> <3CED6015.E7A39399@iprg.nokia.com> <3CEE90C2.7010903@hp.com> <3CEFC4CB.92A5D2B1@iprg.nokia.com> <3CF507C0.7010602@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Vlad, Vladislav Yasevich wrote: > >>If the mobile is inactive when it returns home (and the binding was > >>not deleted for whatever reason) the problem is bigger. > >>The MN will try to configure the link-local address as part of > >>standard IPv6 initialization (it has no idea it's home yet because it > >>doesn't have an interface up yet, so it hasn't seen an RA to tell it > >>that it's home), but will fail because the HA will defend the link-local > >>address. > > > > > > I don't think the HA should do this. > > Why not. The HA has a valid binding and has recieve a NS packet in DAD > format for the link-local address HA is proxying for. Why shouldn't the HA > reply? Yes, I agree that the HA would defend the link-local address. I can't remember just now what I meant by the above; I must have been thinking that "I don't think the home agent should have to do this", meaning that we should try to avoid the problem if possible. It would be nice if the mobile node would remember its link-local address and use the information to send a Binding Update to the home agent. If the mobile node tries and fails to configure the link-local address, it can inspect the packet informing it of failure and surmise that it is at home. It can then attempt to send the deregistration packet to the home agent. Nothing to lose, right? And, much to gain. > I thought that the mobile always knows it's home address. I must at least > know it's home prefix for Dynamic HA Discovery and forming an address from > that is easy (assuming addrconf). And, it has to remember its security assocation with the home agent, presumably. > To send the BU to the home agent, it needs the link-level address. The > way to get that address is either through NS/NA exchange or from the RA. Or from just remembering it, exactly as it remembers the home address. > We can't do the NS/NA exchange since DAD on the link-local address failed > and we don't have any other ones yet. So we need the RA. This is debatable, but still if the home agent sends the Router Advertisement, there is a way for the mobile node to make progress, just by finally sending the deregistration. > > But the mobile node SHOULD NOT forget the home agent's > > layer-2 address (assuming it needs it for framing). > > It can't do that. This address will change every time you change a NIC or > change the default HA. Those are infrequent events, which can be handled by more cumbersome methods. The frequent case should be quite streamlined. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 16:02:30 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01458 for ; Wed, 29 May 2002 16:02:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13609; Wed, 29 May 2002 13:02:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19894; Wed, 29 May 2002 13:01:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TK0OrP029719 for ; Wed, 29 May 2002 13:00:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TK0Oqn029718 for mobile-ip-dist; Wed, 29 May 2002 13:00:24 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TK0LrP029711 for ; Wed, 29 May 2002 13:00:21 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27928 for ; Wed, 29 May 2002 13:00:26 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05574 for ; Wed, 29 May 2002 13:00:25 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA19948; Wed, 29 May 2002 13:00:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4TK0OL31950; Wed, 29 May 2002 13:00:24 -0700 X-mProtect: <200205292000> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdLgtNvj; Wed, 29 May 2002 13:00:21 PDT Message-ID: <3CF53356.59486448@iprg.nokia.com> Date: Wed, 29 May 2002 13:00:22 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: "Charles E. Perkins" , Francis Dupont , jari.arkko@piuha.net, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> <3CED6015.E7A39399@iprg.nokia.com> <3CEE90C2.7010903@hp.com> <3CEEA376.FEB49067@iprg.nokia.com> <3CF50534.7070101@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vladislav Yasevich wrote: > Hmm. Multiple cases: > 1. Mobile did not shutdown gracefully. > 2. Mobile lost the interface before shuttding down. is your binding update list on the interface data structure?? > 3. Packet was lost. didnt the mobile realise that it did not get the binding ack back. > ... (i.e. I can't think of any more right now, but you get the poin?) come on.. this is ridiculous. you want to build a 99.999% reliable protocol?? looks like everybody wants to make a point when it comes to MIPv6. please lets move on...... Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 16:25:12 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02051 for ; Wed, 29 May 2002 16:25:11 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19391; Wed, 29 May 2002 13:24:47 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28308; Wed, 29 May 2002 13:24:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TKNbrP029809 for ; Wed, 29 May 2002 13:23:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TKNbiH029808 for mobile-ip-dist; Wed, 29 May 2002 13:23:37 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TKNYrP029801 for ; Wed, 29 May 2002 13:23:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06524 for ; Wed, 29 May 2002 13:23:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05844 for ; Wed, 29 May 2002 14:23:38 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA21839; Wed, 29 May 2002 13:23:35 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4TKNYR25084; Wed, 29 May 2002 13:23:34 -0700 X-mProtect: <200205292023> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdfJoFMz; Wed, 29 May 2002 13:23:32 PDT Message-ID: <3CF538C4.A99A25D6@iprg.nokia.com> Date: Wed, 29 May 2002 13:23:32 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian Haley CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <200205220848.g4M8mIT15108@givry.rennes.enst-bretagne.fr> <3CED6015.E7A39399@iprg.nokia.com> <3CEE90C2.7010903@hp.com> <3CEFC4CB.92A5D2B1@iprg.nokia.com> <3CF3AC7D.2FC34D79@hp.com> <3CF3C98E.74548D2@iprg.nokia.com> <3CF3E528.67F526E2@hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Brian, I reckon we're pretty close here. Brian Haley wrote: > When a MN is at home, it's global address is valid for as long as the > prefix it used to construct it is valid (and it's actively defending the > address (i.e. running)). When away from home, it's global home address > is only valid if it has a binding with a HA that is defending/proxying > for the address. If a MN cannot register a binding with it's HA and the > lifetime has expired, it's global home address cannot be considered > valid and should not be used until a BU/BAck has successfully taken place. I agree with this(*), and with the other points you made following. >> Perhaps the specification should say this, but a specification does >> not usually mandate storage requirements for a protocol implementation. > > The Mobile IPv6 draft says MNs and HAs "MUST use non-volatile memory" > to store sequence numbers :) Ouch! Uncle! You win! Regards, Charlie P. (*) but there are four extra apostrophes... From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 18:03:22 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05181 for ; Wed, 29 May 2002 18:03:21 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15091; Wed, 29 May 2002 15:02:56 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11716; Wed, 29 May 2002 15:02:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TM1DrP029982 for ; Wed, 29 May 2002 15:01:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TM1D1A029981 for mobile-ip-dist; Wed, 29 May 2002 15:01:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TM1ArP029974 for ; Wed, 29 May 2002 15:01:10 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02227 for ; Wed, 29 May 2002 15:01:14 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA25074 for ; Wed, 29 May 2002 16:01:12 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 039416A905; Thu, 30 May 2002 01:01:06 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 74EF56A904; Thu, 30 May 2002 01:01:02 +0300 (EEST) Message-ID: <3CF54FE3.3050505@kolumbus.fi> Date: Thu, 30 May 2002 01:02:11 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hesham Soliman (ERA)" Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 References: <4DA6EA82906FD511BE2F00508BCF0538044F06A4@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Hesham for your in-depth review and comments! We'll take care of the editorial modifications. I will treat other parts inline below. Most of your comments can be taken in account immediately. But you may be satisfied with an additional explanation on some specific ones, and some others may require more discussion. The whole issue is registered as #35 unless otherwise noted below. > 1. General comments: > > - In general I think the draft has redundant text and in > some cases, significant overlaps between sections. It's > good to have some overlap, but in many cases it is too > repetetive. I'll try to mention specific examples in my > editorial comments. But this could be something to consider > before the final draft is done. The draft is very large > so it is good to remove as much as possible while maintaining > a good level of clarity. I agree. > 2. Specific technical comments > > - I wonder if it's worth referencing some way of creating > the nonce, or making a recommendation on how to do it. Mike > Thomas' last draft had a reference. It might be good to do > that, since it (the nonce) is a pretty significant part of RR. At the moment we only say that it is random. This is a sufficient condition, but may not be fully necessary. A weaker constraint, such as the time-bound variable in Mike's draft might do as well. This is because the use of Kcn hides any regularity in the nonce (if the MAC function was vulnerable to known plain text attack this would be a problem, but they usually aren't). > - I don't understand why MAX_RR_BINDING_LIFE is fixed > to 300 seconds. I would appreciate a reference or a reason. > The attack that Pekka sent a few months ago should not > require the 5 min limit. It simply requires that the BCE > cannot be refreshed without performing RR. In fact there > is probably more hazard in allowing the updates within > the 5 min than if we extend (or remove) the upper time > limit. A future DoS attack would likely die off quite soon (before 5 mins) if there was no TCP ACKs or something like from the victim. For these attacks the limit does not buy much. However, there are other types of attacks. For instance, I could visit your office and install a BCE at some CN that claims your PC is somewhere else. Allowing long BCE lifetimes makes this "hijack" attack possible for a longer time. Note that unlike in the DoS case, no refresh is needed for the attack proceed. Ideally, the effects of my visit should not last too long after my departure. > - Busy CNs will struggle with maintaining the Nonce > and Kbu lifetimes for several (hundreds or thousands?) > of MNs. Do you think this is a valid concern? If so > we need to add some recommendation on how to do this. > I haven't read the state machines in the appendix > yet, so my answer might be there. This may be a valid concern, though (1) you can always deal with it by either bying more memory or declining more RO requests (2) we have some text in 9.4.3. Do you think that text is sufficient: A possible way to implement this is to mark the binding cache entry so that it does not effect sending and receiving of packets, but so that it is found when a binding update is received. > - I might have missed this in an earlier discussion, > but why us the checksum needed for the MH? > It should always be authenticated. Yes, but not all of the messages are authenticated: BM, HOTI, COTI, ... > - Section 6.1.3: Why is the HA tunnelling the HOT a SHOULD? > It seems that this is one of the assumptions that the > protocol is based on (see the security design section). > Shouldn't this be a MUST? Not making this a MUST will > allow attacker on the MNs link to do some nasty stuff. There was a separate thread about this a couple months ago. It seems that the added benefit of encrypted tunneling is quite useful, but mainly for the benefit of the mobile node. Not absolutely necessary perhaps for the security of other nodes. Hence SHOULD. > - It seems like there was a concious decision to separate > the 'reserved' fields in all messages (e.g. section > 6.1.5 (HoT) and 6.1.6), why is that? Well, drawing the boxes together would look graphically better but the fields would still be at different positions, so that is probably not a good idea. Placing the index on the first two bytes would make sense as the next word would be completely reserved, and the field might even be removed. However, we wanted to keep some reserved space at the beginning of messages to store some future flags. This would be inline with the format of BUs. We could also move the index field to the second part of the first full word, making the reserved field continuous. Anyway, I don't feel strong either way we format the messages. > - Why are certain values skipped for the BA status > codes? e.g. between 133 and 137. I suggest we place them > in order. It looks like some magic is attached to those > missing numbers :) I don't know. Comments on the source files seem to indicate some old (now removed) status field values occupied these positions. Why don't we go and compress the list now. > - I think that setting the A flag has to be a MUST > or at the very minimum a SHOULD. It is very clear to > me that the protocol is much weaker and non-deterministic > without mandating the Ack. I would suggest that we mandate > it. There are several examples in the draft the provide > a good reason for mandating the BA. Yes, not using the acks might get you in trouble, having to deal with BEs later. > - Either we explain how the Mobile Prefix sol and adv > can be done securely (using PKI and dynamic SA establishment), > or remove them from the draft. I don't think we should > keep them and say that they must be authenticated 'if possible'. > what does that mean? Either they must be authenticated > or not. I think that they must be. Ok, let's create a separate issue for that. #36. > - Section 8.1,what is the point of mandating the HAO > when the spec says that it must not be received > without a BCE, and the entire RO is a 'should'.? > The HAO should follow the same recommendation as RO. I agree. Should be the same as the rest. > - In section 8.1: I think we should add a line that > if RR is supported, the CN MUST be able to return > a BA in response to a BU. Seems right. If you do something, you must do it completely. > - Section 9.1: Remove all the references to mobile routers. > E.g. the fifth bullet. Also remove the sixth bullet, > the prefix length does not exist anymore. Yeah. > - Section 9.2.2: First sentence, 'MAY' is unnecessay. > If the MN has a BCE, it's pretty strange that it doesn't > use RO and decide to not include the HAO. Hmm... the sentence could also be read from the point of view of the correspondent node. That is, even if the CN has a BCE, the mobile node may have rebooted and lost its binding information. Ok, let's make the sentence clearer! > - Section 9.4.1: Shouldn't the order of the last 2 bullets > be reversed.(Half editorial). You mean doing auth first and then sequence number check? Why? Wouldn't it be better to do the cheaper tests first, such as the sequence number check is? > - Section 9.4.1: Perhaps we should add some text to specify that > 'normally' the CoA nonce index and Home Nonce index are the same, > and that sending both is a precaution for changing the nonce while > RR is in progress. Or am I missing something? You are right. But aren't we already stating this somewhere else, perhaps it shouldn't be repeated here? > - Section 9.6, first paragraph. I thin we should replace > the first SHOULD with MUST. There is no point in having a > binding cache if it doesn't get chacked. I think the SHOULD exists here in order not require the use of some detail from a whole which is optional. Do you think we should try to make the keywords requirements more structured, i.e. SHOULD RO, IF RO THEN MUST RO-FEATURE-X? > - Section 9.7: Remove the third paragraph, it no longer > applies. I'm not sure why you think so. 11.6.6. still exists, no? > - Section 9.7: Fourth paragraph: Do we need to say how > persistent is 'persistent'? or Specify a default rate? I'm open to suggestions. Can you answer your own question? > - Section 10.1: Last sentence in the second paragraph, says > ' it SHOULD NOT be deleted by the HA ...' In section 9.5, > the same action was a 'MUST NOT'. Either MUST NOT, or SHOULD > NOT (accompanied with 'MUST inform the MN') are ok with me. I'd like to reduce the overlap between 9.5 and 10.1, by stating things only in 10.1 for home registrations. > - Section 10.1: Remove '(or has recently)' from the fourth > paragraph. Yes. > - Section 10.1: it would be good to show the order of > HAs in the HA list (last bullet in 10.1 doesn't say > in what order). Yes. > - Section 10.1: In response to the question in the draft, I'd > say that as long as the HA discovery is in the draft, > we have to keep the preference. I think HA discovery is > a nice idea. Ok, let's remove the note. > - Fifth bullet in 10.2: Shouldn't DAD be done for all addresses? > RFC 3041 might be a problem here if we only do DAD > on link-local addresses. I think this is being debated separately. Issue #37 > - Page 93: Bullet starting with 'However, if the 'S' bit > .....'. This strikes me as a problem when renumbering > the Home network is going on. If the HA always chooses > the smallest lifetime, doesn't that mean it will always > be choosing the lifetime of the prefix being deprecated? > Some clarification would be good. Yes it will choose the smallest possible lifetime. Would you like to clarify that this really is the case, or specify some additional constraints that limit the use of prefixes being deprecated through 'S' bit? > - Section 10.4: I don't think ND says anything about > 'gratuitous' NAs. We should replace that with Proxy NA > or some other terminology used in IPv6. Yes. > - Somewhere in section 10 it should be mentioned that > if the S bit is cleared (request the HA to act on behalf > of all the MNs HoAs) then the HA should create an SA in the > SAD for each one of those home addresses. Create or have? > - Page 96: In the four bullets there, I have the following > comments: > - Second bullet, the llA should be there IF the link > layer has link layer addresses. Yes. > - A pedantic question: What happens if ND is secured > with pre-configured SAs. Shouldn't the HA be configured > to act on behalf of MNs and send secure ND messages? I think we can deal with this by stating that rules in the ND RFCs are to be followed (which includes the potential use of SAs). > - Remove the last paragraph before 10.5 (the part about the R bit). Yes. > - Section 10.5: Second paragraph, remove all reference to prefix > length. Yes. > - General comment on multicast: I lost the emails that Dave > Thaler sent on the topic and haven't had time to look them > up. But I thought I'd remind the authors to look them > up and see if they are applicable. Ok... > - Section 10.7: Second paragrpah, Again, why is ESP > optional here ? What is the default behaviour? This was already discussed above. I'm not sure we can state much about the default behaviour, given that the user has to configure things in the SPD. Oh well, I suppose that means default is off... > - Section 10.9.3: 'If a security association ....' > -- > No ifs pleasejust make sure it's secure (MUST). > This goes for the entire section. Yes. > - Page 108: Remove any reference to previous-CoA. See above, where did we agree to remove this? > - Section 11.1: Te bullet starting with, 'A flag when > set, indicates that future Binding Updates .....' > What does this mean?? The MN will keep an entry in > the BUL anyway for a CN that doesn't accept BUs? This is for the MN to not retry RR/BU all the time. > - Page 113: Last bullet, 'other implementation > stragies maybe more appropriate' Like what? > I don't think we need to state this do we? > I would suggest removing this approach and > making the standard more concretein what it > says. But this is internal implementation, isn'#t it? Let's remove the note about the other strategies. But let's astill require that the behaviour must look like this from the outside, don't care how it's done. > - Page 115: 'The segments left in the RH is either > 0 or 1'. Zero? why is Zero ok? I believe this is for dealing with an implementation strategy where the RH is processed but left in its place in the packet, with zero in the field. > - Chapter 11.2.4 assumes that the MN can send > BUs to a 'router' in the local domain. I'm > not sure we can keep this in the spec without > specifying how to secure this BU. This is a CN-BU. > - Section 11.3.3/4: Same comment on securing the messages. As above. > - Add somewhere in Section 11 that the MN MUST NOT > let BCEs in CNs or HA timeout after the MN has > moved. I.e. It MUST deregister. Ok. > - Remove section 11.6.6. > > 3. Editorial comments > > This is not an exhaustive list, but I assume the > draft will be revised and grammar ...etc will be > checked again. > > - secion 5.5: Second sentence 'without creating major new ..' > Should be changed to '..new major...' or reworded. > > - Same section: All the references to, e.g., [1] ...are > they going to be RFCs ? Otherwise they can't be referenced. > > - Section 5.5.1: Second sentence: '...to accept only...' > reword. > > - Section 5.5.9: Second sentence, remove 'only' > > - Section 6.1.1: Last paragraph Add 'the' after > 'Mobility Header are' in the first sentence. > > - Why are sections 6.2.2 and 6.2.3 needed? > can't we refer to 2460? The less text the > better for this spec. > > - In 6.2.4 and 6.2.5 and other sections, please > write either 'Type', 'Length' ...etc in the > option format or 'Type = X', 'Length = Y', > but not just the numbers. > > - Page 56: Repeated text: 'A packet MUST NOT contain.... > associated with each encapsulating IP header' > > - Section 6.4: Second paragraph: 'This uses...' > Replace 'This' with 'The Routing Header' or > 'The new RH' .... > > - Section 9.4.2: Last sentence in the second last > paragraph, add 'of' before 'its lifetime'. > > - Section 9.6: Third paragraph, first sentence, add > 'in' before '6.4'. Thanks. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 19:46:26 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07714 for ; Wed, 29 May 2002 19:46:25 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA04561; Wed, 29 May 2002 16:45:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08551; Wed, 29 May 2002 16:45:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TNimrP000317 for ; Wed, 29 May 2002 16:44:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4TNimaL000315 for mobile-ip-dist; Wed, 29 May 2002 16:44:48 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4TNijrP000306 for ; Wed, 29 May 2002 16:44:45 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21198 for ; Wed, 29 May 2002 16:44:50 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16930 for ; Wed, 29 May 2002 17:45:47 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA04049; Wed, 29 May 2002 16:44:49 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4TNilB03562; Wed, 29 May 2002 16:44:47 -0700 X-mProtect: <200205292344> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdQKcsxA; Wed, 29 May 2002 16:44:46 PDT Message-ID: <3CF567EE.94E8DCAB@iprg.nokia.com> Date: Wed, 29 May 2002 16:44:46 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: John Williams Floroiu , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] are L2 triggers "secure" ? References: <3CED0C15.D65DCDB2@fokus.gmd.de> <016101c20276$91c29480$516015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello folks, I was away last week, and I am still catching up with e-mails. In general, I would like to keep the L2-specific issues including L2 trigger authentication away from a baseline FMIPv6 protocol. The protocol has to work on all link layers, and hence it must not be based on _specific L2 customizations_ or features. This is not to say that L2 features should not be exploited, however, a baseline FMIPv6 protocol should consider IP authentication and performance issues. Link-specific optimizations/customizations should be treated separately. Regards, -Rajeev James Kempf wrote: > I don't recall if the FMIPv6 draft specifically mentions this, but in > the low latency MIPv4 draft we do mention that the MAC layer needs to be > secure in order to use tunnels. In FMIPv6, this is true both for Prereg > and Postreg/BETH, since tunnels are used for both. Perhaps the draft > needs changing. > > In addition, you are correct that 802.11 security won't currently allow > secure tunnels. However, it should also be noted that on 802.11 > including 802.1x, ARP and ND are not secure either. There is no way to > prevent a host from stealing a MAC address on 802.11, unlike switched > Ethernet where 802.1x ties a switch port to the MAC address and won't > allow the host to change it. > > jak > > ----- Original Message ----- > From: "John Williams Floroiu" > To: > Sent: Thursday, May 23, 2002 8:34 AM > Subject: [mobile-ip] are L2 triggers "secure" ? > > > Hi, > > > > I would like to rise a question regarding the tunnel based handover > (section 3.2 in > > draft-ietf-mobileip-fast-mipv6-04.txt). I believe the use of L2 > > triggers might introduce some security holes as long as their "safety" > cannot be correctly assess by the layer 3. > > > > I am not a L2 technology expert, therefore I am not sure how L2 > triggers are actually implemented. However, taking as an > > example the scenario described in fig. 8 (p.25), and trying to > extrapolate somehow the functionality of WaveLAN (which > > is not the only but anyway the most widely considered case study), I > could imagine the situation described below > > occurring. > > > > An attacker spoofing the MAC address of a legitimate MN may force > itself to attach to a different access point (nAP) > > than the one the MN is currently using (oAP). This event happening at > the nAP is most probably the source of a L2-TT > > trigger nAR is going to receive, and the effect is that the incoming > MN traffic is going to be mis-routed, since the > > reception of L2-TT at nAR triggers the initiation of the handover > between (a false) nAR and oAR --- well I do not really > > know how nAR could learn the address of oAR in general, again, maybe > some technologies which I do not know about support > > this. > > > > The bottom line is that an attacker spoofing the identity --- MAC > address or whatever ID appearing in the radio control > > messages, like WaveLAN beacons --- of a legitimate mobile terminal, > can produce fake L2 triggers by attaching to false > > access points, and mount in this way DoS attacks against MNs. > > > > John. > > From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 20:21:55 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08372 for ; Wed, 29 May 2002 20:21:54 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01519; Wed, 29 May 2002 18:22:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA27347; Wed, 29 May 2002 17:21:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U0KwrP000485 for ; Wed, 29 May 2002 17:20:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U0Kv1Y000484 for mobile-ip-dist; Wed, 29 May 2002 17:20:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U0KsrP000477 for ; Wed, 29 May 2002 17:20:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02399 for ; Wed, 29 May 2002 17:20:59 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01094 for ; Wed, 29 May 2002 18:21:56 -0600 (MDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.194.23]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4U0KfFD157372; Wed, 29 May 2002 20:20:41 -0400 Received: from d03nm801.boulder.ibm.com (d03nm801.boulder.ibm.com [9.17.194.244]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4U0Kb519810; Wed, 29 May 2002 18:20:37 -0600 Subject: [mobile-ip] Re: MIPv6 - 17 Review To: Basavaraj.Patil@nokia.com, PRoberts@MEGISTO.com, jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Wed, 29 May 2002 17:17:07 -0700 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.9 |November 16, 2001) at 05/29/2002 06:20:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi folks, I have read all but the Security related sections of the draft, and have the following comments. Thanks, - KK ***************************** Technical Comments ******************************* 1. Section 6.1.3 : The Header Len value is incorrect if the option is present. According to the draft, the size would be 2 + size of mobility options in 8 octets = 2 + 1 = 3. In reality, the packet would be 12 bytes long till the options, and since the UID aligns at offset of 2n (and 12 happens to be a multiple of 2n), the UID option will fit right at the end of the Message Data field of the MH. So total length is 12 + 4 = 16 bytes = 2. The draft should definitely change the statement to something like : "The Header Length field in the Mobility Header for this message MUST be set to 12 bytes + the length of padding if necessary before possible options + the total length of all mobility options present, divided by 8, to give a value in units of 8. If no actual options are present in this message, 4 bytes of padding is necessary." 2. Section 6.1.4 : Same as #1 above. Section 6.1.8 happens to be correct in this respect due to following magic : a. different alignment of option, AND b. different length of the option. (2 bytes extra in both adding to 4 bytes). 3. Section 6.1.7 : Clarify in following para, that the address is the Home Address : "When a packet contains both a Home Address destination option and a Binding Update message, the sender MUST use the same *home* address in both." 4. Section 6.1.8 : In the third last para, the following line : "If no actual options are present in this message, 4 bytes of Pad1 or PadN mobility options are needed" The " 4 bytes of Pad1 or" should be removed, since Section 6.2.2 prohibits using multiple Pad1 options. 5. Section 6.2.3 : "For N octets of padding, the Option Len field contains the value N , and the Option Data consists of N-2 zero-valued octets." should be changed to : "For N octets of padding, the Option Len field contains the value N - 2, and the Option Data consists of N-2 zero-valued octets." This is as per description of Option Len in 6.2.1. 6. Section 6.2.4 : "2 4 Unique Identifier" should be change to "2 2 Unique Identifier". 7. Section 6.2.5 : "3 18" should be changed to "3 16" 8. Section 6.2.6 : "4 6" should be changed to "4 4" 9. Section 6.2.7 : "5 2 + Len" should be changed to "5 Len" And subsequent reference to "2 + Len" should be changed to "Len". 10. Section 6.8 : Under description of "Destination Address" : "Otherwise, the mobile node's home address SHOULD be used." Why is that so ? This is unsolicited Prefix Advertisement, so how can the Home Agent find this home address if it is not registered with it (and thus not present in the binding cache) ? And this also conflicts with the first sentence in this section anyway, "A home agent will send a Mobile Prefix Advertisement message to a mobile node to distribute prefix information about the home link while the mobile node is traveling away from the home network." Shouldn't this be removed ? 11. Section 7.5 : - MinRtrAdvInterval 0.05 seconds - MaxRtrAdvInterval 1.5 seconds This interval is too long, a range of 30 times. If the router is using 1.5 seconds (using Advertisement Interval Option), the MN may need a very long time to register the fact that it has moved, probably having to miss a few of these router advertisements. I think suggested values should be in the range of 0.05 to 0.25 seconds at the most, implementors are welcome to increase this if they want, but Mobile Specs should be more stringent on smooth handoff. 12. Section 8.1 : There has been some discussion on this, but I don't know what the final consensus is. But I feel that the first "MUST" for processing Home Address option should be changed to "SHOULD". If the node is processing this option, it should have a Binding Cache (since the MN would have sent this option only after establishing a Binding Cache). Since the third point is using "SHOULD", this one too should use "SHOULD". Making all three a "MUST" might be restricting some implementation of special mobile devices, which might not need the full functionality, eg a MN which is going to interact with a CN, and never with another MN (this is the scenario where the second bullet is not applicable). 13. Section 9.1 : Remove the two bullets under : "- A flag indicating whether or not this Binding Cache entry represents a mobile node" ... AND " - The length of the routing prefix for the home address. This" ... Both of these have been removed since draft 14/15 or so. The second one need not be replaced with the 'S' bit flag, since the implementation of the 'S' bit would create multiple entries in the binding cache anyway. Hence both of these can be removed. 14. Section 9.4.5 : The last sentence of the second para should be changed to : "When the mobile node receives a packet from some sender containing a Binding Refresh Request option, it MUST confirm that a binding exists in it's BUL for this sender, and then it MAY start a return routability procedure, if necessary, before sending its current binding and a new lifetime in a new Binding Update. This is to prevent Denial of service attacks. 15. Section 10.2 : The 4th bullet is confusing to me. It looks like a BU to HA MUST have both BU as well as a Home Address option, while to a CN, the BU MUST NOT have the Home Address option. I guess this was a subject of debate on the mailing list, but I didn't follow it if it happened. Is this a conscious decision to have two Home Addresses when sending to HA, and is it really necessary ? 16. Section 10.2 : The 5th bullet should be changed to : "This ensures that no other node on the home link was using the mobile node's home address when the Binding Update arrived". 17. Section 10.2 : The 5th bullet needs another modification : "When the home agent sends a successful Binding Acknowledgement to the mobile node, in response to a Binding Update with the `D' bit set, the home agent assures to the mobile node that its home address will continue to be kept unique by the home agent at least as long as the lifetime granted for that home address binding is not over, or while the mobile node transmits Binding Updates with new care-of addresses for that home address. 18. Section 10.2 : The para about 'S' bit should be changed to : "The set of such home addresses is formed by replacing the routing prefix for the given home address with all other routing prefixes *on the mobile node's home link* that are supported by the home agent processing the Binding Update. This is correctly stated 2 bullets below in the "However, if the 'S' bit" ... para ... 19. Section 10.2 : The para about : "- The Refresh field MUST be set to a value less than or equal to" Is Refresh useful at all ? I don't believe it is. It seems to imply that it helps in the case of the Home Agent crashing and has only a volatile storage for the binding cache. But if the Home Agent crashed before the Refresh interval is over, the behaviour is identical to the case where the Refresh field contains the same value as Lifetime. It will be useful only if the HA crashed after the Refresh interval but before the Lifetime interval. Hence it is completely useless in most situations. If this can be removed safely, all references need to be removed in the draft and the Format of the BU section (6.1.8) needs to reflect this. 20. Section 10.4 : The first bullet is slightly wrong. It should say : "- The home agent examines the value of the `S' bit in the new "home registration" Binding Update Packet. If this bit is nonzero," ... The HA has just got a BU packet from MN, and the Binding Cache entry did not exist. Also the Binding Cache doesn't contain a 'S' bit field. We should specify that the HA looks at the BU packet and not the BC entry. 21. Section 10.4 : Part of the last para should be changed to : "In addition, the Router (R) bit in the Advertisement MUST be set to zero. Acting as a proxy ....". 22. Section 10.5 : First sentence of the second para should be changed to : "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 'S' bit was zero in the Binding Update), as described in Section 10.4." Prefix Len is removed. 23. Section 11.2.3 : "- The segments left field in the RH is either 0 or 1." This should be 1 since that is the value set. Also, section 6.4.1 confirms that. 24. Section 11.6.2 : Do we need to mention that the binding to CN be done only after getting a success BA from the HA. I am referring to : "When a mobile node sends a Binding Update to its home agent to register a new primary care-of address (as described in Section 11.6.1), the mobile node SHOULD also start a return routability procedure to each other node for which an entry exists in the mobile node's Binding Update List, as detailed below. Upon successful return routability procedure, a Binding Update message is sent." ... The last sentence could be changed to : "Upon successful return routability procedure and after receiving a successful Binding Acknowledgement from the Home Agent, a Binding Update message is sent to all other nodes". 25. Section 11.6.2 : When the BU packet is formed, should it be specified that a Home Address option MUST NOT be included ? This is relevant to my comment on item #15. 26. Section 11.6.4 : In the second last para, the last sentence should be changed to : "In this case, the mobile node instead SHOULD return a Binding Update to the sender, in which the Lifetime field is set to zero and the care-of address (using a Alternate Care-Of Address option) is set to the mobile node's home address." The source address cannot be set to the Home Address due to ingress filtering, and this should be made more clear. 27. Section 11.6.7 : The last sentence of the second para should include some re-transmission policy in case the NS is lost. Otherwise the MN cannot send a BU to the Home Agent after returning to the Home Network. Some values need to be specified for timeout and number of retransmissions before the MN can assume that the Home Agent is dead (and possibly continue using it's home address and also continue to finish the returning home procedure). ************************************ Typos ************************************ 1. Section 6.1.6 : In the description of the Reserved field, remove the "and the one 32-bit field" since that field does not exist. 2. Section 6.1.7 : In the description of the Reserved field, change the statement to : "These fields are unused. ......" 3. Section 6.1.7 : In the description of the Sequence # field, the Section number 4.5 is wrong, it should be 5.5 4. Section 6.3 : In the 3rd last line of the first para, "MUST not" should be changed to "MUST NOT". 5. Section 6.8 : The first sentence under description of "Destination Address" should be rephrased as "If this message is a response to a Mobile Prefix Solicitation, this field contains the Source Address field from that packet." 6. Section 7.6 : Last para, change the "it" to "it's" : "on it's current link, until its movement detection algorithm" 7. Section 10.1 : In the second para, the "SHOULD NOT" should be changed to "MUST NOT". Conflicts with Section 9.5 8. Section 10.2 : An extra "," at the beginning of : "- , However, if the `S' bit field in the Binding Update is zero," 9. Section 11.1 : In the second bullet item, add a "of". "* one of the mobile node's home addresses for typical Binding Updates (Sections 11.6.1 and 11.6.2), or" 10. Section 11.2.1 : Clarify home address means any of the home addresses in : "Likewise, if the mobile node uses any address other than its home address as the source of a packet sent while away from home" can be changed to : "Likewise, if the mobile node uses any address other than any of its home addresses as the source of a packet sent while away from home" 11. Section 11.6.1 : Change last Character of this section from "B" to "C" (appendix reference). 12. Section 11.7 : The last sentence seems to be mis-formed. Needs rephrasing. From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 20:37:30 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08726 for ; Wed, 29 May 2002 20:37:29 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02945; Wed, 29 May 2002 18:37:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA23065; Wed, 29 May 2002 17:37:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U0aXrP000588 for ; Wed, 29 May 2002 17:36:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U0aXkY000587 for mobile-ip-dist; Wed, 29 May 2002 17:36:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U0aTrP000580 for ; Wed, 29 May 2002 17:36:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA02302 for ; Wed, 29 May 2002 17:36:33 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA12988 for ; Wed, 29 May 2002 18:36:32 -0600 (MDT) Received: from mira-sjc5-7.cisco.com (IDENT:mirapoint@mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4U0aTHs021371; Wed, 29 May 2002 17:36:29 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id ABT42438; Wed, 29 May 2002 17:33:30 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id RAA06573; Wed, 29 May 2002 17:36:28 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15605.29708.260234.936106@thomasm-u1.cisco.com> Date: Wed, 29 May 2002 17:36:28 -0700 (PDT) To: Jari Arkko Cc: "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 In-Reply-To: <3CF54FE3.3050505@kolumbus.fi> References: <4DA6EA82906FD511BE2F00508BCF0538044F06A4@Esealnt861.al.sw.ericsson.se> <3CF54FE3.3050505@kolumbus.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko writes: > > 2. Specific technical comments > > > > - I wonder if it's worth referencing some way of creating > > the nonce, or making a recommendation on how to do it. Mike > > Thomas' last draft had a reference. It might be good to do > > that, since it (the nonce) is a pretty significant part of RR. > > > At the moment we only say that it is random. This is > a sufficient condition, but may not be fully necessary. > A weaker constraint, such as the time-bound variable in > Mike's draft might do as well. This is because the use of > Kcn hides any regularity in the nonce (if the MAC > function was vulnerable to known plain text attack this > would be a problem, but they usually aren't). I see my name here... If this is about constructing the stateless cookie, I'd suggest taking a look at the JFK draft's variation on this. As I recall, their approach was simpler than mine. If you need it encoded into a single field, you can concatenate the MAC with the nonce and lose 12 bytes of nonce if you like. Mike From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 22:42:57 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11736 for ; Wed, 29 May 2002 22:42:57 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA14308; Wed, 29 May 2002 19:42:33 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27151; Wed, 29 May 2002 19:42:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U2fZrP000854 for ; Wed, 29 May 2002 19:41:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U2fZCq000853 for mobile-ip-dist; Wed, 29 May 2002 19:41:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U2fVrP000846 for ; Wed, 29 May 2002 19:41:31 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA09903 for ; Wed, 29 May 2002 19:41:36 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13777 for ; Wed, 29 May 2002 19:41:36 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA10968; Wed, 29 May 2002 19:41:35 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4U2fYw07049; Wed, 29 May 2002 19:41:34 -0700 X-mProtect: <200205300241> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3u86BS; Wed, 29 May 2002 19:41:32 PDT Message-ID: <3CF5915D.634A794F@iprg.nokia.com> Date: Wed, 29 May 2002 19:41:33 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 References: <4DA6EA82906FD511BE2F00508BCF0538044F06A4@Esealnt861.al.sw.ericsson.se> <3CF54FE3.3050505@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Arkko wrote: > > - Why are certain values skipped for the BA status > > codes? e.g. between 133 and 137. I suggest we place them > > in order. It looks like some magic is attached to those > > missing numbers :) > > I don't know. Comments on the source files seem to indicate > some old (now removed) status field values occupied these > positions. Why don't we go and compress the list now. values 133 to 137 had some kind of meaning in the earlier versions of the MIPv6 ID. I am sure that there is still some code in some implementations dealing with these sequence numbers. I would advise against compressing the list. it is going to be a nightmare at the next interop. > > - Section 8.1,what is the point of mandating the HAO > > when the spec says that it must not be received > > without a BCE, and the entire RO is a 'should'.? > > The HAO should follow the same recommendation as RO. > > I agree. Should be the same as the rest. isnt there a danger here? lets assume the MN sends a IPsec protected BU to a CN. there is no BCE at the CN. but the CN still has to process the HAO. the other two SHOULDs in section 8.1 do not affect the processing of HAO. I think it should left as MUST. we should be fine as long as the spec requires that the CN does not process unverified HoA. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 23:14:06 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12041 for ; Wed, 29 May 2002 23:14:06 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12541; Wed, 29 May 2002 21:14:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA02446; Wed, 29 May 2002 20:14:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U3DArP000981 for ; Wed, 29 May 2002 20:13:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U3DAs0000980 for mobile-ip-dist; Wed, 29 May 2002 20:13:10 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U3D7rP000973 for ; Wed, 29 May 2002 20:13:07 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA02284 for ; Wed, 29 May 2002 20:13:12 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA12150 for ; Wed, 29 May 2002 21:13:11 -0600 (MDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id MAA03181; Thu, 30 May 2002 12:13:05 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA12184; Thu, 30 May 2002 12:13:05 +0900 (JST) Date: Thu, 30 May 2002 12:12:37 +0900 (JST) Message-Id: <20020530.121237.120953247.keiichi@iij.ad.jp> To: vijayd@iprg.nokia.com Cc: jari.arkko@kolumbus.fi, hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3CF5915D.634A794F@iprg.nokia.com> References: <4DA6EA82906FD511BE2F00508BCF0538044F06A4@Esealnt861.al.sw.ericsson.se> <3CF54FE3.3050505@kolumbus.fi> <3CF5915D.634A794F@iprg.nokia.com> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Vijay, From: Vijay Devarapalli > > > > - Section 8.1,what is the point of mandating the HAO > > > when the spec says that it must not be received > > > without a BCE, and the entire RO is a 'should'.? > > > The HAO should follow the same recommendation as RO. > > > > I agree. Should be the same as the rest. > > isnt there a danger here? lets assume the MN sends a IPsec > protected BU to a CN. there is no BCE at the CN. but the CN > still has to process the HAO. the other two SHOULDs in > section 8.1 do not affect the processing of HAO. > > I think it should left as MUST. we should be fine as long as > the spec requires that the CN does not process unverified HoA. Really? I think there are three type of CN. (1) traditional IPv6 node (2) HAO aware CN (3) full MIP6 CN The CNs will process HAO as follows, unprotected IPseced HAO HAO (1) ICMP paramprob ICMP paramprob -> bidir-tunnel (2) BE go ahead -> triangular(?) (3) BE go ahead -> ROed communication At least, (1) is not required to support processing HAO. I think HAO processing must be 'SHOULD'. There is no reason to mandate it. Am I correct? Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Wed May 29 23:56:26 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12953 for ; Wed, 29 May 2002 23:56:25 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA22662; Wed, 29 May 2002 21:56:37 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA29685; Wed, 29 May 2002 20:55:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U3shrP001199 for ; Wed, 29 May 2002 20:54:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U3sh2T001198 for mobile-ip-dist; Wed, 29 May 2002 20:54:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U3serP001188 for ; Wed, 29 May 2002 20:54:40 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA20888 for ; Wed, 29 May 2002 20:54:45 -0700 (PDT) From: arvind.sevalkar@lntinfotech.com Received: from vashiout.lntinfotech.com ([203.199.118.66]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA03219 for ; Wed, 29 May 2002 20:54:44 -0700 (PDT) Received: from vashi.lntinfotech.com ([203.199.118.15]) by vashiout.lntinfotech.com (Lotus Domino Build 166.1) with ESMTP id 2002053009285497:1170 ; Thu, 30 May 2002 09:28:54 +0530 Subject: Re: [mobile-ip] issue #25 To: Vijay Devarapalli Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Date: Thu, 30 May 2002 09:24:19 +0530 MIME-Version: 1.0 X-MIMETrack: Serialize by Router on VASHI/LNTINFOTECH(Release 5.0.8 |June 18, 2001) at 05/30/2002 09:25:04 AM, Itemize by SMTP Server on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/30/2002 09:28:55 AM, Serialize by Router on VASHIOUT/LNTINFOTECH(Release 5.0 (Intl)|30 March 1999) at 05/30/2002 09:28:58 AM, Serialize complete at 05/30/2002 09:28:58 AM Message-ID: X-Priority: 3 (Normal) Content-type: text/plain; charset=us-ascii Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Vijay Devarapalli To: arvind.sevalkar@lntinfotech.com Sent by: cc: mobile-ip@sunroof.eng.sun.com owner-mobile-ip@sunroof.e Subject: Re: [mobile-ip] issue #25 ng.sun.com 05/28/2002 10:37 PM hi Arvind, arvind.sevalkar@lntinfotech.com wrote: > ==>> > I am satisfied with this, BU to CN or HA should have HAO and BA should have > RH except when BU is for deleting the Binding cache entry. a small addition to this. the BA should have a routing header when the BU for deleting the Binding Cache entry is sent from a visited link. otherwise the BA would not reach the MN. the routing header is not present only when the MN returns home and sends a deregistration BU. Vijay ==>> Yes, I agree that we have to add routing header when MN is in foreign network and sends BU for deleting entry. Arvind From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 00:03:05 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13073 for ; Thu, 30 May 2002 00:03:04 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA10600; Wed, 29 May 2002 21:02:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA01989; Wed, 29 May 2002 21:02:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U41irP001342 for ; Wed, 29 May 2002 21:01:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U41iY0001341 for mobile-ip-dist; Wed, 29 May 2002 21:01:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U41erP001334 for ; Wed, 29 May 2002 21:01:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA22293 for ; Wed, 29 May 2002 21:01:46 -0700 (PDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24558 for ; Wed, 29 May 2002 22:02:43 -0600 (MDT) Message-ID: <010401c2078e$77589640$b36015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "John Williams Floroiu" , References: <3CED0C15.D65DCDB2@fokus.gmd.de> <016101c20276$91c29480$516015ac@T23KEMPF> <3CF567EE.94E8DCAB@iprg.nokia.com> Subject: Re: [mobile-ip] are L2 triggers "secure" ? Date: Wed, 29 May 2002 20:59:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Rajeev, > I was away last week, and I am still catching up with e-mails. > In general, I would like to keep the L2-specific issues including > L2 trigger authentication away from a baseline FMIPv6 protocol. > The protocol has to work on all link layers, and hence it must > not be based on _specific L2 customizations_ or features. > This is not to say that L2 features should not be exploited, however, a > baseline > FMIPv6 protocol should consider IP authentication and performance > issues. Link-specific optimizations/customizations should be treated > separately. > Does this mean you do not want to mention anything about L2 security in the base draft? If so, I think it may be necessary to then refer to the L2 triggers draft or have a separate draft, as I believe the security directorate will require some statement about security of L2 triggers. I believe this is so regardless of which algorithm is considered. jak From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 00:14:44 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13234 for ; Thu, 30 May 2002 00:14:44 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA28854; Wed, 29 May 2002 22:15:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA04810; Wed, 29 May 2002 21:14:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U4E0rP001421 for ; Wed, 29 May 2002 21:14:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U4E0gB001420 for mobile-ip-dist; Wed, 29 May 2002 21:14:00 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U4DvrP001413 for ; Wed, 29 May 2002 21:13:57 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA24159 for ; Wed, 29 May 2002 21:14:00 -0700 (PDT) Received: from mail.ict.ac.cn ([159.226.39.4]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA13385 for ; Wed, 29 May 2002 22:13:59 -0600 (MDT) Message-Id: <200205300413.WAA13385@pheriche.sun.com> Received: (qmail 17994 invoked from network); 30 May 2002 04:05:04 -0000 Received: from unknown (HELO sjl?ipv6) (159.226.39.209) by 159.226.39.4 with SMTP; 30 May 2002 04:05:04 -0000 Date: Thu, 30 May 2002 12:15:37 +0800 From: jinglin shi To: "zhang.hongyuan@zte.com.cn" , "mobile-ip@sunroof.eng.sun.com" Subject: [mobile-ip] Re: About Home Address Option in Mobile IPv6 Organization: Institute of Computeing Technology,Chinese academy of Science X-mailer: FoxMail 4.0 beta 1 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g4U4DvrP001414 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit > >I am now reading "draft-ietf-mobileip-ipv6-16.txt". > >My questions are as follows: >1. Am I reading the latest draft? > >2.Is it necessary to have a Home Address Option, since the Binding Update >Destination >Option already has a Home Address field which gives the home address of the >mobile node? It will be redundant for the Binding Update to include a Home >Address Option, why there is the redundancy? HA is needed, I think the FA is also needed. to some extent, you are right because we can find where the MN come from its home address field, but we need more info for services. > >3.It is stated in section 5.1.6 of the draft that: > >"A Binding Update message to the correspondent node MUST NOT include the >Home Address option in order to avoid reflection attacks..." which >contradicts the statement made in section 8.2 that: > >"Before accepting a Binding Update option received in any packet, the >receiving node MUST validate the Binding Update according to the following >tests: > >-... >- The packet MUST contain a Home Address option. >...." > >If both statements are true, according to them, all Binding Updates sent to >the correspondent node (not including the home agent) will be discarded. >What's wrong? > >Thanks! > >ZHANG Hongyuan > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > >. = = = = = = = = = = = = = = = = = = = = Ö Àñ£¡ jinglin shi sjl@ict.ac.cn 2002-05-30 From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 03:06:03 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24814 for ; Thu, 30 May 2002 03:06:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05817; Thu, 30 May 2002 01:06:11 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA21285; Thu, 30 May 2002 00:05:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U75FrP001767 for ; Thu, 30 May 2002 00:05:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U75E23001766 for mobile-ip-dist; Thu, 30 May 2002 00:05:14 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U75BrP001759 for ; Thu, 30 May 2002 00:05:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA17458 for ; Thu, 30 May 2002 00:05:11 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21706 for ; Thu, 30 May 2002 01:06:09 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id C7F9C6A905; Thu, 30 May 2002 10:05:08 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BC1D86A904; Thu, 30 May 2002 10:05:06 +0300 (EEST) Message-ID: <3CF5CF68.1060402@kolumbus.fi> Date: Thu, 30 May 2002 10:06:16 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 References: <4DA6EA82906FD511BE2F00508BCF0538044F06A4@Esealnt861.al.sw.ericsson.se> <3CF54FE3.3050505@kolumbus.fi> <3CF5915D.634A794F@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > values 133 to 137 had some kind of meaning in the earlier > versions of the MIPv6 ID. I am sure that there is still some > code in some implementations dealing with these sequence > numbers. I would advise against compressing the list. it > is going to be a nightmare at the next interop. Ok, let's leave it as it is then. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 03:27:00 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25147 for ; Thu, 30 May 2002 03:27:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA12921; Thu, 30 May 2002 00:26:38 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24323; Thu, 30 May 2002 00:26:30 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U7PjrP001849 for ; Thu, 30 May 2002 00:25:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U7Pj2H001848 for mobile-ip-dist; Thu, 30 May 2002 00:25:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U7PgrP001841 for ; Thu, 30 May 2002 00:25:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24169 for ; Thu, 30 May 2002 00:25:42 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA20026 for ; Thu, 30 May 2002 00:25:41 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id D78EC6A905; Thu, 30 May 2002 10:25:34 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EE4786A904; Thu, 30 May 2002 10:25:32 +0300 (EEST) Message-ID: <3CF5D432.7020103@kolumbus.fi> Date: Thu, 30 May 2002 10:26:42 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Keiichi SHIMA Cc: vijayd@iprg.nokia.com, jari.arkko@kolumbus.fi, hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 References: <4DA6EA82906FD511BE2F00508BCF0538044F06A4@Esealnt861.al.sw.ericsson.se> <3CF54FE3.3050505@kolumbus.fi> <3CF5915D.634A794F@iprg.nokia.com> <20020530.121237.120953247.keiichi@iij.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Keiichi SHIMA wrote: > From: Vijay Devarapalli > >>>>- Section 8.1,what is the point of mandating the HAO >>>I agree. Should be the same as the rest. >>> >>isnt there a danger here? lets assume the MN sends a IPsec >>protected BU to a CN. there is no BCE at the CN. but the CN >>still has to process the HAO. the other two SHOULDs in >>section 8.1 do not affect the processing of HAO. >> >>I think it should left as MUST. we should be fine as long as >>the spec requires that the CN does not process unverified HoA. > > Really? > > I think there are three type of CN. > > (1) traditional IPv6 node > (2) HAO aware CN > (3) full MIP6 CN > > The CNs will process HAO as follows, > > unprotected IPseced > HAO HAO > (1) ICMP paramprob ICMP paramprob -> bidir-tunnel > (2) BE go ahead -> triangular(?) > (3) BE go ahead -> ROed communication > > At least, (1) is not required to support processing HAO. I think HAO > processing must be 'SHOULD'. There is no reason to mandate it. The question is, if we want to make the entry (2,ipsec) something whose support is always required. With a SHOULD, even if you may have an IPsec SA you might end up with the parameter problem ICMP. The mobile node will then revert back to bidirectional tunneling. With a MUST, a compliant implementation will process the packet. Note that since there will always be "old" IPv6 nodes, there will be cases where we have an SA and still get the ICMP back. So functionality-wise the result in both cases is the same. We are talking more about what instruction we give to implementers and vendors rather than anything else. And we have an ongoing debate about the right level of the instruction, on the IPNG list. Personally, I feel that it is much more likely that two nodes would be willing to be good-behaving mobilize citizens and use route optimization, than that someone bothered to set up a security association between those nodes. So I think it would be rather unlikely that you'd find a situation where the nodes have an SA, but are unwilling to use full RO. For these reasons I believe the same keyword that we have for RO could equally well apply to HAO. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 04:45:15 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26574 for ; Thu, 30 May 2002 04:45:15 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13761; Thu, 30 May 2002 02:45:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA10858; Thu, 30 May 2002 01:45:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U8iWrP002102 for ; Thu, 30 May 2002 01:44:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U8iWws002101 for mobile-ip-dist; Thu, 30 May 2002 01:44:32 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from odin.France.Sun.COM (odin.France.Sun.COM [129.157.174.8]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U8iRrP002094 for ; Thu, 30 May 2002 01:44:28 -0700 (PDT) Received: from odin.france.sun.com (euroapp.Holland.Sun.COM [129.159.197.58]) by odin.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g4U8i9210122; Thu, 30 May 2002 10:44:11 +0200 (MEST) From: Erik Nordmark - Sun Microsystems Message-Id: <200205300844.g4U8i9210122@odin.France.Sun.COM> Date: Thu, 30 May 2002 08:43:20 -0000 To: "Hesham Soliman (ERA)" Cc: Reply-To: Subject: Re: [mobile-ip] comments on MIPv6 draft-17 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit A few responses. > - I might have missed this in an earlier discussion, > but why us the checksum needed for the MH? > It should always be authenticated. There are some MH packets (binding missing etc) that are not protected by authentication. > - Page 96: In the four bullets there, I have the following > comments: > - Second bullet, the llA should be there IF the link > layer has link layer addresses. > - A pedantic question: What happens if ND is secured > with pre-configured SAs. Shouldn't the HA be configured > to act on behalf of MNs and send secure ND messages? My answer to the last sub-bullet is that worrying about IPsec protected (or otherwise secured ND) is for further study, since there isn't a deployable IETF standard for how to secure ND. > - Page 115: 'The segments left in the RH is either > 0 or 1'. Zero? why is Zero ok? If an implementation processes RH type 2 the same way as type 0 (i.e. first swap addresses and decrement segments left and then feed the packet back into IP) then it will internally (but never on the wire) have RH type 2 with segments left being zero. Do we need to make this more clear in the document? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 05:06:13 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26937 for ; Thu, 30 May 2002 05:06:13 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21499; Thu, 30 May 2002 03:06:22 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA08793; Thu, 30 May 2002 02:06:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U95QrP002190 for ; Thu, 30 May 2002 02:05:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4U95Q08002189 for mobile-ip-dist; Thu, 30 May 2002 02:05:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U95MrP002182 for ; Thu, 30 May 2002 02:05:23 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28273 for ; Thu, 30 May 2002 02:05:24 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23671 for ; Thu, 30 May 2002 02:05:23 -0700 (PDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id SAA17790; Thu, 30 May 2002 18:05:22 +0900 (JST) Received: from localhost (ssh.iij.ad.jp [192.168.2.7]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id SAA09595; Thu, 30 May 2002 18:05:22 +0900 (JST) Date: Thu, 30 May 2002 18:04:52 +0900 (JST) Message-Id: <20020530.180452.14121406.keiichi@iij.ad.jp> To: jari.arkko@kolumbus.fi Cc: vijayd@iprg.nokia.com, hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <3CF5D432.7020103@kolumbus.fi> References: <3CF5915D.634A794F@iprg.nokia.com> <20020530.121237.120953247.keiichi@iij.ad.jp> <3CF5D432.7020103@kolumbus.fi> X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Jari, From: Jari Arkko > The question is, if we want to make the entry (2,ipsec) something > whose support is always required. With a SHOULD, even if you may > have an IPsec SA you might end up with the parameter problem ICMP. > The mobile node will then revert back to bidirectional tunneling. > With a MUST, a compliant implementation will process the packet. Umm, I (currently) think none of them should be must. This is the basic cecept of protocols. If both supports something, something good is occur (ex. RO :). If one of them doesn't have such an extention(?), we just use a traditional method. > Note that since there will always be "old" IPv6 nodes, there will > be cases where we have an SA and still get the ICMP back. So > functionality-wise the result in both cases is the same. We are > talking more about what instruction we give to implementers and > vendors rather than anything else. And we have an ongoing debate > about the right level of the instruction, on the IPNG list. I'm reading the discussion. In my opinion, it is better for the basic specification to keep as possible as small. The needs will deploy advanced extensions (even if it is specified as SHOULD) in the future. > Personally, I feel that it is much more likely that two nodes > would be willing to be good-behaving mobilize citizens and > use route optimization, than that someone bothered to set up > a security association between those nodes. So I think it > would be rather unlikely that you'd find a situation where > the nodes have an SA, but are unwilling to use full RO. > For these reasons I believe the same keyword that we have > for RO could equally well apply to HAO. I understand your opinion. But, I think having an SA and the intention for RO is a different problem. Once all requirements is satisfied (an SA and supporting HAO processing and BCE management), RO occur. Even if we lack one of them, we can still communicate with. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 06:52:02 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28415 for ; Thu, 30 May 2002 06:52:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19821; Thu, 30 May 2002 04:53:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22853; Thu, 30 May 2002 03:51:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UApCrP002318 for ; Thu, 30 May 2002 03:51:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UApC7h002317 for mobile-ip-dist; Thu, 30 May 2002 03:51:12 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UAp9rP002310 for ; Thu, 30 May 2002 03:51:09 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA22685 for ; Thu, 30 May 2002 03:51:08 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA29282 for ; Thu, 30 May 2002 04:51:07 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 0DB016A906; Thu, 30 May 2002 13:51:07 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7286C6A905; Thu, 30 May 2002 13:51:05 +0300 (EEST) Message-ID: <3CF6045E.3040305@piuha.net> Date: Thu, 30 May 2002 13:52:14 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Keiichi SHIMA Cc: vijayd@iprg.nokia.com, hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 References: <3CF5915D.634A794F@iprg.nokia.com> <20020530.121237.120953247.keiichi@iij.ad.jp> <3CF5D432.7020103@kolumbus.fi> <20020530.180452.14121406.keiichi@iij.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Keiichi SHIMA wrote: > I understand your opinion. But, I think having an SA and the > intention for RO is a different problem. Once all requirements is > satisfied (an SA and supporting HAO processing and BCE management), RO > occur. Even if we lack one of them, we can still communicate with. I think we actually agree though you seemed to conclude that we don't... I support the SHOULD RO approach myself, and would also like to have a SHOULD HAO instead of the current MUST HAO. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 09:13:29 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02907 for ; Thu, 30 May 2002 09:13:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03598; Thu, 30 May 2002 07:13:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05870; Thu, 30 May 2002 06:13:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UDCirP002592 for ; Thu, 30 May 2002 06:12:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UDChtI002591 for mobile-ip-dist; Thu, 30 May 2002 06:12:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UDCerP002584 for ; Thu, 30 May 2002 06:12:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15702 for ; Thu, 30 May 2002 06:12:41 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14909 for ; Thu, 30 May 2002 07:13:39 -0600 (MDT) Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LQF67PC2; Thu, 30 May 2002 09:12:40 -0400 Message-ID: <001b01c207db$ad246130$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Phil Neumiller" , "Charles E. Perkins" Cc: "MobileIP" References: <007901c20743$d0cffc90$ab0110ac@meshnetworks.com> Subject: Re: [mobile-ip] Question on RFC 3220 - Agent Advertisement messages in Manets Date: Thu, 30 May 2002 09:12:40 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie, I found this in RFC 3220 > Charlie, > > Suppose one wishes to use MIP with a MANET. Futhermore, suppose one performs an agent advertisement > solicitation. This will normally result in a specially formatted route advertisment which would work fine provided > you had an actual subnet! In the case of a mesh or MANET with no local topologically correct prefixing the > only solution is to have all nodes flood these advertisements over the entire MANET network right? Yuck! > Why couldn't the Agent Advertisement be optionally unicast back to the solicitor MN. > > Thanks, > > Phil > > -- > Phillip D. Neumiller (pneumiller@meshnetworks.com) > My PGP key can be imported from the following URL: > http://pgpkeys.mit.edu From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 09:17:07 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03124 for ; Thu, 30 May 2002 09:17:07 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23753; Thu, 30 May 2002 07:17:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16667; Thu, 30 May 2002 06:17:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UDFDrP002656 for ; Thu, 30 May 2002 06:15:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UDFDJn002655 for mobile-ip-dist; Thu, 30 May 2002 06:15:13 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UDF9rP002648 for ; Thu, 30 May 2002 06:15:09 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06153 for ; Thu, 30 May 2002 06:15:10 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22735 for ; Thu, 30 May 2002 07:15:09 -0600 (MDT) Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LQF67PCM; Thu, 30 May 2002 09:15:08 -0400 Message-ID: <001f01c207dc$05dd3d60$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: "MobileIP" References: <007901c20743$d0cffc90$ab0110ac@meshnetworks.com> Subject: Re: [mobile-ip] Question on RFC 3220 - Agent Advertisement messages in Manets Date: Thu, 30 May 2002 09:15:09 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Charlie, I think I was confused in my previous mail. I found the following in RFC 3220 in the Agent Advertisemetn section. The link-layer destination address of a unicast Agent Advertisement MUST be the same as the source link-layer address of the Agent Solicitation which prompted the Advertisement. Does this mean that soliciations will always be answered with unicast advertisements? When I read the ICMP route advertisement RFC it indicated only multi-cast and subnet broadcast destinations addresses. Is there something in the MIP implementation in the HAs and FAs that knows to send unicast back to solicitations? Thanks, Phil ----- Original Message ----- From: "Phil Neumiller" To: "Charles E. Perkins" ; Cc: "MobileIP" Sent: Wednesday, May 29, 2002 3:05 PM Subject: [mobile-ip] Question on RFC 3220 - Agent Advertisement messages in Manets > Charlie, > > Suppose one wishes to use MIP with a MANET. Futhermore, suppose one performs an agent advertisement > solicitation. This will normally result in a specially formatted route advertisment which would work fine provided > you had an actual subnet! In the case of a mesh or MANET with no local topologically correct prefixing the > only solution is to have all nodes flood these advertisements over the entire MANET network right? Yuck! > Why couldn't the Agent Advertisement be optionally unicast back to the solicitor MN. > > Thanks, > > Phil > > -- > Phillip D. Neumiller (pneumiller@meshnetworks.com) > My PGP key can be imported from the following URL: > http://pgpkeys.mit.edu From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 09:23:37 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03388 for ; Thu, 30 May 2002 09:23:37 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21079; Thu, 30 May 2002 07:24:48 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA18129; Thu, 30 May 2002 06:23:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UDN8rP002756 for ; Thu, 30 May 2002 06:23:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UDN8AA002755 for mobile-ip-dist; Thu, 30 May 2002 06:23:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UDN5rP002748 for ; Thu, 30 May 2002 06:23:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17771 for ; Thu, 30 May 2002 06:23:06 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA08408 for ; Thu, 30 May 2002 07:23:06 -0600 (MDT) Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LQF67PDB; Thu, 30 May 2002 09:23:05 -0400 Message-ID: <002701c207dd$21e09b50$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Phil Neumiller" , "Charles E. Perkins" Cc: "MobileIP" References: <007901c20743$d0cffc90$ab0110ac@meshnetworks.com> <001f01c207dc$05dd3d60$ab0110ac@meshnetworks.com> Subject: [mobile-ip] RFC 3220 - Agent Solicitation TTL = 1? Date: Thu, 30 May 2002 09:23:05 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I am not sure I understand the TTL = 1 thing in agent soliciation messages. In a multi-hop network, the only choice seems to propagate the subnet masks of HA/FA to all mobiles in the subnet if DHCP is used and proxy response to the solicitor with HA/FA subnet mask right? From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 10:14:06 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06132 for ; Thu, 30 May 2002 10:14:05 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19351; Thu, 30 May 2002 08:15:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28140; Thu, 30 May 2002 07:13:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UECrrP002927 for ; Thu, 30 May 2002 07:12:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UECrxh002926 for mobile-ip-dist; Thu, 30 May 2002 07:12:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UECmrP002919 for ; Thu, 30 May 2002 07:12:49 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16844 for ; Thu, 30 May 2002 07:12:43 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19702 for ; Thu, 30 May 2002 08:12:42 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 037D9355B; Thu, 30 May 2002 09:12:42 -0500 (CDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id CF40BE8B; Thu, 30 May 2002 07:12:39 -0700 (PDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id KAA0001977352; Thu, 30 May 2002 10:12:38 -0400 (EDT) Message-ID: <3CF632B4.2B749EAE@hp.com> Date: Thu, 30 May 2002 10:09:56 -0400 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Devarapalli Cc: Jari Arkko , "Hesham Soliman (ERA)" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 References: <4DA6EA82906FD511BE2F00508BCF0538044F06A4@Esealnt861.al.sw.ericsson.se> <3CF54FE3.3050505@kolumbus.fi> <3CF5915D.634A794F@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > values 133 to 137 had some kind of meaning in the earlier > versions of the MIPv6 ID. I am sure that there is still some > code in some implementations dealing with these sequence > numbers. I would advise against compressing the list. it > is going to be a nightmare at the next interop. But there is no way a draft 15 implementation will ever work with a draft 17 (or 18) one, so now is the perfect time to compress them, especially since it's a one-line change to a header file. -Brian From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 10:30:00 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06885 for ; Thu, 30 May 2002 10:30:00 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13761; Thu, 30 May 2002 08:30:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01928; Thu, 30 May 2002 07:29:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UETIrP003024 for ; Thu, 30 May 2002 07:29:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UETI3s003023 for mobile-ip-dist; Thu, 30 May 2002 07:29:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UETErP003016 for ; Thu, 30 May 2002 07:29:14 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA04945 for ; Thu, 30 May 2002 07:29:11 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13267 for ; Thu, 30 May 2002 08:29:11 -0600 (MDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id B13E1806; Thu, 30 May 2002 07:33:40 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche2.zk3.dec.com [16.140.160.162]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 0EA0C126A; Thu, 30 May 2002 09:29:08 -0500 (CDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id KAA0001385369; Thu, 30 May 2002 10:29:06 -0400 (EDT) Message-ID: <3CF6368F.75676574@hp.com> Date: Thu, 30 May 2002 10:26:23 -0400 From: Brian Haley Organization: Tru64 UNIX Networking X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Krishna Kumar Cc: Basavaraj.Patil@nokia.com, PRoberts@MEGISTO.com, jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: MIPv6 - 17 Review References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Krishna Kumar wrote: > 11. Section 7.5 : > > - MinRtrAdvInterval 0.05 seconds > - MaxRtrAdvInterval 1.5 seconds > > This interval is too long, a range of 30 times. If the router is using > 1.5 > seconds (using Advertisement Interval Option), the MN may need a very > long > time to register the fact that it has moved, probably having to miss a > few > of these router advertisements. I think suggested values should be in > the > range of 0.05 to 0.25 seconds at the most, implementors are welcome to > increase this if they want, but Mobile Specs should be more stringent on > smooth handoff. I would agree, but would set the range at 0.05 to 0.15 seconds, although I've found .2 to .5 is adequate for MNs on an Ethernet. > 19. Section 10.2 : The para about : > > "- The Refresh field MUST be set to a value less than or equal to" > > Is Refresh useful at all ? I don't believe it is. I don't feel it's necessary either, since the HA can always send a BRR to the MN if it doesn't feel it's refreshed the binding soon enough. -Brian From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 11:36:39 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09333 for ; Thu, 30 May 2002 11:36:38 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29752; Thu, 30 May 2002 08:36:13 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22995; Thu, 30 May 2002 08:35:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UFZLrP003249 for ; Thu, 30 May 2002 08:35:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UFZKHV003248 for mobile-ip-dist; Thu, 30 May 2002 08:35:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UFZIrP003241 for ; Thu, 30 May 2002 08:35:18 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06906 for ; Thu, 30 May 2002 11:35:18 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g4UFZJqp022711 for ; Thu, 30 May 2002 11:35:19 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g4UFZJU2022710 for mobile-ip@sunroof.eng.sun.com; Thu, 30 May 2002 11:35:19 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4U15BrP000712 for ; Wed, 29 May 2002 18:05:12 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA13697 for ; Wed, 29 May 2002 18:05:15 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12796 for ; Wed, 29 May 2002 19:05:15 -0600 (MDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g4U153g5193756; Wed, 29 May 2002 21:05:03 -0400 Received: from gateway1.beaverton.ibm.com (gateway1.beaverton.ibm.com [138.95.180.2]) by northrelay03.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g4U14xJ57702; Wed, 29 May 2002 21:04:59 -0400 Received: from eng2.beaverton.ibm.com (eng2.beaverton.ibm.com [9.47.57.17]) by gateway1.beaverton.ibm.com (8.11.6/8.11.6) with ESMTP id g4U15S930626; Wed, 29 May 2002 18:05:28 -0700 Received: (from kkumar@localhost) by eng2.beaverton.ibm.com (8.10.0.Beta10/8.8.5/token.aware-1.2) id g4U14w319947; Wed, 29 May 2002 18:04:58 -0700 (PDT) From: Krishna Kumar Message-Id: <200205300104.g4U14w319947@eng2.beaverton.ibm.com> Subject: [mobile-ip] Re: MIPv6 - 17 Review (Fixed tabs, please ignore earlier mail) To: Basavaraj.Patil@nokia.com, PRoberts@MEGISTO.com, jari.arkko@kolumbus.fi Date: Wed, 29 May 2002 18:04:57 -0700 (PDT) Cc: mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi all, My other mailer from where I sent this mail earlier (Lotus Notes!) removes all tabs and puts spaces (UGH!), and hence it is quite un-readable. I am sending the same mail from my unix mailer. Sorry about sending this twice. Thanks, - KK Hi folks, I have read all but the Security related sections of the draft, and have the following comments. Thanks, - KK *************************** Technical Comments **************************** 1. Section 6.1.3 : The Header Len value is incorrect if the option is present. According to the draft, the size would be 2 + size of mobility options in 8 octets = 2 + 1 = 3. In reality, the packet would be 12 bytes long till the options, and since the UID aligns at offset of 2n (and 12 happens to be a multiple of 2n), the UID option will fit right at the end of the Message Data field of the MH. So total length is 12 + 4 = 16 bytes = 2 (and not 3). The draft should definitely change the statement to something like : "The Header Length field in the Mobility Header for this message MUST be set to 12 bytes + the length of padding if necessary before possible options + the total length of all mobility options present, divided by 8, to give a value in units of 8. If no actual options are present in this message, 4 bytes of padding is necessary." 2. Section 6.1.4 : Same as #1 above. Section 6.1.8 happens to be correct in this respect due to following magic : a. different alignment of option, AND b. different length of the option. (2 bytes extra in both adding to 4 bytes). 3. Section 6.1.7 : Clarify in following para, that the address is the Home Address : "When a packet contains both a Home Address destination option and a Binding Update message, the sender MUST use the same *home* address in both." 4. Section 6.1.8 : In the third last para, the following line : "If no actual options are present in this message, 4 bytes of Pad1 or PadN mobility options are needed" The " 4 bytes of Pad1 or" should be removed, since Section 6.2.2 prohibits using multiple Pad1 options. 5. Section 6.2.3 : "For N octets of padding, the Option Len field contains the value N , and the Option Data consists of N-2 zero-valued octets." should be changed to : "For N octets of padding, the Option Len field contains the value N - 2, and the Option Data consists of N-2 zero-valued octets." This is as per description of Option Len in 6.2.1. 6. Section 6.2.4 : "2 4 Unique Identifier" should be change to "2 2 Unique Identifier". 7. Section 6.2.5 : "3 18" should be changed to "3 16" 8. Section 6.2.6 : "4 6" should be changed to "4 4" 9. Section 6.2.7 : "5 2 + Len" should be changed to "5 Len" And subsequent reference to "2 + Len" should be changed to "Len". 10. Section 6.8 : Under description of "Destination Address" : "Otherwise, the mobile node's home address SHOULD be used." Why is that so ? This is unsolicited Prefix Advertisement, so how can the Home Agent find this home address if it is not registered with it (and thus not present in the binding cache) ? And this also conflicts with the first sentence in this section anyway, "A home agent will send a Mobile Prefix Advertisement message to a mobile node to distribute prefix information about the home link while the mobile node is traveling away from the home network." Shouldn't this be removed ? 11. Section 7.5 : - MinRtrAdvInterval 0.05 seconds - MaxRtrAdvInterval 1.5 seconds This interval is too long, a range of 30 times. If the router is using 1.5 seconds (using Advertisement Interval Option), the MN may need a very long time to register the fact that it has moved, probably having to miss a few of these router advertisements. I think suggested values should be in the range of 0.05 to 0.25 seconds at the most, implementors are welcome to increase this if they want, but Mobile Specs should be more stringent on smooth handoff. 12. Section 8.1 : There has been some discussion on this, but I don't know what the final consensus is. But I feel that the first "MUST" for processing Home Address option should be changed to "SHOULD". If the node is processing this option, it should have a Binding Cache (since the MN would have sent this option only after establishing a Binding Cache). Since the third point is using "SHOULD", this one too should use "SHOULD". Making all three a "MUST" might be restricting some implementation of special mobile devices, which might not need the full functionality, eg a MN which is going to interact with a CN, and never with another MN (this is the scenario where the second bullet is not applicable). 13. Section 9.1 : Remove the two bullets under : "- A flag indicating whether or not this Binding Cache entry represents a mobile node" ... AND " - The length of the routing prefix for the home address. This" ... Both of these have been removed since draft 14/15 or so. The second one need not be replaced with the 'S' bit flag, since the implementation of the 'S' bit would create multiple entries in the binding cache anyway. Hence both of these can be removed. 14. Section 9.4.5 : The last sentence of the second para should be changed to : "When the mobile node receives a packet from some sender containing a Binding Refresh Request option, it MUST confirm that a binding exists in it's BUL for this sender, and then it MAY start a return routability procedure, if necessary, before sending its current binding and a new lifetime in a new Binding Update. This is to prevent Denial of service attacks. 15. Section 10.2 : The 4th bullet is confusing to me. It looks like a BU to HA MUST have both BU as well as a Home Address option, while to a CN, the BU MUST NOT have the Home Address option. I guess this was a subject of debate on the mailing list, but I didn't follow it if it happened. Is this a conscious decision to have two Home Addresses when sending to HA, and is it really necessary ? 16. Section 10.2 : The 5th bullet should be changed to : "This ensures that no other node on the home link was using the mobile node's home address when the Binding Update arrived". 17. Section 10.2 : The 5th bullet needs another modification : "When the home agent sends a successful Binding Acknowledgement to the mobile node, in response to a Binding Update with the `D' bit set, the home agent assures to the mobile node that its home address will continue to be kept unique by the home agent at least as long as the lifetime granted for that home address binding is not over, or while the mobile node transmits Binding Updates with new care-of addresses for that home address. 18. Section 10.2 : The para about 'S' bit should be changed to : "The set of such home addresses is formed by replacing the routing prefix for the given home address with all other routing prefixes *on the mobile node's home link* that are supported by the home agent processing the Binding Update. This is correctly stated 2 bullets below in the "However, if the 'S' bit" ... para ... 19. Section 10.2 : The para about : "- The Refresh field MUST be set to a value less than or equal to" Is Refresh useful at all ? I don't believe it is. It seems to imply that it helps in the case of the Home Agent crashing and has only a volatile storage for the binding cache. But if the Home Agent crashed before the Refresh interval is over, the behaviour is identical to the case where the Refresh field contains the same value as Lifetime. It will be useful only if the HA crashed after the Refresh interval but before the Lifetime interval. Hence it is completely useless in most situations. If this can be removed safely, all references need to be removed in the draft and the Format of the BU section (6.1.8) needs to reflect this. 20. Section 10.4 : The first bullet is slightly wrong. It should say : "- The home agent examines the value of the `S' bit in the new "home registration" Binding Update Packet. If this bit is nonzero," ... The HA has just got a BU packet from MN, and the Binding Cache entry did not exist. Also the Binding Cache doesn't contain a 'S' bit field. We should specify that the HA looks at the BU packet and not the BC entry. 21. Section 10.4 : Part of the last para should be changed to : "In addition, the Router (R) bit in the Advertisement MUST be set to zero. Acting as a proxy ....". 22. Section 10.5 : First sentence of the second para should be changed to : "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 'S' bit was zero in the Binding Update), as described in Section 10.4." Prefix Len is removed. 23. Section 11.2.3 : "- The segments left field in the RH is either 0 or 1." This should be 1 since that is the value set. Also, section 6.4.1 confirms that. 24. Section 11.6.2 : Do we need to mention that the binding to CN be done only after getting a success BA from the HA. I am referring to : "When a mobile node sends a Binding Update to its home agent to register a new primary care-of address (as described in Section 11.6.1), the mobile node SHOULD also start a return routability procedure to each other node for which an entry exists in the mobile node's Binding Update List, as detailed below. Upon successful return routability procedure, a Binding Update message is sent." ... The last sentence could be changed to : "Upon successful return routability procedure and after receiving a successful Binding Acknowledgement from the Home Agent, a Binding Update message is sent to all other nodes". 25. Section 11.6.2 : When the BU packet is formed, should it be specified that a Home Address option MUST NOT be included ? This is relevant to my comment on item #15. 26. Section 11.6.4 : In the second last para, the last sentence should be changed to : "In this case, the mobile node instead SHOULD return a Binding Update to the sender, in which the Lifetime field is set to zero and the care-of address (using a Alternate Care-Of Address option) is set to the mobile node's home address." The source address cannot be set to the Home Address due to ingress filtering, and this should be made more clear. 27. Section 11.6.7 : The last sentence of the second para should include some re-transmission policy in case the NS is lost. Otherwise the MN cannot send a BU to the Home Agent after returning to the Home Network. Some values need to be specified for timeout and number of retransmissions before the MN can assume that the Home Agent is dead (and possibly continue using it's home address and also continue to finish the returning home procedure). *********************************** Typos ************************************ 1. Section 6.1.6 : In the description of the Reserved field, remove the "and the one 32-bit field" since that field does not exist. 2. Section 6.1.7 : In the description of the Reserved field, change the statement to : "These fields are unused. ......" 3. Section 6.1.7 : In the description of the Sequence # field, the Section number 4.5 is wrong, it should be 5.5 4. Section 6.3 : In the 3rd last line of the first para, "MUST not" should be changed to "MUST NOT". 5. Section 6.8 : The first sentence under description of "Destination Address" should be rephrased as : "If this message is a response to a Mobile Prefix Solicitation, this field contains the Source Address field from that packet." 6. Section 7.6 : Last para, change the "it" to "it's" : "on it's current link, until its movement detection algorithm" 7. Section 10.1 : In the second para, the "SHOULD NOT" should be changed to "MUST NOT". Conflicts with Section 9.5 8. Section 10.2 : An extra "," at the beginning of : "- , However, if the `S' bit field in the Binding Update is zero," 9. Section 11.1 : In the second bullet item, add a "of". "* one of the mobile node's home addresses for typical Binding Updates (Sections 11.6.1 and 11.6.2), or" 10. Section 11.2.1 : Clarify home address means any of the home addresses in : "Likewise, if the mobile node uses any address other than its home address as the source of a packet sent while away from home" can be changed to : "Likewise, if the mobile node uses any address other than any of its home addresses as the source of a packet sent while away from home" 11. Section 11.6.1 : Change last Character of this section from "B" to "C" (appendix reference). 12. Section 11.7 : The last sentence seems to be mis-formed. Needs rephrasing. From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 12:29:04 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11993 for ; Thu, 30 May 2002 12:29:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10505; Thu, 30 May 2002 10:29:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11111; Thu, 30 May 2002 09:29:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UGSFrP003772 for ; Thu, 30 May 2002 09:28:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UGSFdH003771 for mobile-ip-dist; Thu, 30 May 2002 09:28:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UGSCrP003764 for ; Thu, 30 May 2002 09:28:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10847 for ; Thu, 30 May 2002 09:28:12 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16662 for ; Thu, 30 May 2002 10:28:10 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA08560; Thu, 30 May 2002 09:28:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4UGS9g27672; Thu, 30 May 2002 09:28:09 -0700 X-mProtect: <200205301628> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdWvzbaB; Thu, 30 May 2002 09:28:07 PDT Message-ID: <3CF65317.88606C16@iprg.nokia.com> Date: Thu, 30 May 2002 09:28:07 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: MobileIP Subject: [mobile-ip] Re: RFC 3220 - Agent Solicitation TTL = 1? References: <007901c20743$d0cffc90$ab0110ac@meshnetworks.com> <001f01c207dc$05dd3d60$ab0110ac@meshnetworks.com> <002701c207dd$21e09b50$ab0110ac@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > I am not sure I understand the TTL = 1 thing in agent soliciation messages. > In a multi-hop network, the only choice seems to propagate the subnet masks > of HA/FA to all mobiles in the subnet if DHCP is used and proxy response to > the solicitor with HA/FA subnet mask right? The original motivation for the restriction was to avoid martian invaders. For attaching an ad hoc network to a foreign agent, it makes sense to rescind the restriction, and in fact we have specified that in our drafts to the [manet] working group related to this point. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 12:49:52 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12745 for ; Thu, 30 May 2002 12:49:47 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28437; Thu, 30 May 2002 09:48:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19398; Thu, 30 May 2002 09:48:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UGlNrP003856 for ; Thu, 30 May 2002 09:47:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UGlNZU003855 for mobile-ip-dist; Thu, 30 May 2002 09:47:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UGlJrP003848 for ; Thu, 30 May 2002 09:47:19 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05224 for ; Thu, 30 May 2002 09:47:20 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11038 for ; Thu, 30 May 2002 10:47:19 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA09652; Thu, 30 May 2002 09:47:18 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4UGlGo21586; Thu, 30 May 2002 09:47:16 -0700 X-mProtect: <200205301647> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFkMqAs; Thu, 30 May 2002 09:47:14 PDT Message-ID: <3CF65792.647E6569@iprg.nokia.com> Date: Thu, 30 May 2002 09:47:15 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: John Williams Floroiu , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] are L2 triggers "secure" ? References: <3CED0C15.D65DCDB2@fokus.gmd.de> <016101c20276$91c29480$516015ac@T23KEMPF> <3CF567EE.94E8DCAB@iprg.nokia.com> <010401c2078e$77589640$b36015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit James Kempf wrote: > Rajeev, > > > I was away last week, and I am still catching up with e-mails. > > In general, I would like to keep the L2-specific issues including > > L2 trigger authentication away from a baseline FMIPv6 protocol. > > The protocol has to work on all link layers, and hence it must > > not be based on _specific L2 customizations_ or features. > > This is not to say that L2 features should not be exploited, however, > a > > baseline > > FMIPv6 protocol should consider IP authentication and performance > > issues. Link-specific optimizations/customizations should be treated > > separately. > > > > Does this mean you do not want to mention anything about L2 security in > the base draft? If so, I think it may be necessary to then refer to the > L2 triggers draft or have a separate draft, as I believe the security > directorate will require some statement about security of L2 triggers. I > believe this is so regardless of which algorithm is considered. > Actually, I would like to keep the focus on IP protocol messages, while keeping room for using L2 triggers. I don't see any problem in (informatively) referencing L2 triggers draft. Regards, -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 13:21:23 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13885 for ; Thu, 30 May 2002 13:21:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02796; Thu, 30 May 2002 11:21:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18427; Thu, 30 May 2002 10:21:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UHKTrP004020 for ; Thu, 30 May 2002 10:20:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UHKTY5004019 for mobile-ip-dist; Thu, 30 May 2002 10:20:29 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UHKPrP004012 for ; Thu, 30 May 2002 10:20:26 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16009 for ; Thu, 30 May 2002 10:20:25 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18341 for ; Thu, 30 May 2002 10:20:24 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA11990; Thu, 30 May 2002 10:20:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4UHKNY06021; Thu, 30 May 2002 10:20:23 -0700 X-mProtect: <200205301720> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdD4IiIf; Thu, 30 May 2002 10:20:21 PDT Message-ID: <3CF65F56.5F7E1592@iprg.nokia.com> Date: Thu, 30 May 2002 10:20:22 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: mobileip@ietf.org, MobileIP Subject: Re: [mobile-ip] Question on RFC 3220 - Agent Advertisement messages in Manets References: <007901c20743$d0cffc90$ab0110ac@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > Suppose one wishes to use MIP with a MANET. Futhermore, suppose one > performs an agent advertisement solicitation. This will normally result > in a specially formatted route advertisment which would work fine provided > you had an actual subnet! In the case of a mesh or MANET with no local > topologically correct prefixing the only solution is to have all nodes > flood these advertisements over the entire MANET network right? Yuck! > Why couldn't the Agent Advertisement be optionally unicast back to the > solicitor MN. There are lots of answers here, and it really depends on your assumptions. 1) Of course, you can unicast the advertisement back, according to whatever specification someone writes and gets standardized (or not!). 2) [manet] standards did not exist in 1996 (nor even 2002.45) so Mobile IP standards are not written for the convenience of mobile ad hoc networks. 3) Mobile IP agent advertisements are allowed to be unicast. 4) The router broadcasting the prefix advertisement DOES have to provide connectivity to the prefix it advertises, and NOT necessarily to any specific node within the manet that does not share the prefix. Ad hoc protocols can be viewed as creating host routes for cases where nodes do not share a common prefix, but by no means should preclude useful operation where nodes DO share a common prefix. In fact, you can autoconfigure care-of addresses to get global connectivity and all the other stuff you need, by careful address management and advertisement. If you want a standard, then by all means pick a method (if you like ours, so much the better!) and push! So, what exactly is your model and your need? Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 13:53:11 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15293 for ; Thu, 30 May 2002 13:53:11 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06793; Thu, 30 May 2002 10:52:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02197; Thu, 30 May 2002 10:52:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UHphrP004298 for ; Thu, 30 May 2002 10:51:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UHphVS004297 for mobile-ip-dist; Thu, 30 May 2002 10:51:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UHpdrP004290 for ; Thu, 30 May 2002 10:51:39 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01696 for ; Thu, 30 May 2002 10:51:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20083 for ; Thu, 30 May 2002 11:51:38 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA13878; Thu, 30 May 2002 10:51:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4UHpbP09432; Thu, 30 May 2002 10:51:37 -0700 X-mProtect: <200205301751> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKTUPol; Thu, 30 May 2002 10:51:36 PDT Message-ID: <3CF666A8.D3F691F2@iprg.nokia.com> Date: Thu, 30 May 2002 10:51:36 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: jari.arkko@kolumbus.fi, keiichi@iij.ad.jp CC: hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 References: <4DA6EA82906FD511BE2F00508BCF0538044F06A4@Esealnt861.al.sw.ericsson.se> <3CF54FE3.3050505@kolumbus.fi> <3CF5915D.634A794F@iprg.nokia.com> <20020530.121237.120953247.keiichi@iij.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Keiichi and Jari, let me explain myself again. unverified HAO MUST not be accepted because of reflection attacks. HAO verification at the CN can be done in two ways. 1. checking for a valid BCE 2. an IPsec association between the CN and MN. ( I am talking about triangle routing. it is possible because the CN knows the MN and trusts it not to do any reflection attacks). this also corresponds to the case (2) from you text. > unprotected IPseced > HAO HAO > (2) BE go ahead -> triangular(?) here, HAO can infact be processed and accepted without RO. so, thats why I am saying HAO processing got be a MUST. there is no harm because unverified HAO is never accepted. another example (you might consider it rare) is an intranet, in which CN can process and accept HAO from any MN inside the domain. here the HAO verification comes from fact that both the CN and the MN belong to the same domain and trust each other not to cause any reflection attacks. also take a look at the thread "How to process HAO", in which we all agreed to Francis Dupont's suggestion. do the verification just before "upper layer" processing. and the verification routine uses IPsec match, BCE check or another appropriate mechanism. regards Vijay Keiichi SHIMA / $BEg7D0l(B wrote: > > Hi Vijay, > > From: Vijay Devarapalli > > > > > > - Section 8.1,what is the point of mandating the HAO > > > > when the spec says that it must not be received > > > > without a BCE, and the entire RO is a 'should'.? > > > > The HAO should follow the same recommendation as RO. > > > > > > I agree. Should be the same as the rest. > > > > isnt there a danger here? lets assume the MN sends a IPsec > > protected BU to a CN. there is no BCE at the CN. but the CN > > still has to process the HAO. the other two SHOULDs in > > section 8.1 do not affect the processing of HAO. > > > > I think it should left as MUST. we should be fine as long as > > the spec requires that the CN does not process unverified HoA. > > Really? > > I think there are three type of CN. > > (1) traditional IPv6 node > (2) HAO aware CN > (3) full MIP6 CN > > The CNs will process HAO as follows, > > unprotected IPseced > HAO HAO > (1) ICMP paramprob ICMP paramprob -> bidir-tunnel > (2) BE go ahead -> triangular(?) > (3) BE go ahead -> ROed communication > > At least, (1) is not required to support processing HAO. I think HAO > processing must be 'SHOULD'. There is no reason to mandate it. > > Am I correct? > > Best Regards, > > --- > Keiichi SHIMA > IIJ Research Laboratory > KAME Project From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 14:24:09 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16354 for ; Thu, 30 May 2002 14:24:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08857; Thu, 30 May 2002 12:25:18 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27041; Thu, 30 May 2002 11:24:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UINIrP004502 for ; Thu, 30 May 2002 11:23:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UINI53004501 for mobile-ip-dist; Thu, 30 May 2002 11:23:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UINFrP004494 for ; Thu, 30 May 2002 11:23:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16960 for ; Thu, 30 May 2002 11:23:14 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18160 for ; Thu, 30 May 2002 12:23:13 -0600 (MDT) Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LQF67PQJ; Thu, 30 May 2002 14:23:07 -0400 Message-ID: <007901c20807$0c05dfa0$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: "MobileIP" References: <007901c20743$d0cffc90$ab0110ac@meshnetworks.com> <3CF65F56.5F7E1592@iprg.nokia.com> Subject: Re: [mobile-ip] Question on RFC 3220 - Agent Advertisement messages in Manets Date: Thu, 30 May 2002 14:23:07 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > There are lots of answers here, and it really depends on your assumptions. > > 1) Of course, you can unicast the advertisement back, according to whatever > specification someone writes and gets standardized (or not!). I guess I thought this might be an easy sell for the IESG to add into 3220 no? > > 2) [manet] standards did not exist in 1996 (nor even 2002.45) so Mobile IP > standards are not written for the convenience of mobile ad hoc networks. Yeah, I have really been noticing that a lot lately!!! :-) > > 3) Mobile IP agent advertisements are allowed to be unicast. REALLY? The ICMP router advertisment (Deering) does not allow them as far as I can tell. How do we configure this? Is that the intent of RFC-3220? The spec seemed a bit foggy on this notion to me. It would be really nice if the RFC said something like: the FA/HA MUST support a unicast response when the U bit is set in the solicitation message. THIS IS WHAT I REALLY NEED!!! (Sorry for shouting). > > 4) The router broadcasting the prefix advertisement DOES have to provide > connectivity to the prefix it advertises, and NOT necessarily to > any specific node within the manet that does not share the prefix. > Ad hoc protocols can be viewed as creating host routes for cases > where nodes do not share a common prefix, but by no means should > preclude useful operation where nodes DO share a common prefix. Not really fully fledged host routes since we are still routing based on next hop right? I > > In fact, you can autoconfigure care-of addresses to get global > connectivity and all the other stuff you need, by careful address > management and advertisement. If you want a standard, then by > all means pick a method (if you like ours, so much the better!) > and push! > > So, what exactly is your model and your need? See above! Thanks, Phil From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 17:11:40 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20080 for ; Thu, 30 May 2002 17:11:40 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA12725; Thu, 30 May 2002 15:11:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01859; Thu, 30 May 2002 14:11:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ULAlrP004882 for ; Thu, 30 May 2002 14:10:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4ULAlEg004881 for mobile-ip-dist; Thu, 30 May 2002 14:10:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ULAirP004874 for ; Thu, 30 May 2002 14:10:44 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01636 for ; Thu, 30 May 2002 14:10:44 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10046 for ; Thu, 30 May 2002 15:11:43 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA25000; Thu, 30 May 2002 14:10:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4ULAfE02081; Thu, 30 May 2002 14:10:41 -0700 X-mProtect: <200205302110> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdKX94AO; Thu, 30 May 2002 14:10:39 PDT Message-ID: <3CF6954F.E395C430@iprg.nokia.com> Date: Thu, 30 May 2002 14:10:39 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: MobileIP Subject: Re: [mobile-ip] Question on RFC 3220 - Agent Advertisement messages in Manets References: <007901c20743$d0cffc90$ab0110ac@meshnetworks.com> <3CF65F56.5F7E1592@iprg.nokia.com> <007901c20807$0c05dfa0$ab0110ac@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: >> 1) Of course, you can unicast the advertisement back, according to whatever >> specification someone writes and gets standardized (or not!). > > I guess I thought this might be an easy sell for the IESG to add into 3220 no? I forgot when it was ever easy. You should voice your concerns if you want them to be attended. >> 2) [manet] standards did not exist in 1996 (nor even 2002.45) so Mobile IP >> standards are not written for the convenience of mobile ad hoc networks. > > Yeah, I have really been noticing that a lot lately!!! :-) I have noticed that when one mentions "manet" and "standards" in the same sentence, people often have strange reactions. >> 3) Mobile IP agent advertisements are allowed to be unicast. > > REALLY? The ICMP router advertisment (Deering) does not allow them as > far as I can tell. How do we configure this? Is that the intent of RFC-3220? > The spec seemed a bit foggy on this notion to me. It would be really nice if > the RFC said something like: > > the FA/HA MUST support a unicast response when the U bit is set in the > solicitation message. > > THIS IS WHAT I REALLY NEED!!! (Sorry for shouting). From RFC 3220, section 2.1, page 18... =================================================================================== Destination Address As specified for ICMP Router Discovery [10], the IP destination address of an multicast Agent Advertisement MUST be either the "all systems on this link" multicast address (224.0.0.1) [11] or the "limited broadcast" address (255.255.255.255). The subnet-directed broadcast address of the form .<-1> cannot be used since mobile nodes will not generally know the prefix of the foreign network. When the Agent Advertisement is unicast to a mobile node, the IP home address of the mobile node SHOULD be used as the Destination Address. =================================================================================== Is this good enough? >> 4) The router broadcasting the prefix advertisement DOES have to provide >> connectivity to the prefix it advertises, and NOT necessarily to >> any specific node within the manet that does not share the prefix. >> Ad hoc protocols can be viewed as creating host routes for cases >> where nodes do not share a common prefix, but by no means should >> preclude useful operation where nodes DO share a common prefix. > > Not really fully fledged host routes since we are still routing based on > next hop right? A host route still only has to determine the next hop, not the whole routing path. >> In fact, you can autoconfigure care-of addresses to get global >> connectivity and all the other stuff you need, by careful address >> management and advertisement. If you want a standard, then by >> all means pick a method (if you like ours, so much the better!) >> and push! >> >> So, what exactly is your model and your need? > > See above! Hmmm... I still am not sure, though. But if you say this meeds the need, then O.K.! Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 17:59:19 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20784 for ; Thu, 30 May 2002 17:59:19 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10258; Thu, 30 May 2002 14:58:55 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA28359; Thu, 30 May 2002 14:58:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ULw2rP004999 for ; Thu, 30 May 2002 14:58:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4ULw1hw004998 for mobile-ip-dist; Thu, 30 May 2002 14:58:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4ULvwrP004991 for ; Thu, 30 May 2002 14:57:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA18465 for ; Thu, 30 May 2002 14:57:58 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14554 for ; Thu, 30 May 2002 15:57:57 -0600 (MDT) Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LQF67PZQ; Thu, 30 May 2002 17:57:55 -0400 Message-ID: <001401c20825$0de2e160$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: "MobileIP" References: <007901c20743$d0cffc90$ab0110ac@meshnetworks.com> <3CF65F56.5F7E1592@iprg.nokia.com> <007901c20807$0c05dfa0$ab0110ac@meshnetworks.com> <3CF6954F.E395C430@iprg.nokia.com> Subject: Re: [mobile-ip] Question on RFC 3220 - Agent Advertisement messages in Manets Date: Thu, 30 May 2002 17:57:55 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Charlie and thanks for the quick response. I tried to keep this short, but... :-) > From RFC 3220, section 2.1, page 18... > =================================================================================== > > Destination Address > > As specified for ICMP Router Discovery [10], the IP > destination address of an multicast Agent Advertisement > MUST be either the "all systems on this link" multicast > address (224.0.0.1) [11] or the "limited broadcast" > address (255.255.255.255). The subnet-directed broadcast > address of the form .<-1> cannot be used since > mobile nodes will not generally know the prefix of the > foreign network. When the Agent Advertisement is unicast > to a mobile node, the IP home address of the mobile node > SHOULD be used as the Destination Address. > > =================================================================================== > > Is this good enough? I don't know. Maybe I am really confused but nobody has probably ever asked this question before so let me try (then again how many commercial vendors are mixing MIP with MANETs :-)? Assume the MN uses its home address to route on in its home MANET. Now assume the mobile has moved to a foreign MANET. NOTE: Subnet directed broadcasts are meaningless in a MANET unless you simulate them with a MANET flood. A periodic MANET flood could be used to do the FA advertisements to all MANET/MIP MNs new and old that are "reachable" on the MANET (i.e. have converged routes). Now these reachable MNs MUST put the FA address in a periodic hello message. So every MN that is part of the MANET is advertising the FA via a hello message rather than having the FA do more periodic MANET floods (which I believe to be much more expensive). So the new MN (which still only has its MIP home address) can see the FA address in a hello and decides to do a RREQ to the FA. Once this route has converged the MN can then perform a MIP FA COA binding to the HA. [ BTW: This seems like a pretty ugly way to do a handover.] Upon further reflection, I guess you can't really use solicitation at all in this case because you have to have a route to/from the FA to begin with??? So my original question was probably bogus. I realize that this seems like a ball of confusion and probably is but I think we are breaking new ground here. Do you have a suggestion on how to make this work better? In summary (whew!). o We can't use solicitations unless they are flooded across the MANET to reach the FA (bad idea). o We can do periodic subnet directed broadcast agent advertisements from the FA, but these will only reach the first hop around the FA without flooding. It is then the responsibility of the first ring of nodes to start advertising the FA address in periodic hello messages and this propogates through the whole MANET. It is further more the responsibility of MNs hearing the FA advertisement via AODV hello to start their own periodic agent advertisement. o New nodes entering the foreign subnets will start to hear these hello message agent advertisements and be able to do a RREQ and then a MIP handover. I seem to be missing something critical here. YUCK! Phil From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 18:11:13 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20947 for ; Thu, 30 May 2002 18:11:13 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA13185; Thu, 30 May 2002 16:11:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA03367; Thu, 30 May 2002 15:11:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UMAWrP005124 for ; Thu, 30 May 2002 15:10:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UMAV5I005123 for mobile-ip-dist; Thu, 30 May 2002 15:10:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UMASrP005116 for ; Thu, 30 May 2002 15:10:28 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA22265 for ; Thu, 30 May 2002 15:10:28 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA15458 for ; Thu, 30 May 2002 16:10:28 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA27990; Thu, 30 May 2002 15:10:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4UMAPt03750; Thu, 30 May 2002 15:10:25 -0700 X-mProtect: <200205302210> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdrmdp0u; Thu, 30 May 2002 15:10:24 PDT Message-ID: <3CF6A350.8EBAF3EE@iprg.nokia.com> Date: Thu, 30 May 2002 15:10:24 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Phil Neumiller CC: MobileIP , "Elizabeth M.Belding-Royer" Subject: Re: [mobile-ip] Question on RFC 3220 - Agent Advertisement messages in Manets References: <007901c20743$d0cffc90$ab0110ac@meshnetworks.com> <3CF65F56.5F7E1592@iprg.nokia.com> <007901c20807$0c05dfa0$ab0110ac@meshnetworks.com> <3CF6954F.E395C430@iprg.nokia.com> <001401c20825$0de2e160$ab0110ac@meshnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Phil, Phil Neumiller wrote: > o We can't use solicitations unless they are flooded across the MANET to reach > the FA (bad idea). > o We can do periodic subnet directed broadcast agent advertisements from the > FA, but these will only reach the first hop around the FA without flooding. > It is then the responsibility of the first ring of nodes to start advertising > the FA address in periodic hello messages and this propogates through the > whole MANET. It is further more the responsibility of MNs hearing the FA > advertisement via AODV hello to start their own periodic agent advertisement. > o New nodes entering the foreign subnets will start to hear these hello message > agent advertisements and be able to do a RREQ and then a MIP handover. What do you think about the following drafts? draft-royer-manet-globalv4-00.txt draft-wakikawa-manet-globalv6-00.txt draft-perkins-manet-autoconf-01.txt These have been implemented and tested. Updates are needed, but the basic ideas are there. It's not quite a trivial problem, and it's even more fun if you have multiple access routers/ foreign agents. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 18:18:05 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21088 for ; Thu, 30 May 2002 18:18:04 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19844; Thu, 30 May 2002 15:17:42 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA10139; Thu, 30 May 2002 15:17:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UMGsrP005205 for ; Thu, 30 May 2002 15:16:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4UMGsQ3005204 for mobile-ip-dist; Thu, 30 May 2002 15:16:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4UMGprP005197 for ; Thu, 30 May 2002 15:16:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24796 for ; Thu, 30 May 2002 15:16:51 -0700 (PDT) Received: from meshpdc.meshnetworks.com ([205.245.27.196]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28825 for ; Thu, 30 May 2002 15:16:50 -0700 (PDT) Received: from neumillersimul (gomez-desktop.meshnetworks.com [172.16.1.171]) by meshpdc.meshnetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LQF67P5C; Thu, 30 May 2002 18:16:49 -0400 Message-ID: <002e01c20827$b143c2f0$ab0110ac@meshnetworks.com> Reply-To: "Phil Neumiller" From: "Phil Neumiller" To: "Charles E. Perkins" Cc: "MobileIP" , "Elizabeth M.Belding-Royer" References: <007901c20743$d0cffc90$ab0110ac@meshnetworks.com> <3CF65F56.5F7E1592@iprg.nokia.com> <007901c20807$0c05dfa0$ab0110ac@meshnetworks.com> <3CF6954F.E395C430@iprg.nokia.com> <001401c20825$0de2e160$ab0110ac@meshnetworks.com> <3CF6A350.8EBAF3EE@iprg.nokia.com> Subject: Re: [mobile-ip] Question on RFC 3220 - Agent Advertisement messages in Manets Date: Thu, 30 May 2002 18:16:48 -0400 Organization: MeshNetworks, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I believe I commented on some of these before. I will take a new look at globalv4. BTW is this your answer to the NEMO problem? > What do you think about the following drafts? > draft-royer-manet-globalv4-00.txt > draft-wakikawa-manet-globalv6-00.txt > draft-perkins-manet-autoconf-01.txt > > These have been implemented and tested. Updates are > needed, but the basic ideas are there. > > It's not quite a trivial problem, and it's even > more fun if you have multiple access routers/ > foreign agents. > > Regards, > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 20:34:07 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22923 for ; Thu, 30 May 2002 20:34:06 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA15097; Thu, 30 May 2002 18:34:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA08832; Thu, 30 May 2002 17:34:10 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V0XUrP005527 for ; Thu, 30 May 2002 17:33:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4V0XUuP005526 for mobile-ip-dist; Thu, 30 May 2002 17:33:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V0XMrP005519 for ; Thu, 30 May 2002 17:33:22 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g4V0XL6U345403; Thu, 30 May 2002 17:33:21 -0700 (PDT) Message-Id: <200205310033.g4V0XL6U345403@jurassic.eng.sun.com> Date: Thu, 30 May 2002 17:35:48 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] comments on MIPv6 draft-17 To: jari.arkko@kolumbus.fi Cc: hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iW3VouuFr/aObdeilXzFNA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Jari, > > > - Section 6.1.3: Why is the HA tunnelling the HOT a SHOULD? > > It seems that this is one of the assumptions that the > > protocol is based on (see the security design section). > > Shouldn't this be a MUST? Not making this a MUST will > > allow attacker on the MNs link to do some nasty stuff. > > There was a separate thread about this a couple months > ago. It seems that the added benefit of encrypted tunneling > is quite useful, but mainly for the benefit of the mobile > node. Not absolutely necessary perhaps for the security > of other nodes. Hence SHOULD. I think Hesham has a good point here. If you look at the "More comments on Draft16 -CLARIFICATION " thread (issue #19), where I asked the same question that both HOTI/HOT messages must use ESP tunnel and I thought the decision was 'yes'. Here is some excerpt from that old email discussion: -------------------------------------------------------------------- > 2. > Also, we have had email discussion that only HOT message is sent in > ESP tunnel mode. For symmetry, we should mandate ESP tunnel mode for > both HOT/HOTI messages between MN-HA. Yes. This is especially important given the mobile-side cookies for weak CoT/HoT authentication (prevention of random nodes from the internet spoofing these). > Also, we need to clarify in the draft that ESP tunnel mode must(?) be used > over the MN-HA tunnel for binding update signalling HOTI/HOT traffic > only. The regular data traffic through the same MN-HA tunnel may not > necessarily be protected by ESP. Yes. --------------------------------------------------------------------------- It makes more sense to have MUST for both HOT/HOTI ESP tunnel mode. If the Mobile node can send HOTI message in ESP tunnel mode, it should be able to process incoming HOT ESP tunnel data. Otherwise, the protocol seems very assymetric and lacks required security as well. > > > - Section 8.1,what is the point of mandating the HAO > > when the spec says that it must not be received > > without a BCE, and the entire RO is a 'should'.? > > The HAO should follow the same recommendation as RO. > > I agree. Should be the same as the rest. > Are you adding a separate section on "CN behavior" to specify that all IPv6 nodes that support MobileIPv6 correspondent node functionality, MUST support Route Optimization ? This information is necessary to specify in the draft to avoid confusion on correspondent node implementation. Do we agree on that ? Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Thu May 30 20:56:29 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23213 for ; Thu, 30 May 2002 20:56:29 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA21066; Thu, 30 May 2002 18:56:40 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13408; Thu, 30 May 2002 17:56:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V0tgrP005737 for ; Thu, 30 May 2002 17:55:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4V0tgcF005736 for mobile-ip-dist; Thu, 30 May 2002 17:55:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4V0tdrP005729 for ; Thu, 30 May 2002 17:55:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA13229 for ; Thu, 30 May 2002 17:55:39 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA09619 for ; Thu, 30 May 2002 17:55:38 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA06533; Thu, 30 May 2002 17:55:38 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4V0tb605029; Thu, 30 May 2002 17:55:37 -0700 X-mProtect: <200205310055> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvpShEW; Thu, 30 May 2002 17:55:35 PDT Message-ID: <3CF6CA08.C810C71F@iprg.nokia.com> Date: Thu, 30 May 2002 17:55:36 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Samita Chakrabarti CC: jari.arkko@kolumbus.fi, hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on MIPv6 draft-17 References: <200205310033.g4V0XL6U345403@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit hi, Samita Chakrabarti wrote: > > Hi Jari, > > > > > > - Section 6.1.3: Why is the HA tunnelling the HOT a SHOULD? > > > It seems that this is one of the assumptions that the > > > protocol is based on (see the security design section). > > > Shouldn't this be a MUST? Not making this a MUST will > > > allow attacker on the MNs link to do some nasty stuff. > > > > There was a separate thread about this a couple months > > ago. It seems that the added benefit of encrypted tunneling > > is quite useful, but mainly for the benefit of the mobile > > node. Not absolutely necessary perhaps for the security > > of other nodes. Hence SHOULD. > > I think Hesham has a good point here. If you look at the > "More comments on Draft16 -CLARIFICATION " thread (issue #19), where > I asked the same question that both HOTI/HOT messages > must use ESP tunnel and I thought the decision was 'yes'. issue #14 was about "Require encryption on HA-MN tunnel for MH messages?". the issues list says the adopted concensus was MUST implement and SHOULD be used. Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 07:22:15 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11566 for ; Fri, 31 May 2002 07:22:15 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14295; Fri, 31 May 2002 04:21:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10250; Fri, 31 May 2002 04:21:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VBL1rP006636 for ; Fri, 31 May 2002 04:21:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VBL1gf006635 for mobile-ip-dist; Fri, 31 May 2002 04:21:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VBKwrP006628 for ; Fri, 31 May 2002 04:20:58 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA10115 for ; Fri, 31 May 2002 04:20:57 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11799 for ; Fri, 31 May 2002 04:20:53 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11307; Fri, 31 May 2002 07:20:26 -0400 (EDT) Message-Id: <200205311120.HAA11307@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mobile-ip@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: [mobile-ip] I-D ACTION:draft-ietf-mobileip-aaa-nai-02.txt Date: Fri, 31 May 2002 07:20:26 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : AAA NAI for Mobile IPv4 Extension Author(s) : F. Johansson, T. Johansson Filename : draft-ietf-mobileip-aaa-nai-02.txt Pages : 8 Date : 30-May-02 When a mobile node moves between two foreign networks it has to be reauthenticated. If the home network has multiple AAA servers the reauthentication request may not be received by the same AAAH as previous authentication requests. In order for the new AAAH to be able to forward the request to the correct HA it has to know the identity of the HA. This document defines an extension that enables the HA to pass its identity to the mobile node which can in turn pass it to the AAA server when changing point of attachment. This document specifies a NAI extension that can carry these NAIs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-nai-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-aaa-nai-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-aaa-nai-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: <20020530103411.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-aaa-nai-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-aaa-nai-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020530103411.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 12:33:21 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21627 for ; Fri, 31 May 2002 12:33:21 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20323; Fri, 31 May 2002 09:32:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14885; Fri, 31 May 2002 09:32:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VGVvrP007064 for ; Fri, 31 May 2002 09:31:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VGVvfL007063 for mobile-ip-dist; Fri, 31 May 2002 09:31:57 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VGVsrP007056 for ; Fri, 31 May 2002 09:31:54 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14599 for ; Fri, 31 May 2002 09:31:54 -0700 (PDT) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19686 for ; Fri, 31 May 2002 09:31:53 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 12:27:51 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Cc: Thomas Narten Subject: [mobile-ip] working group last call complete on NAT traversal Date: Fri, 31 May 2002 12:27:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The working group last call on NAT traversal has been closed. We are requesting IETF last call on version -03 of the document. The following changes were made as a result of WG last call: In section 3.1.2, a paragraph has been added pointing forward to a more thorough discussion of handling the case of registering through an FA with a co-locate care-of address. In section 3.2, the exact meaning of the 'F' flag has been clarified, and an 'E' flag has been added which enables a HA to require that the MN use icmp echo requests as keepalive messages, rather than registration requests. In section 3.4, some Agent Advertisement flags which are not covered by any RFC, but were proposed in other drafts have been removed. In section 4.4, a section has been added which clarifies the actions of a mobile node when receiving a registration reply from a home agent which does not understand the UDP Tunnelling Request Extension. In the same section, the use of the 'F' flag has been decoupled from the use of the 'R' flag when registering through an FA with a co-located CoA. In section 4.5 a paragraph has been added which points out that when an FA uses NAT traversal, it MUST send the RRQ with ip source address matching its CoA. Also, when discussing whether an FA should require reverse tunnelling or not, a default case has been added for use when the exact capabilities of the NAT is unknown. In section 4.6, the text has been changed to match the de-coupling of 'R' flag and 'F' flag in the co-located CoA registered through FA case. A paragraph has also been added here to clarify which address the HA should use as effective CoA when doing UDP tunnelling. In section 4.9, text has been added regarding the 'E' flag mentioned above, and the originator of keepalives has been changed to be the requestor of the UDP tunnel, rather than always being the MN. In 4.10, again some changes to de-couple the use of the 'F' and 'R' bit of UDP Tunnel Request Extensions. Section 6, Security condiderations, has been completely re-written, to more clearly discuss the different existing vulnerabilities. In section 7, IANA considerations, a paragraph has been added pointing to IANA's online database, and temporary values for use in interoperability testing has been suggested. The Acknowledgements has been updated, and the references has been split into Normative and Informative. Finally, in a number of places, the wording has been changed to be clearer and more easy to read. Henrik is submitting version -03 of the draft, until then it can be found here: The -03 version of the draft can be found at http://www.levkowetz.com/pub/id/draft-ietf-mobileip-nat-traversal-03.txt, and text with change bars marking the changes since -02 is here http://www.levkowetz.com/pub/id/changes-draft-ietf-mobileip-nat-traversal-02 ..3.txt From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 12:52:15 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22212 for ; Fri, 31 May 2002 12:52:15 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29755; Fri, 31 May 2002 09:51:51 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21748; Fri, 31 May 2002 09:51:32 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VGoRrP007228 for ; Fri, 31 May 2002 09:50:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VGoQFj007227 for mobile-ip-dist; Fri, 31 May 2002 09:50:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VGoHrP007205; Fri, 31 May 2002 09:50:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22178; Fri, 31 May 2002 09:50:18 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00635; Fri, 31 May 2002 09:50:17 -0700 (PDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4VGoDmG002488; Fri, 31 May 2002 18:50:13 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 18:49:48 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF053804593542@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins '" , "Hesham Soliman (ERA)" Cc: "'mobile-ip@sunroof.eng.sun.com '" , "'IPng Working Group '" Subject: RE: [mobile-ip] Issue #23 and Issue #30 Date: Fri, 31 May 2002 18:49:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Charlie, Sorry for the late reply. > => I think the HA must defend all addresses, including > the link-local one. This is related to RFC3041 and > Francis' discussion on the IPv6 list. A node implementing > RFC 3041 might form a global address that belongs to one of > the other MN's Home addresses. Hence, if the HA does not > defend all addresses, a MN might 'lose' one of its > home addresses to another node on the home link. I'd rather prohibit such behavior. I don't see the need for it. I am surprised that RFC 3041 would allow such behavior. Can you point out the offending part of the specification? What was the justification for enabling this? Aren't there "enough" random numbers in 2^64 to avoid clobbering addresses used byHi Charlie other nodes? sheesh... => RFC 2462 makes an optimisation (not a good one IMHO) that if a node does DAD on link-local addresses, it 'owns the interface id' for any other address with any scope. RFC3041 says that a node can generate a new iid and does DAD for _that_ address which uses the new iid. Since this is typically not a link local address, you could get a conflict if the HA does not defend all addresses. For more info, see Francis' thread on 'diid'. I won't be able to relpy quickly at least till monday. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 12:57:03 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22371 for ; Fri, 31 May 2002 12:57:03 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29394; Fri, 31 May 2002 10:57:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23995; Fri, 31 May 2002 09:57:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VGuUrP007336 for ; Fri, 31 May 2002 09:56:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VGuUPo007335 for mobile-ip-dist; Fri, 31 May 2002 09:56:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VGuQrP007328 for ; Fri, 31 May 2002 09:56:26 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05410 for ; Fri, 31 May 2002 09:56:27 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18748 for ; Fri, 31 May 2002 10:56:26 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4VGuMmG003138; Fri, 31 May 2002 18:56:22 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 18:55:52 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F06B6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Vijay Devarapalli '" , "'Jari Arkko '" Cc: "Hesham Soliman (ERA)" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] comments on MIPv6 draft-17 Date: Fri, 31 May 2002 18:55:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Vijay, > > - Why are certain values skipped for the BA status > > codes? e.g. between 133 and 137. I suggest we place them > > in order. It looks like some magic is attached to those > > missing numbers :) > > I don't know. Comments on the source files seem to indicate > some old (now removed) status field values occupied these > positions. Why don't we go and compress the list now. values 133 to 137 had some kind of meaning in the earlier versions of the MIPv6 ID. I am sure that there is still some code in some implementations dealing with these sequence numbers. I would advise against compressing the list. it is going to be a nightmare at the next interop. => This is not an update of an RFC, this is a draft. The least that people will have to worry about is changing constants for error codes in their implementation. There is an entire new protocol in the draft. I don't think this reason is valid. Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 13:02:27 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22557 for ; Fri, 31 May 2002 13:02:27 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05960; Fri, 31 May 2002 10:02:06 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26049; Fri, 31 May 2002 10:02:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VH15rP007440 for ; Fri, 31 May 2002 10:01:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VH15Ot007439 for mobile-ip-dist; Fri, 31 May 2002 10:01:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VH0wrP007429 for ; Fri, 31 May 2002 10:00:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25589 for ; Fri, 31 May 2002 10:00:59 -0700 (PDT) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20942 for ; Fri, 31 May 2002 11:00:58 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4VH0umG003589; Fri, 31 May 2002 19:00:56 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 19:00:54 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F06B7@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Erik Nordmark - Sun Microsystems '" , "Hesham Soliman (ERA)" Cc: "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] comments on MIPv6 draft-17 Date: Fri, 31 May 2002 19:00:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > - Page 96: In the four bullets there, I have the following > comments: > - Second bullet, the llA should be there IF the link > layer has link layer addresses. > - A pedantic question: What happens if ND is secured > with pre-configured SAs. Shouldn't the HA be configured > to act on behalf of MNs and send secure ND messages? My answer to the last sub-bullet is that worrying about IPsec protected (or otherwise secured ND) is for further study, since there isn't a deployable IETF standard for how to secure ND. => Well it is a pedantic comment, but if manual configuration of SAs (granted not scalable) is used, I'm not sure if we need a new standard for it. Anyway, it is an unlikely scenario. > - Page 115: 'The segments left in the RH is either > 0 or 1'. Zero? why is Zero ok? If an implementation processes RH type 2 the same way as type 0 (i.e. first swap addresses and decrement segments left and then feed the packet back into IP) then it will internally (but never on the wire) have RH type 2 with segments left being zero. Do we need to make this more clear in the document? => I think it would be nice to clarify that in the draft. Hesham Erik From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 13:05:03 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22644 for ; Fri, 31 May 2002 13:05:02 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA19509; Fri, 31 May 2002 11:05:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26889; Fri, 31 May 2002 10:04:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VH38rP007503 for ; Fri, 31 May 2002 10:03:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VH38jj007502 for mobile-ip-dist; Fri, 31 May 2002 10:03:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VH32rP007493; Fri, 31 May 2002 10:03:02 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28061; Fri, 31 May 2002 10:03:02 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08299; Fri, 31 May 2002 10:03:02 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA11970; Fri, 31 May 2002 10:03:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4VH30q18678; Fri, 31 May 2002 10:03:00 -0700 X-mProtect: <200205311703> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdGN8SjO; Fri, 31 May 2002 10:02:58 PDT Message-ID: <3CF7ACC3.9272AFBF@iprg.nokia.com> Date: Fri, 31 May 2002 10:02:59 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: "'mobile-ip@sunroof.eng.sun.com '" , "'IPng Working Group '" Subject: Re: [mobile-ip] Issue #23 and Issue #30 References: <4DA6EA82906FD511BE2F00508BCF053804593542@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 List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Hesham, "Hesham Soliman (ERA)" wrote: > => RFC 2462 makes an optimisation (not a good > one IMHO) that if a node does DAD on link-local > addresses, it 'owns the interface id' for any other > address with any scope. I think this is a good idea. > RFC3041 says that a node can generate a new iid > and does DAD for _that_ address which uses the > new iid. Since this is typically not a link local > address, you could get a conflict if the HA > does not defend all addresses. The problem is that RFC 3041 should require any such node to first acquire rights to the link-local address. I hope that is viewed as an omission, and one which can be quickly repaired. Regards, Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 13:15:15 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22922 for ; Fri, 31 May 2002 13:15:14 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13360; Fri, 31 May 2002 10:14:49 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA01470; Fri, 31 May 2002 10:14:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHDxrP007694 for ; Fri, 31 May 2002 10:13:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VHDxDY007693 for mobile-ip-dist; Fri, 31 May 2002 10:13:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHDvrP007686 for ; Fri, 31 May 2002 10:13:57 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA20422 for ; Fri, 31 May 2002 13:13:56 -0400 (EDT) Received: from onion.East.Sun.COM (localhost [IPv6:::1]) by onion.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g4VHDxqp023171 for ; Fri, 31 May 2002 13:13:59 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g4VHDxpR023170 for mobile-ip@sunroof.eng.sun.com; Fri, 31 May 2002 13:13:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VEeqrP006882 for ; Fri, 31 May 2002 07:40:52 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23457 for ; Fri, 31 May 2002 07:40:52 -0700 (PDT) Received: from mail1.telekom.de (mail1.telekom.de [62.225.183.235]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08940 for ; Fri, 31 May 2002 08:40:51 -0600 (MDT) Received: from g9jbr.mgb01.telekom.de by G8SBV.dmz.telekom.de with ESMTP for mobile-ip@sunroof.eng.sun.com; Fri, 31 May 2002 16:39:49 +0200 Received: by G9JBR.mgb01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 16:40:49 +0200 Message-Id: <73D3E97F639DD5119642000347055F0503EB11F9@G9JNS.mgb01.telekom.de> From: "Tessier, Serge" To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] [mobile-IP]: Comments on draft-ietf-mobileip-vpn-problem-statemen t-00 Date: Fri, 31 May 2002 16:40:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This draft appears to be a product of the working group so I address my comments (minor -maybe very personnal- and major -technical- ones) to the authors through the mailing list. a. Abstract & Introduction: When VPN is mentionned I think it should be precised L3-based VPN or even IPSec-based VPN since in the rest of the document IPSec is mentioned but never L2 tunneling mechanisms. Somehow, the following limited scope should be stated : "The scenarios described here assume that the VPN solution is based on L3 mechansims" or alternatively: "The scenarios described here excludes any L2-based VPN realisation". It could even be justified that for the sake of coherence since for interaction purposes (triggerring event notification) mobility and security may need to be put on the 'same level' i.e. network layer (maybe too much implementation specific). It is also an obvious benefit to maintain the well-known Mobile IP link layer independancy through the exclusion of L2TP solution. a'. There may be a lack of 'motivation' chapter (see also d.). In such a chapter it would be the place to mention that for example one could extend already deployed VPN solutions through the offer of 'mobility services' as a VPN add-on feature. b. In all the figures the terms 'GW' is missing in each boxes containing the text 'IPSec-based VPN' c. Also some typos (ASCII conversion) in the text... d. Page 4. After figure 4.0b: This motivation is very important and should be put IMO at the beginning of the document (abstract). Even if it is mentioned in the introduction I think it comes too late, it is too vague (on the contrary, the references to EDGE, GPRS, UMTS do not bring IMO any motivation per se). Sorry, I do not propose anything better. e. Page 5: "Dr. Joe needs to establish an IPsec tunnel to the VPN gateway first so that he can register with the home agent while roaming outside the home network. This implies that the MIPv4 traffic destined to the home network has to run inside an IPsec tunnel." Here I am a bit puzzle: It is indeed a bit hard to state that spontaneously without any introduction/motivation about the fact that the tunnels should be put in that order. I am not sure we (at least I) have reached an exhaustive understanding and I would be happy to have discussion for clarifying these issues (draft-ietf-mobileip-ipsec-use-00.txt is maybe a starting point (?), not the proposal itself but the general philosophy especially the requirements, but it expired in 1998. There are other studies about that topic). There was also a thread on the mobileip-nat-vpn mailing list.. Why not including a section describing tunneling order, listing at least the alternatives and the pros/cons or, at the minimum, letting the door open for issues that are IMHO not understood? With a statement like: "It has still to be investigated in a further version of this document weather the Mobile IP tunnel should be put within the IPSec tunnel or the other way around. In this document we do not make any assumption regarding the tunnelling order." f. Page 5. Section 5.2: If the imaginary mobile user Dr. Joe is introduced, then why not using him here? This document should be about usage scenario so it could be helpfull to state that in the case 1, Dr. Joe visit a 'branch office' (e.g. surgery dept.) outside the hospital's main building. Anyway, more important here: "The FA is trusted, i.e. an SA has been established a priori between the FA and the home VPN gateway." Wouldn't it be more generic to state that there is a GW-to-GW security scheme between a VPN GW located at the edge of the Foreign Network and the 'IPSec-based VPN (GW)' at the edge of the home network? IMHO it would more fit in existing usage scenario, at least the ones I can foreseen. g. Page 7. Figure 6.1b: "Figure 6.1b u Shows IPsec tunnel endpoints, MN-CoA and the VPN External IP address, in co-located mode" It is here abruptly stated that the MN-CoA is the tunnelling end point of the IPSec tunnel. It is a consequence of page 5 sections. I know some other possible combination, which I do not pretend to be better. Wouldn't it be possible to write 'for example' in the previous statement, once again not to preclude any solution? Please also see my comment e. Thanks -Serge From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 13:41:20 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23751 for ; Fri, 31 May 2002 13:41:19 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28849; Fri, 31 May 2002 10:40:58 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22190; Fri, 31 May 2002 10:40:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHdQrP007951 for ; Fri, 31 May 2002 10:39:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VHdQBt007950 for mobile-ip-dist; Fri, 31 May 2002 10:39:26 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHdLrP007943; Fri, 31 May 2002 10:39:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10418; Fri, 31 May 2002 10:39:20 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08772; Fri, 31 May 2002 11:39:20 -0600 (MDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 10:39:19 -0700 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 31 May 2002 10:39:19 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 10:39:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [mobile-ip] RFC 2462 DAD optimization Date: Fri, 31 May 2002 10:39:18 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> Thread-Topic: RFC 2462 DAD optimization Thread-Index: AcIIxXukqoFBaEwtSHeIim8IDmf+IgABEPjQ From: "Richard Draves" To: "Charles E. Perkins" , "Hesham Soliman (ERA)" Cc: , "IPng Working Group " X-OriginalArrivalTime: 31 May 2002 17:39:19.0020 (UTC) FILETIME=[177BCAC0:01C208CA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4VHdMrQ007944 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit I disagree. I think the problem is in the RFC 2462 optimization. The RFC 2462 optimization also can fail with manually-configured addresses - it's not just a problem with RFC 3041 temporary addresses. I'm curious about the implementation status. I know the Windows implementation does not implement the RFC 2462 optimization - it performs DAD on every address independently. What about other implementations? Rich > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, May 31, 2002 10:03 AM > To: Hesham Soliman (ERA) > Cc: 'mobile-ip@sunroof.eng.sun.com '; 'IPng Working Group ' > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > > > Hello Hesham, > > "Hesham Soliman (ERA)" wrote: > > > => RFC 2462 makes an optimisation (not a good > > one IMHO) that if a node does DAD on link-local > > addresses, it 'owns the interface id' for any other > > address with any scope. > > I think this is a good idea. > > > RFC3041 says that a node can generate a new iid > > and does DAD for _that_ address which uses the > > new iid. Since this is typically not a link local > > address, you could get a conflict if the HA > > does not defend all addresses. > > The problem is that RFC 3041 should require any > such node to first acquire rights to the link-local > address. I hope that is viewed as an omission, and > one which can be quickly repaired. > > Regards, > Charlie P. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 13:46:27 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23995 for ; Fri, 31 May 2002 13:46:26 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13717; Fri, 31 May 2002 11:47:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24265; Fri, 31 May 2002 10:45:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHj2rP008058 for ; Fri, 31 May 2002 10:45:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VHj1dG008057 for mobile-ip-dist; Fri, 31 May 2002 10:45:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHiwrP008050; Fri, 31 May 2002 10:44:58 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12161; Fri, 31 May 2002 10:44:57 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01442; Fri, 31 May 2002 10:44:57 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA14756; Fri, 31 May 2002 10:44:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g4VHiub16415; Fri, 31 May 2002 10:44:56 -0700 X-mProtect: <200205311744> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXqtfMs; Fri, 31 May 2002 10:44:54 PDT Message-ID: <3CF7B696.C82EC0B9@iprg.nokia.com> Date: Fri, 31 May 2002 10:44:54 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Richard Draves CC: mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: [mobile-ip] Re: RFC 2462 DAD optimization References: <7695E2F6903F7A41961F8CF888D87EA804BC4CDD@red-msg-06.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello Richard, Even manually configured global addresses should be required to acquire rights to the corresponding link-local address. Why not? Regards, Charlie P. Richard Draves wrote: > > I disagree. I think the problem is in the RFC 2462 optimization. The RFC > 2462 optimization also can fail with manually-configured addresses - > it's not just a problem with RFC 3041 temporary addresses. > > I'm curious about the implementation status. I know the Windows > implementation does not implement the RFC 2462 optimization - it > performs DAD on every address independently. What about other > implementations? > > Rich > > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > Sent: Friday, May 31, 2002 10:03 AM > > To: Hesham Soliman (ERA) > > Cc: 'mobile-ip@sunroof.eng.sun.com '; 'IPng Working Group ' > > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > > > > > > > Hello Hesham, > > > > "Hesham Soliman (ERA)" wrote: > > > > > => RFC 2462 makes an optimisation (not a good > > > one IMHO) that if a node does DAD on link-local > > > addresses, it 'owns the interface id' for any other > > > address with any scope. > > > > I think this is a good idea. > > > > > RFC3041 says that a node can generate a new iid > > > and does DAD for _that_ address which uses the > > > new iid. Since this is typically not a link local > > > address, you could get a conflict if the HA > > > does not defend all addresses. > > > > The problem is that RFC 3041 should require any > > such node to first acquire rights to the link-local > > address. I hope that is viewed as an omission, and > > one which can be quickly repaired. > > > > Regards, > > Charlie P. From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 13:49:42 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24175 for ; Fri, 31 May 2002 13:49:41 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00037; Fri, 31 May 2002 11:49:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26363; Fri, 31 May 2002 10:49:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHmgrP008191 for ; Fri, 31 May 2002 10:48:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VHmgRY008190 for mobile-ip-dist; Fri, 31 May 2002 10:48:42 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHmbrP008183; Fri, 31 May 2002 10:48:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13276; Fri, 31 May 2002 10:48:37 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA13104; Fri, 31 May 2002 11:48:31 -0600 (MDT) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 10:48:31 -0700 Received: from 157.54.8.109 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 31 May 2002 10:48:31 -0700 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 31 May 2002 10:48:31 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [mobile-ip] RE: RFC 2462 DAD optimization Date: Fri, 31 May 2002 10:48:30 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CED28@red-msg-06.redmond.corp.microsoft.com> Thread-Topic: RFC 2462 DAD optimization Thread-Index: AcIIyuf4W9wSnnU1QNyUrroqfIceWwAAAY8g From: "Richard Draves" To: "Charles E. Perkins" Cc: , "IPng Working Group" X-OriginalArrivalTime: 31 May 2002 17:48:31.0196 (UTC) FILETIME=[609B29C0:01C208CB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4VHmcrQ008184 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit You are basically arguing for DIID (duplicate interface-id detection) instead of DAD (duplicate address detection), by using DAD on the link-local address to perform DIID. It seems strange to me to perform DAD on a link-local address that is not actually being used. For better or worse, it's not the architecture that we have today and I'm not inclined to change it. Rich > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Friday, May 31, 2002 10:45 AM > To: Richard Draves > Cc: mobile-ip@sunroof.eng.sun.com; IPng Working Group > Subject: Re: RFC 2462 DAD optimization > > > > Hello Richard, > > Even manually configured global addresses should be required > to acquire rights to the corresponding link-local address. Why not? > > Regards, > Charlie P. > > > Richard Draves wrote: > > > > I disagree. I think the problem is in the RFC 2462 > optimization. The > > RFC 2462 optimization also can fail with > manually-configured addresses > > - it's not just a problem with RFC 3041 temporary addresses. > > > > I'm curious about the implementation status. I know the Windows > > implementation does not implement the RFC 2462 optimization - it > > performs DAD on every address independently. What about other > > implementations? > > > > Rich > > > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: Friday, May 31, 2002 10:03 AM > > > To: Hesham Soliman (ERA) > > > Cc: 'mobile-ip@sunroof.eng.sun.com '; 'IPng Working Group ' > > > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > > > > > > > > > > > Hello Hesham, > > > > > > "Hesham Soliman (ERA)" wrote: > > > > > > > => RFC 2462 makes an optimisation (not a good > > > > one IMHO) that if a node does DAD on link-local addresses, it > > > > 'owns the interface id' for any other address with any scope. > > > > > > I think this is a good idea. > > > > > > > RFC3041 says that a node can generate a new iid > > > > and does DAD for _that_ address which uses the > > > > new iid. Since this is typically not a link local address, you > > > > could get a conflict if the HA does not defend all addresses. > > > > > > The problem is that RFC 3041 should require any > > > such node to first acquire rights to the link-local > address. I hope > > > that is viewed as an omission, and one which can be quickly > > > repaired. > > > > > > Regards, > > > Charlie P. > From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 14:00:17 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24631 for ; Fri, 31 May 2002 14:00:15 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10630; Fri, 31 May 2002 10:59:52 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00598; Fri, 31 May 2002 10:59:43 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHwurP008369 for ; Fri, 31 May 2002 10:58:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VHwuZX008368 for mobile-ip-dist; Fri, 31 May 2002 10:58:56 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VHwqrP008361; Fri, 31 May 2002 10:58:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23704; Fri, 31 May 2002 10:58:52 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09859; Fri, 31 May 2002 10:58:51 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 10:58:50 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 31 May 2002 10:58:50 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 10:58:50 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 31 May 2002 10:58:46 -0700 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.3590.0); Fri, 31 May 2002 10:58:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [mobile-ip] RE: RFC 2462 DAD optimization Date: Fri, 31 May 2002 10:58:44 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CF128@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: RFC 2462 DAD optimization Thread-Index: AcIIy0gRI6qnTT2aQOOpG4ZWWiXDIwAAN4Cw From: "Dave Thaler" To: "Charles E. Perkins" , "Richard Draves" Cc: , "IPng Working Group" X-OriginalArrivalTime: 31 May 2002 17:58:46.0685 (UTC) FILETIME=[CF7754D0:01C208CC] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g4VHwrrQ008362 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit As mentioned in email I sent a week or two back, this is related to the issue of whether a link-local address has to be unique across an entire subnet, not just a link. Today it's defined as a "link-local" not a "subnet-local" address. This means that it is not guaranteed to be unique across a subnet. Manually configured global addresses don't need to require rights to the corresponding link-local address since a) it's not necessary as they don't use the link-local address, b) it's not sufficient since they need to be unique across the subnet, not just the link. So unless you're proposing we redefine "link-local" addresses as "subnet-local" addresses (which would at least be a consistent argument, albeit a change to the architecture), then what you suggest does not seem to me to be the right solution. -Dave > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Friday, May 31, 2002 10:45 AM > To: Richard Draves > Cc: mobile-ip@sunroof.eng.sun.com; IPng Working Group > Subject: Re: RFC 2462 DAD optimization > > > Hello Richard, > > Even manually configured global addresses should be required > to acquire rights to the corresponding link-local address. Why not? > > Regards, > Charlie P. > > > Richard Draves wrote: > > > > I disagree. I think the problem is in the RFC 2462 optimization. The RFC > > 2462 optimization also can fail with manually-configured addresses - > > it's not just a problem with RFC 3041 temporary addresses. > > > > I'm curious about the implementation status. I know the Windows > > implementation does not implement the RFC 2462 optimization - it > > performs DAD on every address independently. What about other > > implementations? > > > > Rich > > > > > -----Original Message----- > > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > > Sent: Friday, May 31, 2002 10:03 AM > > > To: Hesham Soliman (ERA) > > > Cc: 'mobile-ip@sunroof.eng.sun.com '; 'IPng Working Group ' > > > Subject: Re: [mobile-ip] Issue #23 and Issue #30 > > > > > > > > > > > > Hello Hesham, > > > > > > "Hesham Soliman (ERA)" wrote: > > > > > > > => RFC 2462 makes an optimisation (not a good > > > > one IMHO) that if a node does DAD on link-local > > > > addresses, it 'owns the interface id' for any other > > > > address with any scope. > > > > > > I think this is a good idea. > > > > > > > RFC3041 says that a node can generate a new iid > > > > and does DAD for _that_ address which uses the > > > > new iid. Since this is typically not a link local > > > > address, you could get a conflict if the HA > > > > does not defend all addresses. > > > > > > The problem is that RFC 3041 should require any > > > such node to first acquire rights to the link-local > > > address. I hope that is viewed as an omission, and > > > one which can be quickly repaired. > > > > > > Regards, > > > Charlie P. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 14:13:01 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25361 for ; Fri, 31 May 2002 14:13:00 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11570; Fri, 31 May 2002 12:13:12 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06074; Fri, 31 May 2002 11:13:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VIC9rP008608 for ; Fri, 31 May 2002 11:12:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VIC92K008607 for mobile-ip-dist; Fri, 31 May 2002 11:12:09 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VIC5rP008600 for ; Fri, 31 May 2002 11:12:05 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29362 for ; Fri, 31 May 2002 11:12:05 -0700 (PDT) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14272 for ; Fri, 31 May 2002 12:12:04 -0600 (MDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g4VIC36n016435; Fri, 31 May 2002 20:12:03 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 20:11:43 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F06BC@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Jari Arkko '" , "Hesham Soliman (ERA)" Cc: "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] comments on MIPv6 draft-17 Date: Fri, 31 May 2002 20:11:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Jari, I'll just respond to a couple of issues. Email is a rare commodity for me this week :) > - I don't understand why MAX_RR_BINDING_LIFE is fixed > to 300 seconds. I would appreciate a reference or a reason. > The attack that Pekka sent a few months ago should not > require the 5 min limit. It simply requires that the BCE > cannot be refreshed without performing RR. In fact there > is probably more hazard in allowing the updates within > the 5 min than if we extend (or remove) the upper time > limit. A future DoS attack would likely die off quite soon (before 5 mins) if there was no TCP ACKs or something like from the victim. For these attacks the limit does not buy much. => Agreed. However, there are other types of attacks. For instance, I could visit your office and install a BCE at some CN that claims your PC is somewhere else. => Not if my HA tunnels the HOT message securely to me. That's one of the reasons I was suggesting a MUST for ESP tunnelling of HOT messages. Does that answer your attack scenario? Allowing long BCE lifetimes makes this "hijack" attack possible for a longer time. Note that unlike in the DoS case, no refresh is needed for the attack proceed. Ideally, the effects of my visit should not last too long after my departure. => But I'm not sure how you could claim my HoA and CoA if there is a secure tunnel for RR messages between the HA and MN. There are two types of attacks that I thought were relevant: 1. An attacker on the CN-HA path, initiates RR using the victim's HoA, hijacks the traffic. Then moves somewhere else and keeps refreshing the CNs BCE to deny service between the CN and the victim MN. This can be avoided if RR is performed for any refreshing of the BCE. 2. The attacker does RR and sends a BU and moves away, to bomd the network he was in. This is what you mention above and we agree it will be likely to end way before the 5 min are over. So are you talking about a variation of 1) above, where the attacker is on the CN-HA path and he installs a BCE in the CN for a long time? > - Busy CNs will struggle with maintaining the Nonce > and Kbu lifetimes for several (hundreds or thousands?) > of MNs. Do you think this is a valid concern? If so > we need to add some recommendation on how to do this. > I haven't read the state machines in the appendix > yet, so my answer might be there. This may be a valid concern, though (1) you can always deal with it by either bying more memory or declining more RO requests (2) we have some text in 9.4.3. Do you think that text is sufficient: A possible way to implement this is to mark the binding cache entry so that it does not effect sending and receiving of packets, but so that it is found when a binding update is received. => I'm not sure I understand what you mean. My concern was that there will be overlapping lifetimes for the nonces and the CN's keys for the different BCEs. So it wasn't a question of lack of memory, but rather the frequency of generating new keys and remembering which keys are valid for which BCE. But after I thought about it some more, I realised that it's probably not a big issue. > - Section 6.1.3: Why is the HA tunnelling the HOT a SHOULD? > It seems that this is one of the assumptions that the > protocol is based on (see the security design section). > Shouldn't this be a MUST? Not making this a MUST will > allow attacker on the MNs link to do some nasty stuff. There was a separate thread about this a couple months ago. It seems that the added benefit of encrypted tunneling is quite useful, but mainly for the benefit of the mobile node. Not absolutely necessary perhaps for the security of other nodes. Hence SHOULD. => Yes it is for the benefit of the MN. It makes the protocol more secure. Especially against attackers on the MN's link. But I don't understand the relation between 'good for the MN only and not other nodes' and the 'SHOULD'. I might just need some coffee :) but it sounds like you're saying that being good for the MN alone does not justify a MUST. > - It seems like there was a concious decision to separate > the 'reserved' fields in all messages (e.g. section > 6.1.5 (HoT) and 6.1.6), why is that? Well, drawing the boxes together would look graphically better but the fields would still be at different positions, so that is probably not a good idea. => It's not for graphics ;) it might be easier to introduce a new field, for instance if someone wants to add a 32-bit field later, it's easier to have it in one field, instead of 2 16-bit fields. Placing the index on the first two bytes would make sense as the next word would be completely reserved, and the field might even be removed. However, we wanted to keep some reserved space at the beginning of messages to store some future flags. This would be inline with the format of BUs. We could also move the index field to the second part of the first full word, making the reserved field continuous. Anyway, I don't feel strong either way we format the messages. => I don't have a strong opinion either, I was curious. > - Section 9.4.1: Shouldn't the order of the last 2 bullets > be reversed.(Half editorial). You mean doing auth first and then sequence number check? Why? Wouldn't it be better to do the cheaper tests first, such as the sequence number check is? => OK. > - Section 9.7: Remove the third paragraph, it no longer > applies. > - Section 9.7: Fourth paragraph: Do we need to say how > persistent is 'persistent'? or Specify a default rate? I'm open to suggestions. Can you answer your own question? > - Page 93: Bullet starting with 'However, if the 'S' bit > .....'. This strikes me as a problem when renumbering > the Home network is going on. If the HA always chooses > the smallest lifetime, doesn't that mean it will always > be choosing the lifetime of the prefix being deprecated? > Some clarification would be good. Yes it will choose the smallest possible lifetime. Would you like to clarify that this really is the case, or specify some additional constraints that limit the use of prefixes being deprecated through 'S' bit? > - Somewhere in section 10 it should be mentioned that > if the S bit is cleared (request the HA to act on behalf > of all the MNs HoAs) then the HA should create an SA in the > SAD for each one of those home addresses. Create or have? => Well, I suppose create if it doesn't already have it. I guess, except for the IP address of the MN, everything else can be copied, right? > - Page 108: Remove any reference to previous-CoA. See above, where did we agree to remove this? => I assumed that this was agreed on (now that you ask, I can't pin point an email, but I thought it was discussed when Erik published his draft (foresight to hindsight) ). But anyway, securing the BU to the local HA has not been discussed, and I'm not sure if the same security model would apply. I've been thinking about this, perhaps I can send a separate email on it, unless you've already go some info on securing the BU to the previous default router. > - Section 11.1: Te bullet starting with, 'A flag when > set, indicates that future Binding Updates .....' > What does this mean?? The MN will keep an entry in > the BUL anyway for a CN that doesn't accept BUs? This is for the MN to not retry RR/BU all the time. => Sure, but how long is this entry kept for? > - Page 113: Last bullet, 'other implementation > stragies maybe more appropriate' Like what? > I don't think we need to state this do we? > I would suggest removing this approach and > making the standard more concretein what it > says. But this is internal implementation, isn'#t it? Let's remove the note about the other strategies. But let's astill require that the behaviour must look like this from the outside, don't care how it's done. => Agreed. > - Chapter 11.2.4 assumes that the MN can send > BUs to a 'router' in the local domain. I'm > not sure we can keep this in the spec without > specifying how to secure this BU. This is a CN-BU. => I thought it was a HA BU. I'll re-read it then Thanks, Hesham From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 17:12:13 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04873 for ; Fri, 31 May 2002 17:12:12 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19372; Fri, 31 May 2002 15:11:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09910; Fri, 31 May 2002 14:10:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VLAIrP009168 for ; Fri, 31 May 2002 14:10:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VLAICC009167 for mobile-ip-dist; Fri, 31 May 2002 14:10:18 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VLAFrP009160 for ; Fri, 31 May 2002 14:10:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA02910 for ; Fri, 31 May 2002 14:10:14 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA15339 for ; Fri, 31 May 2002 15:10:12 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 2B0E56A906; Sat, 1 Jun 2002 00:10:06 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1F9816A905; Sat, 1 Jun 2002 00:10:04 +0300 (EEST) Message-ID: <3CF7E6F1.4020107@kolumbus.fi> Date: Sat, 01 Jun 2002 00:11:13 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hesham Soliman (ERA)" Cc: "'mobile-ip@sunroof.eng.sun.com '" Subject: Re: [mobile-ip] comments on MIPv6 draft-17 References: <4DA6EA82906FD511BE2F00508BCF0538044F06BC@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hesham Soliman (ERA) wrote: > A future DoS attack would likely die off quite soon (before > 5 mins) if there was no TCP ACKs or something like from the > victim. For these attacks the limit does not buy much. > > => Agreed. > > However, there are other types of attacks. For instance, > I could visit your office and install a BCE at some CN > that claims your PC is somewhere else. > > => Not if my HA tunnels the HOT message securely > to me. That's one of the reasons I was suggesting > a MUST for ESP tunnelling of HOT messages. > Does that answer your attack scenario? Yes, partially. But if your office has just one LAN, an ESP tunnel between the HA and the MN will not help, as the CN's packets will be arriving in cleartext on that LAN. > Allowing long BCE > lifetimes makes this "hijack" attack possible for a longer > time. Note that unlike in the DoS case, no refresh is > needed for the attack proceed. Ideally, the effects of > my visit should not last too long after my departure. > > => But I'm not sure how you could claim my HoA > and CoA if there is a secure tunnel for RR messages > between the HA and MN. > > There are two types of attacks that I thought > were relevant: > > 1. An attacker on the CN-HA path, initiates RR > using the victim's HoA, hijacks the traffic. > Then moves somewhere else and keeps refreshing > the CNs BCE to deny service between the CN and > the victim MN. This can be avoided if RR is > performed for any refreshing of the BCE. Yes. > 2. The attacker does RR and sends a BU and > moves away, to bomd the network he was in. > This is what you mention above and we agree > it will be likely to end way before the 5 min > are over. Yes. > So are you talking about a variation of 1) > above, where the attacker is on the CN-HA > path and he installs a BCE in the CN for > a long time? Yes. So, if I'm on your home LAN or on the CN-hA path for a small amount of time and there is no limit on the BCE lifetimes, I'll install a BCE that redirects your traffic to, say, my server at some other location. > => I'm not sure I understand what you mean. > My concern was that there will be overlapping > lifetimes for the nonces and the CN's keys > for the different BCEs. So it wasn't a question > of lack of memory, but rather the frequency > of generating new keys and remembering which > keys are valid for which BCE. But after I > thought about it some more, I realised that > it's probably not a big issue. If you have a suggestion on how this could be made clearer for implementers, it would be very useful. > => Yes it is for the benefit of the MN. It > makes the protocol more secure. Especially > against attackers on the MN's link. > But I don't understand the relation between > 'good for the MN only and not other nodes' > and the 'SHOULD'. I might just need some > coffee :) but it sounds like you're saying > that being good for the MN alone does not > justify a MUST. Something that prevents bad things from happening to other nodes would be a sufficient condition for a MUST. There might of course be other reasons to make something a MUST, such as a security advantage for the node in question. I suppose it's a judgement call in this case. The earlier debate showed that people had different opinions about this particular situation. >>- Somewhere in section 10 it should be mentioned that >> if the S bit is cleared (request the HA to act on behalf >> of all the MNs HoAs) then the HA should create an SA in the >> SAD for each one of those home addresses. >> > > Create or have? > > => Well, I suppose create if it doesn't already > have it. I guess, except for the IP address > of the MN, everything else can be copied, right? I'm a bit uneasy on spending too much effort on us creating lots of IPsec SAs in some dynamic fashion. Could be easier to just require that these SAs exist, and have been manually configured. >>- Section 11.1: Te bullet starting with, 'A flag when >> set, indicates that future Binding Updates .....' >> What does this mean?? The MN will keep an entry in >> the BUL anyway for a CN that doesn't accept BUs? >> > > This is for the MN to not retry RR/BU all the time. > > => Sure, but how long is this entry kept for? I can't find any other explanation than... the lifetime in the BU. This would actually make sense to me. >>- Chapter 11.2.4 assumes that the MN can send >> BUs to a 'router' in the local domain. I'm >> not sure we can keep this in the spec without >> specifying how to secure this BU. >> > This is a CN-BU. > > => I thought it was a HA BU. I'll re-read it > then I clarified the text. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 17:13:29 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04966 for ; Fri, 31 May 2002 17:13:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26649; Fri, 31 May 2002 14:13:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10997; Fri, 31 May 2002 14:12:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VLCJrP009233 for ; Fri, 31 May 2002 14:12:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VLCJ9p009232 for mobile-ip-dist; Fri, 31 May 2002 14:12:19 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VLCFrP009219 for ; Fri, 31 May 2002 14:12:15 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03540 for ; Fri, 31 May 2002 14:12:14 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02544 for ; Fri, 31 May 2002 14:12:14 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id AF3716A907; Sat, 1 Jun 2002 00:12:07 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EFEF76A905 for ; Sat, 1 Jun 2002 00:12:05 +0300 (EEST) Message-ID: <3CF7E76B.8030702@kolumbus.fi> Date: Sat, 01 Jun 2002 00:13:15 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] new security considerations section Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hello, We have gotten a request to separate the discussion of threats, design rationale, residual threats, and so on completely in the security considerations section. I.e. not spread out in the rest of the document. This has been done by taking most of the 'discussion' away from Section 5 and moving it to Section 15. The remaining parts of the specification concentrate on describing the protocol rules. The new Section 15 text is available at http://www.piuha.net/~jarkko/publications/mipv6/security-considerations-new.txt Comments appreciated. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 19:01:32 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06421 for ; Fri, 31 May 2002 19:01:32 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA16511; Fri, 31 May 2002 16:01:09 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07344; Fri, 31 May 2002 16:01:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VN05rP009729 for ; Fri, 31 May 2002 16:00:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g4VN054x009728 for mobile-ip-dist; Fri, 31 May 2002 16:00:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g4VN02rP009721 for ; Fri, 31 May 2002 16:00:02 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA06920 for ; Fri, 31 May 2002 16:00:01 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08755 for ; Fri, 31 May 2002 17:00:00 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id DEDD16A906; Sat, 1 Jun 2002 01:59:53 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 004E46A905; Sat, 1 Jun 2002 01:59:51 +0300 (EEST) Message-ID: <3CF800AD.2010607@kolumbus.fi> Date: Sat, 01 Jun 2002 02:01:01 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: arvind.sevalkar@lntinfotech.com Cc: Vijay Devarapalli , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issue #25 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=7.0 tests= version=2.20 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Looks like the discussion is converging. Is this the right conclusion: Dest Life Source BU/w HAO BA/w RH ======================================== HA >0 CoA Yes Yes HA >0 HoA No No HA =0 CoA Yes Yes HA =0 HoA No No CN >0 CoA Yes Yes CN >0 HoA No No CN =0 CoA Yes Yes CN =0 HoA No No Essentially, HAO is included exactly when BU source is not the home address. RH is included exactly when there was a HAO in the BU. The special case requested by Vijay (return home and de-register) appears to be covered in the above, since when you return home your source is home address and. De-registration happens regardless of the lifetime field. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 22:05:56 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08754 for ; Fri, 31 May 2002 22:05:56 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01610; Fri, 31 May 2002 19:05:31 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA18664; Fri, 31 May 2002 19:05:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5124NrP010046 for ; Fri, 31 May 2002 19:04:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g5124NX7010045 for mobile-ip-dist; Fri, 31 May 2002 19:04:23 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g5124JrP010038 for ; Fri, 31 May 2002 19:04:20 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g5124J6U597926; Fri, 31 May 2002 19:04:20 -0700 (PDT) Message-Id: <200206010204.g5124J6U597926@jurassic.eng.sun.com> Date: Fri, 31 May 2002 19:06:46 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: RE: [mobile-ip] comments on MIPv6 draft-17 To: jari.arkko@kolumbus.fi, hesham.soliman@era.ericsson.se Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yQ3XIQ19+NWcdPIy6ry90Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > There are two types of attacks that I thought > were relevant: > > 1. An attacker on the CN-HA path, initiates RR > using the victim's HoA, hijacks the traffic. > Then moves somewhere else and keeps refreshing > the CNs BCE to deny service between the CN and > the victim MN. This can be avoided if RR is > performed for any refreshing of the BCE. > You mean the attacker is able to see both COTI/COT and HOTI/HOT message ? If the attacker is only on on CN-HA path, it will not be able to see the COA key, thus will not be able to form a correct Kbu and thus cannot install a BCE on CN. > 2. The attacker does RR and sends a BU and > moves away, to bomd the network he was in. > This is what you mention above and we agree > it will be likely to end way before the 5 min > are over. > > So are you talking about a variation of 1) > above, where the attacker is on the CN-HA > path and he installs a BCE in the CN for > a long time? > For that reason should not the MAX_RR_BINDING_LIFE should be a smaller value? Do we need to define a MIN_RR_BINDING_LIFE as well to ensure that binding will last at least this amount of life? > > - Section 6.1.3: Why is the HA tunnelling the HOT a SHOULD? > > It seems that this is one of the assumptions that the > > protocol is based on (see the security design section). > > Shouldn't this be a MUST? Not making this a MUST will > > allow attacker on the MNs link to do some nasty stuff. > > There was a separate thread about this a couple months > ago. It seems that the added benefit of encrypted tunneling > is quite useful, but mainly for the benefit of the mobile > node. Not absolutely necessary perhaps for the security > of other nodes. Hence SHOULD. > > => Yes it is for the benefit of the MN. It > makes the protocol more secure. Especially > against attackers on the MN's link. > But I don't understand the relation between > 'good for the MN only and not other nodes' > and the 'SHOULD'. I might just need some > coffee :) but it sounds like you're saying > that being good for the MN alone does not > justify a MUST. > Agree. Without having ESP tunnel mode for both HOT/HOTI, the HOA is prone to hijacking. I am not able to understand the logic behind having optional ESP tunnel mode for HOT message. This leaves a security hole in the protocol. If a MN can send HOTI message in ESP tunnel mode, then it should be able to process incoming HOT message in ESP tunnel mode. Besides, making it optional means more complicated implemenation on MN (and HA) and more lines of unnecessary code. I am not able to see any merrit of having ESP tunnel mode optional in HOT path. Making ESP tunnel bidirectional for both HOTI/HOT seems simple, secure and reasonable from the protocol perspective. Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 22:34:26 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09251 for ; Fri, 31 May 2002 22:34:26 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21937; Fri, 31 May 2002 19:33:41 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24355; Fri, 31 May 2002 19:33:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g512WqrP010132 for ; Fri, 31 May 2002 19:32:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g512Wqrh010131 for mobile-ip-dist; Fri, 31 May 2002 19:32:52 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g512WnrP010124 for ; Fri, 31 May 2002 19:32:49 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g512Wn6U600086; Fri, 31 May 2002 19:32:50 -0700 (PDT) Message-Id: <200206010232.g512Wn6U600086@jurassic.eng.sun.com> Date: Fri, 31 May 2002 19:35:16 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: [mobile-ip] Relationship between RR_BINDING and COOKIE_LIFE To: mobile-ip@sunroof.eng.sun.com Cc: samita@eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ZSpw7jQa4T5v+eZzbeDB5Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: It may have been discussed before, sorry if I missed the discussion. I am a bit unclear on the actual binding lifetime as section 14.3 of draft-17 states: However, one difference is that in basic IPv6 an on-path attacker must be constantly present on the link or the path (e.g., in order to perform a man-in-the-middle attack), whereas with Mobile IPv6 an attacker can leave an existing binding behind, even after it is no longer on the link or on the path [23]. For this reason, this specification limits the validity of bindings authorized by return routability to a maximum of MAX_COOKIE_LIFE + MAX_RR_BINDING_LIFE seconds after the last routability check has been performed. Again in section 5.5.7 states: However, it is recommended that correspondent nodes try to keep these cookies acceptable as long as possible and SHOULD NOT accept them beyond MAX_COOKIE_LIFE seconds. So, if RR has been performed at time t and then I expect that the refresh should be performed before t+MAX_COOKIE_LIFE in order to use the same cookie(s). However, if we keep the binding valid beyond t+MAX_COOKIE_LIFE period, then anyway MN needs to do RR check again after cookie lifetime expires. So, my point is what is the purpose of having extended max binding life that is: MAX_COOKIE_LIFE + MAX_RR_BINDING_LIFE ? Does it mean that frequency of RR check could be MAX_COOKIE_LIFE + MAX_RR_BINDING_LIFE in the worst case. That means a BU can be as infrequent as 300 +240 = 9 min. I wonder, why are we allowing the binding to remain valid up to MAX_COOKIE_LIFE + MAX_RR_BINDING_LIFE sec, should not it be just MAX_RR_BINDING_LIFE sec, where MAX_RR_BINDING_LIFE = 300 sec MAX_COOKIE_LIFE = 240 sec Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Fri May 31 22:39:08 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09481 for ; Fri, 31 May 2002 22:39:08 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA26238; Fri, 31 May 2002 20:39:14 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA06787; Fri, 31 May 2002 19:39:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g512cSrP010214 for ; Fri, 31 May 2002 19:38:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3/Submit) id g512cSgd010213 for mobile-ip-dist; Fri, 31 May 2002 19:38:28 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic-17-a [129.146.17.55]) by sunroof.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g512cPrP010206 for ; Fri, 31 May 2002 19:38:25 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with SMTP id g512cP6U600473; Fri, 31 May 2002 19:38:26 -0700 (PDT) Message-Id: <200206010238.g512cP6U600473@jurassic.eng.sun.com> Date: Fri, 31 May 2002 19:40:52 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] comments on MIPv6 draft-17 To: vijayd@iprg.nokia.com Cc: jari.arkko@kolumbus.fi, hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ACtur4sXDSu2Sa6IlKID6Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.9 sun4u sparc Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi Vijay, > > > There was a separate thread about this a couple months > > > ago. It seems that the added benefit of encrypted tunneling > > > is quite useful, but mainly for the benefit of the mobile > > > node. Not absolutely necessary perhaps for the security > > > of other nodes. Hence SHOULD. > > > > I think Hesham has a good point here. If you look at the > > "More comments on Draft16 -CLARIFICATION " thread (issue #19), where > > I asked the same question that both HOTI/HOT messages > > must use ESP tunnel and I thought the decision was 'yes'. > > issue #14 was about "Require encryption on HA-MN tunnel for MH > messages?". the issues list says the adopted concensus was MUST > implement and SHOULD be used. Ok. Then do we know what is the default behavior in the spec ? If the implementation is MUST (which is quite logical), then the draft should make it MUST too. That means the implementation SHOULD be able to disable this functionality optionally. Thanks, -Samita