From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 1 02:20:39 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08433 for ; Thu, 1 Aug 2002 02:20:39 -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 AAA13699; Thu, 1 Aug 2002 00:21: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 XAA15483; Wed, 31 Jul 2002 23:21:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g716KHoN021700 for ; Wed, 31 Jul 2002 23:20:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g716KHVO021699 for mobile-ip-dist; Wed, 31 Jul 2002 23:20: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.4/8.12.4) with ESMTP id g716KDoN021692 for ; Wed, 31 Jul 2002 23:20: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 XAA29795 for ; Wed, 31 Jul 2002 23:20:19 -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 AAA13404 for ; Thu, 1 Aug 2002 00:20:18 -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 g716JuRb011486; Thu, 1 Aug 2002 08:19:56 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 1 Aug 2002 08:19:56 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F08A6@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Rajeev Koodli '" , "'Singh Ajoy-ASINGH1 '" Cc: "''Alper E. YEGIN' '" , "'James Kempf '" , "''Vijay Devarapalli' '" , "'mobile-ip@sunroof.eng.sun.com '" Subject: RE: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmi pv6 ? Date: Thu, 1 Aug 2002 08:19:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Catching up with the thread. > So, my suggestion is that the base protocol > defines the messages necessary to work on all links > while it also allows for scenarios such as yours. This > does not mean that you remove the message from > the spec. Do you agree ? > > AJOY-> I agree with this if you make PrRTAdv as > an optional message. This question is for the WG to decide. What do others think ? Should we make PrRtAdv an optional message ? => NO! This is making the handover prediction in the MN optional, non starter. Interop implications ? => And unacceptable link layer dependencies. Hesham > > > -----Original Message----- > From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] > Sent: Wednesday, July 31, 2002 2:27 PM > To: Singh Ajoy-ASINGH1 > Cc: 'Alper E. YEGIN'; James Kempf; 'Vijay Devarapalli'; > mobile-ip@sunroof.eng.sun.com > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > Ajoy, > > Singh Ajoy-ASINGH1 wrote: > > > Alper, > > In my previous reply to Rajeev, I explained why > > MN is not required to know the L2 address of nAR > > in case of srial link. Why this question again? If you do > > > > I also responded to your input. I guess you agree that > an IP protocol has to supply this information in > order for it work on all links ? At the same time, > the protocol has to work if the MN moves without > receiving the PrRtAdv, which should cover your > scenario. So, my suggestion is that the base protocol > defines the messages necessary to work on all links > while it also allows for scenarios such as yours. This > does not mean that you remove the message from > the spec. Do you agree ? > > Regards, > > -Rajeev > > > not agree, please comment on my previous > > email. > > Regards, > > Ajoy > > > > -----Original Message----- > > From: Alper E. YEGIN [mailto:alper@docomolabs-usa.com] > > Sent: Tuesday, July 30, 2002 6:12 PM > > To: James Kempf; Rajeev Koodli > > Cc: Singh Ajoy-ASINGH1; 'Vijay Devarapalli'; > > mobile-ip@sunroof.eng.sun.com > > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > I think we need to include the complete question here: > > > > 1. How does the MN get the L2 address and IP address of the > > new AR ? I see the following possibilities > > a) PrRtAdv provides this > > b) upon establishing a new link, the MN does RS and gets an RA > > > > How can you avoid PrRtAdv ? Can we assume that L2 trigger > > provides the necessary information ? Which L2 trigger today > > provides such information? > > > > Does MN really get "L2 and IP address of the new AR"? > > I see MN is aware of the L2 id of the Base Stations, but note > > that this is not same as L2 id of AR(s) behind them. > > > > alper > > > > ----- Original Message ----- > > From: "James Kempf" > > To: "Alper E. YEGIN" ; "Rajeev Koodli" > > > > Cc: "Singh Ajoy-ASINGH1" ; "'Vijay Devarapalli'" > > ; > > Sent: Tuesday, July 30, 2002 1:58 PM > > Subject: Re: [mobile-ip] Fast Handover draft: proposed revisions > > > > > > > Which L2 trigger today > > > > > provides such information? > > > > > > > > I'm not aware of any... > > > > > > > > > > I refer you to "Draft Standard for W-CDMA (Wideband Code Division > Multiple > > > Access) Air Interface Compatibility Standard for 1.85 to 1.99 GHz PCS > > > Applications", ANSI J-STD-015, 1998, Section 11.7 "Handoff Operation", > > Section > > > 12.2.4.3, "Handoff Messages," Section 12.2.5.3.7, "Handoff Parameter", > and > > > Section 12.25.3.8, "Handoff Indication". This version is a little old > but > > > probably not very far off from the current W-CDMA specification. > > > > > > In Section 11.7, the procedures for mobile controlled and network > > controlled > > > handover are described. In the mobile controlled case, the mobile sends > a > > layer > > > 2 identifier to the current base station indicating the target base > > station to > > > which the mobile wants to hand over, and gets back a response indicating > > whether > > > handover is allowed or denied. In the network controlled case, the > current > > base > > > station sends the same information to the mobile. (Note: "layer 3" in > this > > > specification actually refers to what from the IP viewpoint would be the > > MAC > > > layer, or layer 2). The network controlled case is used to manage power > > and cell > > > load, the mobile controlled case is used when the power level on the > > mobile goes > > > below the specified handoff point. > > > > > > In either case, the SolPrRtAdv and PrRtAdv of FMIPv6 duplicate, at the > IP > > layer, > > > what W-CDMA already does at the MAC layer. Also in either case, the > layer > > 2 > > > information should be sufficient to allow the base station to perform a > > layer 3 > > > handover without any over the air layer 3 signaling, provided the base > > station > > > has a way to map the target base station id to an IP address, using > GAARD > > or a > > > preconfigured table. > > > > > > Of course, in the R99 UTRAN, the actual W-CDMA protocol is buried under > > the NBAP > > > and RNSAP RAN protocols. > > > > > > I don't have access to an IS-2000 specification at the moment, but I'm > > working > > > on getting the same information. Other wireless link layers must provide > > this > > > information in some form, either before handover, as with the cellular > > > protocols, or afterwards, as with 802.11. Barring make before break, > > without > > > some information at layer 2 about where the mobile is going, it is > simply > > > impossible for the link to get switched, and, without a link, it is not > > possible > > > to do IP. If the layer 2 protocol supports real make before break (not > > soft > > > handover), none of the fast handover protocols are necessary, since the > > mobile > > > can do RS/RA on the forward link while receiving its traffic on the > > backward > > > one. > > > > > > jak > > > > > > (fyi, Alper, the specification in question is in the DoCoMo library, if > > you care > > > to check it out.) > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 1 07:41: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 HAA25945 for ; Thu, 1 Aug 2002 07:41:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA15418; Thu, 1 Aug 2002 05:41:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA09360; Thu, 1 Aug 2002 04:41:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71BenoN022124 for ; Thu, 1 Aug 2002 04:40:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71BennY022123 for mobile-ip-dist; Thu, 1 Aug 2002 04:40: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.4/8.12.4) with ESMTP id g71BejoN022116 for ; Thu, 1 Aug 2002 04:40: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 EAA20469 for ; Thu, 1 Aug 2002 04:40:49 -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 EAA19524 for ; Thu, 1 Aug 2002 04:40:49 -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 HAA25675; Thu, 1 Aug 2002 07:39:38 -0400 (EDT) Message-Id: <200208011139.HAA25675@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-nomad-mobileip-filters-02.txt Date: Thu, 01 Aug 2002 07:39:37 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Filters for Mobile IP Bindings (NOMAD) Author(s) : N. Fikouras et al. Filename : draft-nomad-mobileip-filters-02.txt Pages : 15 Date : 31-Jul-02 In Mobile IP, a mobile node that maintains simultaneous bindings will receive at each registered care-of address a duplicate copy of every datagram from every active flow. However, a mobile node with multiple points of attachment may wish to receive different flows at each one. The purpose of this document is to enable mobile nodes to associate a list of filters with a binding during its establishment (registration, binding update). In this manner, a mobile node may select for each flow the most appropriate point of attachment. In order not to violate layer independence, the filtering of individual flows or groups of them is managed through flow description components made available by existing approaches to QoS support. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nomad-mobileip-filters-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-nomad-mobileip-filters-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-nomad-mobileip-filters-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: <20020731143840.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nomad-mobileip-filters-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-nomad-mobileip-filters-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020731143840.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 1 15:38: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 PAA12522 for ; Thu, 1 Aug 2002 15:38:51 -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 NAA04696; Thu, 1 Aug 2002 13:38: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 MAA14550; Thu, 1 Aug 2002 12:38:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71JY8oN023597 for ; Thu, 1 Aug 2002 12:34:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71JY8LE023596 for mobile-ip-dist; Thu, 1 Aug 2002 12: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71JXuoN023581 for ; Thu, 1 Aug 2002 12:33:59 -0700 (PDT) Received: from lillen (hobo077.Eng.Sun.COM [129.146.31.77]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g71JXpg07911; Thu, 1 Aug 2002 21:33:52 +0200 (MEST) Date: Thu, 1 Aug 2002 19:18:22 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Mobile IPv6 I-D 18:BA status value To: Hiroyuki OHNISHI Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4.3.2-J.20020731113855.06b6db88@imd.m.ecl.ntt.co.jp> 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: > 6.1.2. Binding Refresh Request (BRR) Message > > [...] When a mobile node receives a > packet containing 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 > (see Section 5.2) if it believes the amount of traffic with the > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > correspondent justifies the use of route optimization. > > This means MN judges whether the MN uses RO or not depends > on the amount of traffic with CN when it receives BRR. Yes. Just like the MN initially decides when to first initiate a BU procedure, it isn't required to refresh the binding when it receives the BRR. The MN can presumably use whatever information it has (amount of traffic, the type of traffic, the phase of the moon) to determine which CNs it wants to use RO with at any given time. The high level point is that the BRR is a hint that the CN would like to see the binding refreshed. > And if the amount is low enough, it sends BA with 136 to the CN? Sending a BA in response to a BRR seems odd. I've been assuming the MN would just silently ignore the BRR if the MN doesn't see a need to refresh the binding. Perhaps this should be made explicit in the spec? Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 1 15:43: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 PAA12704 for ; Thu, 1 Aug 2002 15:43:39 -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 NAA25466; Thu, 1 Aug 2002 13:38: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 MAA26571; Thu, 1 Aug 2002 12:38:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71JYKoN023617 for ; Thu, 1 Aug 2002 12:34:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71JYKF9023616 for mobile-ip-dist; Thu, 1 Aug 2002 12:34:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71JY0oN023582 for ; Thu, 1 Aug 2002 12:34:04 -0700 (PDT) Received: from lillen (hobo077.Eng.Sun.COM [129.146.31.77]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g71JXvg07915; Thu, 1 Aug 2002 21:33:58 +0200 (MEST) Date: Thu, 1 Aug 2002 19:25:11 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? To: Rajeev Koodli Cc: Singh Ajoy-ASINGH1 , "'Alper E. YEGIN'" , James Kempf , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3D483F3F.318DE7D4@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: > This question is for the WG to decide. What do others > think ? Should we make PrRtAdv an optional message ? > Interop implications ? I'm having a hard time understanding the question without a specification that I can read which goes into detail of what messages are sent and received in which cases. If there are link layers where this message isn't useful at all, then it isn't useful for those link layers. As long as all the MNs and ARs in fact know that they are operating over such a link layer (which is an implementation issue; my IP stack doesn't know whether it is operating over Ethernet or 802.11 for instance), then it might be reasonable to state that the message is optional *when running over that link layer*. But I think the high-order bit is that such a message might not provide any utility on particular link layers. My 2 cents, Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 1 16:01: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 QAA13210 for ; Thu, 1 Aug 2002 16:01:07 -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 OAA17006; Thu, 1 Aug 2002 14:01: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 NAA07735; Thu, 1 Aug 2002 13:01:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71K0QoN023981 for ; Thu, 1 Aug 2002 13:00:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71K0QA6023980 for mobile-ip-dist; Thu, 1 Aug 2002 13:00: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.4/8.12.4) with ESMTP id g71K0KoN023973 for ; Thu, 1 Aug 2002 13:00: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 NAA07155 for ; Thu, 1 Aug 2002 13:00:25 -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 OAA12710 for ; Thu, 1 Aug 2002 14:00: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 NAA22377; Thu, 1 Aug 2002 13:00:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g71K0Km29251; Thu, 1 Aug 2002 13:00:20 -0700 X-mProtect: <200208012000> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtFlNWL; Thu, 01 Aug 2002 13:00:18 PDT Message-ID: <3D499352.5F5652A@iprg.nokia.com> Date: Thu, 01 Aug 2002 13:00:18 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: Singh Ajoy-ASINGH1 , "'Alper E. YEGIN'" , James Kempf , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? 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 Erik, Erik Nordmark wrote: > > This question is for the WG to decide. What do others > > think ? Should we make PrRtAdv an optional message ? > > Interop implications ? > > I'm having a hard time understanding the question without a specification > that I can read which goes into detail of what messages are sent and received > in which cases. The draft has so far addressed a base protocol that should work on all link types. Here is the URL. http://people.nokia.net/~rajeev/draft-ietf-mobileip-fast-mip6-05.txt The debate is now on whether we could optimize the protocol for certain link types. > > > If there are link layers where this message isn't useful at all, then it > isn't useful for those link layers. As long as all the MNs and ARs in fact > know that they are operating over such a link layer (which is an implementation > issue; my IP stack doesn't know whether it is operating over Ethernet or > 802.11 for instance), then it might be reasonable to state that the message is > optional *when running over that link layer*. > Ok. Although, I do not know of *existing* link layers where the functionality is provided by the link layer with the qualifier that serial links need consideration. > > But I think the high-order bit is that such a message might not provide any > utility on particular link layers. > OK. It would be good enlist those link layers that offer the same functionality today or are required to provide in future. Thanks, -Rajeev > > My 2 cents, > Erik From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 1 18:41: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 SAA19213 for ; Thu, 1 Aug 2002 18:41:07 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA20824; Thu, 1 Aug 2002 16:41: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 PAA12814; Thu, 1 Aug 2002 15:41:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g71MeZoN024299 for ; Thu, 1 Aug 2002 15:40:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g71MeZkX024298 for mobile-ip-dist; Thu, 1 Aug 2002 15:40: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.4/8.12.4) with ESMTP id g71MeToN024291 for ; Thu, 1 Aug 2002 15:40:29 -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 PAA12418 for ; Thu, 1 Aug 2002 15:40:33 -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 QAA27802 for ; Thu, 1 Aug 2002 16:40:30 -0600 (MDT) Message-ID: <011501c239ac$2c9781c0$296015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" , "Erik Nordmark" Cc: "Singh Ajoy-ASINGH1" , "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , References: <3D499352.5F5652A@iprg.nokia.com> Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? Date: Thu, 1 Aug 2002 15:38:35 -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 > > If there are link layers where this message isn't useful at all, then it > > isn't useful for those link layers. As long as all the MNs and ARs in fact > > know that they are operating over such a link layer (which is an implementation > > issue; my IP stack doesn't know whether it is operating over Ethernet or > > 802.11 for instance), then it might be reasonable to state that the message is > > optional *when running over that link layer*. > > > > Ok. Although, I do not know of *existing* link layers where > the functionality is provided by the link layer with the qualifier > that serial links need consideration. > See my message sent out yesterday on wCDMA. The message is unnecessary there because it duplicates information exchanged at the link layer. I believe IS-2000 is a similar situation, but I have not checked. > > > > But I think the high-order bit is that such a message might not provide any > > utility on particular link layers. > > > > OK. It would be good enlist those link layers that offer the > same functionality today or are required to provide in > future. > Do you mean compile a list of such link layers? jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 1 20:20: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 UAA21759 for ; Thu, 1 Aug 2002 20:20:37 -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 SAA23885; Thu, 1 Aug 2002 18:21: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 RAA13861; Thu, 1 Aug 2002 17:21:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g720KCoN024544 for ; Thu, 1 Aug 2002 17:20:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g720KC6D024543 for mobile-ip-dist; Thu, 1 Aug 2002 17:20: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.4/8.12.4) with ESMTP id g720K6oN024533 for ; Thu, 1 Aug 2002 17:20:06 -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 RAA13538 for ; Thu, 1 Aug 2002 17:20:12 -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 RAA24794; Thu, 1 Aug 2002 17:20: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 RAA08554; Thu, 1 Aug 2002 17:20:09 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g720K6R13912; Thu, 1 Aug 2002 17:20:06 -0700 X-mProtect: <200208020020> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4NuDbl; Thu, 01 Aug 2002 17:17:12 PDT Message-ID: <3D49CF88.268F6FCB@iprg.nokia.com> Date: Thu, 01 Aug 2002 17:17:12 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Erik Nordmark , Singh Ajoy-ASINGH1 , "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? References: <3D499352.5F5652A@iprg.nokia.com> <011501c239ac$2c9781c0$296015ac@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: > > > If there are link layers where this message isn't useful at all, then it > > > isn't useful for those link layers. As long as all the MNs and ARs in fact > > > know that they are operating over such a link layer (which is an > implementation > > > issue; my IP stack doesn't know whether it is operating over Ethernet or > > > 802.11 for instance), then it might be reasonable to state that the message > is > > > optional *when running over that link layer*. > > > > > > > Ok. Although, I do not know of *existing* link layers where > > the functionality is provided by the link layer with the qualifier > > that serial links need consideration. > > > > See my message sent out yesterday on wCDMA. The message is unnecessary there > because it duplicates information exchanged at the link layer. I believe IS-2000 > is a similar situation, but I have not checked. > I read your message, but did not understand how the MN gets the L2 address and IP address of the target access router, which is what it needs to send packets. It seemed like what the MN is getting is the BSSID of the target base station. Am I missing something ? > > > > > > > But I think the high-order bit is that such a message might not provide any > > > utility on particular link layers. > > > > > > > OK. It would be good enlist those link layers that offer the > > same functionality today or are required to provide in > > future. > > > > Do you mean compile a list of such link layers? > Yes, so that we know if majority of link layers already supply the information needed. -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 1 21:55: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 VAA23786 for ; Thu, 1 Aug 2002 21:55: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 TAA11222; Thu, 1 Aug 2002 19:55:35 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18223; Thu, 1 Aug 2002 18:55:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g721rioN024750 for ; Thu, 1 Aug 2002 18:53:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.4/8.12.4/Submit) id g721riL5024749 for mobile-ip-dist; Thu, 1 Aug 2002 18:53: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.4/8.12.4) with ESMTP id g721rcoN024742 for ; Thu, 1 Aug 2002 18:53:38 -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 SAA17927 for ; Thu, 1 Aug 2002 18:53:43 -0700 (PDT) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA10051 for ; Thu, 1 Aug 2002 19:53:40 -0600 (MDT) Received: from luster ([202.38.75.76]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id JAA14452 for ; Fri, 2 Aug 2002 09:37:45 +0800 Message-ID: <000f01c239c5$581029b0$2006a8c0@luster> From: "Wang Hui" To: Subject: [mobile-ip] drivers supported layer 2 triggers ....? Date: Fri, 2 Aug 2002 09:38:46 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g721rdoN024743 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello folks here, Sorry to bother u here. I see many discussion on fast handover and the related issues - triggers. I am doing some research about the fast handover of mobile ip. And I want to implement some prototypes of my idea in wlan(802.11b) to gain some experimental data . To setup the wlan, one things is to buy the wireless card and find the matched driver. There are tons of wireless card supporting 802.11b and I dont know how to choose the suitable one. I think different card with different drivers will result in different supporting level of wirelss functions. Triggers supporting is my most interesting functions. We have ordered linksys card for testing. Now before I get the card, I have a question that is whether the drivers of linksys supporting some layer 2 triggers?? If supporting, what are the supported triggers in the current software? Or any suggestion on choosing wireless card(802.11b)? More triggers, more better. ;) I am looking forward to your voice and any suggestion is appreciated. best, W.Hui -- Wang Hui Next Generation Internet Research Team, InfoNet Lab, USTC http://mail.ustc.edu.cn/~whui Tel: +86-551-3603634 From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 10:25: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 KAA21415 for ; Fri, 2 Aug 2002 10:25: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 HAA02905; Fri, 2 Aug 2002 07:24:35 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA06759; Fri, 2 Aug 2002 07:24:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72ENZ3U026190 for ; Fri, 2 Aug 2002 07:23:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72ENZsJ026189 for mobile-ip-dist; Fri, 2 Aug 2002 07:23:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72ENT3U026182 for ; Fri, 2 Aug 2002 07:23: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 HAA06353 for ; Fri, 2 Aug 2002 07:23:33 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23558 for ; Fri, 2 Aug 2002 08:23:32 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA06186 for ; Fri, 2 Aug 2002 07:23:32 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id HAA05914 for ; Fri, 2 Aug 2002 07:23:51 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 2 Aug 2002 09:23:32 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Rajeev Koodli'" , James Kempf Cc: Erik Nordmark , Singh Ajoy-ASINGH1 , "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmi pv6 ? Date: Fri, 2 Aug 2002 09:23:30 -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: I read your message, but did not understand how the MN gets the L2 address and IP address of the target access router, which is what it needs to send packets. It seemed like what the MN is getting is the BSSID of the target base station. Am I missing something ? AJOY-> As far as I know, WCDMA also provides serial link between MN and AR. So, I am not sure why it is must for MN to know L2 address and IP address of the nAR ? Could you clarify? -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Thursday, August 01, 2002 7:17 PM To: James Kempf Cc: Erik Nordmark; Singh Ajoy-ASINGH1; 'Alper E. YEGIN'; 'Vijay Devarapalli'; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? James Kempf wrote: > > > If there are link layers where this message isn't useful at all, then it > > > isn't useful for those link layers. As long as all the MNs and ARs in fact > > > know that they are operating over such a link layer (which is an > implementation > > > issue; my IP stack doesn't know whether it is operating over Ethernet or > > > 802.11 for instance), then it might be reasonable to state that the message > is > > > optional *when running over that link layer*. > > > > > > > Ok. Although, I do not know of *existing* link layers where > > the functionality is provided by the link layer with the qualifier > > that serial links need consideration. > > > > See my message sent out yesterday on wCDMA. The message is unnecessary there > because it duplicates information exchanged at the link layer. I believe IS-2000 > is a similar situation, but I have not checked. > I read your message, but did not understand how the MN gets the L2 address and IP address of the target access router, which is what it needs to send packets. It seemed like what the MN is getting is the BSSID of the target base station. Am I missing something ? > > > > > > > But I think the high-order bit is that such a message might not provide any > > > utility on particular link layers. > > > > > > > OK. It would be good enlist those link layers that offer the > > same functionality today or are required to provide in > > future. > > > > Do you mean compile a list of such link layers? > Yes, so that we know if majority of link layers already supply the information needed. -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 10:42: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 KAA22234 for ; Fri, 2 Aug 2002 10:42: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 IAA01276; Fri, 2 Aug 2002 08:42: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 HAA17050; Fri, 2 Aug 2002 07:42:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72Efc3U026377 for ; Fri, 2 Aug 2002 07:41:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72EfbU9026376 for mobile-ip-dist; Fri, 2 Aug 2002 07:41: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.5+Sun/8.12.5) with ESMTP id g72EfW3U026369 for ; Fri, 2 Aug 2002 07:41:32 -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 HAA16849 for ; Fri, 2 Aug 2002 07:41:36 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00424 for ; Fri, 2 Aug 2002 08:41:35 -0600 (MDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id HAA26993 for ; Fri, 2 Aug 2002 07:41:35 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id HAA21170 for ; Fri, 2 Aug 2002 07:41:34 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 2 Aug 2002 09:41:33 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'Rajeev Koodli'" , James Kempf Cc: Erik Nordmark , Singh Ajoy-ASINGH1 , "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmi pv6 ? Date: Fri, 2 Aug 2002 09:41:31 -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: Yes, so that we know if majority of link layers already supply the information needed. AJOY-> I can see link layer such as CDMA (IS-2000, WCDMA, IS-95A, IS-95B), TDMA (GSM, GPRS, IS-136) provides serial link connection between MN and AR. Correct me if I mis-stated? I do not claim to be expert in all mentioned link layers? On other handoff I can see 802.11 provides CSMA/CA type of MAC. Could you please list all the link layers where MN will really need L2 address as well as IP address of nAR to send any packet out? -----Original Message----- From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com] Sent: Thursday, August 01, 2002 7:17 PM To: James Kempf Cc: Erik Nordmark; Singh Ajoy-ASINGH1; 'Alper E. YEGIN'; 'Vijay Devarapalli'; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? James Kempf wrote: > > > If there are link layers where this message isn't useful at all, then it > > > isn't useful for those link layers. As long as all the MNs and ARs in fact > > > know that they are operating over such a link layer (which is an > implementation > > > issue; my IP stack doesn't know whether it is operating over Ethernet or > > > 802.11 for instance), then it might be reasonable to state that the message > is > > > optional *when running over that link layer*. > > > > > > > Ok. Although, I do not know of *existing* link layers where > > the functionality is provided by the link layer with the qualifier > > that serial links need consideration. > > > > See my message sent out yesterday on wCDMA. The message is unnecessary there > because it duplicates information exchanged at the link layer. I believe IS-2000 > is a similar situation, but I have not checked. > I read your message, but did not understand how the MN gets the L2 address and IP address of the target access router, which is what it needs to send packets. It seemed like what the MN is getting is the BSSID of the target base station. Am I missing something ? > > > > > > > But I think the high-order bit is that such a message might not provide any > > > utility on particular link layers. > > > > > > > OK. It would be good enlist those link layers that offer the > > same functionality today or are required to provide in > > future. > > > > Do you mean compile a list of such link layers? > Yes, so that we know if majority of link layers already supply the information needed. -Rajeev > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 11:42: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 LAA24191 for ; Fri, 2 Aug 2002 11:42:30 -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 IAA15197; Fri, 2 Aug 2002 08:41: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 IAA01376; Fri, 2 Aug 2002 08:41:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72FeF3U026611 for ; Fri, 2 Aug 2002 08:40:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72FeFsc026610 for mobile-ip-dist; Fri, 2 Aug 2002 08:40: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.5+Sun/8.12.5) with ESMTP id g72Fe93U026603 for ; Fri, 2 Aug 2002 08:40:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08135 for ; Fri, 2 Aug 2002 08:40:14 -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 JAA26511; Fri, 2 Aug 2002 09:40:10 -0600 (MDT) Message-ID: <000b01c23a3a$a72c07b0$296015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Erik Nordmark" , "Singh Ajoy-ASINGH1" , "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , References: <3D499352.5F5652A@iprg.nokia.com> <011501c239ac$2c9781c0$296015ac@T23KEMPF> <3D49CF88.268F6FCB@iprg.nokia.com> Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? Date: Fri, 2 Aug 2002 08:38:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > Content-Transfer-Encoding: 7bit > I read your message, but did not understand how the MN > gets the L2 address and IP address of the target access router, which > is what it needs to send packets. It seemed like what the MN is > getting is the BSSID of the target base station. Am I missing > something ? > That requires the Seamoby CARD protocol, or a static table mapping the BS id to the target router id. The same procedure is required by any radio protocol in which the base station is not integrated with the access router, and it would even be required if PrRtAdv were sent, in order that the old AR could get the new AR's IP address for the HI/HaCK. > > Yes, so that we know if majority of link layers already > supply the information needed. > Here is a start at a list: wCDMA - PrRtAdv not necessary, BS id of target BS is supplied by L2 signaling, mapped to router L2/IP address via Seamoby CARD protocol or a static table on BS/old AR. IS-2000 - Same as wCDMA (but needs confirmation) flash OFDM - Fast handover not necessary. Wireless layer 2 is capable of true make-before-break, so the mobile can conduct RS/RA and binding updates on the forward channel to the new BS while getting its traffic on the backward channel. 802.11a,b,g- PrRtAdv and SolPrRtAdv not possible in a portable way, since 802.11 standard provides no prehandover signaling on the mobile or access point. Nonportable, proprietary extensions to some product drivers to provide signal strength may allow use, but depends on product firmware. Bluetooth - The standard Bluetooth IP profile requires IP to run over PPP, so fast handover is probably not an option. (Aside: is somebody looking at how Mobile IP would work with PPP for Bluetooth?) Hyperlan - ??? (is Hyperlan still important?) GSM - ??? ( is it important? GPRS hides the radio protocol fairly deeply?) If anyone is more familiar with these radio protocols, or others that I have missed, please reply with corrections. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 12:23: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 MAA25556 for ; Fri, 2 Aug 2002 12:23:12 -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 JAA04633; Fri, 2 Aug 2002 09:22: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 JAA17402; Fri, 2 Aug 2002 09:22:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72GL03U026836 for ; Fri, 2 Aug 2002 09:21:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72GKxmn026835 for mobile-ip-dist; Fri, 2 Aug 2002 09:20:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72GKs3U026828 for ; Fri, 2 Aug 2002 09:20:54 -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 JAA14458 for ; Fri, 2 Aug 2002 09:20:59 -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 KAA16962 for ; Fri, 2 Aug 2002 10:20:57 -0600 (MDT) Message-ID: <007101c23a40$55d44d90$296015ac@T23KEMPF> From: "James Kempf" To: "Singh Ajoy-ASINGH1" , "'Rajeev Koodli'" Cc: "Erik Nordmark" , "Singh Ajoy-ASINGH1" , "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , References: Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? Date: Fri, 2 Aug 2002 09:19: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 Ajoy, > AJOY-> As far as I know, WCDMA also provides serial link > between MN and AR. So, I am not sure why it is must > for MN to know L2 address and IP address of the nAR ? > Could you clarify? > I wasn't talking about the UTRAN/GPRS protocols, I was just talking about the radio protocol wCDMA. If you look at the whole UTRAN/GPRS, it results in a connection-oriented setup like a serial link terminating at the GGSN (PDP context). They can also set up using PPP. But the wCDMA radio protocol has nothing in it (as far as I can tell) that requires this. Someone having more familiarity with the protocol can correct me if I am wrong. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 12:40: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 MAA26167 for ; Fri, 2 Aug 2002 12:40:03 -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 JAA17407; Fri, 2 Aug 2002 09:39: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 JAA27043; Fri, 2 Aug 2002 09:39:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72Gbu3U027035 for ; Fri, 2 Aug 2002 09:37:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72GbuQu027034 for mobile-ip-dist; Fri, 2 Aug 2002 09:37: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.5+Sun/8.12.5) with ESMTP id g72Gbo3U027027 for ; Fri, 2 Aug 2002 09:37: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 JAA23944 for ; Fri, 2 Aug 2002 09:37:56 -0700 (PDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05704 for ; Fri, 2 Aug 2002 10:37:55 -0600 (MDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA05792 for ; Fri, 2 Aug 2002 09:37:55 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id JAA25573 for ; Fri, 2 Aug 2002 09:38:14 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 2 Aug 2002 11:37:55 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: "'James Kempf'" , Singh Ajoy-ASINGH1 , "'Rajeev Koodli'" Cc: Erik Nordmark , Singh Ajoy-ASINGH1 , "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmi pv6 ? Date: Fri, 2 Aug 2002 11:37:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I wasn't talking about the UTRAN/GPRS protocols, I was just talking about the radio protocol wCDMA. AJOY-> Ok If you look at the whole UTRAN/GPRS, it results in a connection-oriented setup like a serial link terminating at the GGSN (PDP context). can also set up using PPP. But the wCDMA radio protocol has nothing in it (as far as I can tell) that requires this. Someone having more familiarity with the protocol can correct me if I am wrong. AJOY-> Sure, you can can replace UTRAN/GRPS with something else. I did say that you were wrong. I just mentioned that current WCDMA based network provides serial link between MN and AR. This is going to remain same unless the WCDMA MAC is changed drastically. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, August 02, 2002 11:19 AM To: Singh Ajoy-ASINGH1; 'Rajeev Koodli' Cc: Erik Nordmark; Singh Ajoy-ASINGH1; 'Alper E. YEGIN'; 'Vijay Devarapalli'; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? Ajoy, > AJOY-> As far as I know, WCDMA also provides serial link > between MN and AR. So, I am not sure why it is must > for MN to know L2 address and IP address of the nAR ? > Could you clarify? > I wasn't talking about the UTRAN/GPRS protocols, I was just talking about the radio protocol wCDMA. If you look at the whole UTRAN/GPRS, it results in a connection-oriented setup like a serial link terminating at the GGSN (PDP context). They can also set up using PPP. But the wCDMA radio protocol has nothing in it (as far as I can tell) that requires this. Someone having more familiarity with the protocol can correct me if I am wrong. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 13:08:50 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27027 for ; Fri, 2 Aug 2002 13:08: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 LAA01002; Fri, 2 Aug 2002 11:09: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 KAA09861; Fri, 2 Aug 2002 10:09:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72H8F3U027248 for ; Fri, 2 Aug 2002 10:08:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72H8EOf027247 for mobile-ip-dist; Fri, 2 Aug 2002 10:08: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.5+Sun/8.12.5) with ESMTP id g72H883U027240 for ; Fri, 2 Aug 2002 10:08:08 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03057 for ; Fri, 2 Aug 2002 10:08:14 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05028; Fri, 2 Aug 2002 10:08:13 -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 KAA15720; Fri, 2 Aug 2002 10:08:12 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g72H8CX30264; Fri, 2 Aug 2002 10:08:12 -0700 X-mProtect: <200208021708> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAKwWcc; Fri, 02 Aug 2002 10:08:10 PDT Message-ID: <3D4ABC7A.9343333A@iprg.nokia.com> Date: Fri, 02 Aug 2002 10:08:10 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Erik Nordmark , Singh Ajoy-ASINGH1 , "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? References: <3D499352.5F5652A@iprg.nokia.com> <011501c239ac$2c9781c0$296015ac@T23KEMPF> <3D49CF88.268F6FCB@iprg.nokia.com> <000b01c23a3a$a72c07b0$296015ac@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: > > > > I read your message, but did not understand how the MN > > gets the L2 address and IP address of the target access router, which > > is what it needs to send packets. It seemed like what the MN is > > getting is the BSSID of the target base station. Am I missing > > something ? > > > > That requires the Seamoby CARD protocol, or a static table mapping the BS id to > the target router id. The same procedure is required by any radio protocol in > which the base station is not integrated with the access router, and it would > even be required if PrRtAdv were sent, in order that the old AR could get the > new AR's IP address for the HI/HaCK. > The AR needs a mapping, yes. However, how does the MN get the mapping information ? Who provides it ? A link layer message ? If yes, is such thing there in the relevant spec ? > > > > > Yes, so that we know if majority of link layers already > > supply the information needed. > > > > Here is a start at a list: > > wCDMA - PrRtAdv not necessary, BS id of target BS is supplied by L2 > signaling, mapped to router L2/IP address via Seamoby CARD protocol or a static > table on BS/old AR. > Rajeev: Same comment as above: which message provides the information to the MN ? > IS-2000 - Same as wCDMA (but needs confirmation) Ok. > > flash OFDM - Fast handover not necessary. Wireless layer 2 is capable of > true make-before-break, so the mobile > can conduct RS/RA and binding updates on the forward > channel to the new BS while getting its traffic > on the backward channel. > Ok. > 802.11a,b,g- PrRtAdv and SolPrRtAdv not possible in a portable way, since > 802.11 standard provides no prehandover > signaling on the mobile or access point. Nonportable, > proprietary extensions to some product drivers > to provide signal strength may allow use, but depends > on product firmware. > So, how does a WLAN card decide to associate with a new AP ? There is a "scan" message that allows the MS to figure out what APs are within reach. After that, there has to be some guideline as to when the MS changes its AP, based on, e.g., received signal strength. The result of scan is the input to PrRtSol. We don't have to standardize how the scanning works etc, do we ? It suffices to provide a message that can be called when the L2 decides to look for other AP(s). Note that there is analogous support in Linux to send a RS upon detecting a new link. If the MS moves before PrRtSol could be attempted, then the HI/HAck happens after the association with the new AP. -Rajeev > Bluetooth - The standard Bluetooth IP profile requires IP to run over PPP, > so fast handover is probably not an option. > (Aside: is somebody looking at how Mobile IP would work > with PPP for Bluetooth?) > Hyperlan - ??? (is Hyperlan still important?) > GSM - ??? ( is it important? GPRS hides the radio protocol fairly deeply?) > > If anyone is more familiar with these radio protocols, or others that I have > missed, please reply with corrections. > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 13:34: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 NAA27985 for ; Fri, 2 Aug 2002 13:34: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 KAA16997; Fri, 2 Aug 2002 10:33: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 KAA13683; Fri, 2 Aug 2002 10:33:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72HWi3U027416 for ; Fri, 2 Aug 2002 10:32:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72HWi6D027415 for mobile-ip-dist; Fri, 2 Aug 2002 10:32:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72HWc3U027408 for ; Fri, 2 Aug 2002 10:32:38 -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 KAA20336 for ; Fri, 2 Aug 2002 10:32:43 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16282 for ; Fri, 2 Aug 2002 10:32:42 -0700 (PDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id KAA15259 for ; Fri, 2 Aug 2002 10:32:42 -0700 (MST)] Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id KAA11731 for ; Fri, 2 Aug 2002 10:33:00 -0700 (MST)] Received: by IL75EXM04 with Internet Mail Service (5.5.2654.52) id ; Fri, 2 Aug 2002 12:32:39 -0500 Message-ID: From: Singh Ajoy-ASINGH1 To: Singh Ajoy-ASINGH1 , "'James Kempf'" , "'Rajeev Koodli'" Cc: "'Erik Nordmark'" , "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , "'mobile-ip@sunroof.eng.sun.com'" Subject: RE: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmi pv6 ? Date: Fri, 2 Aug 2002 12:30:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: James, Sorry,I missed a NOT in "I did say that you were wrong. " Regards, ajoy -----Original Message----- From: Singh Ajoy-ASINGH1 Sent: Friday, August 02, 2002 11:38 AM To: 'James Kempf'; Singh Ajoy-ASINGH1; 'Rajeev Koodli' Cc: Erik Nordmark; Singh Ajoy-ASINGH1; 'Alper E. YEGIN'; 'Vijay Devarapalli'; mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? I wasn't talking about the UTRAN/GPRS protocols, I was just talking about the radio protocol wCDMA. AJOY-> Ok If you look at the whole UTRAN/GPRS, it results in a connection-oriented setup like a serial link terminating at the GGSN (PDP context). can also set up using PPP. But the wCDMA radio protocol has nothing in it (as far as I can tell) that requires this. Someone having more familiarity with the protocol can correct me if I am wrong. AJOY-> Sure, you can can replace UTRAN/GRPS with something else. I did say that you were wrong. I just mentioned that current WCDMA based network provides serial link between MN and AR. This is going to remain same unless the WCDMA MAC is changed drastically. -----Original Message----- From: James Kempf [mailto:kempf@docomolabs-usa.com] Sent: Friday, August 02, 2002 11:19 AM To: Singh Ajoy-ASINGH1; 'Rajeev Koodli' Cc: Erik Nordmark; Singh Ajoy-ASINGH1; 'Alper E. YEGIN'; 'Vijay Devarapalli'; mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? Ajoy, > AJOY-> As far as I know, WCDMA also provides serial link > between MN and AR. So, I am not sure why it is must > for MN to know L2 address and IP address of the nAR ? > Could you clarify? > I wasn't talking about the UTRAN/GPRS protocols, I was just talking about the radio protocol wCDMA. If you look at the whole UTRAN/GPRS, it results in a connection-oriented setup like a serial link terminating at the GGSN (PDP context). They can also set up using PPP. But the wCDMA radio protocol has nothing in it (as far as I can tell) that requires this. Someone having more familiarity with the protocol can correct me if I am wrong. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 14:24: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 OAA29677 for ; Fri, 2 Aug 2002 14:24:19 -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 MAA12052; Fri, 2 Aug 2002 12:24:55 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12112; Fri, 2 Aug 2002 11:24:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72INi3U027709 for ; Fri, 2 Aug 2002 11:23:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72INium027708 for mobile-ip-dist; Fri, 2 Aug 2002 11:23:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72INa3U027701 for ; Fri, 2 Aug 2002 11:23:36 -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 LAA02607 for ; Fri, 2 Aug 2002 11:23:37 -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 MAA19787 for ; Fri, 2 Aug 2002 12:23:36 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 77CEE1BDB; Fri, 2 Aug 2002 13:23:35 -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 48B31835; Fri, 2 Aug 2002 11:18:37 -0700 (PDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id OAA0002037811; Fri, 2 Aug 2002 14:18:33 -0400 (EDT) Message-ID: <3D4ACCF8.4278AD04@hp.com> Date: Fri, 02 Aug 2002 14:18:33 -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: Jari Arkko Cc: mobile ip Subject: Re: [mobile-ip] MH type field References: <3D406FA5.6680BE72@hp.com> <3D413F89.3060102@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: > Brian Haley wrote: > > > I was wondering why the MH type field (Section 6.1.1, draft 18) was 16 bits > > and not 8 bits. I couldn't find any other IPv6 header that had a type larger > > than 8 bits, and I don't think we'll ever have 65535 types. Should this be > > changed to 8 bits for type and 8 bits reserved? This also saves a nthos() > > for those of us on certain-endian machines, not that 3 assembly instructions > > is buying me anything :) > > 8 bits looks sufficient now. OTOH I don't think the 8 bit reserved field > buys very much either. And there are some protocols in the Internet > where 8 bits looked initially sufficient but proved later to be insufficient. > Mobility is an interesting subject to many folks. Will 256 values cover > all the xMIP extensions that we might need in the future? Yeah, you could > also say that it's a terrible thought that we'd need so much complexity > that 10-15 values wouldn't do... > > By the way, if you switch statements in the code are in network byte > order, you'll save the 3 instructions ;-) > > My gut feeling is that we should keep the current format, unless > someone has strong arguments otherwise. My only follow-up would be that we could change a reserved field into an "extended type" field in the future. For example, if type == 255 then add "extended type" to it to get the actual type. It would be harder to go the other way. Noone else seems to have an opinion either way about such little issues though... -Brian From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 14:49:33 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 OAA00919 for ; Fri, 2 Aug 2002 14:49: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 LAA29187; Fri, 2 Aug 2002 11:48: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 LAA22603; Fri, 2 Aug 2002 11:48:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72IlI3U028038 for ; Fri, 2 Aug 2002 11:47:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72IlIsO028037 for mobile-ip-dist; Fri, 2 Aug 2002 11:47: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.5+Sun/8.12.5) with ESMTP id g72IlC3U028030 for ; Fri, 2 Aug 2002 11:47:12 -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 LAA15436 for ; Fri, 2 Aug 2002 11:47:17 -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 MAA01106 for ; Fri, 2 Aug 2002 12:47:16 -0600 (MDT) Message-ID: <012001c23a54$c7497860$296015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Erik Nordmark" , "Singh Ajoy-ASINGH1" , "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , References: <3D499352.5F5652A@iprg.nokia.com> <011501c239ac$2c9781c0$296015ac@T23KEMPF> <3D49CF88.268F6FCB@iprg.nokia.com> <000b01c23a3a$a72c07b0$296015ac@T23KEMPF> <3D4ABC7A.9343333A@iprg.nokia.com> Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? Date: Fri, 2 Aug 2002 11:45:31 -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 > The AR needs a mapping, yes. However, how does the MN get the > mapping information ? Who provides it ? A link layer message ? If > yes, is such thing there in the relevant spec ? > In the case of radio protocols such as wCDMA, the MN doesn't need this information, since the MN and the old BS exchange the identity of the new BS at the link layer. The old BS sends the Layer 2 identifier of the new BS to the AR by a Layer 2 specific means, or using something like Alper's proposed ICMP message, if the BS and AR are not integrated. If they are integrated, then the AR will have this information. The AR can use either the CARD protocol or a static table to do the lookup, exchange HI/HaCK. The MN's link gets switched at Layer 2, the AR tunnels until the MN completes binding update on the new AR. For link layers where there is no exchange of new BS identity over the air at Layer 2 prior to handover but the MN knows, the MN can use Seamoby CARD to do the mapping, and SolPrRtAdv/PrRtAdv would be required. For link layers with no prehandover signaling between the BS and MN such as 802.11, the MN can use Seamoby CARD after handover and do the mapping, but it is yet unclear how the tunnel would be initiated in this case. Alternatively, the BS can do the mapping if the old BS id is known, and use target triggered handover, which is also undefined in draft 5. The fast handover signaling for this case is the most underspecified in draft 5, IMHO. In any case, how the BS does this mapping is out of scope for the fast handover spec, though we do need to have it nailed down for a complete solution. > > wCDMA - PrRtAdv not necessary, BS id of target BS is supplied by L2 > > signaling, mapped to router L2/IP address via Seamoby CARD protocol or a static > > table on BS/old AR. > > > > > Rajeev: Same comment as above: which message provides the information > to the MN ? See above. > > > IS-2000 - Same as wCDMA (but needs confirmation) > > Ok. > > > > > flash OFDM - Fast handover not necessary. Wireless layer 2 is capable of > > true make-before-break, so the mobile > > can conduct RS/RA and binding updates on the forward > > channel to the new BS while getting its traffic > > on the backward channel. > > > > Ok. > > > 802.11a,b,g- PrRtAdv and SolPrRtAdv not possible in a portable way, since > > 802.11 standard provides no prehandover > > signaling on the mobile or access point. Nonportable, > > proprietary extensions to some product drivers > > to provide signal strength may allow use, but depends > > on product firmware. > > > > So, how does a WLAN card decide to associate with a new AP ? Proprietary. It is not specified in the 802.11 standard. As a practical matter, FER and signal strength are both possibilites. In existing products, there are a wide variety of algorithms, and they are likely to get more varied as vendors start competing on handover performance. > There is > a "scan" message that allows the MS to figure out what APs are within > reach. After that, there has to be some guideline as to when the MS > changes its AP, based on, e.g., received signal strength. It could also be FER. Also, some current products do make a decision based on other measures not associated with the quality of the link. 802.11 is not like cellular, there is no standard signal strength specified nor a standard FER, nor even a requirement that these should be used to make the handover decision. The only standardized signaling is the Reassociation.request() and Reassociation.reply() when the card has selected which access point it will associate with. > The result of scan is the input to PrRtSol. Our experience is that the results of a scan are not typically available to the driver when a handover is necessary, it is conducted by the firmware, and is followed by the Reassociation.request()/reply() without any driver intervention. On some cards, a scan can be forced, signal strength measured, and handover forced by the driver, but this is by no means a standard. Also,during the exchange of PrRtSol/PrRtAdv (which will take some amount of time) after the scan is forced, the firmware could decide to perform handover to a completely different access point. Nothing constrains the firmware to continue being associated with the current access point until the PrRtSol/PrRtAdv completes. Finally, while a scan is being conducted, the card is basically offline for any traffic. This means that the scan prior to the PrRtSol/PrRtAdv would shut down traffic to the card, during which time it would have to be buffered (or dropped) if the scan takes too long. We've measured typical scan times of about 100 ms on a cell with a single MN. This time increases dramatically if there is more than one MN in the cell, because 802.11 has no QoS on signaling traffic. The scan is scheduled on the link with the same priority as MN traffic. With 3 MNs doing continuous traffic, the scan time can be upwards of 200 ms. > We don't have to standardize > how the scanning works etc, do we ? We can't. It is up to IEEE 802.11 to do that. They have been extremely reluctant to do any standardization of prehandover conditions. I've been advised to not pursue the issue with them. > It suffices to provide a message > that can be called when the L2 decides to look for other AP(s). Note > that there is analogous support in Linux to send a RS upon detecting > a new link. > I don't follow. If the Layer 2 protocol doesn't provide this, how can IP help? We can't control what happens at Layer 2 unless the hooks are there. > If the MS moves before PrRtSol could be attempted, then the HI/HAck > happens after the association with the new AP. > Sure, that's target triggered handover. There is something in draft 04 to do this, and also in the FMIPv4 draft. jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 15: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 PAA02296 for ; Fri, 2 Aug 2002 15: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 NAA19314; Fri, 2 Aug 2002 13:14: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 MAA20748; Fri, 2 Aug 2002 12:14:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72JDa3U028228 for ; Fri, 2 Aug 2002 12:13:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72JDZQi028227 for mobile-ip-dist; Fri, 2 Aug 2002 12:13:35 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72JDW3U028220 for ; Fri, 2 Aug 2002 12:13: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 PAA03682 for ; Fri, 2 Aug 2002 15:13:37 -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 g72JDkXA027291 for ; Fri, 2 Aug 2002 15:13:46 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g72JDkfU027290 for mobile-ip@sunroof.eng.sun.com; Fri, 2 Aug 2002 15:13:46 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UD31oN014912 for ; Tue, 30 Jul 2002 06:03:01 -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 GAA23850 for ; Tue, 30 Jul 2002 06:03:06 -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 GAA16858 for ; Tue, 30 Jul 2002 06:03:05 -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 g6UD2xL15567; Tue, 30 Jul 2002 15:02: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 PAA13747; Tue, 30 Jul 2002 15:03:00 +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.12.3/8.12.3) with ESMTP id g6UD2x6o016209; Tue, 30 Jul 2002 15:02:59 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200207301302.g6UD2x6o016209@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobile-ip@sunroof.eng.sun.com Cc: mipv6imp@enst-bretagne.fr Subject: [mobile-ip] new list for Mobile IPv6 implementors Date: Tue, 30 Jul 2002 15:02:59 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I am creating a new mailing list for Mobile IPv6 implementors. My purpose is to fix the small & little details in the draft 19 (i.e., the draft 18 + the closed points, the draft 19 should be out in some days) for the ETSI IPv6 plugtests event at the end of September. The list is at , subscription is initiated by a mail to sympa@enst-bretagne.fr (the mailing-list server) with "subscribe mipv6imp FirstName LastName" in the body. Regards Francis.Dupont@enst-bretagne.fr The (long) URL of the ETSI event is: http://www.etsi.org/plugtests/02UpcomingEvents/IPv6/IPv6_home.htm From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 15:20: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 PAA02523 for ; Fri, 2 Aug 2002 15:20:49 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16645; Fri, 2 Aug 2002 12:19: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 MAA06728; Fri, 2 Aug 2002 12:19:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72JIm3U028528 for ; Fri, 2 Aug 2002 12:18:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72JImPG028527 for mobile-ip-dist; Fri, 2 Aug 2002 12:18: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.5+Sun/8.12.5) with ESMTP id g72JIg3U028517 for ; Fri, 2 Aug 2002 12:18:42 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25871 for ; Fri, 2 Aug 2002 12:18:48 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08142 for ; Fri, 2 Aug 2002 13:18:47 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H08008SVDNB5X@edgemail1.Central.Sun.COM> for mobile-ip@sunroof.eng.sun.com; Fri, 02 Aug 2002 13:18:47 -0600 (MDT) Received: from dhcp-ubur02-174-198.East.Sun.COM ([129.148.174.236]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H0800IRPDNAW1@mail.sun.net> for mobile-ip@sunroof.eng.sun.com; Fri, 02 Aug 2002 13:18:47 -0600 (MDT) Date: Fri, 02 Aug 2002 15:19:24 -0400 From: "Steven M. Glass" Subject: [mobile-ip] Mail problems To: mobile-ip@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) 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 Not the list - with me. Besides being over-committed right now (which you don't care about, I know; I don't want it to effect the list), I had some mail problems which prevented me from approving some posts, so they'll be following this email. Even the archive justifies sending these, but with apologies for the latency. Cheers, Steve From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 15:23: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 PAA02626 for ; Fri, 2 Aug 2002 15:23: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 NAA15497; Fri, 2 Aug 2002 13:24:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27707; Fri, 2 Aug 2002 12:24:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72JNN3U028679 for ; Fri, 2 Aug 2002 12:23:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72JNMNn028678 for mobile-ip-dist; Fri, 2 Aug 2002 12:23: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72JNJ3U028668 for ; Fri, 2 Aug 2002 12:23:19 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA06099 for ; Fri, 2 Aug 2002 15:23:24 -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 g72JNWXA027305 for ; Fri, 2 Aug 2002 15:23:32 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g72JNW49027304 for mobile-ip@sunroof.eng.sun.com; Fri, 2 Aug 2002 15:23:32 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UIV6oN015671; Tue, 30 Jul 2002 11:31:06 -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 LAA14000; Tue, 30 Jul 2002 11:31:10 -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 MAA08308; Tue, 30 Jul 2002 12:31:09 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 41C71695C; Tue, 30 Jul 2002 14:31:07 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 30 Jul 2002 14:31:06 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Tue, 30 Jul 2002 14:31:06 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8DBD@tayexc13.americas.cpqcorp.net> Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt7cTWMfDr88ZlQ3iaoLJAwT95/QAAdA9AAoHdRGA= From: "Bound, Jim" To: , , Cc: , , , X-OriginalArrivalTime: 30 Jul 2002 18:31:06.0982 (UTC) FILETIME=[44C22860:01C237F7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6UIV7oN015672 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit John, I would prefer all requirements for me to implement are in the specs as a programmer. I view node reqs doc as a statement of further reqs of the std regarding conformance not implementation. If we don't want HAO to be MUST make it a SHOULD this should be decided in the MIPv6 spec.k thanks /jim -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Wednesday, July 17, 2002 8:14 PM To: mat@cisco.com; vijayd@iprg.nokia.com Cc: itojun@iijlab.net; keiichi@iij.ad.jp; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Hi Mike, Vijay Devarapalli writes: RO is a SHOULD, it is not a MUST in the current draft. we were not talking about route optimization. we were talking about processing a HAO. in the current spec HAO MUST be processed but not accepted if it cant be verified. verification can be in the form of checking for a valid BCE (created securely), IPsec protected data session, same trusted domain (where you dont expect people to do reflection attacks), the tagging proposal from Rajeev and Charlie, smart ingress filtering from Francis Dupont, etc... Oh, OK. Sorry about that. Still if the code isn't in the CN, the MN should still be able to operate correctly, right? That still seems to me to be a SHOULD rather than a MUST for the same reasons in my reply to John. I guess the long and short of this is that I'm somewhat skeptical of putting general node requirements in the MIP draft since it's probably not the first place one would be looking to figure out if they were an IPv6 compliant node. If it's really, really vital for the health of the net, yadda, yadda, it would be better to put it in a general v6 node requirements RFC, don't you think? Just as an FYI, I replied to the earlier mail because I am trying to sort this out for the node requirements. I think that in MIPv6, it is OK that MIPv6 makes this recommendation (given working group consensus, IESG approval, etc.) but the Node Requirements document is the final word on the issue (assuming WG consensus, IESG approval, etc.). John -------------------------------------------------------------------- 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 Aug 2 15:24: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 PAA02675 for ; Fri, 2 Aug 2002 15:24:40 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA15943; Fri, 2 Aug 2002 13:25: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 MAA08655; Fri, 2 Aug 2002 12:25:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72JO83U028696 for ; Fri, 2 Aug 2002 12:24:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72JO80F028695 for mobile-ip-dist; Fri, 2 Aug 2002 12:24:08 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72JO53U028688 for ; Fri, 2 Aug 2002 12:24:05 -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 PAA06248 for ; Fri, 2 Aug 2002 15:24:09 -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 g72JOIXA027310 for ; Fri, 2 Aug 2002 15:24:18 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g72JOIms027309 for mobile-ip@sunroof.eng.sun.com; Fri, 2 Aug 2002 15:24:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g6UIZHoN015699; Tue, 30 Jul 2002 11:35:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05543; Tue, 30 Jul 2002 11:35:20 -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 MAA21255; Tue, 30 Jul 2002 12:35:20 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B06B26A02; Tue, 30 Jul 2002 14:35:19 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 30 Jul 2002 14:35:19 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Date: Tue, 30 Jul 2002 14:35:18 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8DBE@tayexc13.americas.cpqcorp.net> Thread-Topic: [mobile-ip] Re: HAO and BE processing will be mandated Thread-Index: AcIt8ZI6pG4dYJ6ERBKA9LCbowSLNwAAQizQAoE4d6A= From: "Bound, Jim" To: , , , Cc: , , , X-OriginalArrivalTime: 30 Jul 2002 18:35:19.0402 (UTC) FILETIME=[DB3664A0:01C237F7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g6UIZHoN015700 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit HAO SHOULD be implemented. MUST is a stretch and I always thought so since draft 1. The security argument is irrelevant to being a MUST or SHOULD if I deployed MIPv6 I would not use RR or any IPsec there are many ways to secure the mobile nodes and CNs and I agree with Vijays point on this just not the MUST. That being said anyone who would not want to implement mobile HAO is not in tune with the market at all. But thats not the IETFs job to keep them in tune. /jim -----Original Message----- From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] Sent: Wednesday, July 17, 2002 8:41 PM To: hesham.soliman@era.ericsson.se; mat@cisco.com; itojun@iijlab.net Cc: vijayd@iprg.nokia.com; keiichi@iij.ad.jp; mobile-ip@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated Hi Hesham, => Exactly, IMHO the support for HAO is tied to RO support which is a SHOULD anyway, so the HAO should follow that. Logically, you are inconsistant. As an example, RO is a should, protecting RO is a MUST. => Huh? Protecting it is a must for those who support it! But supporting it is a should. We're dangerously on the edge of a rathole. Debates on support / implement / use of various functions is something to often causes pointless discussions. The question more is, what do general implementations need to implement. In my opinion, general often equals robust. SHOULD does not mean optional, it means you do it unless you have good reason not to do it. I think the burden of proof, then, would be the endpoint which does not implement a certain feature. I think that since HAO is used for security reasons, it may have a strong need to be a must than other functionality. Just my opinion. John From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 15:36: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 PAA03169 for ; Fri, 2 Aug 2002 15:36:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01836; Fri, 2 Aug 2002 13:37: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 MAA13489; Fri, 2 Aug 2002 12:37:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72JZJ3U029207 for ; Fri, 2 Aug 2002 12:35:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72JZJ2v029206 for mobile-ip-dist; Fri, 2 Aug 2002 12:35: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.5+Sun/8.12.5) with ESMTP id g72JYx3U029198 for ; Fri, 2 Aug 2002 12:35:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12229 for ; Fri, 2 Aug 2002 12:34:22 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00415 for ; Fri, 2 Aug 2002 13:34:21 -0600 (MDT) Received: from xpa-fe2 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H08008L9ED95X@edgemail1.Central.Sun.COM> for mobile-ip@sunroof.eng.sun.com; Fri, 02 Aug 2002 13:34:21 -0600 (MDT) Received: from dhcp-ubur02-174-198.East.Sun.COM ([129.148.174.236]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H0800IXAED8W1@mail.sun.net> for mobile-ip@sunroof.eng.sun.com; Fri, 02 Aug 2002 13:34:21 -0600 (MDT) Date: Fri, 02 Aug 2002 15:34:58 -0400 From: "Steven M. Glass" Subject: [mobile-ip] Don't subscribe us to other lists! To: mobile-ip@sunroof.eng.sun.com Cc: Raj Patil , proberts@MEGISTO.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) 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 Sometime on Wednesday, it seems, someone subscribed mobile- ip@sunroof.eng.sun.com to tf-cdma, the CDMA Technical Forum list. Please, and I can't stress this enough, don't do this! If you don't understand why this is bad, and you have a few extra hours, get in touch with me and I'll let you know. In all seriousness, Steven M. Glass owner-mobile-ip@sunroof.eng.sun.com >Date: Wed, 31 Jul 2002 07:39:23 -0400 (EDT) >Message-Id: <200207311139.g6VBdNW29891@ruebert.ieee.org> >To: mobile-ip@sunroof.eng.sun.com >From: majordomo@majordomo.ieee.org >Subject: Welcome to tf-cdma >Reply-To: majordomo@majordomo.ieee.org > >-- > > Here's the general information for the list you've subscribed to, > in case you don't already have it: > > [Last updated on: Wed Dec 5 19:03:20 US/Eastern 2001] > Welcome to CDMA Technical Forum (TF-CDMA), a technical group on W-CDMA, cdma2000, TD- > SCDMA, LAS-CDMA, OFDM-CDMA, P-CDMA, etc. From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 15:39: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 PAA03242 for ; Fri, 2 Aug 2002 15:39: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 NAA17923; Fri, 2 Aug 2002 13:39: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 MAA14295; Fri, 2 Aug 2002 12:39:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72Jbu3U029251 for ; Fri, 2 Aug 2002 12:37:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72Jbun7029250 for mobile-ip-dist; Fri, 2 Aug 2002 12:37: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72Jbr3U029243 for ; Fri, 2 Aug 2002 12:37:53 -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 PAA09767 for ; Fri, 2 Aug 2002 15:37: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 g72Jc7XA027319 for ; Fri, 2 Aug 2002 15:38:07 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g72Jc7ND027318 for mobile-ip@sunroof.eng.sun.com; Fri, 2 Aug 2002 15:38:07 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.4/8.12.4) with ESMTP id g7200noN024505; Thu, 1 Aug 2002 17:00:49 -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 RAA13398; Thu, 1 Aug 2002 17:00:54 -0700 (PDT) Received: from rs04.singnet.com.sg (rs04.singnet.com.sg [165.21.101.94]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03674; Thu, 1 Aug 2002 18:00:52 -0600 (MDT) Received: from mail.hz.zj.cn (netpc14.ie.cuhk.edu.hk [137.189.96.44] (may be forged)) by rs04.singnet.com.sg (8.12.3/8.12.3) with ESMTP id g712jIX4015414; Thu, 1 Aug 2002 10:45:19 +0800 Message-ID: <3D48A0AB.F614F171@mail.hz.zj.cn> Date: Thu, 01 Aug 2002 10:45:00 +0800 From: CWC02-HZ Office X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Subject: [mobile-ip] ADV: 2002 China Wireless Congress - Oct. 15-17, 2002 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit [Sorry for Multiple Copies of This Message. Welcome to CWC02 in China] Dear wireless colleagues: By the end of 2002, China will have over 200 MLN mobile users. From late of 2003, China will issue 3G licenses and full 3G services will be available in 2005. Currently, there is still over 5 MLN new mobile users coming every month, and the mobile revenue is increasing over 25% every year. China is so far the world's largest wireless market, and the most potential business partner in the coming several years. To get involved in this huge business, 2002 China Wireless Congress is the best platform which focuses on the following issues: 1. The New Business Models of China's Mobile Communications 2. Infrastructure of Nationwide Wireless Access Systems 3. Convergence of Wireless Local Access and Mobile Networks 4. Evolution of 2G networks to 2.5G and 3G networks 5. Emerging R&D on 4G Mobile and 4G Mobile Forum 6. Investment Strategies towards 2008 OlympiTek 7. New Spectrum Management and Sharing Policies 8. All-Hands Meeting and Marketing Events In addition, this congress will be together with the famous West-Lake Expo'2002, and really a best combination of business and leisure in Hangzhou - the most beautiful city of China. To join this professional gathering, please visit the website at: http://delson.org/cwc02 or http://china.wirelesscongress.com This 2002 China Wireless Congress will be very busy, please register ASAP before the door is closed. For more information about this congress or about Hangzhou,etc, please also check the website. On behalf of the congress committee, welcome to Hangzhou, the garden of Shanghai ! Thank you. Hangzhou Office of CWC'2002 http://delson.org/cwc02 http://china.wirelesscongress.com [sorry for copy of this message, removal is automatically. This is for conference information only, not for commercial sale. Thanks a lot!] From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 15:40: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 PAA03330 for ; Fri, 2 Aug 2002 15:40:58 -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 MAA00379; Fri, 2 Aug 2002 12:40: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 MAA00196; Fri, 2 Aug 2002 12:40:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72Jcf3U029314 for ; Fri, 2 Aug 2002 12:38:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72JcfRt029313 for mobile-ip-dist; Fri, 2 Aug 2002 12:38: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72Jcc3U029306 for ; Fri, 2 Aug 2002 12:38:38 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09919 for ; Fri, 2 Aug 2002 15:38:43 -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 g72JcpXA027325 for ; Fri, 2 Aug 2002 15:38:51 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g72JcprO027324 for mobile-ip@sunroof.eng.sun.com; Fri, 2 Aug 2002 15:38:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g726vC3U025355 for ; Thu, 1 Aug 2002 23:57:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25953 for ; Thu, 1 Aug 2002 23:57:16 -0700 (PDT) Received: from ponyexpress.ee.columbia.edu (ponyexpress.ee.columbia.edu [128.59.64.61]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA15925 for ; Fri, 2 Aug 2002 00:57:13 -0600 (MDT) Received: from coltrane (coltrane.ocs.columbia.edu [128.59.240.174]) by ponyexpress.ee.columbia.edu (8.12.1/8.12.1) with SMTP id g726vB97029526; Fri, 2 Aug 2002 02:57:11 -0400 From: "Andrew T. Campbell" To: Cc: "Ron@Oit. Gatech. Edu" , "Andrew T. Campbell" Subject: [mobile-ip] MobiCom 2002: Call for Demos Date: Fri, 2 Aug 2002 03:05:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit MobiCom 2002 The Eighth ACM International Conference on Mobile Computing and Networking September 23-26, 2002, Westin Peachtree Plaza, Atlanta, Georgia, USA http://www.acm.org/sigmobile/mobicom/2002/ Sponsored by ACM SIGMOBILE C A L L for D E M O s MobiCom 2002 solicits demos that highlight on-going experimental research on mobile computing topics. Please send a one page description of your demo to: Ron Hutchins MobiCom 2002 Demos Chair Email: ron@oit.gatech.edu before August 8, 2002. Notification of accepted demos will be sent on August 10, 2002. Thank you for your participation From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 18:06:41 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 SAA08912 for ; Fri, 2 Aug 2002 18:06:41 -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 QAA00216; Fri, 2 Aug 2002 16:07: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 PAA16389; Fri, 2 Aug 2002 15:07:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72M643U000051 for ; Fri, 2 Aug 2002 15:06:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72M64Ms000049 for mobile-ip-dist; Fri, 2 Aug 2002 15:06: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72M5h3U000041 for ; Fri, 2 Aug 2002 15:05:58 -0700 (PDT) Received: from lillen (d-umpk17-99-214.Eng.Sun.COM [129.146.99.214]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g72M5ig20544; Sat, 3 Aug 2002 00:05:44 +0200 (MEST) Date: Sat, 3 Aug 2002 00:03:48 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: [mobile-ip] Reflection attack using bogus BU? To: jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In section 9.4.4 draft 18: - Otherwise, if the Source IP Address of the packet containing the Binding Update, is legal for inclusion in a Routing Header, the routing header will be constructed using that IP address. Note that multicast addresses, link-local addresses, loopback addresses, IPv4 mapped addresses, and the unspecified address, MUST NOT be used within a Routing Header for the Binding Acknowledgement. Otherwise, if the Binding Update has a zero lifetime but the Source IP address is not allowable for use within the Routing Header, the Binding Acknowledgment MUST be sent to the mobile node's home address. This seems to say that if a node forms a packet with ip src = mapped address ip dst = reflector HAO = victim MH protocol, type = BU random bits in the authenticator then the reflector will send binding ack to the victim with status 137 Invalid authenticator I propose that when the source address can't use used in a routing header, the CN should silently drop the BU. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 18:37: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 SAA09933 for ; Fri, 2 Aug 2002 18:37: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 QAA21450; Fri, 2 Aug 2002 16:38: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 PAA28963; Fri, 2 Aug 2002 15:38:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72MbS3U000277 for ; Fri, 2 Aug 2002 15:37:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72MbS0w000276 for mobile-ip-dist; Fri, 2 Aug 2002 15: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72MbM3U000269 for ; Fri, 2 Aug 2002 15:37:22 -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 PAA28495 for ; Fri, 2 Aug 2002 15:37:28 -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 PAA01775 for ; Fri, 2 Aug 2002 15:37: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 PAA05135; Fri, 2 Aug 2002 15:37:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g72MbOR10856; Fri, 2 Aug 2002 15:37:24 -0700 X-mProtect: <200208022237> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.90, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdXj068n; Fri, 02 Aug 2002 15:37:20 PDT Message-ID: <3D4B09A0.4F34ECE3@iprg.nokia.com> Date: Fri, 02 Aug 2002 15:37:20 -0700 From: Rajeev Koodli Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Erik Nordmark , Singh Ajoy-ASINGH1 , "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? References: <3D499352.5F5652A@iprg.nokia.com> <011501c239ac$2c9781c0$296015ac@T23KEMPF> <3D49CF88.268F6FCB@iprg.nokia.com> <000b01c23a3a$a72c07b0$296015ac@T23KEMPF> <3D4ABC7A.9343333A@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 James Kempf wrote: > > The AR needs a mapping, yes. However, how does the MN get the > > mapping information ? Who provides it ? A link layer message ? If > > yes, is such thing there in the relevant spec ? > > > > In the case of radio protocols such as wCDMA, the MN doesn't need this > information, since the MN and the old BS exchange the identity of the new BS at > the link layer. The old BS sends the Layer 2 identifier of the new BS to the AR > by a Layer 2 specific means, or using something like Alper's proposed ICMP > message, if the BS and AR are not integrated. If they are integrated, then the > AR will have this information. The AR can use either the CARD protocol or a > static table to do the lookup, exchange HI/HaCK. The MN's link gets switched at > Layer 2, the AR tunnels until the MN completes binding update on the new AR. I guess I was not clear.. The question is not how the old AR can determine the IP address of the new AR, which itself is a separate issue, but how can the MN send packets to the new router. If the MN knows the L2 address of the new BS (not the new AR), can it send packets to the router ? Two options: a) assume that the new AP is capable of routing/switching packets to the new AR based on L2 headers b) assume that the new AP is only a bridge between wireless and wireline portions of the network. In UMTS (scenario a) ), the MN sends packets to the AP (actually to Node B and then to RNC). And, then there is GTP tunneling. However, in UMTS, the MN does not change the AR (i.e., GGSN). As I understand, inter-GGSN handovers are not specified. Inside the GGSN, handover support is done by GTP and is well-specified. So, I am not sure how the scenario you describe above would be applicable specifically to WCDMA networks.. Also, PrRtAdv is as inapplicable as any ND messages defined today. If you consider scenario b), which is applicable to WLAN e.g., the MN needs to know the L2 address of the new AR to send packets. > > > For link layers where there is no exchange of new BS identity over the air at > Layer 2 prior to handover but the MN knows, the MN can use Seamoby CARD to do > the mapping, and SolPrRtAdv/PrRtAdv would be required. > > For link layers with no prehandover signaling between the BS and MN such as > 802.11, the MN can use Seamoby CARD after handover and do the mapping, but it is > yet unclear how the tunnel would be initiated in this case. Alternatively, the > BS can do the mapping if the old BS id is known, and use target triggered > handover, which is also undefined in draft 5. The fast handover signaling for > this case is the most underspecified in draft 5, IMHO. Regarding target-triggered tunnel establishment: how does the new AR know the previous AR, and the previous IP address of the MN ? How does the new AP figure both of these through Reassociate ? Regarding tunnel establishment after association: the MN sends FBU which triggers HI/HAck and hence the tunnel establishment. This may be need to be specified separately, but is not undefined. > > > > So, how does a WLAN card decide to associate with a new AP ? > > Proprietary. It is not specified in the 802.11 standard. As a practical matter, > FER and signal strength are both possibilites. In existing products, there are a > wide variety of algorithms, and they are likely to get more varied as vendors > start competing on handover performance. > This is good enough. We provide a message that implementations can use to obtain the L2 and IP addresses. > > > There is > > a "scan" message that allows the MS to figure out what APs are within > > reach. After that, there has to be some guideline as to when the MS > > changes its AP, based on, e.g., received signal strength. > > It could also be FER. Also, some current products do make a decision based on > other measures not associated with the quality of the link. 802.11 is not like > cellular, there is no standard signal strength specified nor a standard FER, nor > even a requirement that these should be used to make the handover decision. The > only standardized signaling is the Reassociation.request() and > Reassociation.reply() when the card has selected which access point it will > associate with. > This is ok. What we need is a message that the implementations can use independent of what criterion they use to undergo handover. > > > The result of scan is the input to PrRtSol. > > Our experience is that the results of a scan are not typically available to the > driver when a handover is necessary, it is conducted by the firmware, and is > followed by the Reassociation.request()/reply() without any driver intervention. > On some cards, a scan can be forced, signal strength measured, and handover > forced by the driver, but this is by no means a standard. Also,during the > exchange of PrRtSol/PrRtAdv (which will take some amount of time) after the scan > is forced, the firmware could decide to perform handover to a completely > different access point. Nothing constrains the firmware to continue being > associated with the current access point until the PrRtSol/PrRtAdv completes. > Finally, while a scan is being conducted, the card is basically offline for any > traffic. This means that the scan prior to the PrRtSol/PrRtAdv would shut down > traffic to the card, during which time it would have to be buffered (or dropped) > if the scan takes too long. > > We've measured typical scan times of about 100 ms on a cell with a single MN. > This time increases dramatically if there is more than one MN in the cell, > because 802.11 has no QoS on signaling traffic. The scan is scheduled on the > link with the same priority as MN traffic. With 3 MNs doing continuous traffic, > the scan time can be upwards of 200 ms. > All of the above is ok. If the MN has time to do PrRtSol/PrRtAdv, which BTW takes few milliseconds, it will benefit. Otherwise, the protocol will operate from the new link (i.e., FBU sent from new link). So, I don't understand.. > > > It suffices to provide a message > > that can be called when the L2 decides to look for other AP(s). Note > > that there is analogous support in Linux to send a RS upon detecting > > a new link. > > > > I don't follow. If the Layer 2 protocol doesn't provide this, how can IP help? > We can't control what happens at Layer 2 unless the hooks are there. The L2 protocol allows scanning and each card can make a decision to undergo handover based on its own criterion. Then, the IP message can be sent. > > > > If the MS moves before PrRtSol could be attempted, then the HI/HAck > > happens after the association with the new AP. > > > > Sure, that's target triggered handover. There is something in draft 04 to do > this, and also in the FMIPv4 draft. v05 also allows the tunnel establishment through FBU. I will put this under a separate section for tunnel establishment subsequent to new link establishment and more content. -Rajeev > > > jak From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 19:16: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 TAA10896 for ; Fri, 2 Aug 2002 19:16: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 RAA10092; Fri, 2 Aug 2002 17:16:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA15885; Fri, 2 Aug 2002 16:16:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g72NF13U000513 for ; Fri, 2 Aug 2002 16:15:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g72NF0RQ000512 for mobile-ip-dist; Fri, 2 Aug 2002 16:15: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.5+Sun/8.12.5) with ESMTP id g72NEt3U000505 for ; Fri, 2 Aug 2002 16:14: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 QAA10232 for ; Fri, 2 Aug 2002 16:15:00 -0700 (PDT) Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16545; Fri, 2 Aug 2002 17:14:59 -0600 (MDT) From: Masataka Ohta Message-Id: <200208022253.HAA01474@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id HAA01474; Sat, 3 Aug 2002 07:53:41 +0900 Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? In-Reply-To: <3D4B09A0.4F34ECE3@iprg.nokia.com> from Rajeev Koodli at "Aug 2, 2002 03:37:20 pm" To: Rajeev Koodli Date: Sat, 3 Aug 2002 07:53:40 +0859 () CC: James Kempf , Erik Nordmark , Singh Ajoy-ASINGH1 , "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , mobile-ip@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL68 (25)] Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Rajeev > James Kempf wrote: > > Finally, while a scan is being conducted, the card is basically offline for any > > traffic. This means that the scan prior to the PrRtSol/PrRtAdv would shut down > > traffic to the card, during which time it would have to be buffered (or dropped) > > if the scan takes too long. > > > > We've measured typical scan times of about 100 ms on a cell with a single MN. > > This time increases dramatically if there is more than one MN in the cell, > > because 802.11 has no QoS on signaling traffic. The scan is scheduled on the > > link with the same priority as MN traffic. With 3 MNs doing continuous traffic, > > the scan time can be upwards of 200 ms. I'm afraid scan time to scan all the possible frequency channels is more than a second. > All of the above is ok. If the MN has time to do PrRtSol/PrRtAdv, which BTW > takes few milliseconds, it will benefit. Otherwise, the protocol will operate from > the > new link (i.e., FBU sent from new link). So, I don't understand.. It will take several seconds to find the new link. When link latency is a lot larger than mobile IP latency, which is the case with WLAN, minimization of mobile IP latency is meaningless. Masataka Ohta From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 21:53:09 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14804 for ; Fri, 2 Aug 2002 21:53:08 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA01361; Fri, 2 Aug 2002 19:53: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 SAA15860; Fri, 2 Aug 2002 18:53:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g731qb3U000808 for ; Fri, 2 Aug 2002 18:52:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g731qbj5000807 for mobile-ip-dist; Fri, 2 Aug 2002 18:52: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.5+Sun/8.12.5) with ESMTP id g731qV3U000800 for ; Fri, 2 Aug 2002 18:52:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA15685 for ; Fri, 2 Aug 2002 18:52:36 -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 TAA28618 for ; Fri, 2 Aug 2002 19:52:35 -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 SAA14829 for ; Fri, 2 Aug 2002 18:52:35 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g731qY831248 for ; Fri, 2 Aug 2002 18:52:34 -0700 X-mProtect: <200208030152> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVdYTDe; Fri, 02 Aug 2002 18:52:31 PDT Message-ID: <3D4B3760.AF60953E@iprg.nokia.com> Date: Fri, 02 Aug 2002 18:52: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: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobility Header len 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, the Header Len field in Mobility header as described in draft 18 is a multiple of 8 octets including the header fields. how about changing it to a multiple of 8 octects leaving out the first 8 octets. two advangtages 1. buys you 8 bytes :) (I know its minor) 2. IF we have piggybacking tomorrow, Mobility Header can be processed like any other extension header. otherwise I need special code. comments? regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 2 22:17: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 WAA15244 for ; Fri, 2 Aug 2002 22:17: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 TAA28219; Fri, 2 Aug 2002 19:16: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 TAA18372; Fri, 2 Aug 2002 19:16:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g732EH3U000989 for ; Fri, 2 Aug 2002 19:14:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g732EHGb000988 for mobile-ip-dist; Fri, 2 Aug 2002 19:14: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 [129.146.17.55]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g732E83U000981 for ; Fri, 2 Aug 2002 19:14:09 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.5+Sun/8.12.5) with SMTP id g732ED2o756476; Fri, 2 Aug 2002 19:14:13 -0700 (PDT) Message-Id: <200208030214.g732ED2o756476@jurassic.eng.sun.com> Date: Fri, 2 Aug 2002 19:16:53 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] MH type field To: Brian.Haley@hp.com Cc: jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 0LNjYtPG9vXaRiMTgxbt5A== 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 Brian, > > > > 8 bits looks sufficient now. OTOH I don't think the 8 bit reserved field > > buys very much either. And there are some protocols in the Internet > > where 8 bits looked initially sufficient but proved later to be insufficient. > > Mobility is an interesting subject to many folks. Will 256 values cover > > all the xMIP extensions that we might need in the future? Yeah, you could > > also say that it's a terrible thought that we'd need so much complexity > > that 10-15 values wouldn't do... > > > > By the way, if you switch statements in the code are in network byte > > order, you'll save the 3 instructions ;-) > > > > My gut feeling is that we should keep the current format, unless > > someone has strong arguments otherwise. > > My only follow-up would be that we could change a reserved field into > an "extended type" field in the future. For example, if type == 255 then > add "extended type" to it to get the actual type. It would be harder to go > the other way. Noone else seems to have an opinion either way about > such little issues though... How do you think the reserved field be useful in future ? Do you think it could be used for some flags someday ? IMHO, I agree with Jari, that we can keep the MH type field 16 bit for now, as we don't know the extent of future applicability of MH header, unless we know for sure that saving 8 bit as reserved will have some applicability in the near future. -Samita From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 3 09:26: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 JAA03830 for ; Sat, 3 Aug 2002 09:26:12 -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 HAA04414; Sat, 3 Aug 2002 07:26:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06815; Sat, 3 Aug 2002 06:26:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g73DPm3U001777 for ; Sat, 3 Aug 2002 06:25:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g73DPmCn001776 for mobile-ip-dist; Sat, 3 Aug 2002 06: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g73DPg3U001769 for ; Sat, 3 Aug 2002 06:25:42 -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 GAA19086 for ; Sat, 3 Aug 2002 06:25:47 -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 HAA04208 for ; Sat, 3 Aug 2002 07:25:47 -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 g73DPhf09641; Sat, 3 Aug 2002 15:25: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 PAA19158; Sat, 3 Aug 2002 15:25: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.12.3/8.12.3) with ESMTP id g73DPZ6o042560; Sat, 3 Aug 2002 15:25:35 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208031325.g73DPZ6o042560@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobility Header len In-reply-to: Your message of Fri, 02 Aug 2002 18:52:32 PDT. <3D4B3760.AF60953E@iprg.nokia.com> Date: Sat, 03 Aug 2002 15:25: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: the Header Len field in Mobility header as described in draft 18 is a multiple of 8 octets including the header fields. how about changing it to a multiple of 8 octects leaving out the first 8 octets. two advangtages 1. buys you 8 bytes :) (I know its minor) 2. IF we have piggybacking tomorrow, Mobility Header can be processed like any other extension header. otherwise I need special code. => I buy the second argument: the only exception (IPsec extension headers) is already a source of trouble. Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 5 11:42: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 LAA18111 for ; Mon, 5 Aug 2002 11:42:08 -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 JAA13008; Mon, 5 Aug 2002 09:42: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 IAA10275; Mon, 5 Aug 2002 08:42:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75FfY3U005475 for ; Mon, 5 Aug 2002 08:41:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g75FfYYn005474 for mobile-ip-dist; Mon, 5 Aug 2002 08: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75FfR3U005467 for ; Mon, 5 Aug 2002 08:41:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08943 for ; Mon, 5 Aug 2002 08:41:31 -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 JAA12265 for ; Mon, 5 Aug 2002 09:41:30 -0600 (MDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 566D53836; Mon, 5 Aug 2002 11:41:30 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 18472F14; Mon, 5 Aug 2002 11:41:30 -0400 (EDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id LAA0002023822; Mon, 5 Aug 2002 11:41:29 -0400 (EDT) Message-ID: <3D4E9CA9.22DB80DE@hp.com> Date: Mon, 05 Aug 2002 11:41:29 -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: Samita Chakrabarti Cc: jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MH type field References: <200208030214.g732ED2o756476@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Samita Chakrabarti wrote: > How do you think the reserved field be useful in future ? Do you > think it could be used for some flags someday ? Hi Samita, Flags is an option, I'm sure someone will come up with a need some day, I just doubt that we'll ever need 65K MH types. It was simply something I noticed updating to draft 18 that was different from all the other IPv6 headers (like MH Len). -Brian From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 5 16:00:43 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 QAA29662 for ; Mon, 5 Aug 2002 16:00:42 -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 OAA25345; Mon, 5 Aug 2002 14:01: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 NAA25869; Mon, 5 Aug 2002 13:01:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75K043U006405 for ; Mon, 5 Aug 2002 13:00:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g75K04Ui006404 for mobile-ip-dist; Mon, 5 Aug 2002 13: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75Jxw3U006397 for ; Mon, 5 Aug 2002 12:59: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 NAA08228 for ; Mon, 5 Aug 2002 13:00:01 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA05632 for ; Mon, 5 Aug 2002 14:00:00 -0600 (MDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g75K0Xx09388 for ; Mon, 5 Aug 2002 15:00:33 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 5 Aug 2002 14:59:58 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 5 Aug 2002 14:59:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [mobile-ip] WG meeting minutes (IETF54) Date: Mon, 5 Aug 2002 14:59:58 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44A13258@daebe007.NOE.Nokia.com> Thread-Topic: WG meeting minutes (IETF54) Thread-Index: AcI8uqQAfQJLuy9QTC+erJZxXWwy7g== To: X-OriginalArrivalTime: 05 Aug 2002 19:59:58.0568 (UTC) FILETIME=[AD1C1E80:01C23CBA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g75Jxw3U006398 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hello, Attached are the WGs IETF54 meeting minutes. If you find any errors or discrepancies, please do send a note with the correction. -Chairs Mobile IP WG minutes IETF54 @ Yokohama (July 15th) ============================= Meeting minutes captured by Basavaraj Patil and Phil Roberts. Agenda bashing: --------------- Mr. Mastaka Ohta requested a presentation slot - rejected by the chairs, ADs asked, and then insisted that the ongoing persistent request be taken offline WG Doc Status ------------- 3012bis has actually completed WG last call. Actually, it has been sent to the IESG and is on the review list already. 3220bis is with the RFC editor and should be published as a new RFC soon. Reg-Revocation in WG last call now. AAA-Keys has completed WG last call and awaiting changes based on IESG review comments. MIPv6 discussions ------------------ Resolutions of all issues will be proposed to the ML, with included text for the draft. WG will be able to comment. Issues Discussed: 76 - unclear response on whether to include this, asked whether useful, whether not. Dave Johnson requested whether it is dangerous to have it in the text and he and Charlie at least indicated some concern. Some found it useful. 74 - source selection, plus guidance here, plus implementors common sense will get this right (Hesham). Dave J history - acknowledging that it is useful and is there so folks will know it is possible. (Mr. Keichi?) some communications must use COA so text will be needed to clarify this. (?) Problem needs to be solved, will be done elsewhere, not in this document. (Francis) need something like API or state machines for some details and security descriptions. (Hesham) in some other API, let's not make it CoA vs HA, but something more abstract. 62 - (Hesham) separate issue posted to the ML. Some twisted notion of ll home address and needing to keep what's at home. (TJ) thinks it ought to be obvious. (Francis) should wait for DAD and DAAD before deciding on the best solution. (Phil) let's go with what we've got (Hesham) either defending home address or defending link local (Phil) yes, home 72 - (Charlie) uses same binding update signalling as is in this draft, whereas the fast handover work has new signalling. (James) there is signalling for this in the fmip draft. (Charlie) Doesn't make sense to use the existing messages to do what it was designed to do? (Rajeev) new signalling is slightly different. (Charlie) even if you take it out, it could still be done. This provides guidance. (Alper) maybe it would be best left where it is to allow better performance now. (Erik) the security description is incomplete. (Note to self - work with Jari about what is actually needed to make this complete. If it's a lot, take seriously the request to drop it). 49 - (Hesham) need to clarify why this is a hard problem. (Francis) this is a general IPSEC/IKE problem. Give it to IPSEC to solve. (Erik) it is harder than what Hesham said: if I assign myself a temporary address (3041), preferred for a day, deferred for 6 days. Don't want anyone to claim it in the mobility case even though I used it for just a little bit. Hard - need something different. Not tied to binding lifetime, but the lifetime of the temporary address, conflict between multiple mobile nodes trying to claim the same temporary. Conclusion is agreeable to all. 55 - (FD) HA discovery is totally insecure and there is no way to make it sure. (Hesham) It doesn't need to be secure. A fake HA will be discovered immediately. (Raj) What is the threat with not securing the HA process? (FD) Not sure, but need to use IPSEC and IPSEC will fail. All other proposed solutions can be done in a secure manner. (Jim) Was arguing that maybe an alternative is possible, and reducing the size of the doc is a goal. Maybe there is an argument for a special protocol. (Hesham) this mechanism serves a good purpose and it should be left in. (Dave J) Removing features solely for the purpose of making the doc shorter is a recipe to further reducing the implemented functions. (Jari) node requirements can mandate stuff (Dave J) node requirements doesn't exist. At worst you create extra work rather than denial-of-service. (Thomas) not clear there is a concrete proposal here. Need a concrete proposal if we're going to do something to replace this. Proposal is to keep it, finish discussion on the ML. 70 - (DJ) what is the purpose in making it mandatory? (Jari) when using ESP to protect BUs, ESP doesn't protect source address. (DJ) use it only when using ESP? (Jari) possible, but introduces unnecessary dependency. (DJ) Why not make it a required field? We end up with distinguishing between a BU for home and for non-home BUs. (Jari) we already have that. (FD) make it mandatory (Jari) need to know whether it is ESP. Just make a requirement for home registrations. Don't try to solve an implementation problem by changing the protocol. Let implementors. (Hesham) it's not a big problem, don't change it now. (Rajeev) in FMIPv6 and HMIPv6 you need it. (Charlie) leave it up to implementors (Dave J) if you don't know whether you are using ESP you must use this. (TJ) dynamic HA discovery question (56). Alternative proposal, if addresses don't fit in MTU, do it j-1 addresses and make j the address of the HA that is responding. Still get first optimization. (Charlie) important to keep the first optimization. (Hesham) prohibit site-local COA - no text is there. (FD) R-bit is needed to say whether mobile node is a router. (DJ) For RR the MN can't know whether the nonce is too old. An MN can send a BU requesting not to acknowledge. Can't get told nonce is too old. -> Need to be able to handle Binding Acks and match them with sequence numbers even in the case we did not request a binding ack. (DJ) For RR, the cookie may be protected by ESP on HA-MN link. If it isn't protected anyone on or near the FL will see both cookies. Why not require ESP on MN-HA link? (Jari) Previous discussion led us to believe it is a MAY. One of the reasons is that the kind of attacks that can happen will hurt MN-HA but cannot hurt third parties. (DJ) disagrees - affects conversation with CN also. (Hesham) thinks it's a SHOULD (DJ) wants a MUST, reckless not to take advantage of required fnality (DJ) will post rest of issues to list. (Erik) let's not say anything about site-locals (Mr Keichi) why do all nodes have to support HoA? (DJ) for CNs to receive a packet from a mobile node while it is away from home. (Mr K) this does not prevent communication. (DJ) MN that sends a packet with HoA implies that all nodes must support it. Fast Handoff in V6: -------------------- (Phil's pres on an 802.11 fast handoff draft) Phil set the context and provided the background for the work and discussion. He also outlined a strategy for moving forward. Phils recommendation is that Fast HO be defined for specific link layers and we can start with defining Fast HO for 802.11 For details on the proposal refer to the slides. - Hesham agrees. However a general protocol is all you really need. Jak: Disagrees. Example of IPv6 in RFC2461 and 2464 Ohta: FMIPv6 useless. Document is large. 3G/FoMA is not valid for Internet access Hesham: 802.11 work will raise the same issues all over again Jim Bound: Agrees with the process proposed by Phil and supports it Gopal: Doing the 802.11 spec will narrow the focus and help Gopal agrees that the 802.11 spec should simply specify the triggers Rajeev: V05 already supports implementing FMIpv6 on 802.11 Hesham: Will the 802.11 draft simply specify the L2 triggers for fast HO? Jak: The current draft is focused on Preaddress configuration and this is not possible in 802.11 (Rajeev's pres) (Jim) on network controlled handover. How does PAR know to send PrRtAdv without an L2 trigger? Only use when there is potentially no L2trigger, when MN sends a solicitation. Assertion: there is no way to do something like this without some kind of l2 info. (Hesham) tunnel was previously terminated on the mobile node - now what happens with ingress filtering. (Rajeev) question about what's available on L2? (Jim) we are setting requirements (Rajeev) are we putting musts for L2s (Jim) there may be a tight coupling that needs to be specified. - had to cut off the pres, Rajeev will post issues to the ML and solicit discussion from the WG on answers to his question. VPN Traversal requirements -------------------------- (Farid Adrangi presented the requirements) (Raj) on RO, is it an objective to solve v4 R.O. (Farid) may (Raj) what does RO have to do with this problem? If a new entity is introduced is rt. opt. needed. Limited Private Address Support ------------------------------- (Gabriel's pres) new draft updates guidance for implementation of reverse tunneling (Phil) what do you want to do with it? (Gab) separate wg document as BCP or Informational (Pete) concerned that implementation community is split because there are CDMA vendors who are doing separate implementations from what is done at Cthon. Existing RFC is a fine spec, pp2 understands what it means. Needs to review. LMM Requirements ----------------- (Carl pres) Some small modifications. Ready for WG last call. From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 5 17:05:00 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01935 for ; Mon, 5 Aug 2002 17:04:59 -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 OAA14464; Mon, 5 Aug 2002 14:04: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 OAA06291; Mon, 5 Aug 2002 14:03:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75L2M3U006716 for ; Mon, 5 Aug 2002 14:02:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g75L2MFk006715 for mobile-ip-dist; Mon, 5 Aug 2002 14:02:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g75L2H3U006708 for ; Mon, 5 Aug 2002 14:02:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04593 for ; Mon, 5 Aug 2002 14:02:20 -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 PAA12217 for ; Mon, 5 Aug 2002 15:02:19 -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 g75L2GAK018952; Mon, 5 Aug 2002 14:02:16 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-133.cisco.com [128.107.163.133]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ADN48674; Mon, 5 Aug 2002 14:02:14 -0700 (PDT) Message-ID: <3D4EE7D5.FE57408B@cisco.com> Date: Mon, 05 Aug 2002 14:02:13 -0700 From: Alpesh S Patel X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] [Fwd: List of Questions about "AAA Key Distribution Draft"] 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, We have been going over the AAA Key Distribution draft in detail and have the following list of questions. Can someone clarify them. 1. Section 3 (items 8, 9), indicates that unsoliciated key material can be pushed to the MN. Is the intended purpose to generate new keys at MN? The wording says that MN authenticates and then if finds 'unsolicited key material', MN generates key. 2. Is the intention of this draft to also facilitate HA/FA key distribution through AAA? If so, which entity initiates it? Also, how to ensure that FA and HA reaches the same AAA server? (The last question is critical if AAA server is Radius). 3. Where is the MF KeyRequest Extension located compared to MN-AAA AE? If before MN-AAA AE, FA cannot remove this extension before forwarding RRQ to HA. Section 3 (item 4) states this, but just wanted to confirm. 4. Sections 6.1 and 6.3, what is included in subtype data? 5. Sections 6.2 and 6.4, what is included in subtype data? Is it that this contains the extensions specified in section 8 and 9? 6. Why 6.4 has lifetime and not section 9 extension? Why 6.2 does not have lifetime field and section 8 extension has? Can you clarify this? 7. Can MN put multiple MN KeyRequestExtensions in same RRQ to generate multiple keys? If not, then the solution would be to send multiple RRQs. Can a statement in this regards put in the draft to clarify this behavior. Suggestions: ------------ 1. Section 5, the formulae for calculating the key is missing to take the AAA-key into account. It is described in the following paragraph in that section. This needs to be corrected. 2. A paragraph explaining the role of SPI's (how they are setup) to be unidirectional would help if it is spelled out clearly. Thanks Alpesh From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 6 05:13:42 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29939 for ; Tue, 6 Aug 2002 05:13:41 -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 DAA19641; Tue, 6 Aug 2002 03:14: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 CAA16279; Tue, 6 Aug 2002 02:14:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g769D13U008060 for ; Tue, 6 Aug 2002 02:13:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g769D1Mx008059 for mobile-ip-dist; Tue, 6 Aug 2002 02:13: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.5+Sun/8.12.5) with ESMTP id g769Cu3U008052 for ; Tue, 6 Aug 2002 02:12:56 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05466 for ; Tue, 6 Aug 2002 02:13:03 -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 CAA23867 for ; Tue, 6 Aug 2002 02:13:02 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id AA9576A906; Tue, 6 Aug 2002 12:12:43 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 08BCC6A905; Tue, 6 Aug 2002 12:12:38 +0300 (EEST) Message-ID: <3D4F9389.1000101@kolumbus.fi> Date: Tue, 06 Aug 2002 12:14: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: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Reflection attack using bogus BU? References: 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.31 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: > In section 9.4.4 draft 18: > > - Otherwise, if the Source IP Address of the packet containing > the Binding Update, is legal for inclusion in a Routing Header, > the routing header will be constructed using that IP address. > Note that multicast addresses, link-local addresses, loopback > addresses, IPv4 mapped addresses, and the unspecified address, > MUST NOT be used within a Routing Header for the Binding > Acknowledgement. > > Otherwise, if the Binding Update has a zero lifetime but the Source > IP address is not allowable for use within the Routing Header, > the Binding Acknowledgment MUST be sent to the mobile node's home > address. > > This seems to say that if a node forms a packet with > ip src = mapped address > ip dst = reflector > HAO = victim > MH protocol, type = BU > random bits in the authenticator > > then the reflector will send binding ack to the victim with status > 137 Invalid authenticator Right. > I propose that when the source address can't use used in a routing header, > the CN should silently drop the BU. Agreed. Proposed text: - Otherwise, the Binding Acknowledgment MUST NOT be sent. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 6 05:17: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 FAA00104 for ; Tue, 6 Aug 2002 05:17:12 -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 CAA27580; Tue, 6 Aug 2002 02:16: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 CAA05928; Tue, 6 Aug 2002 02:16:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g769Em3U008080 for ; Tue, 6 Aug 2002 02:14:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g769EmsH008079 for mobile-ip-dist; Tue, 6 Aug 2002 02:14: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.5+Sun/8.12.5) with ESMTP id g769Ef3U008071 for ; Tue, 6 Aug 2002 02:14: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 CAA25708 for ; Tue, 6 Aug 2002 02:14:48 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA24539 for ; Tue, 6 Aug 2002 02:14:47 -0700 (PDT) Received: by n2.nomadiclab.com (Postfix, from userid 962) id A0C0022E1F; Tue, 6 Aug 2002 12:16:09 +0300 (EEST) Received: from d2.nomadiclab.com (bastion [131.160.194.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 0130C22E17 for ; Tue, 6 Aug 2002 12:16:03 +0300 (EEST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by d2.nomadiclab.com (Postfix) with ESMTP id A64B36CCAD for ; Tue, 6 Aug 2002 09:16:14 +0300 (EEST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25146; Tue, 6 Aug 2002 03:14: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 CAA16285; Tue, 6 Aug 2002 02:14:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g769D13U008060 for ; Tue, 6 Aug 2002 02:13:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g769D1Mx008059 for mobile-ip-dist; Tue, 6 Aug 2002 02:13: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.5+Sun/8.12.5) with ESMTP id g769Cu3U008052 for ; Tue, 6 Aug 2002 02:12:56 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05466 for ; Tue, 6 Aug 2002 02:13:03 -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 CAA23867 for ; Tue, 6 Aug 2002 02:13:02 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id AA9576A906; Tue, 6 Aug 2002 12:12:43 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 08BCC6A905; Tue, 6 Aug 2002 12:12:38 +0300 (EEST) Message-ID: <3D4F9389.1000101@kolumbus.fi> Date: Tue, 06 Aug 2002 12:14: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: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Reflection attack using bogus BU? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-Spam-Status: No, hits=-0.8 required=5.0 tests=X_AUTH_WARNING,SUBJ_ENDS_IN_Q_MARK version=2.31 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: > In section 9.4.4 draft 18: > > - Otherwise, if the Source IP Address of the packet containing > the Binding Update, is legal for inclusion in a Routing Header, > the routing header will be constructed using that IP address. > Note that multicast addresses, link-local addresses, loopback > addresses, IPv4 mapped addresses, and the unspecified address, > MUST NOT be used within a Routing Header for the Binding > Acknowledgement. > > Otherwise, if the Binding Update has a zero lifetime but the Source > IP address is not allowable for use within the Routing Header, > the Binding Acknowledgment MUST be sent to the mobile node's home > address. > > This seems to say that if a node forms a packet with > ip src = mapped address > ip dst = reflector > HAO = victim > MH protocol, type = BU > random bits in the authenticator > > then the reflector will send binding ack to the victim with status > 137 Invalid authenticator Right. > I propose that when the source address can't use used in a routing header, > the CN should silently drop the BU. Agreed. Proposed text: - Otherwise, the Binding Acknowledgment MUST NOT be sent. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 6 05:17: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 FAA00140 for ; Tue, 6 Aug 2002 05:17:50 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25449; Tue, 6 Aug 2002 02:16: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 CAA17050; Tue, 6 Aug 2002 02:16:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g769Fo3U008157 for ; Tue, 6 Aug 2002 02:15:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g769FoDY008156 for mobile-ip-dist; Tue, 6 Aug 2002 02:15: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.5+Sun/8.12.5) with ESMTP id g769Fe3U008124 for ; Tue, 6 Aug 2002 02:15:40 -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 CAA16604 for ; Tue, 6 Aug 2002 02:15:27 -0700 (PDT) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA17935 for ; Tue, 6 Aug 2002 03:15:24 -0600 (MDT) Received: by n2.nomadiclab.com (Postfix, from userid 962) id C903822E1F; Tue, 6 Aug 2002 12:16:47 +0300 (EEST) Received: from d2.nomadiclab.com (bastion [131.160.194.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 17A7E22E17 for ; Tue, 6 Aug 2002 12:16:42 +0300 (EEST) Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by d2.nomadiclab.com (Postfix) with ESMTP id B4C7B6CCAD for ; Tue, 6 Aug 2002 09:16:52 +0300 (EEST) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25165; Tue, 6 Aug 2002 03:14: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 CAA16285; Tue, 6 Aug 2002 02:14:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g769D13U008060 for ; Tue, 6 Aug 2002 02:13:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g769D1Mx008059 for mobile-ip-dist; Tue, 6 Aug 2002 02:13: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.5+Sun/8.12.5) with ESMTP id g769Cu3U008052 for ; Tue, 6 Aug 2002 02:12:56 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA05466 for ; Tue, 6 Aug 2002 02:13:03 -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 CAA23867 for ; Tue, 6 Aug 2002 02:13:02 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id AA9576A906; Tue, 6 Aug 2002 12:12:43 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 08BCC6A905; Tue, 6 Aug 2002 12:12:38 +0300 (EEST) Message-ID: <3D4F9389.1000101@kolumbus.fi> Date: Tue, 06 Aug 2002 12:14: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: Erik Nordmark Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Reflection attack using bogus BU? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: X-Spam-Status: No, hits=-0.8 required=5.0 tests=X_AUTH_WARNING,SUBJ_ENDS_IN_Q_MARK version=2.31 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: > In section 9.4.4 draft 18: > > - Otherwise, if the Source IP Address of the packet containing > the Binding Update, is legal for inclusion in a Routing Header, > the routing header will be constructed using that IP address. > Note that multicast addresses, link-local addresses, loopback > addresses, IPv4 mapped addresses, and the unspecified address, > MUST NOT be used within a Routing Header for the Binding > Acknowledgement. > > Otherwise, if the Binding Update has a zero lifetime but the Source > IP address is not allowable for use within the Routing Header, > the Binding Acknowledgment MUST be sent to the mobile node's home > address. > > This seems to say that if a node forms a packet with > ip src = mapped address > ip dst = reflector > HAO = victim > MH protocol, type = BU > random bits in the authenticator > > then the reflector will send binding ack to the victim with status > 137 Invalid authenticator Right. > I propose that when the source address can't use used in a routing header, > the CN should silently drop the BU. Agreed. Proposed text: - Otherwise, the Binding Acknowledgment MUST NOT be sent. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 6 05:57: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 FAA01179 for ; Tue, 6 Aug 2002 05:56:59 -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 CAA14017; Tue, 6 Aug 2002 02:56:00 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27749; Tue, 6 Aug 2002 02:55:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g769sr3U010026 for ; Tue, 6 Aug 2002 02:54:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g769srgJ010025 for mobile-ip-dist; Tue, 6 Aug 2002 02:54: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.5+Sun/8.12.5) with ESMTP id g769sl3U010018 for ; Tue, 6 Aug 2002 02:54:47 -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 CAA14241 for ; Tue, 6 Aug 2002 02:54:55 -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 CAA10736 for ; Tue, 6 Aug 2002 02:54:54 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id A1ADD6A906; Tue, 6 Aug 2002 12:54:53 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id CCAD96A905; Tue, 6 Aug 2002 12:54:47 +0300 (EEST) Message-ID: <3D4F9D6B.8050103@kolumbus.fi> Date: Tue, 06 Aug 2002 12:56:59 +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: Hiroyuki OHNISHI , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 I-D 18:BA status value 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=none version=2.31 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: >>6.1.2. Binding Refresh Request (BRR) Message >> >> [...] When a mobile node receives a >> packet containing 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 >> (see Section 5.2) if it believes the amount of traffic with the >> >>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> correspondent justifies the use of route optimization. >> >>This means MN judges whether the MN uses RO or not depends >>on the amount of traffic with CN when it receives BRR. >> > > Yes. Just like the MN initially decides when to first initiate a BU procedure, > it isn't required to refresh the binding when it receives the BRR. > The MN can presumably use whatever information it has (amount of traffic, > the type of traffic, the phase of the moon) to determine which CNs it > wants to use RO with at any given time. > The high level point is that the BRR is a hint that the CN would like to > see the binding refreshed. > > >>And if the amount is low enough, it sends BA with 136 to the CN? >> > > Sending a BA in response to a BRR seems odd. > I've been assuming the MN would just silently ignore the BRR if the MN > doesn't see a need to refresh the binding. Perhaps this should be made > explicit in the spec? Yes. Suggested text follows. Here's a new version of the first paragraph in 9.4.4: When a mobile node receives a packet containing 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 (see Section~\ref{overview:security}) if it believes the amount of traffic with the correspondent justifies the use of route optimization. If it does not believe this, the mobile node MAY choose to either ignore the Binding Refresh Request or to delete its binding from the sender of the Binding Refresh Request. Note that the mobile node SHOULD NOT respond Binding Refresh Requests from previously unknown correspondent nodes due to Denial-of-Service concerns. We also need to clarify how to use 130/136. My proposal is to merge the error codes and add the following text to the end of 9.4.2: The correspondent node MAY refuse to accept a new Binding Cache entry, if it does not have sufficient resources. A new entry MAY also be refused if the correspondent node believes its resources are utilized more efficiently in some other purpose, such as serving another mobile node with higher amount of traffic. In both cases the correspondent node SHOULD return a Binding Acknowledgement with status value 130. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 6 07:45: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 HAA06193 for ; Tue, 6 Aug 2002 07:45: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 FAA26586; Tue, 6 Aug 2002 05:46: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 EAA22924; Tue, 6 Aug 2002 04:46:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76BjM3U010501 for ; Tue, 6 Aug 2002 04:45:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g76BjMZc010500 for mobile-ip-dist; Tue, 6 Aug 2002 04:45:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76BjG3U010493 for ; Tue, 6 Aug 2002 04:45:17 -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 EAA00243 for ; Tue, 6 Aug 2002 04:45:24 -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 EAA22159 for ; Tue, 6 Aug 2002 04:45:22 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 99CFA6A906; Tue, 6 Aug 2002 14:45:21 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 62F5F6A905; Tue, 6 Aug 2002 14:45:15 +0300 (EEST) Message-ID: <3D4FB74E.2080701@kolumbus.fi> Date: Tue, 06 Aug 2002 14:47:26 +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: Brian Haley Cc: mobile ip Subject: Re: [mobile-ip] MH Checksum calculation References: <3D415E47.97D5A2ED@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brian Haley wrote: > Seems like Jari must be back from vacation with all the recent emails :) I wasn't back then, but now I am... > Anyways, I think the Checksum calculation paragraph in Section 6.1.1 > needs some clarification. The pseudo IPv6 header used does not specify > which source address is used if there is a Home Address Option in the > packet. Some MH types do not require HAO (HoTI,CoTI, etc.), one > might have one (BRR, if MN->MN), and others must have one (BU). > I'm assuming that if there's a HAO, that it must be used as the IPv6 > source address for the checksum calculation? If so, in addition to 6.1.1 Right. > changes, it might be good to add some text (in 11.2.1?) that says what > a MN should do if sending a MH message with a HAO. > > Section 11.2.1 does do a good job of saying how a MN should send > a "direct delivery" packet, swapping addresses and such, but doesn't > mention checksum. Checksum calculation should be the same for MH as it is for ICMP etc. My suggestion is to clarify this in 11.2.1 as follows: - Construct the packet using the mobile node's home address as the packet's Source Address, in the same way as if the mobile node were at home. NEW=> This includes the calculation of upper layer checksums using the home address as the value of the source. and then refer to this from 6.1.1 as follows: Note that the procedures described in Section 11.2.1 apply even for the Mobility Header. If a Mobility Header message has a Home Address destination option, then the checksum calculation uses the address in this option as the value of the IPv6 Source Address field. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 6 09:14: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 JAA10164 for ; Tue, 6 Aug 2002 09:14: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 HAA03445; Tue, 6 Aug 2002 07:15:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14937; Tue, 6 Aug 2002 06:15:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76DE13U010719 for ; Tue, 6 Aug 2002 06:14:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g76DE1nc010718 for mobile-ip-dist; Tue, 6 Aug 2002 06:14:01 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76DDt3U010711 for ; Tue, 6 Aug 2002 06:13:55 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09180 for ; Tue, 6 Aug 2002 06:14: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 HAA09085 for ; Tue, 6 Aug 2002 07:14:02 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id AEA726A906; Tue, 6 Aug 2002 16:13:58 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9AD946A905; Tue, 6 Aug 2002 16:13:46 +0300 (EEST) Message-ID: <3D4FCC0D.9020801@kolumbus.fi> Date: Tue, 06 Aug 2002 16:15:57 +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: Brian Haley Cc: Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MH type field References: <200208030214.g732ED2o756476@jurassic.eng.sun.com> <3D4E9CA9.22DB80DE@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit It does not seem that there are very strong feelings either way. Let's just pick one way to do it and stick with it. But Brian's note about possibility to extend type field later is true. This removes the main drawback about the 8 bit type field. The reserved field might also be useful for HOT/COT messages that do not currently have any Reserved fields. So, my suggestion is that we should just shorten the field to 8 bits and leave the rest Reserved. This does not cause any problems, and while the benefit is questionable it *might* be useful. Anyone disagree? Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 6 09:27: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 JAA10848 for ; Tue, 6 Aug 2002 09:27:21 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00983; Tue, 6 Aug 2002 06:26: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 GAA16866; Tue, 6 Aug 2002 06:26:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76DPT3U010866 for ; Tue, 6 Aug 2002 06:25:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g76DPTE6010865 for mobile-ip-dist; Tue, 6 Aug 2002 06:25: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.5+Sun/8.12.5) with ESMTP id g76DPN3U010858 for ; Tue, 6 Aug 2002 06:25:23 -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 GAA13047 for ; Tue, 6 Aug 2002 06:25:31 -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 GAA00518 for ; Tue, 6 Aug 2002 06:25:30 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 374716A906; Tue, 6 Aug 2002 16:25:28 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 058D96A905; Tue, 6 Aug 2002 16:25:11 +0300 (EEST) Message-ID: <3D4FCEB9.20706@kolumbus.fi> Date: Tue, 06 Aug 2002 16:27: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: Vijay Devarapalli Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobility Header len References: <3D4B3760.AF60953E@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 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: > hi, > > the Header Len field in Mobility header as described in draft 18 > is a multiple of 8 octets including the header fields. how about > changing it to a multiple of 8 octects leaving out the first 8 > octets. > > two advangtages > > 1. buys you 8 bytes :) (I know its minor) [Clarification: Allows 8 byte longer MH messages, current max being 2048. Doesn't save bytes on the wire.] > 2. IF we have piggybacking tomorrow, Mobility Header can be > processed like any other extension header. otherwise I need special > code. Let's do this. Suggested text: 8-bit unsigned integer. Length of the Mobility Header in units of 8 octets, excluding the first 8 octets. That is, the length of the Mobility Header beyond the Payload Proto, Header Len, MH Type, Reserved, and Checksum fields and the two first octets of the Message Data field. And some modifications later in the suggested MH Len values for particular messages. Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 6 10:04:03 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 KAA12159 for ; Tue, 6 Aug 2002 10:04:03 -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 HAA18984; Tue, 6 Aug 2002 07:03: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 HAA23621; Tue, 6 Aug 2002 07:03:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76E1I3U011129 for ; Tue, 6 Aug 2002 07:01:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g76E1Imq011128 for mobile-ip-dist; Tue, 6 Aug 2002 07:01: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.5+Sun/8.12.5) with ESMTP id g76E1A3U011121 for ; Tue, 6 Aug 2002 07:01:10 -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 HAA18042 for ; Tue, 6 Aug 2002 07:01:16 -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 HAA17979 for ; Tue, 6 Aug 2002 07:01:16 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id E89A2CE4; Tue, 6 Aug 2002 09:01:12 -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 2F60322DD; Tue, 6 Aug 2002 08:56:10 -0500 (CDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id JAA0001689771; Tue, 6 Aug 2002 09:56:05 -0400 (EDT) Message-ID: <3D4FD575.ABD2406E@hp.com> Date: Tue, 06 Aug 2002 09:56:05 -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: Jari Arkko Cc: mobile ip Subject: Re: [mobile-ip] MH Checksum calculation References: <3D415E47.97D5A2ED@hp.com> <3D4FB74E.2080701@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: > Checksum calculation should be the same for MH as it is for ICMP etc. > My suggestion is to clarify this in 11.2.1 as follows: > > - Construct the packet using the mobile node's home address > as the packet's Source Address, in the same way as if the > mobile node were at home. NEW=> This includes the calculation > of upper layer checksums using the home address as the value > of the source. > > and then refer to this from 6.1.1 as follows: > > Note that the procedures described in Section 11.2.1 apply > even for the Mobility Header. If a Mobility Header message > has a Home Address destination option, then the checksum calculation > uses the address in this option as the value of the IPv6 Source > Address field. This sounds good to me, thanks Jari. -Brian From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 6 13:20: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 NAA19288 for ; Tue, 6 Aug 2002 13:20: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 LAA28723; Tue, 6 Aug 2002 11:21: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 KAA05541; Tue, 6 Aug 2002 10:21:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76HKU3U011575 for ; Tue, 6 Aug 2002 10:20:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g76HKT4T011574 for mobile-ip-dist; Tue, 6 Aug 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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76HKO3U011567 for ; Tue, 6 Aug 2002 10:20:24 -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 KAA21143 for ; Tue, 6 Aug 2002 10:20:30 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22566; Tue, 6 Aug 2002 11:19:54 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA12434; Tue, 6 Aug 2002 10:19:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g76HJes16416; Tue, 6 Aug 2002 10:19:40 -0700 X-mProtect: <200208061719> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduhv4uZ; Tue, 06 Aug 2002 10:19:37 PDT Message-ID: <3D500528.D7252192@iprg.nokia.com> Date: Tue, 06 Aug 2002 10:19: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 CC: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Reflection attack using bogus BU? References: <3D4F9389.1000101@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 Section 10.2 which talks about primary Care-of Address registration with the Home Agent refers to section 9.4.4. specifically the text mentioned below. you should move the text there. it is needed for the HA to select the destination address for the Binding Ack. the reflection attack does not exist when we are talking about Home Agent. Vijay Jari Arkko wrote: > > Erik Nordmark wrote: > > > In section 9.4.4 draft 18: > > > > - Otherwise, if the Source IP Address of the packet containing > > the Binding Update, is legal for inclusion in a Routing Header, > > the routing header will be constructed using that IP address. > > Note that multicast addresses, link-local addresses, loopback > > addresses, IPv4 mapped addresses, and the unspecified address, > > MUST NOT be used within a Routing Header for the Binding > > Acknowledgement. > > > > Otherwise, if the Binding Update has a zero lifetime but the Source > > IP address is not allowable for use within the Routing Header, > > the Binding Acknowledgment MUST be sent to the mobile node's home > > address. > > > > This seems to say that if a node forms a packet with > > ip src = mapped address > > ip dst = reflector > > HAO = victim > > MH protocol, type = BU > > random bits in the authenticator > > > > then the reflector will send binding ack to the victim with status > > 137 Invalid authenticator > > Right. > > > I propose that when the source address can't use used in a routing header, > > the CN should silently drop the BU. > > Agreed. > > Proposed text: > > - Otherwise, the Binding Acknowledgment MUST NOT be sent. > > Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 6 13:24: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 NAA19445 for ; Tue, 6 Aug 2002 13:24: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 LAA01069; Tue, 6 Aug 2002 11:25: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 KAA22811; Tue, 6 Aug 2002 10:25:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g76HOH3U011699 for ; Tue, 6 Aug 2002 10:24:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g76HOHtC011698 for mobile-ip-dist; Tue, 6 Aug 2002 10:24: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.5+Sun/8.12.5) with ESMTP id g76HOB3U011689 for ; Tue, 6 Aug 2002 10:24:11 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23426 for ; Tue, 6 Aug 2002 10:24:17 -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 LAA00568 for ; Tue, 6 Aug 2002 11:24:16 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA12674; Tue, 6 Aug 2002 10:24:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g76HOF622275; Tue, 6 Aug 2002 10:24:15 -0700 X-mProtect: <200208061724> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUX4pRg; Tue, 06 Aug 2002 10:24:12 PDT Message-ID: <3D50063D.6A597F91@iprg.nokia.com> Date: Tue, 06 Aug 2002 10:24: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: Jari Arkko CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobility Header len References: <3D4B3760.AF60953E@iprg.nokia.com> <3D4FCEB9.20706@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: > > Suggested text: > > 8-bit unsigned integer. Length of the Mobility Header in units > of 8 octets, excluding the first 8 octets. That is, the length > of the Mobility Header beyond the Payload Proto, Header Len, MH > Type, Reserved, and Checksum fields and the two first octets of > the Message Data field. Okay. But isnt it sufficient if the text says 8-bit unsigned integer. Length of the Mobility Header in units of 8 octets, excluding the first 8 octets. regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 6 23:01: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 XAA09469 for ; Tue, 6 Aug 2002 23:01:40 -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 VAA07041; Tue, 6 Aug 2002 21:02: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 UAA02351; Tue, 6 Aug 2002 20:02:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g773163U012788 for ; Tue, 6 Aug 2002 20:01:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77316Ef012787 for mobile-ip-dist; Tue, 6 Aug 2002 20:01: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.5+Sun/8.12.5) with ESMTP id g773103U012780 for ; Tue, 6 Aug 2002 20:01:01 -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 UAA04756 for ; Tue, 6 Aug 2002 20:01:09 -0700 (PDT) Received: from tama5.ecl.ntt.co.jp (tama5.ecl.ntt.co.jp [129.60.39.102]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15952 for ; Tue, 6 Aug 2002 20:01:08 -0700 (PDT) Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/07/30/02) with ESMTP id MAA07620; Wed, 7 Aug 2002 12:01:02 +0900 (JST) (envelope-from ohnishi.hiroyuki@lab.ntt.co.jp) Received: from nttmail3.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g77311Rp014430; Wed, 7 Aug 2002 12:01:01 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.3/8.12.3) with ESMTP id g77311xH007880; Wed, 7 Aug 2002 12:01:01 +0900 (JST) Received: from imd.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id MAA14155; Wed, 7 Aug 2002 12:01:00 +0900 (JST) Received: from OHNISHI-GW.lab.ntt.co.jp by imd.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id MAA24288; Wed, 7 Aug 2002 12:01:00 +0900 (JST) Message-Id: <4.3.2-J.20020807102508.05250c38@imd.m.ecl.ntt.co.jp> X-Sender: ho005@imd.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 4.3.2-J Date: Wed, 07 Aug 2002 12:06:53 +0900 To: Jari Arkko , Erik Nordmark From: Hiroyuki OHNISHI Subject: Re: [mobile-ip] Mobile IPv6 I-D 18:BA status value Cc: mobile-ip@sunroof.eng.sun.com In-Reply-To: <3D4F9D6B.8050103@kolumbus.fi> 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, At 12:56 02/08/06 +0300, Jari Arkko wrote: >Erik Nordmark wrote: > >>>6.1.2. Binding Refresh Request (BRR) Message >>> >>> [...] When a mobile node receives a >>> packet containing 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 >>> (see Section 5.2) if it believes the amount of traffic with the >>> >>>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> correspondent justifies the use of route optimization. >>> >>>This means MN judges whether the MN uses RO or not depends >>>on the amount of traffic with CN when it receives BRR. >>Yes. Just like the MN initially decides when to first initiate a BU procedure, >>it isn't required to refresh the binding when it receives the BRR. >>The MN can presumably use whatever information it has (amount of traffic, >>the type of traffic, the phase of the moon) to determine which CNs it >>wants to use RO with at any given time. The high level point is that the >>BRR is a hint that the CN would like to >>see the binding refreshed. >> >>>And if the amount is low enough, it sends BA with 136 to the CN? >>Sending a BA in response to a BRR seems odd. >>I've been assuming the MN would just silently ignore the BRR if the MN >>doesn't see a need to refresh the binding. Perhaps this should be made >>explicit in the spec? > > >Yes. Suggested text follows. > >Here's a new version of the first paragraph in 9.4.4: > > When a mobile node receives a packet containing 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 (see Section~\ref{overview:security}) if it believes the > amount of traffic with the correspondent justifies the use of route > optimization. If it does not believe this, the mobile node MAY choose > to either ignore the Binding Refresh Request or to delete its binding > from the sender of the Binding Refresh Request. Note that the mobile > node SHOULD NOT respond Binding Refresh Requests from previously > unknown correspondent nodes due to Denial-of-Service concerns. > >We also need to clarify how to use 130/136. My proposal is to >merge the error codes and add the following text to the end of 9.4.2: > > The correspondent node MAY refuse to accept a new Binding Cache > entry, if it does not have sufficient resources. A new entry MAY > also be refused if the correspondent node believes its resources > are utilized more efficiently in some other purpose, such as > serving another mobile node with higher amount of traffic. In both > cases the correspondent node SHOULD return a Binding > Acknowledgement with status value 130. > >Jari I agree to merge the 130/136 error codes because it is difficult for the MN to use these different code effectively as you mentioned in your e-mail. But I want to confirm the meaning of second operation [A new entry MAY also be refused if .....]. It says that the route optimization is effective to reduce the traffic, but handling binding cache consumes CN's resources and the CN does not want to create new binding cache for a MN with which CN has a little amount of traffic. So there is a trade-off between the reduction of amount of traffic and the consumption of CN's resource. CN MAY decide how to use R.O from these 2 viewpoints. Is my understanding correct? -- Hiroyuki From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 7 01:21:41 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12906 for ; Wed, 7 Aug 2002 01:21: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 XAA11416; Tue, 6 Aug 2002 23:22:25 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA29680; Tue, 6 Aug 2002 22:22:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g775LN3U013177 for ; Tue, 6 Aug 2002 22:21:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g775LMIa013176 for mobile-ip-dist; Tue, 6 Aug 2002 22:21:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g775LG3U013169 for ; Tue, 6 Aug 2002 22:21: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 WAA13530 for ; Tue, 6 Aug 2002 22:21:24 -0700 (PDT) Received: from VX23.CC.MONASH.EDU.AU (vx23.cc.monash.edu.au [130.194.1.23]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA20080 for ; Tue, 6 Aug 2002 23:21:22 -0600 (MDT) Received: from splat.its.monash.edu.au ([130.194.1.73]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KL0RKIKNRU9DEVSF@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Wed, 07 Aug 2002 15:20:03 +1000 Received: from splat (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 7B62E130003 for ; Wed, 07 Aug 2002 15:20:02 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by splat.its.monash.edu.au (Postfix) with ESMTP id 4EC91130004 for ; Wed, 07 Aug 2002 15:20:02 +1000 (EST) Date: Wed, 07 Aug 2002 15:20:02 +1000 From: Greg Daley Subject: [mobile-ip] (Announce) Hierarchical MIPv6 implementation for Linux To: mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D50AE02.3030709@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT We are pleased to announce the first release of source code for the Monash HMIPv6 implementation for Linux. This is published as a patch to HUT's MIPL 0.9.3 and radvd 0.7.1 The code is available for download from: http://www.ctie.monash.edu.au/ipv6/hmipv6.htm This implementation provides: * Conformance to draft-ietf-mobileip-hmipv6-06.txt * Correct MN and MAP function for HMIPv6 Basic Mode. * Support for all IPv6 transport layers * Dynamic MAP information configuration/propagation. The source code is published under GNU GPL (kernel) and a BSD-style (radvd) open-source license. Additional information is available at the web site. Interest from other organizations with HMIPv6 implementations is especially sought, for the purposes of interoperability testing. Greg Daley Centre for Telecommunications and Information Engineering, Monash University. From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 7 03:30: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 DAA08601 for ; Wed, 7 Aug 2002 03:30:05 -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 BAA20723; Wed, 7 Aug 2002 01:30: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 AAA26884; Wed, 7 Aug 2002 00:30:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g777Sc3U013663 for ; Wed, 7 Aug 2002 00:28:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g777Scnc013662 for mobile-ip-dist; Wed, 7 Aug 2002 00: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g777SW3U013655 for ; Wed, 7 Aug 2002 00:28:32 -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 AAA21564 for ; Wed, 7 Aug 2002 00:28:40 -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 BAA19806 for ; Wed, 7 Aug 2002 01:28:39 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id E9AA96A907; Wed, 7 Aug 2002 10:28:38 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2BE8D6A906; Wed, 7 Aug 2002 10:28:33 +0300 (EEST) Message-ID: <3D50CCA5.4030908@kolumbus.fi> Date: Wed, 07 Aug 2002 10:30:45 +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: Hiroyuki OHNISHI Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Mobile IPv6 I-D 18:BA status value References: <4.3.2-J.20020807102508.05250c38@imd.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hiroyuki OHNISHI wrote: > I agree to merge the 130/136 error codes because it is difficult for the MN > to use these different code effectively as you mentioned in your e-mail. Good. > But I want to confirm the meaning of second operation [A new entry MAY > also be refused if .....]. > It says that the route optimization is effective to reduce the traffic, > but handling binding cache consumes CN's resources and > the CN does not want to create new binding cache for a MN > with which CN has a little amount of traffic. > So there is a trade-off between the reduction of amount of traffic and > the consumption of CN's resource. CN MAY decide how to use R.O from > these 2 viewpoints. > Is my understanding correct? Yes. But I don't really want to emphasize the resource consumption point: RR+RO consumes an extremely small amount of resources from the CN. Still, in some cases one wants to carefully evaluate the tradeoff, e.g. on busy servers. The idea is to allow CNs to make these decisions. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 7 03:56: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 DAA09038 for ; Wed, 7 Aug 2002 03:56: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 AAA08964; Wed, 7 Aug 2002 00:55: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 AAA01093; Wed, 7 Aug 2002 00:55:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g777rj3U013857 for ; Wed, 7 Aug 2002 00:53:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g777rjWw013856 for mobile-ip-dist; Wed, 7 Aug 2002 00:53: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.5+Sun/8.12.5) with ESMTP id g777re3U013849 for ; Wed, 7 Aug 2002 00:53:40 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24483 for ; Wed, 7 Aug 2002 00:53:48 -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 BAA12268 for ; Wed, 7 Aug 2002 01:53:47 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id C3FCB6A906; Wed, 7 Aug 2002 10:53:43 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 066A96A905; Wed, 7 Aug 2002 10:53:38 +0300 (EEST) Message-ID: <3D50D286.1060409@kolumbus.fi> Date: Wed, 07 Aug 2002 10:55:50 +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: Vladislav Yasevich , Francis Dupont Cc: "Hesham Soliman (EAB)" , "''mobile-ip@sunroof.eng.sun.com' '" Subject: Re: [mobile-ip] The link-local address issue References: <200207150752.g6F7qkGF061058@givry.rennes.enst-bretagne.fr> <3D4116C7.7030700@kolumbus.fi> <3D454370.9050802@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 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: > Yes, I agree. There was a thread a few months ago about > what to do with NCE on the mobile, but that did not get any > answeres. It looks like the "resetting" all ND state is > the way to go. Looks like some people agree at least. Francis, you said you agreed as well but that it should not be bound to MIPv6. I'm not sure I understand what you mean. Where are you proposing to make this clarification? In a new revision of the ND specifications? I think the mobility specification is the right place to treat this issue. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 7 04:31: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 EAA09824 for ; Wed, 7 Aug 2002 04:31: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 CAA00136; Wed, 7 Aug 2002 02:32: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 BAA07343; Wed, 7 Aug 2002 01:32:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g778Ux3U014357 for ; Wed, 7 Aug 2002 01:30:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g778Uwwf014356 for mobile-ip-dist; Wed, 7 Aug 2002 01:30: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.5+Sun/8.12.5) with ESMTP id g778Uo3U014328 for ; Wed, 7 Aug 2002 01:30: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 BAA03003 for ; Wed, 7 Aug 2002 01:30:59 -0700 (PDT) Received: from lit.a-star.edu.sg (rodin.krdl.org.sg [192.122.139.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29593 for ; Wed, 7 Aug 2002 02:30:57 -0600 (MDT) Received: from mailhost1 (localhost [127.0.0.1]) by lit.a-star.edu.sg (8.11.1/8.11.1) with ESMTP id g778Tcf08934 for ; Wed, 7 Aug 2002 16:29:38 +0800 (SGT) Received: from vsys (vsys.lit.org.sg [192.168.137.194]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 HotFix 0.5 (built Jun 7 2002)) with SMTP id <0H0G00BR3T16M6@mailhost.lit.org.sg> for mobile-ip@sunroof.eng.sun.com; Wed, 07 Aug 2002 16:31:58 +0800 (SGT) Date: Wed, 07 Aug 2002 16:30:51 +0800 From: Vrizlynn Thing Subject: [mobile-ip] CN to MN (Sending Binding Acknowledgement) To: Mobile IP Mailing List Message-id: <011d01c23dec$bf40b3e0$c289a8c0@vsys> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/alternative; boundary="Boundary_(ID_ycvSJp7IdSRwZlXMaYtM9Q)" X-Priority: 3 X-MSMail-priority: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --Boundary_(ID_ycvSJp7IdSRwZlXMaYtM9Q) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi all, On Section 9.4.4 of the Mobile IPv6 internet draft, it was specified that: "if the packet is to be sent to the mobile node at any address other than the mobile node's home address, it MUST be sent using a Routing header... - Whenever the Binding Update is accepted with a nonzero lifetime, the routing header will be constructed using the care-of address as described in Section 9.6. - Otherwise, if the Source IP Address of the packet containing the Binding Update, is legal for inclusion in a Routing Header, the routing header will be constructed using that IP address. Note that multicast addresses, link-local addresses, loopback addresses, IPv4 mapped addresses, and the unspecified address, MUST NOT be used within a Routing Header for the Binding Acknowledgement. Otherwise, if the Binding Update has a zero lifetime but the Source IP address is not allowable for use within the Routing Header, the Binding Acknowledgment MUST be sent to the mobile node's home address." Is this referring to the Type 0 or 2 RH? If the "addresses other than Home Address" is referring to the Care-of Address (if caching of BU entry is successful), shouldn't Type 2 RH be used with the Home Address in it (as in Section 9.6: Sending Packets to a MN)? And if caching fails, shouldn't BAck be sent back to the Home Address (without RH, and tunnelled by HA to MN)? Please correct me if I'm wrong. Regards, Vrizlynn Thing (Ms) --Boundary_(ID_ycvSJp7IdSRwZlXMaYtM9Q) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi all,
 
On Section 9.4.4 of the Mobile IPv6 internet draft, it was specified that:
 
"if the packet is to be sent to the mobile node at any address other than the mobile
   node's home address, it MUST be sent using a Routing header...
 
    -  Whenever the Binding Update is accepted with a nonzero lifetime,
       the routing header will be constructed using the care-of address
       as described in Section 9.6.

    -  Otherwise, if the Source IP Address of the packet containing
       the Binding Update, is legal for inclusion in a Routing Header,
       the routing header will be constructed using that IP address.
       Note that multicast addresses, link-local addresses, loopback
       addresses, IPv4 mapped addresses, and the unspecified address,
       MUST NOT be used within a Routing Header for the Binding
       Acknowledgement.

   Otherwise, if the Binding Update has a zero lifetime but the Source
   IP address is not allowable for use within the Routing Header,
   the Binding Acknowledgment MUST be sent to the mobile node's home
   address."
Is this referring to the Type 0 or 2 RH?
If the "addresses other than Home Address" is referring to the Care-of Address (if caching
of BU entry is successful), shouldn't Type 2 RH be used with the Home Address in it (as
in Section 9.6: Sending Packets to a MN)?
And if caching fails, shouldn't BAck be sent back to the Home Address (without RH,
and tunnelled by HA to MN)?
 
Please correct me if I'm wrong.
 
 
Regards,
Vrizlynn Thing (Ms)
--Boundary_(ID_ycvSJp7IdSRwZlXMaYtM9Q)-- From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 7 05:49: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 FAA11320 for ; Wed, 7 Aug 2002 05:49:07 -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 DAA15400; Wed, 7 Aug 2002 03: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 CAA15782; Wed, 7 Aug 2002 02:49:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g779mV3U014760 for ; Wed, 7 Aug 2002 02:48:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g779mVSQ014759 for mobile-ip-dist; Wed, 7 Aug 2002 02:48:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g779mP3U014752 for ; Wed, 7 Aug 2002 02:48: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 CAA15607 for ; Wed, 7 Aug 2002 02:48:35 -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 DAA14856 for ; Wed, 7 Aug 2002 03:48:34 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id E230A6A906; Wed, 7 Aug 2002 12:48:32 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 27A376A905; Wed, 7 Aug 2002 12:48:27 +0300 (EEST) Message-ID: <3D50ED6F.6030405@kolumbus.fi> Date: Wed, 07 Aug 2002 12:50:39 +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: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Reflection attack using bogus BU? References: <3D4F9389.1000101@kolumbus.fi> <3D500528.D7252192@iprg.nokia.com> 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.31 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: > Section 10.2 which talks about primary Care-of Address registration > with the Home Agent refers to section 9.4.4. specifically the text > mentioned below. you should move the text there. it is needed for > the HA to select the destination address for the Binding Ack. > > the reflection attack does not exist when we are talking about > Home Agent. Yes. The HA can still keep sending the BA even in these cases. I will make the following change in 10.2: The rules for selecting the Destination IP address (and possibly Routing Header construction) for the Binding Acknowledgement to the mobile node are the same as in section 9.4.4. => If the packet is to be sent to the mobile node at any address other than the mobile node's home address, it MUST be sent using a Routing header (even if the binding was rejected). The intermediate IP address, to which the packet will be delivered immediately before the home address, is determined as follows: - Whenever the Binding Update is accepted with a nonzero lifetime, the routing header will be constructed using the care-of address as described in Section 9.6. - Otherwise, the Source IP Address of the packet containing the Binding Update MUST be used, unless it is a multicast address, link-local address, loopback address, IPv4 mapped address, or the unspecified address. - Otherwise, the Binding Acknowledgment MUST be sent to the mobile node's home address. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 7 06:17: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 GAA11783 for ; Wed, 7 Aug 2002 06:17:50 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA05110; Wed, 7 Aug 2002 03:16: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 DAA27543; Wed, 7 Aug 2002 03:16:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77AFr3U014966 for ; Wed, 7 Aug 2002 03:15:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77AFqsf014965 for mobile-ip-dist; Wed, 7 Aug 2002 03:15: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.5+Sun/8.12.5) with ESMTP id g77AFl3U014955 for ; Wed, 7 Aug 2002 03:15:47 -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 DAA23640 for ; Wed, 7 Aug 2002 03:15:55 -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 DAA17014 for ; Wed, 7 Aug 2002 03:15:54 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 99AE36A905; Wed, 7 Aug 2002 13:15:53 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id C9B296A901 for ; Wed, 7 Aug 2002 13:15:47 +0300 (EEST) Message-ID: <3D50F3D8.2060704@kolumbus.fi> Date: Wed, 07 Aug 2002 13:18:00 +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] issue 94: unclear references to "addresses allowable in RH" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Background: Text in Section 6.1.7 says: The care-of address MUST NOT be any IPv6 address which is prohibited for use within a Routing Header; thus multicast addresses, the unspecified address, loop-back address, and link-local addresses are excluded. Binding Updates indicating any such excluded care-of address MUST be silently discarded. and Section 9.4.4 says: - Otherwise, if the Source IP Address of the packet containing the Binding Update, is legal for inclusion in a Routing Header, the routing header will be constructed using that IP address. Note that multicast addresses, link-local addresses, loopback addresses, IPv4 mapped addresses, and the unspecified address, MUST NOT be used within a Routing Header for the Binding Acknowledgement. as well as Otherwise, if the Binding Update has a zero lifetime but the Source IP address is not allowable for use within the Routing Header, the Binding Acknowledgment MUST be sent to the mobile node's home address. All these texts refer to addresses allowable for use within the Routing Header. The given list does not appear to match RFC 2460's definition of allowable addresses, as it only disallows multicast addresses. Furthermore, some of the text talks about the IPv6 destination address and still refers to the allowable RH addresses. Proposal: It is unnecessary to refer to other documents for the allowable addresses. We can simply list them in our document. Two alternative ways to do this: 1) List the illegal address types, i.e., a multicast address, link-local address, loopback address, IPv4 mapped address, or the unspecified address. 2) List the legal address types, i.e., global unicast address. I'm concerned that we might miss something by picking the first scheme. And what if there are new address types in the future? From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 7 06:48: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 GAA12228 for ; Wed, 7 Aug 2002 06:47:59 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25446; Wed, 7 Aug 2002 04:48:44 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25612; Wed, 7 Aug 2002 03:48:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77Ala3U015146 for ; Wed, 7 Aug 2002 03:47:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77Ala2U015145 for mobile-ip-dist; Wed, 7 Aug 2002 03:47: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.5+Sun/8.12.5) with ESMTP id g77AlU3U015138 for ; Wed, 7 Aug 2002 03:47:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA04103 for ; Wed, 7 Aug 2002 03:47:38 -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 EAA24743 for ; Wed, 7 Aug 2002 04:47:37 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 95C5E6A906; Wed, 7 Aug 2002 13:47:36 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id CCB306A905; Wed, 7 Aug 2002 13:47:30 +0300 (EEST) Message-ID: <3D50FB47.10605@kolumbus.fi> Date: Wed, 07 Aug 2002 13:49:43 +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: Vrizlynn Thing Cc: Mobile IP Mailing List Subject: Re: [mobile-ip] CN to MN (Sending Binding Acknowledgement) References: <011d01c23dec$bf40b3e0$c289a8c0@vsys> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vrizlynn Thing wrote: > Is this referring to the Type 0 or 2 RH? Type 2. See a separate thread on removing some references to addresses allowable in RH. The remaining RH references should state type 2 in all cases. That is, in your specific example the text should have read: "if the packet is to be sent to the mobile node at any address other than the mobile node's home address, it MUST be sent using a Type 2 Routing header... > If the "addresses other than Home Address" is referring to the Care-of > Address (if caching I believe it refers to the source address of the BU. Let's clarify the text as follows: Furthermore, if the packet is to be sent to the mobile node at any address other than the mobile node's home address, ... => The acknowledgement is sent to the Source Address of the IPv6 header that carried the Binding Update. If this address is different from the home address of the mobile node, ... I registered the above modifications as issue #95. > of BU entry is successful), shouldn't Type 2 RH be used with the Home > Address in it (as > in Section 9.6: Sending Packets to a MN)? Yes. > And if caching fails, shouldn't BAck be sent back to the Home Address > (without RH, > and tunnelled by HA to MN)? For CNs, I think it makes more sense to send the packet to the source address of the BU if possible. This would avoid some reflection attacks that would otherwise become possible. As Vijay pointed out, this does not apply to HAs so the HA would still be able to respond to the home address. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 7 08:43: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 IAA15443 for ; Wed, 7 Aug 2002 08:43: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 FAA05498; Wed, 7 Aug 2002 05:42: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 FAA18837; Wed, 7 Aug 2002 05:42:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77Cfm3U015474 for ; Wed, 7 Aug 2002 05:41:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77CfmVF015473 for mobile-ip-dist; Wed, 7 Aug 2002 05:41: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.5+Sun/8.12.5) with ESMTP id g77Cfg3U015466 for ; Wed, 7 Aug 2002 05:41:42 -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 FAA14607 for ; Wed, 7 Aug 2002 05:41:51 -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 FAA05049 for ; Wed, 7 Aug 2002 05:41:51 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 50D396A901; Wed, 7 Aug 2002 15:41:49 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B00796A905; Wed, 7 Aug 2002 15:41:42 +0300 (EEST) Message-ID: <3D51160B.1000605@kolumbus.fi> Date: Wed, 07 Aug 2002 15:43:55 +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: Kevin Miles , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] MIPv6 I-D 18: Miscellaneous Comments References: <006b01c234f0$64799440$596cfe90@emea.cisco.com> <3D41E346.83C63531@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 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: > Kevin Miles wrote: > >>So at any time the mobile can choose to switch from S=1 to S=0? Which begs the >>question, can it also switch the other way and manage its set of BCEs >>individually? (Isn't this where we came in :-) >> >>I can't actually think why it would be useful for a mobile node to want to >>change the value of S in either direction during a single binding. Does anyone >>have a reason for allowing this? >> >>My preferred resolution is to declare that the value of S on all rereg and dereg >>BUs is ignored and treated as if it were the same as on the original BU. (If the >>mobile node really needs to change the value of S, it can always dereg and reg >>again.) >> > > I agree with Kevin. Ok. Suggested text. Add to fifth bullet of section 11.6.1: The value of the `S' bit MUST be set equivalently for subsequent de-registrations and re-registrations with the same addresses. and then in 10.2: If the `S' bit field in the Binding Update is zero, The home agent creates or updates Binding Cache entries for each of possibly several home addresses. 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. The home agent creates such a separate primary care-of address registration for each such home address. Note that the same considerations for Duplicate Address Detection apply for each affected home address. => If the `S' bit field in the Binding Update is zero, The home agent creates Binding Cache entries for each of possibly several home addresses. 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. The home agent creates such a separate primary care-of address registration for each such home address. Note that the same considerations for Duplicate Address Detection apply for each affected home address. The value of the `S' bit field is examined only for new registrations. Its value is ignored on de-registrations and re-registrations of the same addresses. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 7 11:20: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 LAA23021 for ; Wed, 7 Aug 2002 11:20: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 JAA00525; Wed, 7 Aug 2002 09:21: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 IAA13065; Wed, 7 Aug 2002 08:21:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77FKC3U016034 for ; Wed, 7 Aug 2002 08:20:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77FKCEM016033 for mobile-ip-dist; Wed, 7 Aug 2002 08:20: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.5+Sun/8.12.5) with ESMTP id g77FK73U016026 for ; Wed, 7 Aug 2002 08:20:07 -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 IAA17920 for ; Wed, 7 Aug 2002 08:20:16 -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 IAA26588 for ; Wed, 7 Aug 2002 08:20:11 -0700 (PDT) Message-ID: <000001c23e25$acb09180$296015ac@T23KEMPF> From: "James Kempf" To: "Rajeev Koodli" Cc: "Erik Nordmark" , "Singh Ajoy-ASINGH1" , "'Alper E. YEGIN'" , "'Vijay Devarapalli'" , References: <3D499352.5F5652A@iprg.nokia.com> <011501c239ac$2c9781c0$296015ac@T23KEMPF> <3D49CF88.268F6FCB@iprg.nokia.com> <000b01c23a3a$a72c07b0$296015ac@T23KEMPF> <3D4ABC7A.9343333A@iprg.nokia.com> <3D4B09A0.4F34ECE3@iprg.nokia.com> Subject: Re: [mobile-ip] Subject Change: Should PrRtAdv be optional in fmipv6 ? Date: Fri, 2 Aug 2002 17:09: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 > I guess I was not clear.. The question is not how the old AR can determine the > IP address of the new AR, which itself is a separate issue, but how can the MN send > > packets to the new router. If the MN knows the L2 address of the new BS (not the > new AR), can it send packets to the router ? Two options: > > a) assume that the new AP is capable of routing/switching packets to the new AR > based on L2 headers > b) assume that the new AP is only a bridge between wireless and wireline portions > of > the network. > > In UMTS (scenario a) ), the MN sends packets to the AP (actually to Node B and then > to RNC). > And, then there is GTP tunneling. However, in UMTS, the MN does not change the > AR (i.e., GGSN). As I understand, inter-GGSN handovers are not specified. Inside > the GGSN, handover support is done by GTP and is well-specified. So, I am not > sure how the scenario you describe above would be applicable specifically to WCDMA > networks.. > Also, PrRtAdv is as inapplicable as any ND messages defined today. > Even if you don't consider GPRS, the base station could take care of making sure the packets get to the new router, since the router would likely be at the segmentation and reassembly point for the radio frames. So I don't think it's an issue in cellular protocols. > If you consider scenario b), which is applicable to WLAN e.g., the MN needs to know > > the L2 address of the new AR to send packets. > Three possibilities: 1) The MN runs Seamoby CARD protocol, maps the new AP address into the new AR address. 2) MN sends the packet to the new AP L2 address and the new AP forwards to the new AR. In this case, the AP isn't working as a transparent bridge anymore. 3) The tunnel doesn't run between the new AR and old AR, it runs between the new AP and the old AP. The new AP and old AP exchange the target triggered signaling when the new AP gets the Reassociation.request(). Note that 3) isn't quite as unlikely as it may seem, since the new AP must already use IAPP back to the old AP to request the old AP to clean up its resources for the mobile. 1) is out of scope for the fast handover draft, 2) and 3) would require some AP work, and therefore is out of scope for the generic fast handover draft, but maybe in for the 802.11 specific fast handover draft. > > > > > > > For link layers where there is no exchange of new BS identity over the air at > > Layer 2 prior to handover but the MN knows, the MN can use Seamoby CARD to do > > the mapping, and SolPrRtAdv/PrRtAdv would be required. > > > > For link layers with no prehandover signaling between the BS and MN such as > > 802.11, the MN can use Seamoby CARD after handover and do the mapping, but it is > > yet unclear how the tunnel would be initiated in this case. Alternatively, the > > BS can do the mapping if the old BS id is known, and use target triggered > > handover, which is also undefined in draft 5. The fast handover signaling for > > this case is the most underspecified in draft 5, IMHO. > > Regarding target-triggered tunnel establishment: how does the new AR know > the previous AR, and the previous IP address of the MN ? How does the new AP > figure both of these through Reassociate ? > New AP sends MN L2 address and old AP address to new AR through proposed ICMP protocol, uses Seamoby CARD to find IP address of old AR for target triggered handover signaling. The only issue is, unlike MIPv4, that the old AR doesn't necessarily know the care of address for the MN, unless the AR has locked down the neighbor cache and still has it around. I think in our implementation we lock down the neighbor cache and send back the MN's old CoA in the target triggered handover reply signaling, and flush the cache when the tunnel gets torn down. Alternatively, if the AP is handling the tunnel, it does the target triggered handover back to the old AP in conjunction with the IAPP signaling. > Regarding tunnel establishment after association: the MN sends FBU which > triggers HI/HAck and hence the tunnel establishment. This may be need to > be specified separately, but is not undefined. > I'm unclear why FBU is being used here, but I think we should discuss that in a separate thread. > > > > > > > > > So, how does a WLAN card decide to associate with a new AP ? > > > > Proprietary. It is not specified in the 802.11 standard. As a practical matter, > > FER and signal strength are both possibilites. In existing products, there are a > > wide variety of algorithms, and they are likely to get more varied as vendors > > start competing on handover performance. > > > > This is good enough. We provide a message that implementations can use > to obtain the L2 and IP addresses. > Can you explain what you mean by a message? The handover decision making is happening internally to the firmware on the interface card. There is network traffic involved, but it is strictly determined by the 802.11 scanning protocol. > > > > > There is > > > a "scan" message that allows the MS to figure out what APs are within > > > reach. After that, there has to be some guideline as to when the MS > > > changes its AP, based on, e.g., received signal strength. > > > > It could also be FER. Also, some current products do make a decision based on > > other measures not associated with the quality of the link. 802.11 is not like > > cellular, there is no standard signal strength specified nor a standard FER, nor > > even a requirement that these should be used to make the handover decision. The > > only standardized signaling is the Reassociation.request() and > > Reassociation.reply() when the card has selected which access point it will > > associate with. > > > > This is ok. What we need is a message that the implementations can use > independent of what criterion they use to undergo handover. > Same question as above? > > > > > > The result of scan is the input to PrRtSol. > > > > Our experience is that the results of a scan are not typically available to the > > driver when a handover is necessary, it is conducted by the firmware, and is > > followed by the Reassociation.request()/reply() without any driver intervention. > > On some cards, a scan can be forced, signal strength measured, and handover > > forced by the driver, but this is by no means a standard. Also,during the > > exchange of PrRtSol/PrRtAdv (which will take some amount of time) after the scan > > is forced, the firmware could decide to perform handover to a completely > > different access point. Nothing constrains the firmware to continue being > > associated with the current access point until the PrRtSol/PrRtAdv completes. > > Finally, while a scan is being conducted, the card is basically offline for any > > traffic. This means that the scan prior to the PrRtSol/PrRtAdv would shut down > > traffic to the card, during which time it would have to be buffered (or dropped) > > if the scan takes too long. > > > > We've measured typical scan times of about 100 ms on a cell with a single MN. > > This time increases dramatically if there is more than one MN in the cell, > > because 802.11 has no QoS on signaling traffic. The scan is scheduled on the > > link with the same priority as MN traffic. With 3 MNs doing continuous traffic, > > the scan time can be upwards of 200 ms. > > > > All of the above is ok. If the MN has time to do PrRtSol/PrRtAdv, which BTW > takes few milliseconds, it will benefit. Maybe I wasn't clear here. The issue is that even in *that few milliseconds*, the firmware may decide to switch to another AP than the one that was selected by the driver and sent in the PrRtSol/PrRtAv. Can you explain how the Mobile IP stack can benefit if it runs some nonzero probability of ending up on a different access point? > Otherwise, the protocol will operate from > the > new link (i.e., FBU sent from new link). So, I don't understand.. > The current definition of how this works in draft 05 has that defined as an error case. In 802.11, unless the standard IETF Mobile IP fast handover specification for 802.11 is defined such that it depends on proprietary extensions to 802.11, the case of the mobile moving without any prehandover notification will be the norm. And, again, I'm unclear why FBU is being used in this case, but we should take that up in a separate thread. > > > > > It suffices to provide a message > > > that can be called when the L2 decides to look for other AP(s). Note > > > that there is analogous support in Linux to send a RS upon detecting > > > a new link. > > > > > > > I don't follow. If the Layer 2 protocol doesn't provide this, how can IP help? > > We can't control what happens at Layer 2 unless the hooks are there. > > The L2 protocol allows scanning and each card can make a decision > to undergo handover based on its own criterion. Then, the IP message > can be sent. > As I mentioned above, the firmware has its own ideas. The driver may decide to switch to access point A, but if the firmware switches to access point B, the IP signaling won't reflect reality. > > > > > > > If the MS moves before PrRtSol could be attempted, then the HI/HAck > > > happens after the association with the new AP. > > > > > > > Sure, that's target triggered handover. There is something in draft 04 to do > > this, and also in the FMIPv4 draft. > > v05 also allows the tunnel establishment through FBU. I will put this under > a separate section for tunnel establishment subsequent to new link > establishment and more content. > OK. jak From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 7 13:31: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 NAA00116 for ; Wed, 7 Aug 2002 13:31:13 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03332; Wed, 7 Aug 2002 11:31:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04529; Wed, 7 Aug 2002 10:31:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77HUW3U016461 for ; Wed, 7 Aug 2002 10:30:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g77HUWQ8016460 for mobile-ip-dist; Wed, 7 Aug 2002 10:30: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.5+Sun/8.12.5) with ESMTP id g77HUR3U016453 for ; Wed, 7 Aug 2002 10:30:27 -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 KAA03937 for ; Wed, 7 Aug 2002 10:30:35 -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 LAA12308; Wed, 7 Aug 2002 11:30: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 KAA17121; Wed, 7 Aug 2002 10:30:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g77HUWf26592; Wed, 7 Aug 2002 10:30:32 -0700 X-mProtect: <200208071730> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdkgJFfO; Wed, 07 Aug 2002 10:30:30 PDT Message-ID: <3D515936.FE4F2C8B@iprg.nokia.com> Date: Wed, 07 Aug 2002 10:30:30 -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: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Reflection attack using bogus BU? References: <3D4F9389.1000101@kolumbus.fi> <3D500528.D7252192@iprg.nokia.com> <3D50ED6F.6030405@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: > If the packet > is to be sent to the mobile node at any address other than the mobile > node's home address, it MUST be sent using a Routing header (even if > the binding was rejected). The intermediate IP address, to which > the packet will be delivered immediately before the home address, is > determined as follows: > > - Whenever the Binding Update is accepted with a nonzero lifetime, > the routing header will be constructed using the care-of address > as described in Section 9.6. > > - Otherwise, the Source IP Address of the packet containing > the Binding Update MUST be used, unless it is a multicast > address, link-local address, loopback address, IPv4 mapped > address, or the unspecified address. > > - Otherwise, the Binding Acknowledgment MUST be sent to the mobile > node's home address. this wont go anywhere. the MN is not at home. the HA should not send a Binding Ack, in case it cant be sent to the MN's current CoA. the third point could say - Otherwise, the Binding Acknowledgment is not sent. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 7 21:57: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 VAA17251 for ; Wed, 7 Aug 2002 21:57:28 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27543; Wed, 7 Aug 2002 18:56: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 SAA07092; Wed, 7 Aug 2002 18:56:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g781sV3U017895 for ; Wed, 7 Aug 2002 18:54:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g781sVkd017894 for mobile-ip-dist; Wed, 7 Aug 2002 18:54:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g781sP3U017887 for ; Wed, 7 Aug 2002 18:54:25 -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 SAA07298 for ; Wed, 7 Aug 2002 18:54:33 -0700 (PDT) Received: from lit.a-star.edu.sg (rodin.krdl.org.sg [192.122.139.27]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA15600 for ; Wed, 7 Aug 2002 19:54:31 -0600 (MDT) Received: from mailhost1 (localhost [127.0.0.1]) by lit.a-star.edu.sg (8.11.1/8.11.1) with ESMTP id g781r4d26484 for ; Thu, 8 Aug 2002 09:53:04 +0800 (SGT) Received: from vsys (vsys.lit.org.sg [192.168.137.194]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 HotFix 0.5 (built Jun 7 2002)) with SMTP id <0H0I00BCL5C6M6@mailhost.lit.org.sg> for mobile-ip@sunroof.eng.sun.com; Thu, 08 Aug 2002 09:55:25 +0800 (SGT) Date: Thu, 08 Aug 2002 09:54:15 +0800 From: Vrizlynn Thing Subject: Re: [mobile-ip] CN to MN (Sending Binding Acknowledgement) To: Jari Arkko , Vrizlynn Thing Cc: Mobile IP Mailing List Message-id: <002101c23e7e$84b3ea20$c289a8c0@vsys> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <011d01c23dec$bf40b3e0$c289a8c0@vsys> <3D50FB47.10605@kolumbus.fi> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT > > The acknowledgement is sent to the Source Address of the IPv6 header > that carried the Binding Update. If this address is different from > the home address of the mobile node, ... > > I registered the above modifications as issue #95. > > > > For CNs, I think it makes more sense to send the packet to the source > address of the BU if possible. This would avoid some reflection attacks > that would otherwise become possible. As Vijay pointed out, this does > not apply to HAs so the HA would still be able to respond to the home > address. > I agree with the above. Let's say we have 3 cases here. Case 1: BU accepted for caching src = CoA dest = CN BAck sent with src = CN, dest = CoA, RH2 = HoA Case 2: BU accepted for deletion (lifetime == 0) src = HoA dest = CN BAck sent with src = CN, dest = HoA If src in BU is not HoA but legal RH address, then BAck dest = this src address, RH2 = HoA Case 3: BU not accepted src = CoA / HoA / other addresses dest = CN BAck sent with src = CN, dest = HoA If src in BU is not HoA but legal RH address, then BAck dest = this src address (no RH2 in this case since binding not accepted) Am I right to say these? I voiced out these questions mainly because in Sect. 9.4.4 (Sending Binding Acknowledgement), it's stated that RH should contain either CoA or Src address. Whereas, I believe in any cases if RH is to be used, it should contain HoA instead. Regards, Vrizlynn Thing From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 8 03:00: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 DAA02712 for ; Thu, 8 Aug 2002 03:00: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 BAA20758; Thu, 8 Aug 2002 01:01: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 AAA19436; Thu, 8 Aug 2002 00:01:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g787063U018597 for ; Thu, 8 Aug 2002 00:00:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g78705RU018596 for mobile-ip-dist; Thu, 8 Aug 2002 00: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g787003U018589 for ; Thu, 8 Aug 2002 00:00:00 -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 AAA21973 for ; Thu, 8 Aug 2002 00:00:08 -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 AAA19626 for ; Thu, 8 Aug 2002 00:00:07 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 0E4BC6A905; Thu, 8 Aug 2002 09:59:59 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 61E8A6A901; Thu, 8 Aug 2002 09:59:52 +0300 (EEST) Message-ID: <3D52176D.2090200@kolumbus.fi> Date: Thu, 08 Aug 2002 10:02:05 +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: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Reflection attack using bogus BU? References: <3D4F9389.1000101@kolumbus.fi> <3D500528.D7252192@iprg.nokia.com> <3D50ED6F.6030405@kolumbus.fi> <3D515936.FE4F2C8B@iprg.nokia.com> 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.31 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: >> - Otherwise, the Binding Acknowledgment MUST be sent to the mobile >> node's home address. >> > > this wont go anywhere. the MN is not at home. the HA should not > send a Binding Ack, in case it cant be sent to the MN's current > CoA. > > the third point could say > > - Otherwise, the Binding Acknowledgment is not sent. I though you argued earlier that the CN and HA cases are different, and the third points differ because there's no reflection attack danger. But perhaps I misunderstood this. Anyway, if the HA sends something to the mobile node's home address, this should be intercepted by the HA and sent to the currently registered CoA. Note that currently registered may not be the same as the source address used in the BU, particularly if the BU failed for some reason. But I guess the main question here is if we *need* to do anything else than to drop the ack if the source is weird? I'd be very happy if we didn't need to do anything else. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 8 05:45: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 FAA06266 for ; Thu, 8 Aug 2002 05:45: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 CAA27358; Thu, 8 Aug 2002 02:44:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07984; Thu, 8 Aug 2002 02:44:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g789h43U019105 for ; Thu, 8 Aug 2002 02:43:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g789h4KC019104 for mobile-ip-dist; Thu, 8 Aug 2002 02:43: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.5+Sun/8.12.5) with ESMTP id g789gw3U019097 for ; Thu, 8 Aug 2002 02:42:58 -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 CAA07881 for ; Thu, 8 Aug 2002 02:43:09 -0700 (PDT) Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19723 for ; Thu, 8 Aug 2002 03:43:07 -0600 (MDT) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 8 Aug 2002 11:43:06 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Subject: [mobile-ip] TR: (Announce) Hierarchical MIPv6 implementation for Linux Date: Thu, 8 Aug 2002 11:43:06 +0200 Message-ID: Thread-Topic: [mobile-ip] (Announce) Hierarchical MIPv6 implementation for Linux Thread-Index: AcI90oOxtjHyxHnlS9uo4LGOjWTzoQA4bU1AAALV1+A= From: "AUVRAY Sebastien FTRD/DMI/CAE" To: "mobile-ip list (E-mail)" X-OriginalArrivalTime: 08 Aug 2002 09:43:06.0890 (UTC) FILETIME=[FFAB7EA0:01C23EBF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g789gw3U019098 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit FYI Cordialement, Sebastien Sebastien ------------------------------------------------------------------ Sebastien AUVRAY France Telecom R&D - DMI/SIR/IPI 42, rue des Coutures BP 6243 14066 CAEN Cedex 4 Tel. : 02.31.75.90.54 Fax : 02.31.75.56.26 e-mail : sebastien.auvray@francetelecom.com ------------------------------------------------------------------ -----Message d'origine----- De : Greg Daley [mailto:greg.daley@eng.monash.edu.au] Envoye : mercredi 7 aout 2002 07:20 A : mobile-ip@sunroof.eng.sun.com Objet : [mobile-ip] (Announce) Hierarchical MIPv6 implementation for Linux We are pleased to announce the first release of source code for the Monash HMIPv6 implementation for Linux. This is published as a patch to HUT's MIPL 0.9.3 and radvd 0.7.1 The code is available for download from: http://www.ctie.monash.edu.au/ipv6/hmipv6.htm This implementation provides: * Conformance to draft-ietf-mobileip-hmipv6-06.txt * Correct MN and MAP function for HMIPv6 Basic Mode. * Support for all IPv6 transport layers * Dynamic MAP information configuration/propagation. The source code is published under GNU GPL (kernel) and a BSD-style (radvd) open-source license. Additional information is available at the web site. Interest from other organizations with HMIPv6 implementations is especially sought, for the purposes of interoperability testing. Greg Daley Centre for Telecommunications and Information Engineering, Monash University. From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 8 07:08: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 HAA07880 for ; Thu, 8 Aug 2002 07:08:45 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27510; Thu, 8 Aug 2002 05:09:24 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15197; Thu, 8 Aug 2002 04:09:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78B8L3U019415 for ; Thu, 8 Aug 2002 04:08:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g78B8KQk019414 for mobile-ip-dist; Thu, 8 Aug 2002 04:08:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78B8C3U019400 for ; Thu, 8 Aug 2002 04:08:12 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA14830 for ; Thu, 8 Aug 2002 04:08:20 -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 FAA26833 for ; Thu, 8 Aug 2002 05:08:17 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id BC1EC6A905; Thu, 8 Aug 2002 14:08:07 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 132936A901; Thu, 8 Aug 2002 14:08:00 +0300 (EEST) Message-ID: <3D525195.7010807@piuha.net> Date: Thu, 08 Aug 2002 14:10:13 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Vijay Devarapalli Cc: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Reflection attack using bogus BU? References: <3D4F9389.1000101@kolumbus.fi> <3D500528.D7252192@iprg.nokia.com> <3D50ED6F.6030405@kolumbus.fi> <3D515936.FE4F2C8B@iprg.nokia.com> <3D52176D.2090200@kolumbus.fi> 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.31 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: >> this wont go anywhere. the MN is not at home. the HA should not >> send a Binding Ack, in case it cant be sent to the MN's current CoA. And I wrote: > But I guess the main question here is if we *need* to do anything > else than to drop the ack if the source is weird? I'd be very happy > if we didn't need to do anything else. After some thinking, we do need to handle at least the case where the source address is link-local (when the MN is returning home). Also, I'm not sure the rule about the current CoA is sufficient either. Say, the MN has moved and can no longer use the previous coa. Then, it sends a BU but for some reason with a wrong sequence number. The BA will give an error about this, and the MN must be able to read this error before the situation can be corrected. So it would seem that we must be able to send the BA to the source of the BU rather than the currently registered coa? Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 8 07:10: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 HAA07921 for ; Thu, 8 Aug 2002 07:10:05 -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 FAA28314; Thu, 8 Aug 2002 05:10: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 EAA15605; Thu, 8 Aug 2002 04:10:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78B9s3U019451 for ; Thu, 8 Aug 2002 04:09:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g78B9rXt019450 for mobile-ip-dist; Thu, 8 Aug 2002 04:09: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.5+Sun/8.12.5) with ESMTP id g78B9l3U019440 for ; Thu, 8 Aug 2002 04:09: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 EAA21716 for ; Thu, 8 Aug 2002 04:09:55 -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 FAA24939 for ; Thu, 8 Aug 2002 05:09:52 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id B7AD96A905; Thu, 8 Aug 2002 14:09:34 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B62A16A901; Thu, 8 Aug 2002 14:09:26 +0300 (EEST) Message-ID: <3D5251EC.7070602@kolumbus.fi> Date: Thu, 08 Aug 2002 14:11: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: Vrizlynn Thing Cc: Vrizlynn Thing , Mobile IP Mailing List Subject: Re: [mobile-ip] CN to MN (Sending Binding Acknowledgement) References: <011d01c23dec$bf40b3e0$c289a8c0@vsys> <3D50FB47.10605@kolumbus.fi> <002101c23e7e$84b3ea20$c289a8c0@vsys> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Vrizlynn Thing wrote: > I agree with the above. Let's say we have 3 cases here. > > Case 1: BU accepted for caching > src = CoA > dest = CN > > BAck sent with src = CN, dest = CoA, RH2 = HoA Right. > Case 2: BU accepted for deletion (lifetime == 0) > src = HoA > dest = CN > > BAck sent with src = CN, dest = HoA > If src in BU is not HoA but legal RH address, then BAck dest = this src > address, RH2 = HoA > > > Case 3: BU not accepted > src = CoA / HoA / other addresses > dest = CN > > BAck sent with src = CN, dest = HoA > If src in BU is not HoA but legal RH address, then BAck dest = this src > address (no RH2 in this case since binding not accepted) No. Per issue #92 CNs will not respond to HoA if the src is unsuitable. So: BAck sent with src=CN, dest=bu src, RH2=hoa I think this applies to both cases 2 and 3. The real differentiator is is (1) whether bu src is equal to home address or not, and then if not (2) whether the bu src is a suitable address or not. > Am I right to say these? I voiced out these questions mainly because in > Sect. 9.4.4 (Sending Binding Acknowledgement), it's stated that > RH should contain either CoA or Src address. Whereas, I believe in any cases > if RH is to be used, it should contain HoA instead. Correct. This should be fixed. Sigh... 9.4.4. is a continuous source of trouble... let's try to create better text to fix #92, #94 and #95. This one is for 9.4.4: The acknowledgement is sent to the Source Address of the IPv6 header that carried the Binding Update. Note that this procedure is independent from the treatment of regular packets and does not use information from the Binding Cache. If the Source Address field does not contain a global unicast address, the Binding Acknowledgement MUST NOT be sent. If the address is a global unicast address, further processing depends on whether this address is the home address of the mobile node or not. If the Binding Update does not contain a Home Address destination option, then the source address is the home address of the mobile node. If so, the Binding Acknowledgement MUST be sent directly to this address. Otherwise, the Binding Acknowledgement MUST still be sent to the source address, but a Type 2 Routing Header MUST be added to the packet to carry the home address. And this one is for 10.2: The acknowledgement is sent to the Source Address of the IPv6 header that carried the Binding Update. Note that this procedure is independent from the treatment of regular packets and does not use information from the Binding Cache. If the Source Address field does not contain a global or link-local unicast address, the Binding Acknowledgement MUST NOT be sent. If the address is of these types, further processing depends on whether the address was the home address of the mobile node or not. If the Binding Update does not contain a Home Address destination option, then the source address is the home address of the mobile node. If so, the Binding Acknowledgement MUST be sent directly to this address. Otherwise, the Binding Acknowledgement MUST still be sent to the source address, but a Type 2 Routing Header MUST be added to the packet to carry the home address. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 8 13:11: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 NAA19897 for ; Thu, 8 Aug 2002 13:11: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 LAA09520; Thu, 8 Aug 2002 11:12:03 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24835; Thu, 8 Aug 2002 10:11:58 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78HAf3U021198 for ; Thu, 8 Aug 2002 10:10:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g78HAfhm021197 for mobile-ip-dist; Thu, 8 Aug 2002 10:10: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.5+Sun/8.12.5) with ESMTP id g78HAZ3U021189 for ; Thu, 8 Aug 2002 10:10:35 -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 KAA07882 for ; Thu, 8 Aug 2002 10:10:45 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27835; Thu, 8 Aug 2002 11:10: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 KAA28792; Thu, 8 Aug 2002 10:10:42 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g78HAeX13360; Thu, 8 Aug 2002 10:10:40 -0700 X-mProtect: <200208081710> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3zGBE5; Thu, 08 Aug 2002 10:10:38 PDT Message-ID: <3D52A60F.8E6E88C8@iprg.nokia.com> Date: Thu, 08 Aug 2002 10:10:39 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Reflection attack using bogus BU? References: <3D4F9389.1000101@kolumbus.fi> <3D500528.D7252192@iprg.nokia.com> <3D50ED6F.6030405@kolumbus.fi> <3D515936.FE4F2C8B@iprg.nokia.com> <3D52176D.2090200@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: > > Vijay Devarapalli wrote: > > >> - Otherwise, the Binding Acknowledgment MUST be sent to the mobile > >> node's home address. > >> > > > > this wont go anywhere. the MN is not at home. the HA should not > > send a Binding Ack, in case it cant be sent to the MN's current > > CoA. > > > > the third point could say > > > > - Otherwise, the Binding Acknowledgment is not sent. > > I though you argued earlier that the CN and HA cases are > different, and the third points differ because there's no > reflection attack danger. But perhaps I misunderstood this. no you did not. I was saying that. > Anyway, if the HA sends something to the mobile node's home address, > this should be intercepted by the HA and sent to the currently registered > CoA. Note that currently registered may not be the same as the source > address used in the BU, particularly if the BU failed for some reason. I dont want this. let me try to construct a scenario 1. HA has a binding for MN pointing to CoA1. 2. MN sends a binding update to the HA with CoA2. 3. BU fails for some reason and is not accepted. a) CoA2 is a valid address (a global unicast address). the HA sends a binding ack to CoA2 and not CoA1. the BCE contents are not used. the routing header contains the HoA. b) CoA2 is not a valid address (a non-global unicast address). HA does not send a binding ack. does this sound ok? regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 8 13:16: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 NAA20113 for ; Thu, 8 Aug 2002 13:16:25 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA02367; Thu, 8 Aug 2002 11:17:08 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28477; Thu, 8 Aug 2002 10:17:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78HG53U021360 for ; Thu, 8 Aug 2002 10:16:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g78HG5cH021359 for mobile-ip-dist; Thu, 8 Aug 2002 10:16: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.5+Sun/8.12.5) with ESMTP id g78HFx3U021352 for ; Thu, 8 Aug 2002 10:15:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10811 for ; Thu, 8 Aug 2002 10:16:07 -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 LAA13957 for ; Thu, 8 Aug 2002 11:16:04 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA29122; Thu, 8 Aug 2002 10:16:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g78HG2K20129; Thu, 8 Aug 2002 10:16:02 -0700 X-mProtect: <200208081716> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd3RxDhk; Thu, 08 Aug 2002 10:16:00 PDT Message-ID: <3D52A750.4A2F8155@iprg.nokia.com> Date: Thu, 08 Aug 2002 10:16:00 -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: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Reflection attack using bogus BU? References: <3D4F9389.1000101@kolumbus.fi> <3D500528.D7252192@iprg.nokia.com> <3D50ED6F.6030405@kolumbus.fi> <3D515936.FE4F2C8B@iprg.nokia.com> <3D52176D.2090200@kolumbus.fi> <3D525195.7010807@piuha. 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: > > >> this wont go anywhere. the MN is not at home. the HA should not > >> send a Binding Ack, in case it cant be sent to the MN's current CoA. > > And I wrote: > > > But I guess the main question here is if we *need* to do anything > > else than to drop the ack if the source is weird? I'd be very happy > > if we didn't need to do anything else. > > After some thinking, we do need to handle at least the case where > the source address is link-local (when the MN is returning home). okay. anyway, if a BU was received with link local address as the source address the HA can assume it is from the same link. if the MN sends a BU from a visited link with the source address set to link local, the packet should have never been forwarded by the router serving the MN in the visited link. > Also, I'm not sure the rule about the current CoA is sufficient > either. Say, the MN has moved and can no longer use the previous > coa. Then, it sends a BU but for some reason with a wrong sequence > number. The BA will give an error about this, and the MN must be > able to read this error before the situation can be corrected. So > it would seem that we must be able to send the BA to the source of > the BU rather than the currently registered coa? right. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 8 13: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 NAA20616 for ; Thu, 8 Aug 2002 13:34: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 LAA13700; Thu, 8 Aug 2002 11:35:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03730; Thu, 8 Aug 2002 10:34:59 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78HXc3U021725 for ; Thu, 8 Aug 2002 10:33:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g78HXcbb021724 for mobile-ip-dist; Thu, 8 Aug 2002 10:33:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78HXW3U021717 for ; Thu, 8 Aug 2002 10:33:32 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19089 for ; Thu, 8 Aug 2002 10:33:40 -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 LAA12797 for ; Thu, 8 Aug 2002 11:33:39 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA00431; Thu, 8 Aug 2002 10:33:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g78HXcO14968; Thu, 8 Aug 2002 10:33:38 -0700 X-mProtect: <200208081733> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpds9bkbi; Thu, 08 Aug 2002 10:33:36 PDT Message-ID: <3D52AB70.BFB06F81@iprg.nokia.com> Date: Thu, 08 Aug 2002 10:33: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@piuha.net, Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Reflection attack using bogus BU? References: <3D4F9389.1000101@kolumbus.fi> <3D500528.D7252192@iprg.nokia.com> <3D50ED6F.6030405@kolumbus.fi> <3D515936.FE4F2C8B@iprg.nokia.com> <3D52176D.2090200@kolumbus.fi> <3D525195.7010807@piuha. 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: > > Jari Arkko wrote: > > > > Vijay Devarapalli wrote: > > > > >> this wont go anywhere. the MN is not at home. the HA should not > > >> send a Binding Ack, in case it cant be sent to the MN's current CoA. > > > > And I wrote: > > > > > But I guess the main question here is if we *need* to do anything > > > else than to drop the ack if the source is weird? I'd be very happy > > > if we didn't need to do anything else. > > > > After some thinking, we do need to handle at least the case where > > the source address is link-local (when the MN is returning home). > > okay. anyway, if a BU was received with link local address as > the source address the HA can assume it is from the same link. > if the MN sends a BU from a visited link with the source address > set to link local, the packet should have never been forwarded > by the router serving the MN in the visited link. one more thing. there is no need for the MN to send a BU using link local address. it is possible with the current draft 18 for the MN to send a BU with its home address as the source after it comes home. and it works. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 8 16:43: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 QAA26327 for ; Thu, 8 Aug 2002 16:43:46 -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 OAA12489; Thu, 8 Aug 2002 14:44:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13992; Thu, 8 Aug 2002 13:44:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78Kh23U022228 for ; Thu, 8 Aug 2002 13:43:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g78Kh2ob022227 for mobile-ip-dist; Thu, 8 Aug 2002 13:43:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78Kgu3U022220 for ; Thu, 8 Aug 2002 13:42:56 -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 NAA08430 for ; Thu, 8 Aug 2002 13:43:06 -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 NAA11845 for ; Thu, 8 Aug 2002 13:43:05 -0700 (PDT) Received: by megisto-sql1.megisto.com with Internet Mail Service (5.5.2653.19) id ; Thu, 8 Aug 2002 16:36:57 -0400 Message-ID: From: Phil Roberts To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Mobile IP Working Group Cochairman Date: Thu, 8 Aug 2002 16:36:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi folks, We'd like to announce that we've added Gabriel Montenegro as a third cochair for the Mobile IP Working Group. We are pleased to welcome him into this role. The three of us are coordinating our efforts and there should be no noticeable interruption of WG activities. Gabriel's contact info is gab@sun.com. Some of you may know that I've taken the job of chairing the nominations committe for the upcoming year. (By the way, pariticipating in the nominating process is a valuable and rewarding activity and you can volunteer to be a committe member by sending an email to me. The committee members will be chosen at random from the folks who volunteer. You can read more about it at: http://www.ietf.org/nomcom/index.html). Gabriel's help with the Mobile IP working group will free up cycles for me for that activity. Thanks, Phil From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 8 18:49:50 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29821 for ; Thu, 8 Aug 2002 18:49:50 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19994; Thu, 8 Aug 2002 16:50: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 PAA27977; Thu, 8 Aug 2002 15:50:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78Mn63U022624 for ; Thu, 8 Aug 2002 15:49:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g78Mn53T022623 for mobile-ip-dist; Thu, 8 Aug 2002 15:49:05 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g78Mn33U022616 for ; Thu, 8 Aug 2002 15:49:03 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA12691 for ; Thu, 8 Aug 2002 18:49:12 -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 g78MnMXA002532 for ; Thu, 8 Aug 2002 18:49:22 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g78MnMZL002531 for mobile-ip@sunroof.eng.sun.com; Thu, 8 Aug 2002 18:49:22 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g77JCF3U016806 for ; Wed, 7 Aug 2002 12:12:15 -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 MAA21072 for ; Wed, 7 Aug 2002 12:12:25 -0700 (PDT) Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01776 for ; Wed, 7 Aug 2002 12:12:24 -0700 (PDT) Received: from ece2.ece.arizona.edu (ece2 [128.196.28.165]) by tiquini.ece.arizona.edu (8.12.5/8.12.5) with ESMTP id g77JCOts006901 for ; Wed, 7 Aug 2002 12:12:24 -0700 (MST) Received: (from confs@localhost) by ece2.ece.arizona.edu (8.11.6+Sun/8.10.2) id g77JCMC18139 for mobile-ip@sunroof.eng.sun.com; Wed, 7 Aug 2002 12:12:23 -0700 (MST) Date: Wed, 7 Aug 2002 12:12:23 -0700 (MST) From: "Marwan M. Krunz" Message-Id: <200208071912.g77JCMC18139@ece2.ece.arizona.edu> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MOBICOM 2002 - Call For Participation Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: [Many appologies if you receive duplicates of this message] ======================================= C A L L for P A R T I C I P A T I O N ======================================= *** ACM MobiCom 2002 *** The Eighth ACM International Conference on Mobile Computing and Networking September 23-28, 2002 Westin Peachtree Plaza, Atlanta, Georgia, USA Sponsored by ACM SIGMOBILE ----------------------------------------------------------------------- MobiCom has grown in prestige since its inception in 1995 to become the leading technical meeting to learn about the latest and most exciting developments in mobile networking and computing. This year's conference includes 26 outstanding technical papers, 8 informative tutorials, two very interesting panels, an exceptional student poster session, and 6 full-day workshops that reflect important new research directions, including new workshops on sensor networks and wireless security. As the global interest in mobile and wireless research and development surges, come join the debate on the future of mobile and wireless communication networks. Please find below information concerning registration, hotel accommodation, and a summary of the MobiCom 2002 program. We look forward to hosting you in Atlanta! Ian F. Akyildiz MobiCom 2002 General Chair ---------------------------------------------------------------------- FULL TECHNICAL PROGRAM: nhttp://www.acm.org/sigmobile/mobicom/2002/ SECURE ONLINE REGISTRATION: Early Registration cut-off ** August 22, 2002** http://www.regmaster.com/mobicom2002.html CONFERENCE HOTEL/VENUE: Hotel Registration cut-off **August 31, 2002** http://www.acm.org/sigmobile/mobicom/2002/hotelinfo/ CONFERENCE PROGRAM SUMMARY: --------------------------- + 8 tutorials, September 23-24, 2002: Mobile IPv6 Charles E. Perkins, Nokia Research Center Wireless Sensor Networks Deborah Estrin, University of California, Los Angeles Akbar Sayeed, University of Wisconsin-Madison Mani Srivastava, University of California, Los Angeles M-Commerce - Issues, Applications and Technologies Upkar Varshney, Georgia State University Mobile Computing Middleware Cecilia Mascolo, University College London Wireless IP Multimedia Henning Schulzrinne, Columbia University QoS Enhancements for Wireless Packet Networks Mike Tzamaloukas, Skymoon Ventures Wireless Data Network and Systems H. Anthony Chan, San Jose State University Mobile Ad Hoc Networking Elizabeth Belding-Royer, UC Santa Barbara, Sung-Ju Lee, HP Laboratories + 26 technical papers (September 25-27, 2002) covering sessions on: Security, media access control, transport layer issues, WLANs, sensor networks, energy efficient systems, wireless QOS, systems issues, and future research challenges. + 2 panels "Evolution of Mobile and Wireless Networks: Enablers and Inhibitors" Organizer and Moderator: Tom LaPorta, Lucent Technologies "Home Networks - Wired or Wireless?" Organizer and Moderator: Marie-Jose Montpetit, MJMontpetit.com + a student poster session (new to MobiCom) + a DEMO session of mobile and wireless kit + 6 one day ACM workshops, September 28, 2002: Workshop on Wireless Sensor Networks and Applications (WSNA 2002) Workshop on Wireless Security (WiSe) Workshop on Wireless Mobile Multimedia (WoWMoM 2002) Workshop on Discrete Algorithms and Methods for Mobile Computing and Communications (Dial M for Mobility 2002) Workshop on Modeling Analysis and Simulation of Wireless and Mobile Systems (MSWiM 2002) Workshop on Mobile Commerce From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 9 07:00:08 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22231 for ; Fri, 9 Aug 2002 07:00: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 FAA20864; Fri, 9 Aug 2002 05:00:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA28163; Fri, 9 Aug 2002 04:00:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79AxU3U024078 for ; Fri, 9 Aug 2002 03:59:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79AxUIU024077 for mobile-ip-dist; Fri, 9 Aug 2002 03:59:30 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79AxO3U024070 for ; Fri, 9 Aug 2002 03:59: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 DAA12389 for ; Fri, 9 Aug 2002 03:59:32 -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 DAA23812 for ; Fri, 9 Aug 2002 03:59:32 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id F3BAE6A905; Fri, 9 Aug 2002 13:59:30 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7BE5F6A901; Fri, 9 Aug 2002 13:59:25 +0300 (EEST) Message-ID: <3D53A113.3090506@kolumbus.fi> Date: Fri, 09 Aug 2002 14:01:39 +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: Erik Nordmark , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Reflection attack using bogus BU? References: <3D4F9389.1000101@kolumbus.fi> <3D500528.D7252192@iprg.nokia.com> <3D50ED6F.6030405@kolumbus.fi> <3D515936.FE4F2C8B@iprg.nokia.com> <3D52176D.2090200@kolumbus.fi> <3D52A60F.8E6E88C8@iprg.nokia.com> 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.31 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: > 1. HA has a binding for MN pointing to CoA1. > > 2. MN sends a binding update to the HA with CoA2. > > 3. BU fails for some reason and is not accepted. > > a) CoA2 is a valid address (a global unicast address). > the HA sends a binding ack to CoA2 and not CoA1. the > BCE contents are not used. the routing header contains > the HoA. > > b) CoA2 is not a valid address (a non-global unicast > address). HA does not send a binding ack. > > does this sound ok? Yes. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 9 08:29: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 IAA24710 for ; Fri, 9 Aug 2002 08:29:39 -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 GAA28128; Fri, 9 Aug 2002 06:30: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 FAA26733; Fri, 9 Aug 2002 05:30:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79CTE3U024548 for ; Fri, 9 Aug 2002 05:29:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79CTEwI024546 for mobile-ip-dist; Fri, 9 Aug 2002 05:29: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79CT43U024525 for ; Fri, 9 Aug 2002 05:29:04 -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 g79CTBg07228; Fri, 9 Aug 2002 14:29:11 +0200 (MEST) Date: Fri, 9 Aug 2002 14:27:12 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] CN to MN (Sending Binding Acknowledgement) To: Vrizlynn Thing Cc: Jari Arkko , Vrizlynn Thing , Mobile IP Mailing List In-Reply-To: "Your message with ID" <002101c23e7e$84b3ea20$c289a8c0@vsys> 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: > Case 3: BU not accepted > src = CoA / HoA / other addresses > dest = CN > > BAck sent with src = CN, dest = HoA > If src in BU is not HoA but legal RH address, then BAck dest = this src > address (no RH2 in this case since binding not accepted) The safe thing to do (to avoid using this for reflection attacks) in this case is to send the BAck with a destination which is the source of the BU. Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 9 08:33: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 IAA24973 for ; Fri, 9 Aug 2002 08:33: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 FAA01590; Fri, 9 Aug 2002 05:32: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 FAA27325; Fri, 9 Aug 2002 05:32:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79CVw3U024647 for ; Fri, 9 Aug 2002 05:31:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79CVwg2024646 for mobile-ip-dist; Fri, 9 Aug 2002 05:31: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 bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79CVp3U024633 for ; Fri, 9 Aug 2002 05:31:52 -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 g79CVwg07773; Fri, 9 Aug 2002 14:31:58 +0200 (MEST) Date: Fri, 9 Aug 2002 14:30:00 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [mobile-ip] CN to MN (Sending Binding Acknowledgement) To: Jari Arkko Cc: Vrizlynn Thing , Vrizlynn Thing , Mobile IP Mailing List In-Reply-To: "Your message with ID" <3D5251EC.7070602@kolumbus.fi> 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: > So: > > BAck sent with src=CN, dest=bu src, RH2=hoa > > I think this applies to both cases 2 and 3. The real differentiator is > is (1) whether bu src is equal to home address or not, and then if > not (2) whether the bu src is a suitable address or not. While this packet doesn't cause reflection attacks in case 3 (since it is delivered to the bu src) it seems a bit odd to have the RH2 there. Doesn't cause harm as far as I can tell mbut it looks odd... Erik From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 9 08:45:27 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25408 for ; Fri, 9 Aug 2002 08:45:27 -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 GAA15473; Fri, 9 Aug 2002 06:46: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 FAA07722; Fri, 9 Aug 2002 05:46:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79CjD3U024955 for ; Fri, 9 Aug 2002 05:45:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79CjD2E024954 for mobile-ip-dist; Fri, 9 Aug 2002 05:45: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.5+Sun/8.12.5) with ESMTP id g79Cj73U024947 for ; Fri, 9 Aug 2002 05:45:07 -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 FAA07640 for ; Fri, 9 Aug 2002 05:45:16 -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 GAA04433 for ; Fri, 9 Aug 2002 06:45:15 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 9C4A46A905; Fri, 9 Aug 2002 15:45:09 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 496466A901; Fri, 9 Aug 2002 15:45:04 +0300 (EEST) Message-ID: <3D53B9D5.5000601@kolumbus.fi> Date: Fri, 09 Aug 2002 15:47:17 +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: Vrizlynn Thing , Vrizlynn Thing , Mobile IP Mailing List Subject: Re: [mobile-ip] CN to MN (Sending Binding Acknowledgement) 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=none version=2.31 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: >> BAck sent with src=CN, dest=bu src, RH2=hoa >> >>I think this applies to both cases 2 and 3. The real differentiator is >>is (1) whether bu src is equal to home address or not, and then if >>not (2) whether the bu src is a suitable address or not. > > While this packet doesn't cause reflection attacks in case 3 > (since it is delivered to the bu src) it seems a bit odd to have > the RH2 there. Doesn't cause harm as far as I can tell mbut it looks odd... The rules that I'm proposing (see bottom of [1]) sends the BA always to the BU src (and drops it if the src is unsuitable). RH2 goes to the packet when the src is not the home address. Are you saying that you'd like RH2 to be included only if (a) the BU src is not the home address AND (b) the BU has been successful? Jari [1] http://www.piuha.net/~jarkko/publications/mipv6/issues/issue95.txt From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 9 10:54: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 KAA28938 for ; Fri, 9 Aug 2002 10:54: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 IAA21784; Fri, 9 Aug 2002 08:55:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02123; Fri, 9 Aug 2002 07:55:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Esd3U026086 for ; Fri, 9 Aug 2002 07:54:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79EsdWa026085 for mobile-ip-dist; Fri, 9 Aug 2002 07:54:39 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79EsX3U026078 for ; Fri, 9 Aug 2002 07:54:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24092 for ; Fri, 9 Aug 2002 07:54: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 HAA12962 for ; Fri, 9 Aug 2002 07:54:40 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 40AF26A905; Fri, 9 Aug 2002 17:54:38 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6921A6A901; Fri, 9 Aug 2002 17:54:32 +0300 (EEST) Message-ID: <3D53D82E.7070201@piuha.net> Date: Fri, 09 Aug 2002 17:56:46 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: Vijay Devarapalli , Michael Thomas , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] R (router) bit in BUs References: <200207271546.g6RFk96o006133@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=5.0 tests=none version=2.31 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: > However, I have some doubts about this still. But let me first > describe the alternatives we have: > > 1. No R-bit in base spec. > > => do you mean "R-bit in base spec". Yes. Sorry for the confusion. > 2. R-Bit in an draft-kniveton-mobrtr-02.txt > 3. No R-bit, ever. > > I think no one is arguing for #3 so we can only consider #1 and > #2. But what is their difference? One concern is that if the base > spec does not define this, then it becomes impossible to extend this > functionality later. This is obviously not an issue, as there is > reserved space in the BUs that can be used. > > => I can't see a real difference between a reversed dedicated space > and #1. So #1 is simpler for the future. Yeah, well... the only real difference is that in #1 we have some text in the base RFC while in #2 we don't. The behaviour is really the same in any case. > Another possible concern is that when base-only HA implementations > are deployed, it becomes impossible to deploy mobile routers as the > existing HAs do not support them. > > => don't forget that in IPv6 a node is either a host or a router > (exclusive "or"). > > Presumably, > we are talking a case where a mobile host is a router at the same time. > > => s/host/node/ ! > > In conclusion, my suggestion is that we should define the R bit in > draft-kniveton and keep the base spec from increasing in length once > more... > > => as you still have to reserve the bit I don't buy this argument. The reservation is for a _set_ of bits that can be used for a number of potential future things. This debate is turning to one a rather philosophical one. Do we describe the bit now in the base spec but leave it's main use to be described later? Or do we put everything in the later, complete spec for mobile routers? We are not going to break anything either way. My preference is to keep related functionality described in one place (the complete mobile router spec), and to strip the base RFC of features that aren't operational until some further developments occur. But looking at this thread, many people seem to be OK with putting the R bit back in. I'm OK with that as well. Could you Francis propose the text that is needed? Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 9 11:41:44 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00666 for ; Fri, 9 Aug 2002 11:41:43 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07657; Fri, 9 Aug 2002 09:42: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 IAA06231; Fri, 9 Aug 2002 08:42:26 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79FfF3U026662 for ; Fri, 9 Aug 2002 08:41:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79FfF1W026661 for mobile-ip-dist; Fri, 9 Aug 2002 08:41:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Ff83U026654 for ; Fri, 9 Aug 2002 08:41:09 -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 IAA07980 for ; Fri, 9 Aug 2002 08:41:18 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10122 for ; Fri, 9 Aug 2002 08:41:17 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g79FfU619159; Fri, 9 Aug 2002 10:41:30 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 9 Aug 2002 10:41:15 -0500 Message-ID: <6B49EDFE974BD51197D70002A56079D803ECF343@zrc2c013.us.nortel.com> From: "Ahmad Muhanna" To: "'mobile-ip'" Cc: "'Charlie Perkins'" Subject: [mobile-ip] A Race condition which may cause denial of service if network con dition persist Date: Fri, 9 Aug 2002 10:41:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23FBB.307DF2F0" 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_01C23FBB.307DF2F0 Content-Type: text/plain; charset="iso-8859-1" Hello Charlie, This is a race condition where the FA and the MN does everything according to the standard BUT still this scenario may cause a denial of service for many Mobile Nodes when the network "probably" is handling a heavy traffic or more explicitly when it takes about a second for the FA to receive the RRP from the HA for any DYNAMIC BASIC/Reverse Tunnel Mobile IP call. Background: According to the standard (RFC3220) Mobile Node can not send RRQ messages with less than one second interval. In other words, Mobile Node must wait at least one second before retrying to register with the same FA. Now as we know that Air time (Wireless) is the most precious thing for carriers, Carriers MAY very well configure their Mobile Nodes with a retry timer of "1 second". Details: MN PDSN HA ------ ----------- ----- <<<<<======= Agent Adv. FAC=C1 ==== (1) (2)===== RRQ ============>>>>>>>>> Home Address = 0.0.0.0 ID = ID1 FAC = C1 (3)===== RRQ ============>>>>>>> Home Address = 0.0.0.0 ID = ID1 FAC = C1 <<<<<<===== RRP ========== (4) Home Address = a.b.c.d. ID = ID1 FAC = C1 <<<<<<===== RRP ===============(5.1) {Mobile Node is REGISTERED with Home Address = a.b.c.d.} Home Address = a.b.c.d. ID = ID1 FAC = C2 (5.2)===== RRQ Retransmission ====>>>>> {Since Mobile Node is Registered C1 is Used Challenge} Home Address = 0.0.0.0 ID (timestamp) = ID2 FAC = C1 ** Mobile Node ignores the RRP(5.1) since it already sent a retransmission RRQ with ID2. <<<<<<== RRP (code=106 Stale Challenge) ==(6) Home Address = a.b.c.d. ID = ID2 FAC = C3 (7)===== Agent Solicitation Msg ====>>>>> <<<<<======= Agent Adv. FAC=C4 ==== (8) (9)===== RRQ ============>>>>>>>>> {C4 is not USED BUT Mobile Node is Registered with Home Address = a.b.c.d. NOT 0.0.0.0} Home Address = 0.0.0.0 ID = ID3 FAC = C4 <<<= RRP(code=99 Home Address missing)==(10) Home Address = a.b.c.d. ID = ID3 FAC = C5 This scenario continues and eventually MN takes down the call after exhausting all retries. There is a big possibility, if the network condition persists, MN will not get service. Although this is a race condition but it is very possible and may cause a denial of service to some Mobile Nodes for some time. Charlie, Your comments is greatly appreciated. Regards; Ahmad Muhanna ------_=_NextPart_001_01C23FBB.307DF2F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A Race condition which may cause denial of service if network = condition persist

Hello Charlie,

This is a race condition where the FA and the MN does = everything according to the standard
BUT still this scenario may cause a denial of = service for many Mobile Nodes when the network
"probably" is handling a heavy traffic or = more explicitly when it takes about a second
for the FA to receive the RRP from the HA for any = DYNAMIC BASIC/Reverse Tunnel Mobile IP call.

Background:
According to the standard (RFC3220) Mobile Node can = not send RRQ messages with less than one second interval.
In other words, Mobile Node must wait at least one = second before retrying to register with the same FA.
Now as we know that Air time (Wireless) is the most = precious thing for carriers, Carriers MAY very well configure
their Mobile Nodes with a retry timer of "1 = second".


Details:

MN      =         =         =         =         PDSN    =         =         =         =         =         HA
------  =         =         =         =         = -----------     =         =         =         =         =         -----

<<<<<=3D=3D=3D=3D=3D=3D=3D  Agent = Adv. FAC=3DC1  =3D=3D=3D=3D (1)

(2)=3D=3D=3D=3D=3D RRQ    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>>>>=
        =         Home = Address  =3D 0.0.0.0
        =         ID      =         =3D ID1
        =         FAC     =         =3D C1
        =         =         =         =                (3)=3D=3D=3D=3D=3D RRQ =     = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>>
        =         =         =         =         =         =         Home = Address  =3D 0.0.0.0
        =         =         =         =         =         =         ID      =         =3D ID1
        =         =         =         =         =         =         FAC     =         =3D C1

        =         =         =         =                 = <<<<<<=3D=3D=3D=3D=3D RRP =         = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  (4)
        =         =         =         =         =         =         Home = Address  =3D a.b.c.d.
        =         =         =         =         =         =         ID      =         =3D ID1
        =         =         =         =         =         =         FAC     =         =3D C1

   <<<<<<=3D=3D=3D=3D=3D = RRP      = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D(5.1)    = {Mobile Node is REGISTERED with Home Address =3D a.b.c.d.}
        =         Home = Address  =3D a.b.c.d.
        =         ID      =         =3D ID1
        =         FAC     =         =3D C2

(5.2)=3D=3D=3D=3D=3D RRQ Retransmission = =3D=3D=3D=3D>>>>>    =              = {Since Mobile Node is Registered C1 is Used Challenge}
        =         Home = Address  =3D 0.0.0.0
        =         ID = (timestamp)  =3D ID2
        =         FAC     =         =3D C1

** Mobile Node ignores the RRP(5.1) since it already = sent a retransmission RRQ with ID2.

   <<<<<<=3D=3D RRP = (code=3D106 Stale Challenge) =3D=3D(6)
        =         Home = Address  =3D a.b.c.d.
        =         ID      =         =3D ID2
        =         FAC     =         =3D C3

(7)=3D=3D=3D=3D=3D Agent Solicitation Msg = =3D=3D=3D=3D>>>>>   

<<<<<=3D=3D=3D=3D=3D=3D=3D  Agent = Adv. FAC=3DC4  =3D=3D=3D=3D (8)

(9)=3D=3D=3D=3D=3D RRQ    = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>>>>>>>>>=            {C4 is not USED = BUT Mobile Node is Registered with Home Address =3D a.b.c.d. NOT = 0.0.0.0}

        =         Home = Address  =3D 0.0.0.0
        =         ID      =         =3D ID3
        =         FAC     =         =3D C4

 <<<=3D RRP(code=3D99 Home Address = missing)=3D=3D(10)
        =         Home = Address  =3D a.b.c.d.
        =         ID      =         =3D ID3
        =         FAC     =         =3D C5

This scenario continues and eventually MN takes down = the call after exhausting all retries.
There is a big possibility, if the network condition = persists, MN will not get service.

Although this is a race condition but it is very = possible and may cause a denial of service to
some Mobile Nodes for some time.

Charlie,
Your comments is greatly appreciated.

Regards;
Ahmad Muhanna

------_=_NextPart_001_01C23FBB.307DF2F0-- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 9 11:54:53 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01068 for ; Fri, 9 Aug 2002 11:54:52 -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 IAA12016; Fri, 9 Aug 2002 08:54:02 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12592; Fri, 9 Aug 2002 08:54:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Fqo3U026866 for ; Fri, 9 Aug 2002 08:52:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79FqonL026865 for mobile-ip-dist; Fri, 9 Aug 2002 08:52:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79Fqh3U026858 for ; Fri, 9 Aug 2002 08:52: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 IAA09351 for ; Fri, 9 Aug 2002 08:52:52 -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 IAA17159 for ; Fri, 9 Aug 2002 08:52:51 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00949; Fri, 9 Aug 2002 11:51:35 -0400 (EDT) Message-Id: <200208091551.LAA00949@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-montavont-mobileip-mmi-00.txt Date: Fri, 09 Aug 2002 11:51: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. Title : MIPv6 for Multiple Interfaces Author(s) : N. Montavont, T. Noel, M. Kassi-Lahlou Filename : draft-montavont-mobileip-mmi-00.txt Pages : 10 Date : 24-Jul-02 MIPv6 [MIPv6] allows a MN to maintain its IPv6 communications while moving between subnets. This document presents the problematic for a MN of having multiple network interfaces. It discusses how to perform vertical handovers (flow redirection between interfaces) and propose MMI (MIPv6 for Multiple Interfaces) which describes the use of MIPv6 to support multiple interfaces. These extensions focus on the MN ability to use a backup interface for communications and to redirect flows between its own interfaces. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-montavont-mobileip-mmi-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-montavont-mobileip-mmi-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-montavont-mobileip-mmi-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: <20020809120319.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-montavont-mobileip-mmi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-montavont-mobileip-mmi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020809120319.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 9 14:33: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 OAA06572 for ; Fri, 9 Aug 2002 14:33:20 -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 MAA04968; Fri, 9 Aug 2002 12:34: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 LAA16427; Fri, 9 Aug 2002 11:34:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79IWr3U027563 for ; Fri, 9 Aug 2002 11:32:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g79IWr9P027562 for mobile-ip-dist; Fri, 9 Aug 2002 11:32: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 jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g79IWl3U027555 for ; Fri, 9 Aug 2002 11:32:47 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.5+Sun/8.12.5) with SMTP id g79IWvmG693229; Fri, 9 Aug 2002 11:32:57 -0700 (PDT) Message-Id: <200208091832.g79IWvmG693229@jurassic.eng.sun.com> Date: Fri, 9 Aug 2002 11:35:36 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: [mobile-ip] MIPv6 Draft 18 Comments To: jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DN1TSpzvmqt4Ik+xRti7DA== 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: Better late than never :-) Draft 18 is more organized than draft 17. Thanks for adding sections on node requirements for supporting RO to make things clear. The following are my comments (some of them may be already mentioned by the previous reviewers): 1. Section 4. Basic Operation It's good add a subsection at the end to describe the two modes of operation for clarity : 1) MN-CN communication through reverse tunnel via HA 2) MN-CN communication using Route Optimization In this section, we can specify that RR procedure is the default RO mechanism defined in this draft. 2. Since, lifetime field has been changed to 16 bit, s/0xffffffff/0xffff 3. section 6.1.7 (BU) Now that we removed home-address field from the BU message and made HAO manadatory for all BUs for which src-addr is not home-addr. A line after the following paragraph is needed: A Binding Update to the home agent MUST include the Home Address destination option if the Source Address field in the IPv6 header is not the home address of the mobile node. i,e. A binding Update to the Correspondent node MUST include home address option (section 9.4.1) . 3. section 6.1.8 indicates that we don't have "no Security Association" status code anymore and we have: 137 Invalid authenticator That suggests Binding Authorization Data Option is manadatory for all binding update messages--correct ? If that is the case, then that must be specified in 6.1.7 as well. Otherwise, we need another status error code or specification when the HA or CN receives a BU without binding authorization data option. 4. 6.1.9 Status code 1: 1 Home Address destination option used without a binding Is this still valid ? 5. section 8.2 Route Optimization Requirements for All IPv6 Nodes It's missing the MN behavior, How about adding a text something like this? A node that is performing mobile node operation MUST be able to process RTHDR_TYPE2 extension header (section 11.2.3 and 6.4). All other nodes MUST ignore and drop RTHDR_TYPE2 extensions. 6. section 8.4 One more requirement to be added: - Every home agent MUST support IPSec ESP for protection of packets belonging to Return Routability Procedure (section 10.7). 7. section 8.5 Additional requirement: -MUST be able to process RTHDR_TYPE2 extension header as defined in 6.4 and 11.2.3 8. section 9.2.2 , section 9.4.6 needs update as they specify that HAO without binding asociation MUST be dropped. 9. section 10.3 remove: - The Refresh field MUST be set to zero. 10. section 9.4.1 s/144/138 s/145/139 s/141/135 Perhaps there are more cases throughout the document. 11. section 10. Home Agent Operation Should not we have a section here on "Processing Binding Updates" ? -Samita From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 9 23:49:22 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19639 for ; Fri, 9 Aug 2002 23:49:22 -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 VAA22826; Fri, 9 Aug 2002 21:50: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 UAA15437; Fri, 9 Aug 2002 20:50:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7A3n63U028686 for ; Fri, 9 Aug 2002 20:49:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7A3n6W7028685 for mobile-ip-dist; Fri, 9 Aug 2002 20: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7A3n13U028678 for ; Fri, 9 Aug 2002 20:49:01 -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 UAA07079 for ; Fri, 9 Aug 2002 20:49:11 -0700 (PDT) From: vriz@lit.a-star.edu.sg Received: from lit.a-star.edu.sg (rodin.krdl.org.sg [192.122.139.27]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA05534 for ; Fri, 9 Aug 2002 20:49:10 -0700 (PDT) Received: from mailhost1 (localhost [127.0.0.1]) by lit.a-star.edu.sg (8.11.1/8.11.1) with ESMTP id g7A3lmd09933 for ; Sat, 10 Aug 2002 11:47:48 +0800 (SGT) Received: from lit.org.sg (localhost [127.0.0.1]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 HotFix 0.5 (built Jun 7 2002)) with ESMTP id <0H0L00E70ZZGYH@mailhost.lit.org.sg> for mobile-ip@sunroof.eng.sun.com; Sat, 10 Aug 2002 11:50:12 +0800 (SGT) Received: from [192.122.139.152] by mailhost.lit.org.sg (mshttpd); Sat, 10 Aug 2002 11:50:04 +0800 Date: Sat, 10 Aug 2002 11:50:04 +0800 Subject: Re: [mobile-ip] CN to MN (Sending Binding Acknowledgement) To: Jari Arkko Cc: Mobile IP Mailing List Message-id: <351713a06f.3a06f35171@lit.org.sg> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 0.5 (built Jun 7 2002) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline 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 > > Case 2: BU accepted for deletion (lifetime == 0) > > src = HoA > > dest = CN > > > > BAck sent with src = CN, dest = HoA > > If src in BU is not HoA but legal RH address, then BAck dest = > this src > > address, RH2 = HoA > > > > > > Case 3: BU not accepted > > src = CoA / HoA / other addresses > > dest = CN > > > > BAck sent with src = CN, dest = HoA > > If src in BU is not HoA but legal RH address, then BAck dest = > this src > > address (no RH2 in this case since binding not accepted) > > > No. Per issue #92 CNs will not respond to HoA if the src is > unsuitable. That means checking of whether the src address is legal for routing purpose, is compulsory no matter whether if it's (src address's) a HoA or not? > So: > > BAck sent with src=CN, dest=bu src, RH2=hoa > > I think this applies to both cases 2 and 3. The real > differentiator is > is (1) whether bu src is equal to home address or not, and then if > not (2) whether the bu src is a suitable address or not. > > The acknowledgement is sent to the Source Address of the IPv6 > header that carried the Binding Update. Note that this procedure is > independent from the treatment of regular packets and does not use > information from the Binding Cache. > > If the Source Address field does not contain a global unicast > address, the Binding Acknowledgement MUST NOT be sent. > > If the address is a global unicast address, further processing > depends on whether this address is the home address of the > mobile node > or not. If the Binding Update does not contain a Home Address > destination option, then the source address is the home address > of the mobile > node. If so, the Binding Acknowledgement MUST be sent directly > to this address. > Otherwise, the Binding Acknowledgement MUST still be sent to > the source address, > but a Type 2 Routing Header MUST be added to the packet to > carry the > home address. > Therefore, binding cache information is not to be used when sending BAck. The src address must be checked if it's legal. Determination of whether RH2 is to be used only if the BU contains a dest opt for HoA. If there's no dest opt for HoA, then BAck is sent directly to the src address. As Erik pointed out, is it necessary to use RH2 if the BAck is to return a failure status code? Will there be any security loophole in this case? Regards, Vrizlynn Thing From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 13 14:57: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 OAA13719 for ; Tue, 13 Aug 2002 14:57:24 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17118; Tue, 13 Aug 2002 12: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 LAA13659; Tue, 13 Aug 2002 11:58:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DIv43U009194 for ; Tue, 13 Aug 2002 11:57:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DIv4DQ009193 for mobile-ip-dist; Tue, 13 Aug 2002 11:57: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.5+Sun/8.12.5) with ESMTP id g7DIuw3U009186 for ; Tue, 13 Aug 2002 11:56: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 LAA13262 for ; Tue, 13 Aug 2002 11:57:07 -0700 (PDT) Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01799 for ; Tue, 13 Aug 2002 11:57:07 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 4A2CD1D88 for ; Tue, 13 Aug 2002 11:57:07 -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 6D4FF21AA; Tue, 13 Aug 2002 13:57:06 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7DIv6x0001077453; Tue, 13 Aug 2002 14:57:06 -0400 (EDT) Message-ID: <3D595681.7050007@hp.com> Date: Tue, 13 Aug 2002 14:57:05 -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: MobilIP Subject: [mobile-ip] Question about MIPv6 draft 18 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 I have some questions about Section 5 (Security) in draft 18. 1. Multiple subsections use the symbol '|' in the cookie and key calculations. Does this symbol mean "concatinate" or "Logical OR"? (my guess is "Concatinate"). If my guess is correct, in what order are the bits concatinated (i.e cookie | none == ((cookie << 64) | nonce)? 2. Section 5.2.5 uses a function First64() in calculating home and care-of cookies. Which bits are assumed to be the first 64 bits? 3. There doesn't appear to be a section on processing and validating Binding Updates. Is it enought to make sure that authenticator matches, or should the entire HMAC match? (My guess it the entire HMAC). 4. Section 5.2.7 says the following: "Before sending a Binding Update, the mobile node has to wait for both the Home and Care-of Cookies to arrive. Due to resource limitations, rapid deletion of bindings, or reboots it can not be guaranteed that the cookies are still fresh and acceptable when the correspondent node uses them in the processing of the Binding Update. If the cookies have become too old, the correspondent node replies with an an error code in the Binding Acknowledgement. The mobile node can then retry the return routability procedure. However, it is recommended that correspondent nodes try to keep these cookies acceptable as long as possible and SHOULD NOT accept them beyond MAX_COOKIE_LIFE seconds." I find this paragraph highly confusing from the point of view of a correspondent node. This paragraph implies that the correspondent should timeout and therefore cache cookies, but the whole assumption behind RR is that correspondent doesn't keep state per mobile node until BU had happened. So, in effect, the corresondent times out nonces every MAX_COOKIE_LIFE seconds. Is my understanding correct? Depending on the replies to the above, I might have more questions, but I'll hold them for now. Thanks -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 Tue Aug 13 16:40:22 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18449 for ; Tue, 13 Aug 2002 16:40:22 -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 LAA07773; Tue, 13 Aug 2002 11:05:47 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA18490; Tue, 13 Aug 2002 10:05:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7DH4Q3U008854 for ; Tue, 13 Aug 2002 10:04:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7DH4Qtd008853 for mobile-ip-dist; Tue, 13 Aug 2002 10:04: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.5+Sun/8.12.5) with ESMTP id g7DH4K3U008846 for ; Tue, 13 Aug 2002 10:04: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 KAA17837 for ; Tue, 13 Aug 2002 10:04:30 -0700 (PDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04935 for ; Tue, 13 Aug 2002 10:04:30 -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 g7DH4T6I021857; Tue, 13 Aug 2002 10:04:29 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-133.cisco.com [128.107.163.133]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ADQ35161; Tue, 13 Aug 2002 10:00:20 -0700 (PDT) Message-ID: <3D593B1E.DDA92851@cisco.com> Date: Tue, 13 Aug 2002 10:00:14 -0700 From: Alpesh S Patel X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] [Fwd: List of Questions about "AAA Key Distribution Draft"] References: <3D4EE7D5.FE57408B@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Posting it again... Alpesh S Patel wrote: > Hi, > > We have been going over the AAA Key Distribution draft in > detail and have the following list of questions. Can someone > clarify them. > > 1. Section 3 (items 8, 9), indicates that unsoliciated key material > can be pushed to the MN. Is the intended purpose to generate > new keys at MN? The wording says that MN authenticates and > then if finds 'unsolicited key material', MN generates key. > > 2. Is the intention of this draft to also facilitate HA/FA key > distribution through AAA? If so, which entity initiates it? > Also, how to ensure that FA and HA reaches the same AAA server? > (The last question is critical if AAA server is Radius). > > 3. Where is the MF KeyRequest Extension located compared to MN-AAA > AE? If before MN-AAA AE, FA cannot remove this extension before > forwarding RRQ to HA. Section 3 (item 4) states this, but just > wanted to confirm. > > 4. Sections 6.1 and 6.3, what is included in subtype data? > > 5. Sections 6.2 and 6.4, what is included in subtype data? Is it > that this contains the extensions specified in section 8 and 9? > > 6. Why 6.4 has lifetime and not section 9 extension? > Why 6.2 does not have lifetime field and section 8 extension has? > Can you clarify this? > > 7. Can MN put multiple MN KeyRequestExtensions in same RRQ to > generate multiple keys? If not, then the solution would be to send > multiple RRQs. Can a statement in this regards put in the draft to > clarify this behavior. > > Suggestions: > ------------ > 1. Section 5, the formulae for calculating the key is missing to take > the AAA-key into account. It is described in the following > paragraph in that section. This needs to be corrected. > > 2. A paragraph explaining the role of SPI's (how they are setup) to be > unidirectional would help if it is spelled out clearly. > > Thanks > Alpesh From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 13 20:43: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 UAA27187 for ; Tue, 13 Aug 2002 20:43: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 SAA02016; Tue, 13 Aug 2002 18:43:52 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA08588; Tue, 13 Aug 2002 17:43:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E0gd3U010162 for ; Tue, 13 Aug 2002 17:42:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7E0gdUp010161 for mobile-ip-dist; Tue, 13 Aug 2002 17:42: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.5+Sun/8.12.5) with ESMTP id g7E0gX3U010154 for ; Tue, 13 Aug 2002 17:42:33 -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 RAA08379 for ; Tue, 13 Aug 2002 17:42:42 -0700 (PDT) From: hannu.flinck@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA19373 for ; Tue, 13 Aug 2002 17:42:42 -0700 (PDT) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7E0gcM24385 for ; Tue, 13 Aug 2002 19:42:43 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 13 Aug 2002 19:42:35 -0500 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 13 Aug 2002 19:41:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] Question about MIPv6 draft 18 Date: Tue, 13 Aug 2002 17:41:33 -0700 Message-ID: Thread-Topic: [mobile-ip] Question about MIPv6 draft 18 Thread-Index: AcJC/ARpAlRZs1oRTAyadJKsnWng1wALjJXg To: , X-OriginalArrivalTime: 14 Aug 2002 00:41:34.0441 (UTC) FILETIME=[5723BD90:01C2432B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7E0gY3U010155 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Vlad About your question 3 there is a section describing BU processing and validation in 9.4.1 "Receiving Binding Updates". So this should be covered. However under Home Agent Operation for shake of clarity I would like to propose some lines of description how a static SA is used to validate the MN-HA BUs. Current text that describes in 10.2 "Primary Care-of Address Registration" starts with an assumption that the BU is valid. But says nothing how the validation is done. Later in section 10.3 "Primary Care-of address De-Registration" the text finally refers to Section 9.4.1. However section 9.4.1 has been written Return Routability in mind that doesn't apply as such with the home agent that has IPsec SA. Regards Hannu -----Original Message----- From: ext Vladislav Yasevich [mailto:Vladislav.Yasevich@hp.com] Sent: 13 August, 2002 11:57 AM To: MobilIP Subject: [mobile-ip] Question about MIPv6 draft 18 Hi I have some questions about Section 5 (Security) in draft 18. 1. Multiple subsections use the symbol '|' in the cookie and key calculations. Does this symbol mean "concatinate" or "Logical OR"? (my guess is "Concatinate"). If my guess is correct, in what order are the bits concatinated (i.e cookie | none == ((cookie << 64) | nonce)? 2. Section 5.2.5 uses a function First64() in calculating home and care-of cookies. Which bits are assumed to be the first 64 bits? 3. There doesn't appear to be a section on processing and validating Binding Updates. Is it enought to make sure that authenticator matches, or should the entire HMAC match? (My guess it the entire HMAC). 4. Section 5.2.7 says the following: "Before sending a Binding Update, the mobile node has to wait for both the Home and Care-of Cookies to arrive. Due to resource limitations, rapid deletion of bindings, or reboots it can not be guaranteed that the cookies are still fresh and acceptable when the correspondent node uses them in the processing of the Binding Update. If the cookies have become too old, the correspondent node replies with an an error code in the Binding Acknowledgement. The mobile node can then retry the return routability procedure. However, it is recommended that correspondent nodes try to keep these cookies acceptable as long as possible and SHOULD NOT accept them beyond MAX_COOKIE_LIFE seconds." I find this paragraph highly confusing from the point of view of a correspondent node. This paragraph implies that the correspondent should timeout and therefore cache cookies, but the whole assumption behind RR is that correspondent doesn't keep state per mobile node until BU had happened. So, in effect, the corresondent times out nonces every MAX_COOKIE_LIFE seconds. Is my understanding correct? Depending on the replies to the above, I might have more questions, but I'll hold them for now. Thanks -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 Tue Aug 13 22:00: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 WAA29186 for ; Tue, 13 Aug 2002 22:00:05 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08248; Tue, 13 Aug 2002 18:59: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 SAA09161; Tue, 13 Aug 2002 18:59:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E1ve3U010382 for ; Tue, 13 Aug 2002 18:57:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7E1vekX010381 for mobile-ip-dist; Tue, 13 Aug 2002 18:57:40 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E1vZ3U010374 for ; Tue, 13 Aug 2002 18:57:35 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.5+Sun/8.12.5) with SMTP id g7E1vimG480913; Tue, 13 Aug 2002 18:57:44 -0700 (PDT) Message-Id: <200208140157.g7E1vimG480913@jurassic.eng.sun.com> Date: Tue, 13 Aug 2002 19:00:26 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: RE: [mobile-ip] Question about MIPv6 draft 18 To: hannu.flinck@nokia.com Cc: mobile-ip@sunroof.eng.sun.com, Vladislav.Yasevich@hp.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: FYBlZ1r1dlx2E6McajCJfw== 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 under Home Agent Operation for shake of clarity I would like to propose some lines of description how a static SA is used to validate the MN-HA BUs. Current text that describes in 10.2 "Primary Care-of Address Registration" starts with an assumption that the BU is valid. But says nothing how the validation is done. Later in section 10.3 "Primary Care-of address De-Registration" the text finally refers to Section 9.4.1. > > However section 9.4.1 has been written Return Routability in mind that doesn't apply as such with the home agent that has IPsec SA. > Agreed. Currently Section 10 (Home Agent Operation) is missing a section on "Processing Binding Updates". A section seems to be necessary to describe HA's processing of binding updates from MN. -Samita > -----Original Message----- > From: ext Vladislav Yasevich [mailto:Vladislav.Yasevich@hp.com] > Sent: 13 August, 2002 11:57 AM > To: MobilIP > Subject: [mobile-ip] Question about MIPv6 draft 18 > > > Hi > > I have some questions about Section 5 (Security) in > draft 18. > > 1. Multiple subsections use the symbol '|' in the cookie > and key calculations. Does this symbol mean "concatinate" > or "Logical OR"? (my guess is "Concatinate"). If my guess > is correct, in what order are the bits concatinated (i.e > cookie | none == ((cookie << 64) | nonce)? > > 2. Section 5.2.5 uses a function First64() in calculating home > and care-of cookies. Which bits are assumed to be the first > 64 bits? > > 3. There doesn't appear to be a section on processing and validating > Binding Updates. Is it enought to make sure that authenticator > matches, or should the entire HMAC match? (My guess it the > entire HMAC). > > 4. Section 5.2.7 says the following: > > "Before sending a Binding Update, the mobile node has to wait for both > the Home and Care-of Cookies to arrive. Due to resource limitations, > rapid deletion of bindings, or reboots it can not be guaranteed that > the cookies are still fresh and acceptable when the correspondent > node uses them in the processing of the Binding Update. If the > cookies have become too old, the correspondent node replies with > an an error code in the Binding Acknowledgement. The mobile node > can then retry the return routability procedure. However, it is > recommended that correspondent nodes try to keep these cookies > acceptable as long as possible and SHOULD NOT accept them beyond > MAX_COOKIE_LIFE seconds." > > I find this paragraph highly confusing from the point of view of a > correspondent node. This paragraph implies that the correspondent > should timeout and therefore cache cookies, but the whole assumption > behind RR is that correspondent doesn't keep state per mobile node until > BU had happened. So, in effect, the corresondent times out nonces every > MAX_COOKIE_LIFE seconds. Is my understanding correct? > > > Depending on the replies to the above, I might have more questions, > but I'll hold them for now. > > Thanks > -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 Tue Aug 13 22:43: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 WAA00447 for ; Tue, 13 Aug 2002 22:43:09 -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 TAA07586; Tue, 13 Aug 2002 19:42: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 TAA19944; Tue, 13 Aug 2002 19:42:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E2fG3U010654 for ; Tue, 13 Aug 2002 19:41:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7E2fGns010653 for mobile-ip-dist; Tue, 13 Aug 2002 19:41: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.17.55]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7E2fB3U010646 for ; Tue, 13 Aug 2002 19:41:11 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.5+Sun/8.12.5) with SMTP id g7E2fKmG484018; Tue, 13 Aug 2002 19:41:21 -0700 (PDT) Message-Id: <200208140241.g7E2fKmG484018@jurassic.eng.sun.com> Date: Tue, 13 Aug 2002 19:44:02 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Question about MIPv6 draft 18 To: Vladislav.Yasevich@hp.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ELQSdNGP7el09jw8KEO8Sw== 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: > can then retry the return routability procedure. 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." > > I find this paragraph highly confusing from the point of view of a > correspondent node. This paragraph implies that the correspondent > should timeout and therefore cache cookies, but the whole assumption > behind RR is that correspondent doesn't keep state per mobile node until > BU had happened. So, in effect, the corresondent times out nonces every > MAX_COOKIE_LIFE seconds. Is my understanding correct? I am assuming you are referring to K0/K1 cookies. Well, it seems CN needs to keep track of N(j)s, N(i)s for COOKIE_MAX_LIFE time in a sliding window scale. So at a given COOKIE_MAX_LIFE time, there will be X number of N(j)s and Y number of N(i)s around in the system depending on the nonce generation frequency. Since K0 or K1 are fn(Ni, Hoa), fn(Nj, Coa) respectively, CN does not need to keep the cookies saved for their lifetime, but it needs to compute everytime it processes a request. I thought about the possibility of keeping K0/K1 as well, but then it means more memory and then in a way it's keeping state of MN, before accepting the BU for that MN--which is not recommended. -Samita From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 14 13:46: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 NAA18870 for ; Wed, 14 Aug 2002 13:46: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 LAA06191; Wed, 14 Aug 2002 11:47:16 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA26055; Wed, 14 Aug 2002 10:47:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EHk13U013237 for ; Wed, 14 Aug 2002 10:46:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7EHk1QQ013236 for mobile-ip-dist; Wed, 14 Aug 2002 10:46: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.5+Sun/8.12.5) with ESMTP id g7EHjt3U013229 for ; Wed, 14 Aug 2002 10:45:55 -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 KAA25481 for ; Wed, 14 Aug 2002 10:46:04 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11363 for ; Wed, 14 Aug 2002 10:46:04 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id D34F81DAB; Wed, 14 Aug 2002 12:46:01 -0500 (CDT) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 3880CE71; Wed, 14 Aug 2002 12:46:01 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7EHk0x0001258838; Wed, 14 Aug 2002 13:46:00 -0400 (EDT) Message-ID: <3D5A9758.4090602@hp.com> Date: Wed, 14 Aug 2002 13:46:00 -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: mobile-ip@sunroof.eng.sun.com Cc: Samita Chakrabarti Subject: Re: [mobile-ip] Question about MIPv6 draft 18 References: <200208140241.g7E2fKmG484018@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 Samita Chakrabarti wrote: >> can then retry the return routability procedure. 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." >> >> I find this paragraph highly confusing from the point of view of a >> correspondent node. This paragraph implies that the correspondent >> should timeout and therefore cache cookies, but the whole assumption >> behind RR is that correspondent doesn't keep state per mobile node until >> BU had happened. So, in effect, the corresondent times out nonces every >> MAX_COOKIE_LIFE seconds. Is my understanding correct? > > > > I am assuming you are referring to K0/K1 cookies. > > Well, it seems CN needs to keep track of N(j)s, N(i)s for > COOKIE_MAX_LIFE time in a sliding window scale. So at a > given COOKIE_MAX_LIFE time, there will be X number of N(j)s > and Y number of N(i)s around in the system depending on > the nonce generation frequency. Well, that's what I was asking. The correspondent keeps nonces instead of cookies. However the paragraph I quoted implies that cookies are kept, which is actually not true and against previous recomendations. And, in effect, a nonce may remain valid up to a maximum of "nonce generation interval" + MAX_COOKIE_LIFE (that's how far the time window may slide). Additionally, it would be nice to recomend a nonce generation frequency that is more specific then "... at regular intervals,for example every few minutes". > > Since K0 or K1 are fn(Ni, Hoa), fn(Nj, Coa) respectively, > CN does not need to keep the cookies saved for their lifetime, > but it needs to compute everytime it processes a request. Yes, but the time window on the nonce only slides when the cookie for a CoT or a HoT are computed, not everytime. > > I thought about the possibility of keeping K0/K1 as well, but > then it means more memory and then in a way it's keeping state > of MN, before accepting the BU for that MN--which is not > recommended. > That would actually be really bad, because you would need K0/K1 pair for each mobile node talking to you and that can be a very large number. This would also open for yet another DOS attack, where all an attacker would do is run RR with different addresses and consume all your cookie space and cause another redirect attack that would result for HoT and CoT messages. -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 Aug 14 14:50: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 OAA21177 for ; Wed, 14 Aug 2002 14:50:44 -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 LAA21323; Wed, 14 Aug 2002 11:49:40 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA10686; Wed, 14 Aug 2002 11:49:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EImQ3U013514 for ; Wed, 14 Aug 2002 11:48:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7EImQ6i013513 for mobile-ip-dist; Wed, 14 Aug 2002 11:48: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.5+Sun/8.12.5) with ESMTP id g7EImK3U013506 for ; Wed, 14 Aug 2002 11:48: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 LAA10456 for ; Wed, 14 Aug 2002 11:48:30 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07143 for ; Wed, 14 Aug 2002 12:48: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 LAA01626; Wed, 14 Aug 2002 11:48:27 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7EImQS24099; Wed, 14 Aug 2002 11:48:26 -0700 X-mProtect: <200208141848> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUTZ4m8; Wed, 14 Aug 2002 11:48:23 PDT Message-ID: <3D5AA5F7.46E4F872@iprg.nokia.com> Date: Wed, 14 Aug 2002 11:48:23 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: mobile-ip@sunroof.eng.sun.com, Samita Chakrabarti Subject: Re: [mobile-ip] Question about MIPv6 draft 18 References: <200208140241.g7E2fKmG484018@jurassic.eng.sun.com> <3D5A9758.4090602@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: > This would also open for yet another DOS attack, where > all an attacker would do is run RR with different addresses and > consume all your cookie space I am not sure I understood this DoS attack. how is this possible? the attacker can be at only one CoA at a time. the purpose of Care-of test is to prevent an attacker from claiming any arbitrary CoA. right? > and cause another redirect attack > that would result for HoT and CoT messages. didnt understand this. Vijay From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 14 15:36:17 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 PAA22512 for ; Wed, 14 Aug 2002 15:36:16 -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 NAA02736; Wed, 14 Aug 2002 13:36:56 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA27895; Wed, 14 Aug 2002 12:36:53 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EJTJ3U013804 for ; Wed, 14 Aug 2002 12:29:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7EJTJjx013803 for mobile-ip-dist; Wed, 14 Aug 2002 12: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.5+Sun/8.12.5) with ESMTP id g7EJTD3U013796 for ; Wed, 14 Aug 2002 12:29:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA09564 for ; Wed, 14 Aug 2002 12:29:24 -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 NAA04869 for ; Wed, 14 Aug 2002 13:29:22 -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 3A7C4C01; Wed, 14 Aug 2002 14:29:20 -0500 (CDT) Received: from anw.zk3.dec.com (banw4.zk3.dec.com [16.140.128.5]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 9415AFB0; Wed, 14 Aug 2002 14:29:19 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7EJTJU0002381003; Wed, 14 Aug 2002 15:29:19 -0400 (EDT) Message-ID: <3D5AAF8F.1010405@hp.com> Date: Wed, 14 Aug 2002 15:29:19 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question about MIPv6 draft 18 References: <200208140241.g7E2fKmG484018@jurassic.eng.sun.com> <3D5A9758.4090602@hp.com> <3D5AA5F7.46E4F872@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 This was an attempt to say that storing K0/K1 cookies on the CN is a bad idea. If the correspondent caches K0/K1 (the bad behavior), an attacker can send CoTI and HoTI messages from bogus source addresses. this would cause creation and caching of cookies and a response of CoT and HoT messages respectively. Thus the attack is two-fold. One part consumes memory/cookie space. The attacker has 4 minutes (240 sec) in which the cookies cached on the CN will be valid. That can be a lot of cookies. The other part sends HoT or CoT messages to some hosts that doen't expect them and may result in additional ICMP errors. All in all, bad situation. This all really points to a paragraph is Section 5.2.7 that implied (to me on my first few reads) that a CN keeps cookies. It might be better to talk about nonces from the CN point of view and stick to cookies from the MN point of view. -vlad Vijay Devarapalli wrote: > hi Vlad, > > Vladislav Yasevich wrote: > > >>This would also open for yet another DOS attack, where >>all an attacker would do is run RR with different addresses and >>consume all your cookie space > > > I am not sure I understood this DoS attack. how is this possible? > the attacker can be at only one CoA at a time. the purpose of > Care-of test is to prevent an attacker from claiming any > arbitrary CoA. right? > > >>and cause another redirect attack >>that would result for HoT and CoT messages. > > > didnt understand this. > > Vijay > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Aug 14 16:07: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 QAA23487 for ; Wed, 14 Aug 2002 16:07:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06661; Wed, 14 Aug 2002 14:07: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 NAA07912; Wed, 14 Aug 2002 13:07:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EK5g3U014039 for ; Wed, 14 Aug 2002 13:05:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7EK5g4Z014038 for mobile-ip-dist; Wed, 14 Aug 2002 13:05: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 jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EK5a3U014031 for ; Wed, 14 Aug 2002 13:05:36 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.5+Sun/8.12.5) with SMTP id g7EK5kmG625346; Wed, 14 Aug 2002 13:05:46 -0700 (PDT) Message-Id: <200208142005.g7EK5kmG625346@jurassic.eng.sun.com> Date: Wed, 14 Aug 2002 13:08:28 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Question about MIPv6 draft 18 To: Vladislav.Yasevich@hp.com Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 7XMdTOCm2z7b4BEA+m8NjA== 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: > instead of cookies. However the paragraph I quoted implies that > cookies are kept, which is actually not true and against previous > recomendations. And, in effect, a nonce may remain valid up to > a maximum of "nonce generation interval" + MAX_COOKIE_LIFE (that's > how far the time window may slide). > Yes, a nonce should be valid at least up to MAX_COOKIE_LIFE, otherwise, a BU refresh with valid cookie life time will not be able to generate the same key. > > > > Since K0 or K1 are fn(Ni, Hoa), fn(Nj, Coa) respectively, > > CN does not need to keep the cookies saved for their lifetime, > > but it needs to compute everytime it processes a request. > > Yes, but the time window on the nonce only slides when the cookie > for a CoT or a HoT are computed, not everytime. > I am not sure what you mean by this, could you please explain ? > > > > I thought about the possibility of keeping K0/K1 as well, but > > then it means more memory and then in a way it's keeping state > > of MN, before accepting the BU for that MN--which is not > > recommended. > > > > That would actually be really bad, because you would need K0/K1 pair > for each mobile node talking to you and that can be a very large > number. This would also open for yet another DOS attack, where > all an attacker would do is run RR with different addresses and > consume all your cookie space and cause another redirect attack > that would result for HoT and CoT messages. Right. Keeping cookies are bad ideas. -Samita From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 14 16:37: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 QAA24283 for ; Wed, 14 Aug 2002 16:37:39 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10406; Wed, 14 Aug 2002 14:38: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 NAA20113; Wed, 14 Aug 2002 13:38:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7EKaw3U014276 for ; Wed, 14 Aug 2002 13:36:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7EKaw3K014275 for mobile-ip-dist; Wed, 14 Aug 2002 13:36: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.5+Sun/8.12.5) with ESMTP id g7EKap3U014268 for ; Wed, 14 Aug 2002 13:36:51 -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 NAA19555 for ; Wed, 14 Aug 2002 13:37:02 -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 NAA27262 for ; Wed, 14 Aug 2002 13:37:02 -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 B3372374E; Wed, 14 Aug 2002 15:37:01 -0500 (CDT) Received: from anw.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id BCB12C67; Wed, 14 Aug 2002 13:37:00 -0700 (PDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7EKb0d0001011711; Wed, 14 Aug 2002 16:37:00 -0400 (EDT) Message-ID: <3D5ABF6C.9050609@hp.com> Date: Wed, 14 Aug 2002 16:37:00 -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: Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question about MIPv6 draft 18 References: <200208142005.g7EK5kmG625346@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: >>>Since K0 or K1 are fn(Ni, Hoa), fn(Nj, Coa) respectively, >>>CN does not need to keep the cookies saved for their lifetime, >>>but it needs to compute everytime it processes a request. >> >>Yes, but the time window on the nonce only slides when the cookie >>for a CoT or a HoT are computed, not everytime. >> > > > I am not sure what you mean by this, could you please explain ? I'll try... A nonce is valid for MAX_COOKIE_LIFE after the cookie is generated to make the cookie valid. So, for every (new) cookie that's generated from a nonce, the time that the nonce and the cookie are valid stides out to MAX_COOKIE_LIFE. But, conceptually, cookies are originally generated for HoT and CoT messages only. They just will need to be recomputed to figure out Kbu. So, my assumption (and this is just my assumption) is that the timeout on the nonce is reset only when the cookies are computed for HoT and CoT messages. Otherwise nonces, and thus cookies, might be kept for much longer then intended. Does that make sense? -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 Aug 14 23:30: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 XAA02998 for ; Wed, 14 Aug 2002 23:30:30 -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 UAA08045; Wed, 14 Aug 2002 20:29: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 UAA09072; Wed, 14 Aug 2002 20:29:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F3SX3U015512 for ; Wed, 14 Aug 2002 20:28:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7F3SW9E015511 for mobile-ip-dist; Wed, 14 Aug 2002 20:28: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 jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7F3SR3U015504 for ; Wed, 14 Aug 2002 20:28:27 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.5+Sun/8.12.5) with SMTP id g7F3ScmG726617; Wed, 14 Aug 2002 20:28:38 -0700 (PDT) Message-Id: <200208150328.g7F3ScmG726617@jurassic.eng.sun.com> Date: Wed, 14 Aug 2002 20:31:21 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Question about MIPv6 draft 18 To: Vladislav.Yasevich@hp.com Cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: hvfAo05Nf1kBRTN+RCRfGA== 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 Vlad, > >>Yes, but the time window on the nonce only slides when the cookie > >>for a CoT or a HoT are computed, not everytime. > >> > > > > > > I am not sure what you mean by this, could you please explain ? > > > I'll try... > > A nonce is valid for MAX_COOKIE_LIFE after the cookie is generated > to make the cookie valid. So, for every (new) cookie that's generated from > a nonce, the time that the nonce and the cookie are valid stides out to > MAX_COOKIE_LIFE. But, conceptually, cookies are originally generated for > HoT and CoT messages only. They just will need to be recomputed to figure > out Kbu. So, my assumption (and this is just my assumption) is that the > timeout on the nonce is reset only when the cookies are computed for HoT and > CoT messages. Otherwise nonces, and thus cookies, might be kept for much > longer then intended. > > Does that make sense? > Let me see if my understanding is correct... For example, if nonces are generated in every 10 sec, then there will be about 20 (18 + 2 extra) nonces will be valid for MAX_COOKIE_LIFE (180sec). So for a 10 sec period at a given time, there might be 5 HOTI/COTI messages from 5 MNs; they all will use same Ni, Nj even though their cookies are different and so is the expiry time for each cookie, depending on when they are generated. So, if one HOTI or COTI message is received at t+9 sec, when t= Nonce Nj generation time, then this Nj cannot expire until after 10+MAX_COOKIE_LIFE sec. Are you saying that the nonce timeout value should be updated everytime a cookie is created ? That may be possible, or simply setting to the max value (nonce generation value + COOKIE_LIFE_TIME + delta) may save some CPU cycles. But, I think the draft should specify the "delta" value. "delta" value is the extra time a old nonce to be around to make sure that nonce does not disappear between sending HOT/COT and receiving BU. This value should depend on the RTT of max (COT path , HOT path). Also, I agree with you that the draft is unclear about managing nonce and nonce-indices and their generation frequency. Section 5.2.7 ( Updating Node Keys and Nonces) needs to specify the nonce timeout logic more clearly than it is now. The second and third paragraph of this section mostly talks about the cookie lifetime which is confusing in the context of Nonces. Perhaps the heading needs to change to say " Updating Node Keys and Nonces and Cookies" and add one more paragraph on Nonce timeout procedure. Copying to Jari Arkko for his comments. -Samita From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 15 09:20: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 JAA24991 for ; Thu, 15 Aug 2002 09:20: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 HAA20625; Thu, 15 Aug 2002 07:21: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 GAA22640; Thu, 15 Aug 2002 06:21:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FDKJ3U017180 for ; Thu, 15 Aug 2002 06:20:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FDKJga017179 for mobile-ip-dist; Thu, 15 Aug 2002 06:20: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.5+Sun/8.12.5) with ESMTP id g7FDKD3U017172 for ; Thu, 15 Aug 2002 06:20:13 -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 GAA08459 for ; Thu, 15 Aug 2002 06:20:24 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04521 for ; Thu, 15 Aug 2002 06:20:24 -0700 (PDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id DA621BD7; Thu, 15 Aug 2002 06:20:23 -0700 (PDT) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id A844B1103; Thu, 15 Aug 2002 06:20:22 -0700 (PDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7FDKLx0001423029; Thu, 15 Aug 2002 09:20:21 -0400 (EDT) Message-ID: <3D5BAA94.5090104@hp.com> Date: Thu, 15 Aug 2002 09:20:20 -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: Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi Subject: Re: [mobile-ip] Question about MIPv6 draft 18 References: <200208150328.g7F3ScmG726617@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: > > Let me see if my understanding is correct... > > For example, if nonces are generated in every 10 sec, then there will be > about 20 (18 + 2 extra) nonces will be valid for MAX_COOKIE_LIFE (180sec). I thought MAX_COOKIE_LIFE was 240? This brings up another possible problem. The MAX_COOKIE_LIFE duration at a mobile node SHOULD not be smaller that at the correspondent node (assumig MAX_COOKIE_LIFE is configurable). Otherwise, the situations where RR will succeed, but BU fail due to nonce timeout will become very likely. This might be something that needs to be in the draft... > > So for a 10 sec period at a given time, there might be 5 HOTI/COTI messages > from 5 MNs; they all will use same Ni, Nj even though their cookies are > different and so is the expiry time for each cookie, depending on when they > are generated. So, if one HOTI or COTI message is received at t+9 sec, when > t= Nonce Nj generation time, then this Nj cannot expire until after > 10+MAX_COOKIE_LIFE sec. Are you saying that the nonce timeout value should > be updated everytime a cookie is created ? That may be possible, or simply > setting to the max value (nonce generation value + COOKIE_LIFE_TIME + delta) > may save some CPU cycles. I was saing that that nonce timeout value needs to be updated every time a "new" cookie is generated from a given nonce. The "new" cookie is a cookie that is generated for the first time, usually during processing of HoTI and CoTI messages. This means that any cookie generation as part of the BU processing does NOT effect the current timeout value of a nonce. Also, using your example, I would actually say that the Nj can not expire until after t+9+MAX_COOKIE_LIFE, but that's a more conservative estimate. > > But, I think the draft should specify the "delta" value. "delta" value is > the extra time a old nonce to be around to make sure that nonce does not > disappear between sending HOT/COT and receiving BU. > This value should depend on the RTT of max (COT path , HOT path). This would be extremely rare as the mobile node would have to delay MAX_COOKIE_LIFE-RRT(mn-cn path) to send a BU after RR is complete. The recovery mechanims is in place and the mobile will succeed eventually. > > Also, I agree with you that the draft is unclear about managing nonce > and nonce-indices and their generation frequency. > > Section 5.2.7 ( Updating Node Keys and Nonces) needs to specify the > nonce timeout logic more clearly than it is now. The second and third > paragraph of this section mostly talks about the cookie lifetime which > is confusing in the context of Nonces. > > Perhaps the heading needs to change to say " Updating Node Keys and Nonces and > Cookies" and add one more paragraph on Nonce timeout procedure. "Updating Node Keys, Nonces and Cookies" ;) Section 5.2.2 states the following: " ... Expected validity times for the nonces values and the procedures for updating them are discussed later in Section 5.2.7. " As we see now, 5.2.7 does not talk about nonces. > > Copying to Jari Arkko for his comments. > > -Samita Thanks -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 Aug 15 14:31: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 OAA09326 for ; Thu, 15 Aug 2002 14:31:10 -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 MAA18233; Thu, 15 Aug 2002 12:31: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 LAA08624; Thu, 15 Aug 2002 11:31:47 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FIUY3U017970 for ; Thu, 15 Aug 2002 11:30:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FIUXRs017969 for mobile-ip-dist; Thu, 15 Aug 2002 11:30:33 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FIUR3U017962 for ; Thu, 15 Aug 2002 11:30: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 LAA29603 for ; Thu, 15 Aug 2002 11:30:38 -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 LAA00097 for ; Thu, 15 Aug 2002 11:30: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 LAA08167; Thu, 15 Aug 2002 11:30:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7FIUae06244; Thu, 15 Aug 2002 11:30:36 -0700 X-mProtect: <200208151830> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdw1YKVM; Thu, 15 Aug 2002 11:30:34 PDT Message-ID: <3D5BF349.38F22B05@iprg.nokia.com> Date: Thu, 15 Aug 2002 11:30: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: Vladislav Yasevich CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question about MIPv6 draft 18 References: <200208140241.g7E2fKmG484018@jurassic.eng.sun.com> <3D5A9758.4090602@hp.com> <3D5AA5F7.46E4F872@iprg.nokia.com> <3D5AAF8F.1010405@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: > > Vijay > > This was an attempt to say that storing K0/K1 cookies on > the CN is a bad idea. I was not disputing the above statement. but the DoS attack that you described as the reason is not correct (or atleast I did not understand it). > If the correspondent caches K0/K1 (the bad behavior), an attacker > can send CoTI and HoTI messages from bogus source addresses. > this would cause creation and caching of cookies and a response of > CoT and HoT messages respectively. Thus the attack is two-fold. > One part consumes memory/cookie space. The attacker has 4 minutes > (240 sec) in which the cookies cached on the CN will be valid. > That can be a lot of cookies. how can it be a lot of cookies? the CN would be storing only one K0/K1 per MN. a new pair of cookies can be created only if the MN moves and does CoTi and HoTi for a new CoA and a new HoA. how can one MN launch this DoS attack? regards Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 15 14:54:07 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10791 for ; Thu, 15 Aug 2002 14:54:07 -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 LAA05772; Thu, 15 Aug 2002 11:53:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08555; Thu, 15 Aug 2002 11:53:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FIpw3U018160 for ; Thu, 15 Aug 2002 11:51:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FIpwwQ018159 for mobile-ip-dist; Thu, 15 Aug 2002 11:51: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.5+Sun/8.12.5) with ESMTP id g7FIpq3U018152 for ; Thu, 15 Aug 2002 11:51:52 -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 LAA07904 for ; Thu, 15 Aug 2002 11:52:03 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13084 for ; Thu, 15 Aug 2002 11:52:02 -0700 (PDT) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 5A0C86B41; Thu, 15 Aug 2002 14:52:02 -0400 (EDT) Received: from anw.zk3.dec.com (band.zk3.dec.com [16.140.128.6]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 81F47C67; Thu, 15 Aug 2002 13:52:01 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7FIq1M0002059024; Thu, 15 Aug 2002 14:52:01 -0400 (EDT) Message-ID: <3D5BF850.9050705@hp.com> Date: Thu, 15 Aug 2002 14:52:00 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question about MIPv6 draft 18 References: <200208140241.g7E2fKmG484018@jurassic.eng.sun.com> <3D5A9758.4090602@hp.com> <3D5AA5F7.46E4F872@iprg.nokia.com> <3D5AAF8F.1010405@hp.com> <3D5BF349.38F22B05@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 It does not have to be a mobile node. It can be any node. -vlad > how can it be a lot of cookies? the CN would be storing only > one K0/K1 per MN. a new pair of cookies can be created only if > the MN moves and does CoTi and HoTi for a new CoA and a new HoA. > how can one MN launch this DoS attack? > > regards > Vijay > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Aug 15 15:22: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 PAA12118 for ; Thu, 15 Aug 2002 15:22:48 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17658; Thu, 15 Aug 2002 13:23: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 MAA00808; Thu, 15 Aug 2002 12:23:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FJMD3U018425 for ; Thu, 15 Aug 2002 12:22:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FJMD2B018424 for mobile-ip-dist; Thu, 15 Aug 2002 12:22: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.5+Sun/8.12.5) with ESMTP id g7FJM73U018417 for ; Thu, 15 Aug 2002 12:22: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 MAA29739 for ; Thu, 15 Aug 2002 12:22:18 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02546 for ; Thu, 15 Aug 2002 13:22:17 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA11675; Thu, 15 Aug 2002 12:22:16 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7FJMF027091; Thu, 15 Aug 2002 12:22:15 -0700 X-mProtect: <200208151922> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpJZMtg; Thu, 15 Aug 2002 12:22:13 PDT Message-ID: <3D5BFF64.74C60AA9@iprg.nokia.com> Date: Thu, 15 Aug 2002 12:22:12 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question about MIPv6 draft 18 References: <200208140241.g7E2fKmG484018@jurassic.eng.sun.com> <3D5A9758.4090602@hp.com> <3D5AA5F7.46E4F872@iprg.nokia.com> <3D5AAF8F.1010405@hp.com> <3D5BF349.38F22B05@iprg.nokia.com> <3D5BF850.9050705@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: > > Vijay > > It does not have to be a mobile node. It can be any node. > you are right. it can be any node. but the CN still stores only one K0/K1 pair at any time per node, right? one single node cannot fill up memory at the CN by generating a large number of K0/K1 pairs. I dont know what I am missing. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 15 15:43: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 PAA13153 for ; Thu, 15 Aug 2002 15:43: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 MAA09551; Thu, 15 Aug 2002 12:42: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 MAA25840; Thu, 15 Aug 2002 12:42:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FJeq3U018590 for ; Thu, 15 Aug 2002 12:40:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FJeqkg018589 for mobile-ip-dist; Thu, 15 Aug 2002 12:40: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.5+Sun/8.12.5) with ESMTP id g7FJek3U018582 for ; Thu, 15 Aug 2002 12:40:46 -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 MAA06679 for ; Thu, 15 Aug 2002 12:40:56 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08588 for ; Thu, 15 Aug 2002 12:40:55 -0700 (PDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 4FA2541BF; Thu, 15 Aug 2002 14:40:55 -0500 (CDT) Received: from anw.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id E5CFDF2A; Thu, 15 Aug 2002 15:40:54 -0400 (EDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7FJesd0000796894; Thu, 15 Aug 2002 15:40:54 -0400 (EDT) Message-ID: <3D5C03C6.3080106@hp.com> Date: Thu, 15 Aug 2002 15:40:54 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question about MIPv6 draft 18 References: <200208140241.g7E2fKmG484018@jurassic.eng.sun.com> <3D5A9758.4090602@hp.com> <3D5AA5F7.46E4F872@iprg.nokia.com> <3D5AAF8F.1010405@hp.com> <3D5BF349.38F22B05@iprg.nokia.com> <3D5BF850.9050705@hp.com> <3D5BFF64.74C60AA9@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: > Vladislav Yasevich wrote: > >>Vijay >> >>It does not have to be a mobile node. It can be any node. >> > > > you are right. it can be any node. but the CN still stores > only one K0/K1 pair at any time per node, right? No, the cookies are generated per address. If the address changes, the cookie changes. In the end, to the correspondent, it will look like a large number of mobile nodes are trying to do RR. How many times can 1 node run RR in a 240 sec interval? (240sec == MAX_COOKIE_LIFE). The atack is defeated however by ingress filtering and other RFP checks. > one single > node cannot fill up memory at the CN by generating a large > number of K0/K1 pairs. > > I dont know what I am missing. > > Vijay > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Aug 15 16:36: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 QAA15223 for ; Thu, 15 Aug 2002 16:36: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 NAA08202; Thu, 15 Aug 2002 13:35: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 NAA28507; Thu, 15 Aug 2002 13:35:22 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FKY63U018938 for ; Thu, 15 Aug 2002 13:34:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FKY6p8018937 for mobile-ip-dist; Thu, 15 Aug 2002 13:34: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.5+Sun/8.12.5) with ESMTP id g7FKY03U018930 for ; Thu, 15 Aug 2002 13:34: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 NAA28021 for ; Thu, 15 Aug 2002 13:34:11 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00079 for ; Thu, 15 Aug 2002 14:34:10 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 6436168F2 for ; Thu, 15 Aug 2002 16:34:09 -0400 (EDT) Received: from anw.zk3.dec.com (band.zk3.dec.com [16.140.128.6]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 49B10FBD; Thu, 15 Aug 2002 13:34:08 -0700 (PDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7FKY7M0002077664; Thu, 15 Aug 2002 16:34:07 -0400 (EDT) Message-ID: <3D5C103F.50304@hp.com> Date: Thu, 15 Aug 2002 16:34:07 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question about MIPv6 draft 18 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 I have a comment about authorization of BAcks in draft 18. They way I interpret the spec, if the BU has the Authorization Data option, BAck must contains this option as well. I get this out sections 5.2.6 and and 9.4.4. However, section 6.2.7 "Binding Authorization Data" says: " ... This specification gives the rules only for the return routability procedure. For this procedure, this option can only appear in a Binding Update message and rules for calculating the Authenticator value are described in Section 6.1.7." This seems to restrict Bindgin Authorisation Data only to BUs. Also, going and reading 6.1.7, I can't find the rules for calculating the Authenticator value. I think the reference needs to be fixed as well. -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 Aug 15 17:10: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 RAA16167 for ; Thu, 15 Aug 2002 17:10:44 -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 OAA26437; Thu, 15 Aug 2002 14:09: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 OAA11476; Thu, 15 Aug 2002 14:09:46 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FL8c3U019243 for ; Thu, 15 Aug 2002 14:08:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FL8caW019242 for mobile-ip-dist; Thu, 15 Aug 2002 14:08:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FL8W3U019235 for ; Thu, 15 Aug 2002 14:08: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 OAA26303 for ; Thu, 15 Aug 2002 14:08:42 -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 OAA19152 for ; Thu, 15 Aug 2002 14:08:42 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA17050; Thu, 15 Aug 2002 14:08:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7FL8eM08028; Thu, 15 Aug 2002 14:08:40 -0700 X-mProtect: <200208152108> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1gCq4A; Thu, 15 Aug 2002 14:02:59 PDT Message-ID: <3D5C16D5.1A6B344A@iprg.nokia.com> Date: Thu, 15 Aug 2002 14:02: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: Vladislav Yasevich CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question about MIPv6 draft 18 References: <200208140241.g7E2fKmG484018@jurassic.eng.sun.com> <3D5A9758.4090602@hp.com> <3D5AA5F7.46E4F872@iprg.nokia.com> <3D5AAF8F.1010405@hp.com> <3D5BF349.38F22B05@iprg.nokia.com> <3D5BF850.9050705@hp.com> <3D5BFF64.74C60AA9@iprg.nokia.com> <3D5C03C6 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: > No, the cookies are generated per address. If the address > changes, the cookie changes. In the end, to the correspondent, > it will look like a large number of mobile nodes are trying to > do RR. How many times can 1 node run RR in a 240 sec interval? > (240sec == MAX_COOKIE_LIFE). > > The atack is defeated however by ingress filtering and other RFP > checks. exactly. this is what was I was trying to say. I know that storing K0/K1 is a bad idea. but for other reasons. and not the DoS attack you mentioned. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 15 17:33:35 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16966 for ; Thu, 15 Aug 2002 17:33:34 -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 PAA29621; Thu, 15 Aug 2002 15:34: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 OAA05125; Thu, 15 Aug 2002 14:34:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FLWp3U019461 for ; Thu, 15 Aug 2002 14:32:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FLWo1q019460 for mobile-ip-dist; Thu, 15 Aug 2002 14:32:50 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FLWj3U019453 for ; Thu, 15 Aug 2002 14:32:45 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA04538 for ; Thu, 15 Aug 2002 14:32:55 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08346 for ; Thu, 15 Aug 2002 14:32:54 -0700 (PDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 264A863FE; Thu, 15 Aug 2002 17:32:54 -0400 (EDT) Received: from anw.zk3.dec.com (banw4.zk3.dec.com [16.140.128.5]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 290B41264; Thu, 15 Aug 2002 14:32:53 -0700 (PDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7FLWqU0002143254; Thu, 15 Aug 2002 17:32:52 -0400 (EDT) Message-ID: <3D5C1E04.5050905@hp.com> Date: Thu, 15 Aug 2002 17:32:52 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question about MIPv6 draft 18 References: <200208140241.g7E2fKmG484018@jurassic.eng.sun.com> <3D5A9758.4090602@hp.com> <3D5AA5F7.46E4F872@iprg.nokia.com> <3D5AAF8F.1010405@hp.com> <3D5BF349.38F22B05@iprg.nokia.com> <3D5BF850.9050705@hp.com> <3D5BFF64.74C60AA9@iprg.nokia.com> <3D5C03C6 <3D5C16D5.1A6B344A@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: > hi Vlad, > > Vladislav Yasevich wrote: > > >>No, the cookies are generated per address. If the address >>changes, the cookie changes. In the end, to the correspondent, >>it will look like a large number of mobile nodes are trying to >>do RR. How many times can 1 node run RR in a 240 sec interval? >>(240sec == MAX_COOKIE_LIFE). >> >>The atack is defeated however by ingress filtering and other RFP >>checks. > > > exactly. this is what was I was trying to say. I know that > storing K0/K1 is a bad idea. but for other reasons. and not > the DoS attack you mentioned. That's assuming these RFP checks are used. Do you think this should be mentioned in the security considerations? -vlad > > Vijay > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Aug 15 17:42: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 RAA17223 for ; Thu, 15 Aug 2002 17:42:55 -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 PAA00311; Thu, 15 Aug 2002 15:43: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 OAA25052; Thu, 15 Aug 2002 14:43:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FLgU3U019643 for ; Thu, 15 Aug 2002 14:42:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FLgTQo019642 for mobile-ip-dist; Thu, 15 Aug 2002 14:42: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.5+Sun/8.12.5) with ESMTP id g7FLgL3U019635 for ; Thu, 15 Aug 2002 14:42: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 OAA17694 for ; Thu, 15 Aug 2002 14:42:31 -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 PAA29671 for ; Thu, 15 Aug 2002 15:42: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 OAA19852; Thu, 15 Aug 2002 14:42:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7FLgSq11269; Thu, 15 Aug 2002 14:42:28 -0700 X-mProtect: <200208152142> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd17SuBn; Thu, 15 Aug 2002 14:42:25 PDT Message-ID: <3D5C2041.ABA2D474@iprg.nokia.com> Date: Thu, 15 Aug 2002 14:42:25 -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: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question about MIPv6 draft 18 References: <200208140241.g7E2fKmG484018@jurassic.eng.sun.com> <3D5A9758.4090602@hp.com> <3D5AA5F7.46E4F872@iprg.nokia.com> <3D5AAF8F.1010405@hp.com> <3D5BF349.38F22B05@iprg.nokia.com> <3D5BF850.9050705@hp.com> <3D5BFF64.74C60AA9@iprg.nokia.com> <3D5C03C6 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: > > Hi Vijay > That's assuming these RFP checks are used. Do > you think this should be mentioned in the security considerations? hold on Vlad. we came down this dicussion path assuming CN stores K0/K1. if it does not (which is the case now), we dont have to mention it anywhere. RPF checks need to be there anyway. MIPv6 does not have to say anything about them. Vijay From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 15 18:25: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 SAA18300 for ; Thu, 15 Aug 2002 18:25:44 -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 QAA20810; Thu, 15 Aug 2002 16:26: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 PAA12516; Thu, 15 Aug 2002 15:26:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FMPB3U019951 for ; Thu, 15 Aug 2002 15:25:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FMPAww019950 for mobile-ip-dist; Thu, 15 Aug 2002 15:25: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 jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FMP53U019943 for ; Thu, 15 Aug 2002 15:25:05 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.5+Sun/8.12.5) with SMTP id g7FMPFmG940196; Thu, 15 Aug 2002 15:25:16 -0700 (PDT) Message-Id: <200208152225.g7FMPFmG940196@jurassic.eng.sun.com> Date: Thu, 15 Aug 2002 15:27:58 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Question about MIPv6 draft 18 To: Vladislav.Yasevich@hp.com Cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: LHP2fGB1HARtrgGpdZhfVw== 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: > > For example, if nonces are generated in every 10 sec, then there will be > > about 20 (18 + 2 extra) nonces will be valid for MAX_COOKIE_LIFE (180sec). > > I thought MAX_COOKIE_LIFE was 240? This brings up another possible > problem. The MAX_COOKIE_LIFE duration at a mobile node SHOULD not be > smaller that at the correspondent node (assumig MAX_COOKIE_LIFE is > configurable). Otherwise, the situations where RR will succeed, but BU > fail due to nonce timeout will become very likely. This might be something > that needs to be in the draft... > Oops. I did not see that the MAX_COOKIE_LIFE is now changed from 180 to 240. It was 180 sec before ( I think, draft 16). > > > > So for a 10 sec period at a given time, there might be 5 HOTI/COTI messages > > from 5 MNs; they all will use same Ni, Nj even though their cookies are > > different and so is the expiry time for each cookie, depending on when they > > are generated. So, if one HOTI or COTI message is received at t+9 sec, when > > t= Nonce Nj generation time, then this Nj cannot expire until after > > 10+MAX_COOKIE_LIFE sec. Are you saying that the nonce timeout value should > > be updated everytime a cookie is created ? That may be possible, or simply > > setting to the max value (nonce generation value + COOKIE_LIFE_TIME + delta) > > may save some CPU cycles. > > I was saing that that nonce timeout value needs to be updated every time a > "new" cookie is generated from a given nonce. The "new" cookie is a cookie > that is generated for the first time, usually during processing of HoTI and > CoTI messages. This means that any cookie generation as part of the BU > processing does NOT effect the current timeout value of a nonce. > > Also, using your example, I would actually say that the Nj can not > expire until after t+9+MAX_COOKIE_LIFE, but that's a more conservative > estimate. > True. > > > > But, I think the draft should specify the "delta" value. "delta" value is > > the extra time a old nonce to be around to make sure that nonce does not > > disappear between sending HOT/COT and receiving BU. > > This value should depend on the RTT of max (COT path , HOT path). > > This would be extremely rare as the mobile node would have to delay > MAX_COOKIE_LIFE-RRT(mn-cn path) to send a BU after RR is complete. > The recovery mechanims is in place and the mobile will succeed eventually. > After thinking about it a bit, I realized that this situation would be rare and in those cases, MN should restart RR procedure. > > > > Also, I agree with you that the draft is unclear about managing nonce > > and nonce-indices and their generation frequency. > > > > Section 5.2.7 ( Updating Node Keys and Nonces) needs to specify the > > nonce timeout logic more clearly than it is now. The second and third > > paragraph of this section mostly talks about the cookie lifetime which > > is confusing in the context of Nonces. > > > > Perhaps the heading needs to change to say " Updating Node Keys and Nonces and > > Cookies" and add one more paragraph on Nonce timeout procedure. > > "Updating Node Keys, Nonces and Cookies" ;) > Yes, that was not correct. So we need to come up with a better sub-heading. > Section 5.2.2 states the following: > " ... Expected validity times for > the nonces values and the procedures for updating them are discussed > later in Section 5.2.7. " > > As we see now, 5.2.7 does not talk about nonces. Actually, I looked at the hardcopy of draft 16, the explanation on nonce and Kcn updates using examples (Nj, N(j+1)) seems to have more information than that in draft 18. Some text similar to that would be helpful (in section 5.2.7 of draft 18) for implementors. Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 15 18:42:42 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18836 for ; Thu, 15 Aug 2002 18:42:41 -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 QAA03423; Thu, 15 Aug 2002 16:43:28 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA09909; Thu, 15 Aug 2002 15:43:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7FMg93U020142 for ; Thu, 15 Aug 2002 15:42:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7FMg8R9020141 for mobile-ip-dist; Thu, 15 Aug 2002 15:42: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.5+Sun/8.12.5) with ESMTP id g7FMg33U020134 for ; Thu, 15 Aug 2002 15:42:03 -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 PAA29469 for ; Thu, 15 Aug 2002 15:42:13 -0700 (PDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27597 for ; Thu, 15 Aug 2002 16:42:12 -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 g7FMg7RY044166; Thu, 15 Aug 2002 18:42:07 -0400 Received: from d03nm801.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.3/NCO/VER6.3) with ESMTP id g7FMg5DU219114; Thu, 15 Aug 2002 16:42:06 -0600 Subject: [mobile-ip] 2 Questions on Mobile Draft 18 To: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Krishna Kumar" Date: Thu, 15 Aug 2002 15:35:23 -0700 X-MIMETrack: Serialize by Router on D03NM801/03/M/IBM(Release 5.0.10 |March 22, 2002) at 08/15/2002 04:42:05 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 all, 1. In section 5.2.1 : 5.2.2. Nonces Each correspondent node also generates nonces at regular intervals, for example every few minutes. The nonces should be generated by using a random number generator that is known to have good randomness properties [1]. A correspondent node may use the same Kcn and nonce with all the mobiles it is in communication with, so that it does not need to generate and store a new nonce when a new mobile contacts it. Does this mean that nonces are generated at regular intervals as stated in the first sentence, or the same one is used in all communications with all mobile nodes, as implied in the last sentence ? 2. Binding Refresh Advice (Section 6.2.8) : This Type=7 is missing in Section 13, the IANA considerations. Also, the type should be 6! Thanks, - KK From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 15 21:04: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 VAA21900 for ; Thu, 15 Aug 2002 21:04:14 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA00072; Thu, 15 Aug 2002 19:05:07 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09330; Thu, 15 Aug 2002 18:05:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7G13s3U020660 for ; Thu, 15 Aug 2002 18:03:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7G13sRI020659 for mobile-ip-dist; Thu, 15 Aug 2002 18:03:54 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7G13m3U020652 for ; Thu, 15 Aug 2002 18:03:48 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.5+Sun/8.12.5) with SMTP id g7G13vmG976752; Thu, 15 Aug 2002 18:03:58 -0700 (PDT) Message-Id: <200208160103.g7G13vmG976752@jurassic.eng.sun.com> Date: Thu, 15 Aug 2002 18:06:39 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] 2 Questions on Mobile Draft 18 To: kumarkr@us.ibm.com Cc: mobile-ip@sunroof.eng.sun.com, jari.arkko@kolumbus.fi MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: he28yWqmVz9vOKwrq70fYA== 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: > 1. In section 5.2.1 : > > 5.2.2. Nonces > > Each correspondent node also generates nonces at regular intervals, > for example every few minutes. The nonces should be generated by > using a random number generator that is known to have good randomness > properties [1]. A correspondent node may use the same Kcn and nonce > with all the mobiles it is in communication with, so that it does not > need to generate and store a new nonce when a new mobile contacts it. > > Does this mean that nonces are generated at regular intervals as stated in > the > first sentence, or the same one is used in all communications with all > mobile > nodes, as implied in the last sentence ? > It is the former. Since the nonces are generated in regular intervals, same nonce value will be used for "all" (or any) mobile nodes that send HOTI/COTI messages during that interval. -Samita From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 15 21:45: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 VAA23031 for ; Thu, 15 Aug 2002 21:45:51 -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 TAA10442; Thu, 15 Aug 2002 19:46: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 SAA21951; Thu, 15 Aug 2002 18:46:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7G1jS3U020862 for ; Thu, 15 Aug 2002 18:45:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7G1jSfb020861 for mobile-ip-dist; Thu, 15 Aug 2002 18:45: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 [129.146.17.55]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7G1jM3U020854 for ; Thu, 15 Aug 2002 18:45:22 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.5+Sun/8.12.5) with SMTP id g7G1jXmG990283; Thu, 15 Aug 2002 18:45:33 -0700 (PDT) Message-Id: <200208160145.g7G1jXmG990283@jurassic.eng.sun.com> Date: Thu, 15 Aug 2002 18:48:16 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: [mobile-ip] Home and COA cookie generation To: jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: W7t+r5g8P/gB/OmLcVUE0g== 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: Section 5.2.5 of draft 18, specifies the following algorithm for home cookie and coa cookie: home cookie = First64(MAC_Kcn(home address | nonce)) care-of cookie = First64(MAC_Kcn(care-of address | nonce)) Previously, (draft 16) talked about concatanating 0 and 1 for home cookie and care-of cookie, i.e: home cookie = MAC_Kcn (home_address | nonce| 0) coa cookie = MAC_Kcn (coa_address | nonce | 1) Have we decided not use 0 and 1 any more to distinguish the cookies ? Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 16 07:11:25 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11275 for ; Fri, 16 Aug 2002 07:11:25 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12973; Fri, 16 Aug 2002 05:12: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 EAA13261; Fri, 16 Aug 2002 04:12:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GBAx3U021915 for ; Fri, 16 Aug 2002 04:10:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7GBAx0K021914 for mobile-ip-dist; Fri, 16 Aug 2002 04:10:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GBAr3U021907 for ; Fri, 16 Aug 2002 04:10: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 EAA24530 for ; Fri, 16 Aug 2002 04:11:03 -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 FAA11098 for ; Fri, 16 Aug 2002 05:11:01 -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 g7GBAqRc016019; Fri, 16 Aug 2002 13:10:53 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 16 Aug 2002 13:10:52 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F08D5@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Vijay Devarapalli'" , Vladislav Yasevich Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] Question about MIPv6 draft 18 Date: Fri, 16 Aug 2002 13:10:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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: > how can it be a lot of cookies? the CN would be storing only > one K0/K1 per MN. a new pair of cookies can be created only if > the MN moves and does CoTi and HoTi for a new CoA and a new HoA. > how can one MN launch this DoS attack? => There are possibly 2^^64 addresses on a single link :) all can be CoAs. So it doesn't have to move anywhere. Hesham > > regards > Vijay > From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 16 10:10: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 KAA16268 for ; Fri, 16 Aug 2002 10:10:37 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02436; Fri, 16 Aug 2002 08:11: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 HAA26768; Fri, 16 Aug 2002 07:11:18 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GEA03U022352 for ; Fri, 16 Aug 2002 07:10:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7GE9xNA022351 for mobile-ip-dist; Fri, 16 Aug 2002 07:09:59 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GE9s3U022344 for ; Fri, 16 Aug 2002 07:09:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26434 for ; Fri, 16 Aug 2002 07:10:03 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12933 for ; Fri, 16 Aug 2002 08:10:02 -0600 (MDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2047666EE; Fri, 16 Aug 2002 10:10:02 -0400 (EDT) Received: from anw.zk3.dec.com (banw4.zk3.dec.com [16.140.128.5]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id BBCEB1426; Fri, 16 Aug 2002 10:10:01 -0400 (EDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7GEA1U0002278573; Fri, 16 Aug 2002 10:10:01 -0400 (EDT) Message-ID: <3D5D07B9.2050908@hp.com> Date: Fri, 16 Aug 2002 10:10:01 -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: Samita Chakrabarti Cc: jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Home and COA cookie generation References: <200208160145.g7G1jXmG990283@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 Hi Samita Why would you need to distinguish the cookies like this? -vlad Samita Chakrabarti wrote: > Section 5.2.5 of draft 18, specifies the following algorithm for > home cookie and coa cookie: > > home cookie = First64(MAC_Kcn(home address | nonce)) > > care-of cookie = First64(MAC_Kcn(care-of address | nonce)) > > > > Previously, (draft 16) talked about concatanating 0 and 1 for > home cookie and care-of cookie, i.e: > home cookie = MAC_Kcn (home_address | nonce| 0) > coa cookie = MAC_Kcn (coa_address | nonce | 1) > > Have we decided not use 0 and 1 any more to distinguish the cookies ? > > Thanks, > -Samita > > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Aug 16 12:36: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 MAA22121 for ; Fri, 16 Aug 2002 12:36:18 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06909; Fri, 16 Aug 2002 10:37: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 JAA03563; Fri, 16 Aug 2002 09:37:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GGZq3U022727 for ; Fri, 16 Aug 2002 09:35:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5/Submit) id g7GGZpJ3022726 for mobile-ip-dist; Fri, 16 Aug 2002 09:35: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 [129.146.17.55]) by sunroof.eng.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g7GGZk3U022719 for ; Fri, 16 Aug 2002 09:35:46 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.5+Sun/8.12.5) with SMTP id g7GGZumG220951; Fri, 16 Aug 2002 09:35:57 -0700 (PDT) Message-Id: <200208161635.g7GGZumG220951@jurassic.eng.sun.com> Date: Fri, 16 Aug 2002 09:38:39 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Home and COA cookie generation To: Vladislav.Yasevich@hp.com Cc: jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 9iG/lHMNSTiyx9Vx0wz/Zw== 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: > > Why would you need to distinguish the cookies like this? > > -vlad I don't know the reason why it was put in there before. That's why I was asking the question. -Samita > > Samita Chakrabarti wrote: > > Section 5.2.5 of draft 18, specifies the following algorithm for > > home cookie and coa cookie: > > > > home cookie = First64(MAC_Kcn(home address | nonce)) > > > > care-of cookie = First64(MAC_Kcn(care-of address | nonce)) > > > > > > > > Previously, (draft 16) talked about concatanating 0 and 1 for > > home cookie and care-of cookie, i.e: > > home cookie = MAC_Kcn (home_address | nonce| 0) > > coa cookie = MAC_Kcn (coa_address | nonce | 1) > > > > Have we decided not use 0 and 1 any more to distinguish the cookies ? > > > > Thanks, > > -Samita > > > > > > > > > -- > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 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 Aug 19 04:18: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 EAA24819 for ; Mon, 19 Aug 2002 04:18:06 -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 CAA17039; Mon, 19 Aug 2002 02:18: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 BAA19497; Mon, 19 Aug 2002 01:18:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J8HZ3c028386 for ; Mon, 19 Aug 2002 01:17:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7J8HZWd028385 for mobile-ip-dist; Mon, 19 Aug 2002 01:17: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J8HT3c028378 for ; Mon, 19 Aug 2002 01:17:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA11096 for ; Mon, 19 Aug 2002 01:17:39 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08425 for ; Mon, 19 Aug 2002 02:17:38 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 433036A906; Mon, 19 Aug 2002 11:17:21 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 786566A904; Mon, 19 Aug 2002 11:17:18 +0300 (EEST) Message-ID: <3D60AAB0.4080704@kolumbus.fi> Date: Mon, 19 Aug 2002 11:22:08 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Krishna Kumar Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] 2 Questions on Mobile Draft 18 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=none version=2.31 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: > Each correspondent node also generates nonces at regular intervals, > for example every few minutes. The nonces should be generated by > using a random number generator that is known to have good randomness > properties [1]. A correspondent node may use the same Kcn and nonce > with all the mobiles it is in communication with, so that it does not > need to generate and store a new nonce when a new mobile contacts it. > > Does this mean that nonces are generated at regular intervals as stated in > the > first sentence, or the same one is used in all communications with all > mobile > nodes, as implied in the last sentence ? As Samita commented earlier, the former is the right interpreration. But the text is a bit unclear. How about this: A correspondent node may use the same Kcn and nonce with all the mobiles it is in communication with, so that it does not need to generate and store a new nonce when a new mobile contacts it. => A correspondent node uses the same Kcn and nonce with all the mobiles it is in communication with. I'll assign this issue #96. > 2. Binding Refresh Advice (Section 6.2.8) : This Type=7 is missing in > Section 13, > the IANA considerations. Also, the type should be 6! Yes. Thanks for noticing this. Issue #97. The Type will be set to 6 in Section 6.2.8, and it will be listed in Section 13. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 19 04:41: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 EAA25191 for ; Mon, 19 Aug 2002 04:41: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 CAA23664; Mon, 19 Aug 2002 02:42:04 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23927; Mon, 19 Aug 2002 01:42:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J8er3c028574 for ; Mon, 19 Aug 2002 01:40:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7J8erhT028573 for mobile-ip-dist; Mon, 19 Aug 2002 01:40:53 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J8ej3c028566 for ; Mon, 19 Aug 2002 01:40:46 -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 BAA28314 for ; Mon, 19 Aug 2002 01:40:56 -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 BAA08772 for ; Mon, 19 Aug 2002 01:40:55 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 10CDB6A906; Mon, 19 Aug 2002 11:40:54 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 337276A904; Mon, 19 Aug 2002 11:40:51 +0300 (EEST) Message-ID: <3D60B035.4040409@kolumbus.fi> Date: Mon, 19 Aug 2002 11:45:41 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com, Tuomas Aura , Michael Roe Subject: Re: [mobile-ip] Home and COA cookie generation References: <200208160145.g7G1jXmG990283@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 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: > Section 5.2.5 of draft 18, specifies the following algorithm for > home cookie and coa cookie: > > home cookie = First64(MAC_Kcn(home address | nonce) > care-of cookie = First64(MAC_Kcn(care-of address | nonce)) > > Previously, (draft 16) talked about concatanating 0 and 1 for > home cookie and care-of cookie, i.e: > home cookie = MAC_Kcn (home_address | nonce| 0) > coa cookie = MAC_Kcn (coa_address | nonce | 1) > > Have we decided not use 0 and 1 any more to distinguish the cookies ? The rules have been simplified in draft 18. There does not seem to be any advantage in making the cookies truly different this way. (A long time ago we debated whether the cookies must depend on both addresses, but that was another issue.) The inclusion of the 0 or 1 in the input of the MAC has the effect of requiring the MN to use specifically the Home Test and the Care-of Test messages to retrieve the corresponding cookies. If these values are not included, an attacker could use the value acquired through a Care-of Test message as a home cookie. However, this does not appear to make the life of the attacker any easier; if the attacker can send a particular MH message then he can most likely send another MH message as well. Obviously, the cookies are still dependent on the addresses so the attacker can't get a home cookie without being able to receive traffic at the home address. Tuomas or Mike may comment on this, as the values were included in BAKE/2. My proposal is to not include the values unless we have an explicit reason to do so. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 19 05:33: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 FAA26369 for ; Mon, 19 Aug 2002 05:33: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 DAA17067; Mon, 19 Aug 2002 03:34: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 CAA04545; Mon, 19 Aug 2002 02:34:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J9Xa3c028933 for ; Mon, 19 Aug 2002 02:33:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7J9XaJm028932 for mobile-ip-dist; Mon, 19 Aug 2002 02:33: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J9XV3c028925 for ; Mon, 19 Aug 2002 02:33:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22202 for ; Mon, 19 Aug 2002 02:33: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 DAA06359 for ; Mon, 19 Aug 2002 03:33:40 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id AB9846A906; Mon, 19 Aug 2002 12:33:38 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 071576A904 for ; Mon, 19 Aug 2002 12:33:36 +0300 (EEST) Message-ID: <3D60BC92.1010805@kolumbus.fi> Date: Mon, 19 Aug 2002 12:38:26 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] issues 92, 94, 95 and text for sending BAs with RH Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit I have updated the text proposals to fix issues #92, #94 and #95 based on comments I received. Namely, we do not want to prevent site-local addresses from using mobility. Also, the text becomes simpler if the condition for using RH is the presense of HAO in the BU. New text for 9.4.4: The acknowledgement is sent to the Source Address of the IPv6 header that carried the Binding Update. Note that this procedure is independent from the treatment of regular packets and does not use information from the Binding Cache. If the Source Address field does not contain a site-local or global unicast address, the Binding Acknowledgement MUST NOT be sent. Otherwise, further processing depends on whether or not the Binding Update contains a Home Address destination option. If it does, the source address is the home address of the mobile node and the Binding Acknowledgement MUST be sent directly to this address. Otherwise, the Binding Acknowledgement MUST still be sent to the source address but a Type 2 Routing Header MUST be added to the packet to carry the home address. And for 10.2: The acknowledgement is sent to the Source Address of the IPv6 header that carried the Binding Update. Note that this procedure is independent from the treatment of regular packets and does not use information from the Binding Cache. If the Source Address field does not contain a unicast address, the Binding Acknowledgement MUST NOT be sent. Otherwise, further processing depends on whether or not the Binding Update contains a Home Address destination option. If it does, the source address is the home address of the mobile node and the Binding Acknowledgement MUST be sent directly to this address. Otherwise, the Binding Acknowledgement MUST still be sent to the source address but a Type 2 Routing Header MUST be added to the packet to carry the home address. From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 19 10:39: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 KAA03431 for ; Mon, 19 Aug 2002 10:39:19 -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 IAA11146; Mon, 19 Aug 2002 08:40: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 HAA12223; Mon, 19 Aug 2002 07:40:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JEcf3c000628 for ; Mon, 19 Aug 2002 07:38:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JEcf0r000627 for mobile-ip-dist; Mon, 19 Aug 2002 07:38: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JEcX3c000620 for ; Mon, 19 Aug 2002 07:38:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA11869 for ; Mon, 19 Aug 2002 07:38:43 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01759 for ; Mon, 19 Aug 2002 08:38:42 -0600 (MDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 1F9C451E; Mon, 19 Aug 2002 09:38:42 -0500 (CDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 9BA1814AD; Mon, 19 Aug 2002 10:38:41 -0400 (EDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id KAA0001677500; Mon, 19 Aug 2002 10:38:41 -0400 (EDT) Message-ID: <3D6102F0.6C4B9DC9@hp.com> Date: Mon, 19 Aug 2002 10:38:41 -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: Jari Arkko Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with RH References: <3D60BC92.1010805@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, I'm confused, all Binding Updates must contain a Home Address option, so that check is always true. I thought draft 15 had good text about this: "Furthermore, if the packet is to be sent to the mobile node at any address other than the mobile node's home address, it MUST be sent using a Routing header (even if the binding was rejected)." The point being that if the source and home address are equal, we don't use a Routing Header. At Cthon 2002 we agreed this was good since we're conserving bytes on the wire(less). Your third paragraph in each of these below seems to contradict itself: 1) If a HAO is present, the BAck must be sent directly to this address. This implies no route optimization. 2) If a HAO is not present, the BAck is sent to the source of the packet with the home address in the T2 RH. But in this case we don't have a home address to put in the RH. -Brian Jari Arkko wrote: > I have updated the text proposals to fix issues > #92, #94 and #95 based on comments I received. Namely, we do not > want to prevent site-local addresses from using mobility. Also, > the text becomes simpler if the condition for using RH is the presense > of HAO in the BU. > > New text for 9.4.4: > > The acknowledgement is sent to the Source Address of the IPv6 header > that carried the Binding Update. Note that this procedure is > independent from the treatment of regular packets and does not use > information from the Binding Cache. > > If the Source Address field does not contain a site-local or global > unicast address, the Binding Acknowledgement MUST NOT be sent. > > Otherwise, further processing depends on whether or not the Binding > Update contains a Home Address destination option. If it does, the > source address is the home address of the mobile node and the > Binding Acknowledgement MUST be sent directly to this address. > Otherwise, the Binding Acknowledgement MUST still be sent to the > source address but a Type 2 Routing Header MUST be added to the > packet to carry the home address. > > And for 10.2: > > The acknowledgement is sent to the Source Address of the IPv6 header > that carried the Binding Update. Note that this procedure is > independent from the treatment of regular packets and does not use > information from the Binding Cache. > > If the Source Address field does not contain a unicast address, the > Binding Acknowledgement MUST NOT be sent. > > Otherwise, further processing depends on whether or not the Binding > Update contains a Home Address destination option. If it does, the > source address is the home address of the mobile node and the > Binding Acknowledgement MUST be sent directly to this address. > Otherwise, the Binding Acknowledgement MUST still be sent to the > source address but a Type 2 Routing Header MUST be added to the > packet to carry the home address. From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 19 13:23: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 NAA10258 for ; Mon, 19 Aug 2002 13:23:25 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17387; Mon, 19 Aug 2002 11:24: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 KAA15431; Mon, 19 Aug 2002 10:23:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JHMi3c001669 for ; Mon, 19 Aug 2002 10:22:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JHMiMw001668 for mobile-ip-dist; Mon, 19 Aug 2002 10:22:44 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JHMc3c001661 for ; Mon, 19 Aug 2002 10:22:38 -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 KAA15033 for ; Mon, 19 Aug 2002 10:22:47 -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 LAA24719 for ; Mon, 19 Aug 2002 11:22:47 -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 3A1E120CF; Mon, 19 Aug 2002 10:22:47 -0700 (PDT) Received: from anw.zk3.dec.com (band.zk3.dec.com [16.140.128.6]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 1286DF20; Mon, 19 Aug 2002 12:22:46 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7JHMjM0001648038; Mon, 19 Aug 2002 13:22:45 -0400 (EDT) Message-ID: <3D612965.20807@hp.com> Date: Mon, 19 Aug 2002 13:22:45 -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: jari.arkko@kolumbus.fi Cc: MobilIP Subject: [mobile-ip] Additional question on BAs 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 If the BA is sent to the mobile node, in response to BU, with the status of 137 (Invalid authenticator), 138 (Expired Home Nonce Index), or 139 (Expired Care-of Nonce Index), shuld this BA contains the Authorization Data option and authenticator? It looks to me like it should not because the CN was unable to authenticate the BU. -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 Aug 19 14:57: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 OAA12811 for ; Mon, 19 Aug 2002 14:57:11 -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 LAA20422; Mon, 19 Aug 2002 11:56:27 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21783; Mon, 19 Aug 2002 11:56:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JItL3c002010 for ; Mon, 19 Aug 2002 11:55:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JItLIe002009 for mobile-ip-dist; Mon, 19 Aug 2002 11:55:21 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JItF3c002002 for ; Mon, 19 Aug 2002 11:55:15 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with SMTP id g7JItPUo828491; Mon, 19 Aug 2002 11:55:25 -0700 (PDT) Message-Id: <200208191855.g7JItPUo828491@jurassic.eng.sun.com> Date: Mon, 19 Aug 2002 11:58:08 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with RH To: jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ImBETzxgEOPdno0eRgX+JA== 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, As noted earlier, the third paragraph in both sections seems to be incorrect. Please see the comments below. > I have updated the text proposals to fix issues > #92, #94 and #95 based on comments I received. Namely, we do not > want to prevent site-local addresses from using mobility. Also, > the text becomes simpler if the condition for using RH is the presense > of HAO in the BU. > > New text for 9.4.4: > > The acknowledgement is sent to the Source Address of the IPv6 header > that carried the Binding Update. Note that this procedure is > independent from the treatment of regular packets and does not use > information from the Binding Cache. > > If the Source Address field does not contain a site-local or global > unicast address, the Binding Acknowledgement MUST NOT be sent. > ... and the binding update packet is dropped. (please add this for clarification). > Otherwise, further processing depends on whether or not the Binding > Update contains a Home Address destination option. If it does, the > source address is the home address of the mobile node and the > Binding Acknowledgement MUST be sent directly to this address. > Otherwise, the Binding Acknowledgement MUST still be sent to the > source address but a Type 2 Routing Header MUST be added to the > packet to carry the home address. > Perhaps you mean to say the following: If the source address of the Binding Update is equal to the home address of the mobile node in the binding cache (i.e. mobile node is back at home) or the home-address in the HAO, then also it sends the BA to it's source addr (in this case, home-addr)-- so we are already covered by the first paragraph. Also 9.4.4 also specifies in the beginning that: Furthermore, if the packet is to be sent to the mobile node at any address other than the mobile node's home address, it MUST be sent using a Routing header (even if the binding was rejected). So, I think the third paragraph is incorrect and unnecessary in section 9.4.4. For section 10.2, situation is a little different that BU may not contain a HAO ( as per 6.1.7), but even in that case your first and second paragraph are okay. The third paragraph should write the following: ( as discussed and agreed at Cthon2002, Brian H. already mentioned) If the Source Address field in the IPv6 header of the Binding Update is equal to the home address of mobile node, then it indicates that the mobile node is back at home. In this case, Binding Acknowledgement does (MUST?) not include Type 2 Routing Header. BTW, I kind of liked the list of illegal addresses for the RH Type 2 header for clarification in spec. > And for 10.2: > > The acknowledgement is sent to the Source Address of the IPv6 header > that carried the Binding Update. Note that this procedure is > independent from the treatment of regular packets and does not use > information from the Binding Cache. > > If the Source Address field does not contain a unicast address, the ^^^^^^^^^^^^^^^^^ Unicast address alone is not enough. Did you mean to say site-local and global unicast address ? > Binding Acknowledgement MUST NOT be sent. > > Otherwise, further processing depends on whether or not the Binding > Update contains a Home Address destination option. If it does, the > source address is the home address of the mobile node and the > Binding Acknowledgement MUST be sent directly to this address. > Otherwise, the Binding Acknowledgement MUST still be sent to the > source address but a Type 2 Routing Header MUST be added to the > packet to carry the home address. > BTW, why do we need to include RH Type 2 in BA when src-addr != home-addr, is this because of authentication verification at the MN end ? May be we should clarify that in the draft. Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 19 15:03:05 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 PAA13030 for ; Mon, 19 Aug 2002 15:03:05 -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 MAA24132; Mon, 19 Aug 2002 12:02: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 MAA07930; Mon, 19 Aug 2002 12:02:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JJ1D3c002183 for ; Mon, 19 Aug 2002 12:01:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JJ1Dv2002182 for mobile-ip-dist; Mon, 19 Aug 2002 12: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 jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JJ173c002175 for ; Mon, 19 Aug 2002 12:01:07 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with SMTP id g7JJ1IUo830788; Mon, 19 Aug 2002 12:01:18 -0700 (PDT) Message-Id: <200208191901.g7JJ1IUo830788@jurassic.eng.sun.com> Date: Mon, 19 Aug 2002 12:04:01 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Home and COA cookie generation To: jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com, tuomaura@microsoft.com, mroe@microsoft.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DP58f1zvBzgtwrQSzJHWrQ== 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 wrote: > > Section 5.2.5 of draft 18, specifies the following algorithm for > > home cookie and coa cookie: > > > > home cookie = First64(MAC_Kcn(home address | nonce) > > care-of cookie = First64(MAC_Kcn(care-of address | nonce)) > > > > Previously, (draft 16) talked about concatanating 0 and 1 for > > home cookie and care-of cookie, i.e: > > home cookie = MAC_Kcn (home_address | nonce| 0) > > coa cookie = MAC_Kcn (coa_address | nonce | 1) > > > > Have we decided not use 0 and 1 any more to distinguish the cookies ? > > The rules have been simplified in draft 18. There does not > seem to be any advantage in making the cookies truly different > this way. (A long time ago we debated whether the cookies must > depend on both addresses, but that was another issue.) > > The inclusion of the 0 or 1 in the input of the MAC has the > effect of requiring the MN to use specifically the Home Test > and the Care-of Test messages to retrieve the corresponding > cookies. If these values are not included, an attacker could > use the value acquired through a Care-of Test message as a > home cookie. However, this does not appear to make the life > of the attacker any easier; if the attacker can send a particular > MH message then he can most likely send another MH message as > well. Obviously, the cookies are still dependent on the addresses > so the attacker can't get a home cookie without being able to > receive traffic at the home address. > > Tuomas or Mike may comment on this, as the values were included > in BAKE/2. My proposal is to not include the values unless we > have an explicit reason to do so. Thanks for the explanation. I am fine with current proposal. -Samita From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 19 16:50: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 QAA15554 for ; Mon, 19 Aug 2002 16:50: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 OAA21025; Mon, 19 Aug 2002 14:51: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 NAA00268; Mon, 19 Aug 2002 13:51:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JKnQ3c002489 for ; Mon, 19 Aug 2002 13:49:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JKnQHA002488 for mobile-ip-dist; Mon, 19 Aug 2002 13:49: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JKnI3c002481 for ; Mon, 19 Aug 2002 13:49:18 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA29312 for ; Mon, 19 Aug 2002 13:49:30 -0700 (PDT) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19389 for ; Mon, 19 Aug 2002 14:49:29 -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 7ABAE120F; Mon, 19 Aug 2002 13:49:29 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 824C9C82; Mon, 19 Aug 2002 15:49:28 -0500 (CDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id QAA0001738451; Mon, 19 Aug 2002 16:49:27 -0400 (EDT) Message-ID: <3D6159D7.F1F9C41D@hp.com> Date: Mon, 19 Aug 2002 16:49:27 -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: jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with RH References: <200208191855.g7JItPUo828491@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Samita Chakrabarti wrote: > For section 10.2, situation is a little different that BU may not contain a > HAO ( as per 6.1.7), but even in that case your first and second paragraph > are okay. The third paragraph should write the following: Well, I completely missed that comment in section 6.1.7 about the HAO, especially since section 10.2 says: "- A Home Address destination option MUST be present in the message." There's been so many changes to all sections of the draft it's getting hard to remember if this is already fixed, but if an HAO isn't necessary for home bindings, then please copy the text from 6.1.7 to 10.2. That said, why have this optimization? Do the byte-savings outweigh the added complexity? -Brian From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 19 18:12: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 SAA16986 for ; Mon, 19 Aug 2002 18:12: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 QAA06216; Mon, 19 Aug 2002 16:13:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01115; Mon, 19 Aug 2002 15:13:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JMC33c002827 for ; Mon, 19 Aug 2002 15:12:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JMC3Yp002826 for mobile-ip-dist; Mon, 19 Aug 2002 15:12:03 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JMBu3c002818 for ; Mon, 19 Aug 2002 15:11:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA00622 for ; Mon, 19 Aug 2002 15:12:07 -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 QAA20149 for ; Mon, 19 Aug 2002 16:12:05 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 257296A906; Tue, 20 Aug 2002 01:12:05 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3131F6A901; Tue, 20 Aug 2002 01:12:03 +0300 (EEST) Message-ID: <3D616E56.10805@kolumbus.fi> Date: Tue, 20 Aug 2002 01:16:54 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with RH References: <200208191855.g7JItPUo828491@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 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: >> If the Source Address field does not contain a site-local or global >> unicast address, the Binding Acknowledgement MUST NOT be sen > > ... and the binding update packet is dropped. > (please add this for clarification). => ... the Binding Update MUST be silently discarded, and the Binding Acknowledgement MUST NOT be sent. > Furthermore, if the packet > is to be sent to the mobile node at any address other than the mobile > node's home address, it MUST be sent using a Routing header (even if > the binding was rejected). > > So, I think the third paragraph is incorrect and unnecessary in section 9.4.4. This was a part of the old text that the new text is expected to replace. So, we need to keep this part of the old text... just that it could perhaps be more exact so that it would say exactly when are we not sending to the home address and what type of RH to use. Feel free to propose text ;-) > > For section 10.2, situation is a little different that BU may not contain a > HAO ( as per 6.1.7), but even in that case your first and second paragraph > are okay. The third paragraph should write the following: According to Brian, all BUs contain a HAO. > ( as discussed and agreed at Cthon2002, Brian H. already mentioned) > > If the Source Address field in the IPv6 header of the Binding Update is > equal to the home address of mobile node, then it indicates that the > mobile node is back at home. In this case, Binding Acknowledgement does > (MUST?) not include Type 2 Routing Header. Couldn't we use this text in both 9.4.4 and 10.2? >>And for 10.2: >> >> The acknowledgement is sent to the Source Address of the IPv6 header >> that carried the Binding Update. Note that this procedure is >> independent from the treatment of regular packets and does not use >> information from the Binding Cache. >> >> If the Source Address field does not contain a unicast address, the > > ^^^^^^^^^^^^^^^^^ > Unicast address alone is not enough. Did you mean to say site-local and > global unicast address ? Global unicast addresses are obviously allowed. I think link-locals can also be used for dereg to the HA. And, wouldn't it be bad if made it illegal to use MIPv6 within a site that uses only site-local addresses? So that was the justification for allowing all unicast addresses. However, on second look this covers also NSAP addresss, the unspecified address etc. So perhaps we should stick with "link-local, site-local, or global unicast addresses". Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 19 18:12: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 SAA17001 for ; Mon, 19 Aug 2002 18:12:57 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01783; Mon, 19 Aug 2002 16:13: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 PAA01190; Mon, 19 Aug 2002 15:13:42 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JMBu3c002817 for ; Mon, 19 Aug 2002 15:11:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JMBuAZ002816 for mobile-ip-dist; Mon, 19 Aug 2002 15: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JMBo3c002809 for ; Mon, 19 Aug 2002 15:11:50 -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 PAA00599 for ; Mon, 19 Aug 2002 15:12: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 QAA09511 for ; Mon, 19 Aug 2002 16:12:00 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 8807D6A904; Tue, 20 Aug 2002 01:11:59 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B71F26A901; Tue, 20 Aug 2002 01:11:57 +0300 (EEST) Message-ID: <3D616E51.4030508@kolumbus.fi> Date: Tue, 20 Aug 2002 01:16:49 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haley Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with RH References: <3D60BC92.1010805@kolumbus.fi> <3D6102F0.6C4B9DC9@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brian Haley wrote: > Jari, > > I'm confused, all Binding Updates must contain a Home Address option, > so that check is always true. I thought draft 15 had good text about this: It seems that there's even more to fix: 6.1.7 allows optional HAO. For CNs, 9.4.1 always requires a HAO but 11.6.2. allows optional HAO. For HAs, 11.6.1 10.2, and 10.3 all agree that a HAO is needed. My mistake... So, this should be fixed as always requiring a HAO, even when sending from the home address? > "Furthermore, if the packet > is to be sent to the mobile node at any address other than the mobile > node's home address, it MUST be sent using a Routing header (even if > the binding was rejected)." > > The point being that if the source and home address are equal, we don't > use a Routing Header. At Cthon 2002 we agreed this was good since > we're conserving bytes on the wire(less). Agree with this. > Your third paragraph in each of these below seems to contradict itself: > > 1) If a HAO is present, the BAck must be sent directly to this address. > This implies no route optimization. > > 2) If a HAO is not present, the BAck is sent to the source of the packet > with the home address in the T2 RH. But in this case we don't have > a home address to put in the RH. Yes, the third paragraph is bad... The intention was to say that if HAO is present, then include a T2 RH. And if the HAO is not present, then send directly. Based on this and the above, we need a new third paragraph. Jari From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 19 18:35: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 SAA17226 for ; Mon, 19 Aug 2002 18:35:56 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA02619; Mon, 19 Aug 2002 15:35: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 PAA03219; Mon, 19 Aug 2002 15:35:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JMXi3c003139 for ; Mon, 19 Aug 2002 15:33:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7JMXhFC003138 for mobile-ip-dist; Mon, 19 Aug 2002 15:33:43 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7JMXc3c003131 for ; Mon, 19 Aug 2002 15:33:38 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with SMTP id g7JMXmUo895771; Mon, 19 Aug 2002 15:33:49 -0700 (PDT) Message-Id: <200208192233.g7JMXmUo895771@jurassic.eng.sun.com> Date: Mon, 19 Aug 2002 15:36:32 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with RH To: jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ATnL+ZcdZkb5hK55X+tTPQ== 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: > > > > ... and the binding update packet is dropped. > > (please add this for clarification). > > => ... the Binding Update MUST be silently discarded, and the Binding > Acknowledgement MUST NOT be sent. > Ok. Thanks. > > > Furthermore, if the packet > > is to be sent to the mobile node at any address other than the mobile > > node's home address, it MUST be sent using a Routing header (even if > > the binding was rejected). > > > > So, I think the third paragraph is incorrect and unnecessary in section 9.4.4. > > This was a part of the old text that the new text is expected to replace. > So, we need to keep this part of the old text... just that it could perhaps > be more exact so that it would say exactly when are we not sending to the home > address and what type of RH to use. Feel free to propose text ;-) > Well, I think the above old text is good to keep. But the line after this text needs to change. I'd leave it to the editor :-) > > > > For section 10.2, situation is a little different that BU may not contain a > > HAO ( as per 6.1.7), but even in that case your first and second paragraph > > are okay. The third paragraph should write the following: > > According to Brian, all BUs contain a HAO. > If so, then we have to make sure that we don't have any inconsistency in any other places in the draft. For example, Section 6.1.7 says: A Binding Update to the home agent MUST include the Home Address destination option if the Source Address field in the IPv6 header is not the home address of the mobile node. If we decide BU MUST always contain HAO, then the above text will have to change. I thought, BU MUST contain HA0 for Route Optimization BU, but is not necessary for home agent registration while back at home. If making HAO mandatory for all BUs makes the code and the protocol less complex, I am all for it. > > ( as discussed and agreed at Cthon2002, Brian H. already mentioned) > > > > If the Source Address field in the IPv6 header of the Binding Update is > > equal to the home address of mobile node, then it indicates that the > > mobile node is back at home. In this case, Binding Acknowledgement does > > (MUST?) not include Type 2 Routing Header. > > Couldn't we use this text in both 9.4.4 and 10.2? > I don't see a problem in using it for both cases. > >>And for 10.2: > >> > >> The acknowledgement is sent to the Source Address of the IPv6 header > >> that carried the Binding Update. Note that this procedure is > >> independent from the treatment of regular packets and does not use > >> information from the Binding Cache. > >> > >> If the Source Address field does not contain a unicast address, the > > > > ^^^^^^^^^^^^^^^^^ > > Unicast address alone is not enough. Did you mean to say site-local and > > global unicast address ? > > > Global unicast addresses are obviously allowed. I think link-locals can also > be used for dereg to the HA. And, wouldn't it be bad if made it illegal > to use MIPv6 within a site that uses only site-local addresses? So that > was the justification for allowing all unicast addresses. However, on > second look this covers also NSAP addresss, the unspecified address etc. > So perhaps we should stick with "link-local, site-local, or global unicast > addresses". > Ok with me. Thanks, -Samita From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 19 20:11: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 UAA18581 for ; Mon, 19 Aug 2002 20:11:14 -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 RAA22070; Mon, 19 Aug 2002 17:10: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 RAA13657; Mon, 19 Aug 2002 17:10:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7K09F3c003519 for ; Mon, 19 Aug 2002 17:09:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7K09F5W003518 for mobile-ip-dist; Mon, 19 Aug 2002 17:09:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7K0993c003511 for ; Mon, 19 Aug 2002 17:09:09 -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 RAA13120 for ; Mon, 19 Aug 2002 17:09:21 -0700 (PDT) Received: from lit.a-star.edu.sg (rodin.krdl.org.sg [192.122.139.27]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA21539 for ; Mon, 19 Aug 2002 17:09:20 -0700 (PDT) Received: from mailhost1 (localhost [127.0.0.1]) by lit.a-star.edu.sg (8.11.1/8.11.1) with ESMTP id g7K07ns10651 for ; Tue, 20 Aug 2002 08:07:49 +0800 (SGT) X-Authentication-Warning: rodin.lit.org.sg: iscan owned process doing -bs Received: from vsys (vsys.lit.org.sg [192.168.137.194]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 HotFix 0.5 (built Jun 7 2002)) with SMTP id <0H14003LT8H8QF@mailhost.lit.org.sg> for mobile-ip@sunroof.eng.sun.com; Tue, 20 Aug 2002 08:10:27 +0800 (SGT) Date: Tue, 20 Aug 2002 08:09:09 +0800 From: Vrizlynn Thing Subject: Re: [mobile-ip] CN to MN (Sending Binding Acknowledgement) To: Jari Arkko , vriz@lit.org.sg Cc: Mobile IP Mailing List Message-id: <001601c247dd$d2f7b9b0$c289a8c0@vsys> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <351713a06f.3a06f35171@lit.org.sg> <3D60BEA9.1050307@kolumbus.fi> 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: "Jari Arkko" To: Cc: "Mobile IP Mailing List" Sent: Monday, August 19, 2002 5:47 PM Subject: Re: [mobile-ip] CN to MN (Sending Binding Acknowledgement) > > This is debatable, I think. I'm not sure I see why we would _have_ to send > it either with RH2 or without. Couldn't we simply do it the same way as we > do for the regular BA? > > > Will there be any security loophole in this case? > > I don't think we have any security loophole if we always respond to the same > source address that was in the request. Adding RH2 doesn't really cause anything > terrible to happen, as the result will stay within the same node. > I believe we could do that in a consistent way (sending RH2 even in event of failure status for BAck, if dest opt is used), if it doesn't raise any security issue. Vrizlynn Thing (Ms.) Senior Engineer Laboratories for Information Technology 21 Heng Mui Keng Terrace Singapore 119613 Tel: +65 68746728 Fax: +65 67768109 Email: vriz@lit.a-star.edu.sg From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 19 21:17: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 VAA19715 for ; Mon, 19 Aug 2002 21:16:57 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21244; Mon, 19 Aug 2002 19:17:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA06460; Mon, 19 Aug 2002 18:17:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7K1GL3c003825 for ; Mon, 19 Aug 2002 18:16:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7K1GLXZ003824 for mobile-ip-dist; Mon, 19 Aug 2002 18:16: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7K1G43c003806; Mon, 19 Aug 2002 18:16: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 SAA05773; Mon, 19 Aug 2002 18:16:08 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA10319; Mon, 19 Aug 2002 18:16:03 -0700 (PDT) Received: from kenawang ([147.11.233.13]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id SAA25602; Mon, 19 Aug 2002 18:14:24 -0700 (PDT) Message-Id: <4.2.2.20020819211305.0284a1b0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 19 Aug 2002 21:15:13 -0400 To: Erik Nordmark From: Margaret Wasserman Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization Cc: Robert Elz , Dave Thaler , "Charles E. Perkins" , itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, IPng Working Group In-Reply-To: References: <"Your message with ID" <770.1023183551@munnari.OZ.AU> 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: At 06:26 AM 6/4/02 , Erik Nordmark wrote: > > | My preference is that we just ban DAD optimization in all cases. > > > > That's certainly an option. The "new prefix causes several thousand > > nodes to all attempt DAD at the same time" argument is the one which > > makes me hesitant to simply support this without further investigation. If thousands of nodes are involved, the DAD optimization may not be enough to fix this problem. Instead, we might need some sort of random delay on the creation of addresses when a new prefix is received. Margaret From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 04:00:16 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07302 for ; Tue, 20 Aug 2002 04:00:16 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA26348; Tue, 20 Aug 2002 02:01: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 BAA05623; Tue, 20 Aug 2002 01:01:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7K7xp3c005164 for ; Tue, 20 Aug 2002 00:59:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7K7xpkc005163 for mobile-ip-dist; Tue, 20 Aug 2002 00:59:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7K7xk3c005156 for ; Tue, 20 Aug 2002 00:59:46 -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 AAA03030 for ; Tue, 20 Aug 2002 00:59:57 -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 BAA25815 for ; Tue, 20 Aug 2002 01:59:54 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 30D926A904; Tue, 20 Aug 2002 10:59:52 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id AE9FC6A901; Tue, 20 Aug 2002 10:59:43 +0300 (EEST) Message-ID: <3D61F813.7040804@piuha.net> Date: Tue, 20 Aug 2002 11:04:35 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haley Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with RH References: <200208191855.g7JItPUo828491@jurassic.eng.sun.com> <3D6159D7.F1F9C41D@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brian Haley wrote: > That said, why have this optimization? Do the byte-savings outweigh the > added complexity? The HAO could be omitted only in the de-registration case, which may not be frequent enough to talk about big savings. One argument for making HAO optional in BUs is that then it would follow the use of HAO in other traffic, i.e. if you are at home you don't include it. However, it seems that getting this described in text is going to take some amount of words; it would be specification-wise simpler to just say that all BUs must have a HAO. So I'm leaning towards that now... Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 04:31: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 EAA07957 for ; Tue, 20 Aug 2002 04:31:49 -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 BAA27658; Tue, 20 Aug 2002 01:31:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA09034; Tue, 20 Aug 2002 01:31:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7K8Tn3c005388 for ; Tue, 20 Aug 2002 01:29:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7K8TneT005387 for mobile-ip-dist; Tue, 20 Aug 2002 01:29: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7K8Th3c005380; Tue, 20 Aug 2002 01:29:44 -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 BAA07086; Tue, 20 Aug 2002 01:29:55 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26912; Tue, 20 Aug 2002 01:29:53 -0700 (PDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA28974; Tue, 20 Aug 2002 11:29:40 +0300 Date: Tue, 20 Aug 2002 11:29:40 +0300 Message-Id: <200208200829.LAA28974@burp.tkv.asdf.org> From: Markku Savela To: mrw@windriver.com CC: Erik.Nordmark@sun.com, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <4.2.2.20020819211305.0284a1b0@mail.windriver.com> (message from Margaret Wasserman on Mon, 19 Aug 2002 21:15:13 -0400) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <"Your message with ID" <770.1023183551@munnari.OZ.AU> <4.2.2.20020819211305.0284a1b0@mail.windriver.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > From: Margaret Wasserman > > > That's certainly an option. The "new prefix causes several thousand > > > nodes to all attempt DAD at the same time" argument is the one which > > > makes me hesitant to simply support this without further investigation. > > If thousands of nodes are involved, the DAD optimization may not be > enough to fix this problem. Umm? DAD optimization definitely removes the quoted problem. When optimized, DAD is only done on the link local address when a node is attached (or booted) to the network. > Instead, we might need some sort of random delay on the creation of > addresses when a new prefix is received. The random delay is already specified for DAD in the boot/attach process. The delay is less suitable for DAD's done on RA. In optimized environment, addresses are useable immediately after RA. With non-optimized and delayed DAD, we would have undetermined gap after RA, when an address retrieved from DNS might not work. I would like my network to be as deterministic as possible, avoid randomness when not absolutely necessary. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 08:46:24 2002 Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12230 for ; Tue, 20 Aug 2002 08:46:24 -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 GAA29801; Tue, 20 Aug 2002 06:47: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 FAA19917; Tue, 20 Aug 2002 05:47:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KCjs3c006019 for ; Tue, 20 Aug 2002 05:45:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KCjreD006018 for mobile-ip-dist; Tue, 20 Aug 2002 05:45: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KCjm3c006011 for ; Tue, 20 Aug 2002 05:45:48 -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 FAA20384 for ; Tue, 20 Aug 2002 05:45:59 -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 FAA23574 for ; Tue, 20 Aug 2002 05:45:51 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id F16666A901; Tue, 20 Aug 2002 15:45:46 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 56D476A904; Tue, 20 Aug 2002 15:45:34 +0300 (EEST) Message-ID: <3D6233FD.4030409@kolumbus.fi> Date: Tue, 20 Aug 2002 15:20:13 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Re: MIPv6 Draft 18 Comments References: <200208091832.g79IWvmG693229@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Thanks Samita for your review! Some discussion inline: > 1. > Section 4. Basic Operation > > It's good add a subsection at the end to describe the two > modes of operation for clarity : > 1) MN-CN communication through reverse tunnel via HA > 2) MN-CN communication using Route Optimization > In this section, we can specify that RR procedure > is the default RO mechanism defined in this draft. Agreed. (I'll group this and the following items under a new issue #100.) > 2. > Since, lifetime field has been changed to > 16 bit, s/0xffffffff/0xffff Yes. > 3. > section 6.1.7 (BU) > Now that we removed home-address field from the BU > message and made HAO manadatory for all BUs for > which src-addr is not home-addr. A line after the > following paragraph is needed: > > A Binding Update to the home agent MUST include the Home Address > destination option if the Source Address field in the IPv6 header is > not the home address of the mobile node. > > i,e. > A binding Update to the Correspondent node MUST include > home address option (section 9.4.1) . Ok, this is being discussed separately. I think we are leaning towards having a HAO always. > 3. > section 6.1.8 indicates that we don't have "no Security > Association" status code anymore and we have: > > 137 Invalid authenticator > > That suggests Binding Authorization Data Option is manadatory > for all binding update messages--correct ? Not quite. BAD (!) options are mandatory for CN binding updates, but not for HA binding updates. > If that is the case, then that must be specified in 6.1.7 > as well. Otherwise, we need another status error code or > specification when the HA or CN receives a BU without > binding authorization data option. My suggestion is to rename 137 as "Invalid or missing authenticator", which would cover the case where BAD wasn't included in a BU to a CN. > 4. > > 6.1.9 > > Status code 1: > 1 Home Address destination option used without a binding > Is this still valid ? I think it is still valid, but a more proper name would perhaps be "Home Address destination option used without sufficient validation", the validation mechanisms being (1) existing binding or (2) use of IPSec. Note that this issue is separate from the discussion of whether or not the HAO and the IPsec validation are mandatory. (Whether or not they are, it is still possible that someone sends an unauthenticated HAO without a binding.) > 5. > section 8.2 Route Optimization Requirements for All IPv6 Nodes > > It's missing the MN behavior, > > How about adding a text something like this? > > A node that is performing mobile node operation MUST be able to > process RTHDR_TYPE2 extension header (section 11.2.3 and 6.4). > All other nodes MUST ignore and drop RTHDR_TYPE2 extensions. Hmm... ok, but the purpose of this section was to list only requirements for CNs. A CN can also be an MN at the same time. How about Unless the correspondent node is also acting as a mobile node, it MUST ignore Type 2 Routing headers and drop all packets that it has received with such headers. We should also change: The following requirements apply to all nodes that support route optimization: to The following requirements apply to all correspondent nodes that support route optimization: I'll put this under issue #101. > 6. > section 8.4 > > One more requirement to be added: > > - Every home agent MUST support IPSec ESP for protection of > packets belonging to Return Routability Procedure (section > 10.7). Yes. > 7. > > section 8.5 > > Additional requirement: > > -MUST be able to process RTHDR_TYPE2 extension header as defined > in 6.4 and 11.2.3 Yes. "RTHDR_TYPE2 extension header" => "Type 2 Routing header" > 8. > > section 9.2.2 , section 9.4.6 needs update as they specify that > HAO without binding asociation MUST be dropped. Yes. Back to issue #100. > 9. > section 10.3 > > remove: > - The Refresh field MUST be set to zero. Right. > 10. > section 9.4.1 > s/144/138 > s/145/139 > s/141/135 > > Perhaps there are more cases throughout the document. Yes (see also issue 91). > 11. > section 10. Home Agent Operation > > Should not we have a section here on "Processing Binding Updates" ? Isn't 10.2 & 10.3 just that? Or would you like a different name? Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 08:46: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 IAA12245 for ; Tue, 20 Aug 2002 08:46:29 -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 GAA10274; Tue, 20 Aug 2002 06:47: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 FAA19926; Tue, 20 Aug 2002 05:47:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KCk83c006032 for ; Tue, 20 Aug 2002 05:46:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KCk8OT006031 for mobile-ip-dist; Tue, 20 Aug 2002 05: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KCk03c006021 for ; Tue, 20 Aug 2002 05:46:00 -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 FAA19547 for ; Tue, 20 Aug 2002 05:46:11 -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 GAA13544 for ; Tue, 20 Aug 2002 06:46:04 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 695AC6A904; Tue, 20 Aug 2002 15:45:51 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1EEF26A906; Tue, 20 Aug 2002 15:45:40 +0300 (EEST) Message-ID: <3D62374D.4040908@kolumbus.fi> Date: Tue, 20 Aug 2002 15:34:21 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "Alan O'Neill" , "'Dave Thaler'" , Erik Nordmark , fenner@research.att.com Subject: [mobile-ip] moving on with the multicast issue (#63) References: <748C6D0A58C0F94CA63C198B6674697A0EBABC@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit A discussion has taken place on and off-list about the multicast mechanisms in MIPv6 and exactly what the base RFC must say and allow. The main discussion item has been whether to allow sending only via the HA, or also locally. We have come up with the following proposal in the discussion: 1. We clarify in the draft that HAO is not allowed for CoA-sourced multicast traffic. Reason: reduces complexity and we simply don't know how to do this at this time. 2. We allow HA tunneling AND CoA sourced traffic, but add an applicability statement that describes what limitations these mechanisms have. Reason: This does not prevent anything, but warns the implementers so that they can think about the implications for the multicast routing infrastructure. Later, when we have better technology we can revisit this statement. 3. We require MLD to be run without HAO. Reason: This makes multicast traffic that uses care-of address equivalent to any other local traffic. Also implied by item 1. -----text for 1------ (1) send directly on the foreign link being visited => (1) Send directly on the foreign link being visited. The application is aware of the care-of address and uses it for multicast traffic just like any other stationary address. The mobile node MUST NOT use Home Address destination option in such traffic. -----text for 2------- Note that direct sending from the foreign link is only applicable whilst the MN is at that foreign link. This is because the associated multicast tree is specific to that source location and any change of location and source address will invalidate the source specific tree or branch and the application context of the other multicast group members. This specification does not provide mechanisms to enable such local multicast session to survive hand-off, and to seamlessly continue from a new CCoA on each new foreign link. Any such mechanism, developed as an extension to this specification, needs to take into account the impact of fast moving mobile nodes on the Internet multicast routing protocols and their ability to maintain the integrity of source specific multicast trees and branches. Whilst the use of reverse tunnelling can ensure that multicast trees are independent of the MN's movement, in some case such tunnelling can have adverse affects. The latency of specific types of multicast applications such as multicast based discovery protocols will be impacted when the RTT between the foreign subnet and the HA is significant compared to that of the topology to be discovered. In addition, the delivery tree from the HA in such circumstances relies on unicast encapsulation from the HA to the MN and is therefore bandwidth inefficient compared to the native multicast forwarding in the foreign multicast system. -----text for 3------ If the multicast applications depend on the address of the joining node, the mobile node MAY treat the router as a correspondent node and establish a binding with it. The mobile node can then use the Home Address destination option in the sent control messages. => The mobile node MUST NOT use the Home Address destination option when sending MLD packets [ref]. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 08:53: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 IAA12487 for ; Tue, 20 Aug 2002 08:52: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 FAA24058; Tue, 20 Aug 2002 05:52:14 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21430; Tue, 20 Aug 2002 05:52:12 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KCp83c006304 for ; Tue, 20 Aug 2002 05:51:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KCp89h006303 for mobile-ip-dist; Tue, 20 Aug 2002 05:51: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KCp03c006293; Tue, 20 Aug 2002 05:51:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA21367; Tue, 20 Aug 2002 05:51:11 -0700 (PDT) Received: from ratree.psu.ac.th ([202.28.97.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11966; Tue, 20 Aug 2002 06:50:55 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7KCnr127380; Tue, 20 Aug 2002 19:49:56 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7KCnSW29294; Tue, 20 Aug 2002 19:49:28 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Markku Savela cc: mrw@windriver.com, Erik.Nordmark@sun.com, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-Reply-To: <200208200829.LAA28974@burp.tkv.asdf.org> References: <200208200829.LAA28974@burp.tkv.asdf.org> <"Your message with ID" <770.1023183551@munnari.OZ.AU> <4.2.2.20020819211305.0284a1b0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Aug 2002 19:49:28 +0700 Message-ID: <29292.1029847768@munnari.OZ.AU> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Date: Tue, 20 Aug 2002 11:29:40 +0300 From: Markku Savela Message-ID: <200208200829.LAA28974@burp.tkv.asdf.org> | The delay is less suitable for DAD's done on RA. In optimized | environment, addresses are useable immediately after RA. That's true, but I'm not sure this is important. | With | non-optimized and delayed DAD, we would have undetermined gap after | RA, when an address retrieved from DNS might not work. If you're sticking things in the DNS simultaneously with RA, or even before the RA is issued, then yes, I'd expect breakage. But I can't imagine why anyone would do that. Usually, I'd expect, you'd advertise the new prefix (via RA) then after that's done, advertise the new addresses in the DNS - either by manually waiting for the RA to take effect (which might involve waiting a few RA transmit cycles - some hosts might be busy and miss the first RA after all) and then editing the DNS, or by using dynamic DNS, and having each host update its own address(es) as they are installed in the host. | I would like my | network to be as deterministic as possible, avoid randomness when not | absolutely necessary. The way to achieve that is to test that the hosts have picked up the new prefix before advertising it in the DNS, not by assuming that every host will necessarily have the address available the instant that the RA is transmitted. kre From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 09:18: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 JAA13549 for ; Tue, 20 Aug 2002 09:18: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 GAA10480; Tue, 20 Aug 2002 06:18:05 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26771; Tue, 20 Aug 2002 06:18:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KDGc3c006624 for ; Tue, 20 Aug 2002 06:16:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KDGb06006623 for mobile-ip-dist; Tue, 20 Aug 2002 06:16: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KDGV3c006616; Tue, 20 Aug 2002 06:16:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25571; Tue, 20 Aug 2002 06:16:42 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA24937; Tue, 20 Aug 2002 07:16:40 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id QAA29174; Tue, 20 Aug 2002 16:15:37 +0300 Date: Tue, 20 Aug 2002 16:15:37 +0300 Message-Id: <200208201315.QAA29174@burp.tkv.asdf.org> From: Markku Savela To: kre@munnari.OZ.AU CC: mrw@windriver.com, Erik.Nordmark@sun.com, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <29292.1029847768@munnari.OZ.AU> (message from Robert Elz on Tue, 20 Aug 2002 19:49:28 +0700) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <200208200829.LAA28974@burp.tkv.asdf.org> <"Your message with ID" <770.1023183551@munnari.OZ.AU> <4.2.2.20020819211305.0284a1b0@mail.windriver.com> <29292.1029847768@munnari.OZ.AU> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > From: Robert Elz > If you're sticking things in the DNS simultaneously with RA, or even > before the RA is issued, then yes, I'd expect breakage. But I can't > imagine why anyone would do that. But, this is exactly the normal situation. The prefix, that is announced in RA, is one the global prefixes for link. I assume global addresses are in the DNS. It can be just situation that router was temporarily down and then came online/reachable again. At least in our system, application can connect to an global address, but if there is no route, the connect can be on hold for a while in wait for router advertisement. If such arrives, onlink route for the prefix is intalled, and immediately also the connections are activated (SYN packets sent causing the Neighbor solitications for the destionations). Now, if the other hosts are delaying their replies, I may get unreachable... perhaps not a big deal, but still not pretty either. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 09:41:23 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14084 for ; Tue, 20 Aug 2002 09:41:22 -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 HAA13300; Tue, 20 Aug 2002 07:42: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 GAA00612; Tue, 20 Aug 2002 06:42:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KDeF3c006813 for ; Tue, 20 Aug 2002 06:40:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KDeFhZ006812 for mobile-ip-dist; Tue, 20 Aug 2002 06:40:15 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KDe93c006805; Tue, 20 Aug 2002 06:40:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA19338; Tue, 20 Aug 2002 06:40:04 -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 HAA12590; Tue, 20 Aug 2002 07:40: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 g7KDdxU04285; Tue, 20 Aug 2002 15:39: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 PAA14560; Tue, 20 Aug 2002 15:39: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.12.3/8.12.3) with ESMTP id g7KDdw6o002495; Tue, 20 Aug 2002 15:39:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208201339.g7KDdw6o002495@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Margaret Wasserman cc: Erik Nordmark , Robert Elz , Dave Thaler , "Charles E. Perkins" , itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, IPng Working Group Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-reply-to: Your message of Mon, 19 Aug 2002 21:15:13 EDT. <4.2.2.20020819211305.0284a1b0@mail.windriver.com> Date: Tue, 20 Aug 2002 15:39: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: Instead, we might need some sort of random delay on the creation of addresses when a new prefix is received. => IMHO the delay should be in the DAD itself. We already got a random delay between 0 and MAX_RTR_SOLICITATION_DELAY for the first DAD on an interface, why not require it in all cases? Another detail: before doing DAD, the solicited group must be joined and this is another cause of collisions when implementations are buggy (i.e., no new report should be sent because the node is already a member of the group). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 10:13: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 KAA15089 for ; Tue, 20 Aug 2002 10:13:04 -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 HAA09595; Tue, 20 Aug 2002 07:12: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 HAA28491; Tue, 20 Aug 2002 07:12:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KEAc3c007110 for ; Tue, 20 Aug 2002 07:10:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KEAcIg007109 for mobile-ip-dist; Tue, 20 Aug 2002 07:10: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KEAW3c007102; Tue, 20 Aug 2002 07:10:32 -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 HAA06608; Tue, 20 Aug 2002 07:10:41 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00591; Tue, 20 Aug 2002 08:10:40 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA29298; Tue, 20 Aug 2002 17:10:31 +0300 Date: Tue, 20 Aug 2002 17:10:31 +0300 Message-Id: <200208201410.RAA29298@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: mrw@windriver.com, Erik.Nordmark@sun.com, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <200208201339.g7KDdw6o002495@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Tue, 20 Aug 2002 15:39:58 +0200) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <200208201339.g7KDdw6o002495@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > From: Francis Dupont > Another detail: before doing DAD, the solicited group must be joined > and this is another cause of collisions when implementations are buggy > (i.e., no new report should be sent because the node is already a member > of the group). What report? Solicited node is LINKLOCAL group, there is no need to send any joins on those? Or is some weird multilink hack again breaking the basic assumptions about Link Local? From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 10:29:57 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15688 for ; Tue, 20 Aug 2002 10:29:57 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA20329; Tue, 20 Aug 2002 07:29: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 HAA02960; Tue, 20 Aug 2002 07:29:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KERc3c007372 for ; Tue, 20 Aug 2002 07:27:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KERcEN007371 for mobile-ip-dist; Tue, 20 Aug 2002 07:27:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KERW3c007364; Tue, 20 Aug 2002 07:27:32 -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 HAA02553; Tue, 20 Aug 2002 07:27:42 -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 IAA10982; Tue, 20 Aug 2002 08:27: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 g7KERbU09998; Tue, 20 Aug 2002 16:27: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 QAA15065; Tue, 20 Aug 2002 16:27:38 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id g7KERb6o002654; Tue, 20 Aug 2002 16:27:37 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208201427.g7KERb6o002654@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: mrw@windriver.com, Erik.Nordmark@sun.com, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-reply-to: Your message of Tue, 20 Aug 2002 17:10:31 +0300. <200208201410.RAA29298@burp.tkv.asdf.org> Date: Tue, 20 Aug 2002 16:27:37 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: What report? Solicited node is LINKLOCAL group, there is no need to send any joins on those? Or is some weird multilink hack again breaking the basic assumptions about Link Local? => from RFC 2710: MLD messages ARE sent for multicast addresses whose scope is 2 (link-local), including Solicited-Node multicast addresses [ADDR- ARCH], except for the link-scope, all-nodes address (FF02::1). Francis.Dupont@enst-bretagne.fr PS: the reason is that layer-2 devices need to know if they can remove multicast packets to nodes which are not listening for them (cf draft-ietf-magma-snoop-02.txt). From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 10:33: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 KAA15801 for ; Tue, 20 Aug 2002 10:33:25 -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 IAA00731; Tue, 20 Aug 2002 08:34: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 HAA14889; Tue, 20 Aug 2002 07:34:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KEXT3c007545 for ; Tue, 20 Aug 2002 07:33:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KEXTsX007544 for mobile-ip-dist; Tue, 20 Aug 2002 07:33: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KEXM3c007534 for ; Tue, 20 Aug 2002 07:33:22 -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 HAA11672 for ; Tue, 20 Aug 2002 07:33:32 -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 IAA00247 for ; Tue, 20 Aug 2002 08:33:31 -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 g7KEXURb028505; Tue, 20 Aug 2002 16:33:30 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 20 Aug 2002 16:33:25 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F08EB@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Jari Arkko'" , Samita Chakrabarti Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H Date: Tue, 20 Aug 2002 16:33:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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, > Global unicast addresses are obviously allowed. I think > link-locals can also > be used for dereg to the HA. And, wouldn't it be bad if > made it illegal > to use MIPv6 within a site that uses only site-local > addresses? So that > was the justification for allowing all unicast addresses. > However, on > second look this covers also NSAP addresss, the unspecified > address etc. > So perhaps we should stick with "link-local, site-local, or > global unicast > addresses". => There were some complicaitons with Site-local addresses that I raised in the meeting. Just to reiterate, it is hard for a MN to know if it's in the home site or not or in two sites at the same time. This makes it difficult to use Site-local CoAs. Also, if the HA is multi-sited then how does it know which site the MN belongs to? these may not be difficult issues (?) but they're not trivial either. I think that we would need to add substantial text to discuss these cases. If I remember correctly, there was a suggestion from Erik to remove any reference to Site-local in the draft. I don't know how much of a loss it would be, but given time constraints, this seems like a reasonable way to go. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 11:57:59 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18098 for ; Tue, 20 Aug 2002 11:57: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 IAA17997; Tue, 20 Aug 2002 08:57: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 IAA05140; Tue, 20 Aug 2002 08:57:13 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KFu43c008026 for ; Tue, 20 Aug 2002 08:56:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KFu3IC008025 for mobile-ip-dist; Tue, 20 Aug 2002 08:56: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KFtv3c008018 for ; Tue, 20 Aug 2002 08:55:57 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA29973 for ; Tue, 20 Aug 2002 08:56:07 -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 JAA28276 for ; Tue, 20 Aug 2002 09:56:04 -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 E6A2A34F6; Tue, 20 Aug 2002 10:56:01 -0500 (CDT) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id EC458D9E; Tue, 20 Aug 2002 10:56:00 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7KFu000001110710; Tue, 20 Aug 2002 11:56:00 -0400 (EDT) Message-ID: <3D626690.5090301@hp.com> Date: Tue, 20 Aug 2002 11:56:00 -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: "'Jari Arkko'" Cc: "Hesham Soliman (EAB)" , Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H References: <4DA6EA82906FD511BE2F00508BCF0538044F08EB@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 FWIW, I agree with Hesham. Site-Locals are not trivially handled if the HA is multi-sited (it's a little easier on MN). So, for the sake of simplicity of the protocol (which is already rather complex), let's remove the site-local use. -vlad Hesham Soliman (EAB) wrote: > > => There were some complicaitons with Site-local addresses > that I raised in the meeting. Just to reiterate, it is hard for > a MN to know if it's in the home site or not or in two sites at the > same time. This makes it difficult to use Site-local CoAs. > Also, if the HA is multi-sited then how does it know which > site the MN belongs to? these may not be difficult issues (?) > but they're not trivial either. I think that we would need > to add substantial text to discuss these cases. If I remember > correctly, there was a suggestion from Erik to remove any > reference to Site-local in the draft. I don't know how much of > a loss it would be, but given time constraints, this seems > like a reasonable way to go. > > Hesham > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Tue Aug 20 13:03:09 2002 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19463 for ; Tue, 20 Aug 2002 13:03:09 -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 KAA29904; Tue, 20 Aug 2002 10:02: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 KAA27043; Tue, 20 Aug 2002 10:02:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KH1B3c008449 for ; Tue, 20 Aug 2002 10:01:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KH1Bf9008448 for mobile-ip-dist; Tue, 20 Aug 2002 10:01: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KH163c008441 for ; Tue, 20 Aug 2002 10:01: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 KAA26867 for ; Tue, 20 Aug 2002 10:01:17 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA06398 for ; Tue, 20 Aug 2002 11:01:16 -0600 (MDT) Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 20 Aug 2002 18:01:08 +0100 Message-ID: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> Date: Tue, 20 Aug 2002 18:01:07 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL/Mobile Systems Group X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] LMM requirements 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, I have read the latest version of the LMM requirements and I have some comments as well as questions about some of these. - 3.2.5-> What does the draft define as a security hole? Where can a security hole be introduced (like in what aspects -signalling or data) ? - 3.2.5 -> How does the possibility of a DoS attack come into play for the core LMM function? - 3.2.1 ->How does a replay attack come into action for the LMA. Does it mean replay of a sniffed RBU message? Basically does it refer to the RBU message? - 3.2.6 ->The security associate with routing, does it refer to the possibility of forging the entries in the regional binding cache with the intent of deflecting traffic on a node other than the MN? -3.2.6 ->what is defined as topological confidentiality within a LMM domain. If the RA provides the prefix of the LMA how does one envisage that this can reveal the topology of the domain?? A simple traceroute on the RCoA could do that.. -3.3.2 -> when it is said that non-lmm-aware host/HA/MN must interoperate with LMA is it meant that "the operation of the LMM function is optional with default mode of operation MIPv6"? 3.3.3 -> must not increase the no. of messages between MN-CN/HA. I take it you mean global BUs. Increase it in contrast to what though??? Also "must minimize the global (BU) signalling between MN-peers". What is max acceptable threshold? Furthermore, I believe that the last statement is wrong on the same clause. Consider: It is stated that "The amount of regional (RBU) signalling must not surpass the amount of global signalling...(used basically under base IP mobility)". Well the threhold you allow here is fundamentally wrong. Why? In mip we have only global signals, say Xg. In LMM we have global and local signals, X'g and Xi. If you allow (from the clause) Xi=Xg then it will be that (Xi+X'g)> Xg (unless X'g=0, i.e. I am still in the home net) which is unacceptable for LMM since its signalling cost gets bigger than that of base MIPv6. The relations that must hold are: The sum of intra-domain RBU signals must always be less than the number of BU signal performed under base MIPv6. The inter-domain signals for LMM must always be the difference between the total no. of MIPv6 BU signals and the sum of intra-domain RBU under LMM. This way the basic equation of Xg = X'g + Xi is always honoured. You see what we want to achieve is break the multiplicative term Xg of (k+1)Xg for MIPv6 where Xg is also the number of handoffs into a much smaller one with the remainder being just additive, i.e. (k+2)X'g + Xi I suggest that 3.3.3 is restated to reflect that. -3.4.1 states that "The LMM complexity.." does that mean "the scaling of BU/RBU signalling" ? Also if it scales linearly with the size of the local domain, then it contradicts directly the last statement of 3.4.5. If I accept 3.4.1 to be the case (subject to proof) then I cannot accept 3.4.5. Please remove 3.4.5 unless there is contradictory evidence. -3.4.2 states "The LMM must keep the number of host routes to a minimum". What is this measure of minimum; basically what is considered to be the maximum? -3.4.4 I trust that as long as the LMM function does not depend the MIPv6 function then it will not interfere with it. Besides the LMA is a major interferer :).. I can only deduce that you do not mean interfere, but impede the MIP function. If this is the case then the clause must be removed since it is expressed in detail in 3.5.1, 3.5.2, 3.5.3. If it is not then just remove it since it does not make sense (at least to me :). - 3.4.5 From what I understand so far from networking, configuration and interconnects in networking have nothing to do with IP routing. Do you mean "route"? - 3.4.7 states "..header/tunneling overhead caused by LMM must be reduced on the radio link by compression". The expression to me conveys semantings of compression on the radio link (i.e. layer 2). LMM works on layer 3. Thus the above statement is impossible since either the radio link compresses anything (LMM or not) or we hit a layer violation. I want to believe that this wants to mean "..caused by LMM must be reduced by IP header compression (RHOC specs), when the underlying link layer is wireless due to bandwidth restrictions.". Could we change it to something like that? -3.4.8 "..should not prohibit optimal placement of LMM agent..."..while this is fine..optimal placement of something is bound to be restrictive on how the topology is configured for LMM, yes? If this is the case then this conflicts the statement of 3.4.5, where you enforce a must that the LMM function does not restrict the configuration of the network. If this is the case should we remove the statement of 3.4.5, or is there a different rationale? 3.5.1, 3.5.2, 3.5.3 the must on the increase is ok on all of them. What I believe though is that it should also be a must on the decrease. Consider: latency: if not decrease it stays the same or gets bigger. Well if it stays the same, we still win on less signalling..sorry latency reduction is not the selling feature for LMM). But if it gets bigger then it conflict the "MUST NOT" about increase. The clauses must be revisited to state that "At worst, latency, service disruption (i.e. latency), and no of messages incurred by LMM must be the same as in MIPv6" 3.7. Traces of this clause are found in 3.4.5. Please remove the relevant statement of 3.4.5 3.9 is rather puzzling. I believe it basically means that LMM and MIP must interoperate when LMM is available. Fine. The last bit confuses me though.. I think it tries to say that while the above interoperability is assumed to exist, optimisation from either end, MIPv6 or LMM MAY be interoperable with the other. I believe the title of the requirement must change to "Interoperability between MIPv6, LMM and potential optimisations." I would appreciate if on the security requirements somebody could give a plausible situation that the LMM function is likely to engage. -- thanks theo UCL/Mobile Systems Group From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 16:54: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 QAA26469 for ; Tue, 20 Aug 2002 16:54:02 -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 OAA17508; Tue, 20 Aug 2002 14:54: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 NAA25503; Tue, 20 Aug 2002 13:54:49 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KKre3c009258 for ; Tue, 20 Aug 2002 13:53:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7KKremq009255 for mobile-ip-dist; Tue, 20 Aug 2002 13:53: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KKrY3c009247 for ; Tue, 20 Aug 2002 13:53:34 -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 NAA10430 for ; Tue, 20 Aug 2002 13:53:43 -0700 (PDT) Received: from idcpa4.pa.interdigital.com ([12.32.197.142]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA16828 for ; Tue, 20 Aug 2002 14:53:42 -0600 (MDT) Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Aug 2002 16:52:34 -0400 Message-ID: From: "Shahrier, Sharif M." To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] FMIPv6 over 802.11b Date: Tue, 20 Aug 2002 16:52: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: I had been informed by the chair that the WG is working on a draft on how to use FMIPv6 handover between different 802.11 wireless LANs. There is supposed to be someone already working on the draft. I am interested in participating in this work, and would be grateful if the author of the draft would contact me directly, or if someone could send me the pointer to that draft. Thank you. Sharif. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 21:35: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 VAA02940 for ; Tue, 20 Aug 2002 21:35:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA17030; Tue, 20 Aug 2002 19:36: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 SAA02498; Tue, 20 Aug 2002 18:36:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L1SN3c010147 for ; Tue, 20 Aug 2002 18:28:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7L1SMiq010146 for mobile-ip-dist; Tue, 20 Aug 2002 18:28: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 [129.146.17.55]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L1SG3c010139 for ; Tue, 20 Aug 2002 18:28:17 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with SMTP id g7L1SQD7342529; Tue, 20 Aug 2002 18:28:26 -0700 (PDT) Message-Id: <200208210128.g7L1SQD7342529@jurassic.eng.sun.com> Date: Tue, 20 Aug 2002 18:31:09 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: RE: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H To: hesham.soliman@era.ericsson.se, jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: QrlI5KlVFXwCFrAlINozTg== 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 perhaps we should stick with "link-local, site-local, or > > global unicast > > addresses". > > => There were some complicaitons with Site-local addresses > that I raised in the meeting. Just to reiterate, it is hard for > a MN to know if it's in the home site or not or in two sites at the > same time. This makes it difficult to use Site-local CoAs. > Also, if the HA is multi-sited then how does it know which > site the MN belongs to? these may not be difficult issues (?) > but they're not trivial either. I think that we would need > to add substantial text to discuss these cases. If I remember > correctly, there was a suggestion from Erik to remove any > reference to Site-local in the draft. I don't know how much of > a loss it would be, but given time constraints, this seems > like a reasonable way to go. Seconded. -Samita From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 20 22:04:17 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 WAA03544 for ; Tue, 20 Aug 2002 22:04:16 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA28040; Tue, 20 Aug 2002 20:04: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 TAA10232; Tue, 20 Aug 2002 19:04:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L1xJ3c010334 for ; Tue, 20 Aug 2002 18:59:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7L1xIT7010333 for mobile-ip-dist; Tue, 20 Aug 2002 18:59: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 jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7L1xC3c010326 for ; Tue, 20 Aug 2002 18:59:12 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with SMTP id g7L1xMD7346981; Tue, 20 Aug 2002 18:59:22 -0700 (PDT) Message-Id: <200208210159.g7L1xMD7346981@jurassic.eng.sun.com> Date: Tue, 20 Aug 2002 19:02:07 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Re: MIPv6 Draft 18 Comments To: jari.arkko@kolumbus.fi Cc: mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: lAyHqreGtkGBFk/QquAxcg== 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 for your response. The discussion points are in-line. > > 3. > > section 6.1.8 indicates that we don't have "no Security > > Association" status code anymore and we have: > > > > 137 Invalid authenticator > > > > That suggests Binding Authorization Data Option is manadatory > > for all binding update messages--correct ? > > Not quite. BAD (!) options are mandatory for CN binding updates, > but not for HA binding updates. > Ok. So the HA binding update can have IPsec transport mode alternatively. > > If that is the case, then that must be specified in 6.1.7 > > as well. Otherwise, we need another status error code or > > specification when the HA or CN receives a BU without > > binding authorization data option. > > My suggestion is to rename 137 as "Invalid or missing authenticator", > which would cover the case where BAD wasn't included in a BU to a > CN. > Ok. Then this is valid for CN case, but not for HA case. How should HA react if it receives a BU without BAD or IPsec (or any other security mechanism in future) ? Do you think "No security association" error code would be valid for this case ? > > 4. > > > > 6.1.9 > > > > Status code 1: > > 1 Home Address destination option used without a binding > > Is this still valid ? > > I think it is still valid, but a more proper name would perhaps > be "Home Address destination option used without sufficient validation", > the validation mechanisms being (1) existing binding or (2) use of > IPSec. > Ok. > Note that this issue is separate from the discussion of whether or > not the HAO and the IPsec validation are mandatory. (Whether or not > they are, it is still possible that someone sends an unauthenticated > HAO without a binding.) > So the code should check in the following order: 1) If IPsec association is present 2) If there is an existing binding 3) If this is a mobility header type for binding update If none of those conditions satisfy, then the above error status code should be sent-right ? > > 5. > > section 8.2 Route Optimization Requirements for All IPv6 Nodes > > > > It's missing the MN behavior, > > > > How about adding a text something like this? > > > > A node that is performing mobile node operation MUST be able to > > process RTHDR_TYPE2 extension header (section 11.2.3 and 6.4). > > All other nodes MUST ignore and drop RTHDR_TYPE2 extensions. > > Hmm... ok, but the purpose of this section was to list only requirements > for CNs. A CN can also be an MN at the same time. How about > > Unless the correspondent node is also acting as a mobile node, > it MUST ignore Type 2 Routing headers and drop all packets > that it has received with such headers. > Fine w/me. > We should also change: > > The following requirements apply to all nodes that support route > optimization: > > to > > The following requirements apply to all correspondent nodes that support route > optimization: > > I'll put this under issue #101. > Ok. > > section 8.5 > > > > Additional requirement: > > > > -MUST be able to process RTHDR_TYPE2 extension header as defined > > in 6.4 and 11.2.3 > > Yes. "RTHDR_TYPE2 extension header" => "Type 2 Routing header" > Right. Sorry about the mix-up. > > 11. > > section 10. Home Agent Operation > > > > Should not we have a section here on "Processing Binding Updates" ? > > Isn't 10.2 & 10.3 just that? Or would you like a different name? You are right. For consistency with CN and MN, how about naming this section accordingly ? Also, there has been requests in the alias to clarify the security mechanism and processing associated with BU processing at home agent. Thanks again, -Samita From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 21 06:16: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 GAA05463 for ; Wed, 21 Aug 2002 06:16:31 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14293; Wed, 21 Aug 2002 04:17: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 DAA00096; Wed, 21 Aug 2002 03:17:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LAGL3c011739 for ; Wed, 21 Aug 2002 03:16:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LAGKlA011738 for mobile-ip-dist; Wed, 21 Aug 2002 03:16:20 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LAGF3c011728 for ; Wed, 21 Aug 2002 03:16:15 -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 DAB01181 for ; Wed, 21 Aug 2002 03:16:24 -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 DAA08530 for ; Wed, 21 Aug 2002 03:16:22 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id 3A3B66A901; Wed, 21 Aug 2002 13:16:19 +0300 (EEST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7F4776A904; Wed, 21 Aug 2002 13:16:07 +0300 (EEST) Message-ID: <3D636792.3020908@kolumbus.fi> Date: Wed, 21 Aug 2002 13:12:34 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladislav Yasevich Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] BADs only in BUs (issue 104) References: <3D5C103F.50304@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 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: > I have a comment about authorization of BAcks in draft 18. > > They way I interpret the spec, if the BU has the Authorization > Data option, BAck must contains this option as well. I get this > out sections 5.2.6 and and 9.4.4. > > However, section 6.2.7 "Binding Authorization Data" says: > " ... This specification gives the rules only for > the return routability procedure. For this procedure, this option > can only appear in a Binding Update message and rules for calculating > the Authenticator value are described in Section 6.1.7." > > This seems to restrict Bindgin Authorisation Data only to BUs. Yes, this is a left-over from the time that we only had BU authorization. This needs to be fixed. Suggested new text: For this procedure, this option can only appear in the Binding Update and Binding Acknowledgement messages and rules for calculating the Authenticator value are described in Section 5.2.6. > Also, going and reading 6.1.7, I can't find the rules for calculating > the Authenticator value. I think the reference needs to be fixed as well. Fixed above. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 21 08:10: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 IAA07224 for ; Wed, 21 Aug 2002 08:10:38 -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 GAA07975; Wed, 21 Aug 2002 06:11: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 FAA20847; Wed, 21 Aug 2002 05:11:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LCAH3c012015 for ; Wed, 21 Aug 2002 05:10:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LCAH4Z012013 for mobile-ip-dist; Wed, 21 Aug 2002 05:10: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LCA83c012006 for ; Wed, 21 Aug 2002 05:10:09 -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 FAA24087 for ; Wed, 21 Aug 2002 05:10:19 -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 GAA07383 for ; Wed, 21 Aug 2002 06:10:05 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id CFE966A906; Wed, 21 Aug 2002 15:09:59 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 436366A901; Wed, 21 Aug 2002 15:09:49 +0300 (EEST) Message-ID: <3D638432.6010905@kolumbus.fi> Date: Wed, 21 Aug 2002 15:14:42 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladislav Yasevich , "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] Clarifications for section 5 (issue 102) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * 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: > 1. Multiple subsections use the symbol '|' in the cookie > and key calculations. Does this symbol mean "concatinate" > or "Logical OR"? (my guess is "Concatinate"). If my guess > is correct, in what order are the bits concatinated (i.e > cookie | none == ((cookie << 64) | nonce)? It should be defined. Suggested text follows: "Here A | B denotes concatenation of the strings A and B, and First64(A) denotes the first 64 bits of the string A." > 2. Section 5.2.5 uses a function First64() in calculating home > and care-of cookies. Which bits are assumed to be the first > 64 bits? Is the above enough? > 3. There doesn't appear to be a section on processing and validating > Binding Updates. Is it enought to make sure that authenticator > matches, or should the entire HMAC match? (My guess it is the > entire HMAC). and then later Hannu Flinck writes: > About your question 3 there is a section > describing BU processing and validation in 9.4.1 "Receiving Binding > Updates". So this should be covered. Right. 9.4.1 and 5.2.6 together should do the job. The rules for calculating the authenticator field indicate the use of the MAK_(k) function which has been defined as the HMAC function. > However under Home Agent Operation for sake of clarity I would like > to propose some lines of description how a static SA is used to > validate the MN-HA BUs. Current text that describes in 10.2 "Primary > Care-of Address Registration" starts with an assumption that the BU is > valid. But says nothing how the validation is done. Later in section > 10.3 "Primary Care-of address De-Registration" the text finally refers > to Section 9.4.1. > > However section 9.4.1 has been written Return Routability in mind that > doesn't apply as such with the home agent that has IPsec Yes, this reference isn't quite correct. But note that in 9.4.1 there are two separate activities listed, "validation" and "authorization". I think we can still refer to the validation steps for sequence numbers etc, but we need a new text for the authorization part which in this case works with IPsec. Text is being prepared for that, as required by issue 69. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 21 08:23: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 IAA07458 for ; Wed, 21 Aug 2002 08:23: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 FAA03984; Wed, 21 Aug 2002 05:22: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 FAA26626; Wed, 21 Aug 2002 05:22:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LCLP3c012207 for ; Wed, 21 Aug 2002 05:21:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LCLOIA012206 for mobile-ip-dist; Wed, 21 Aug 2002 05: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LCLI3c012199 for ; Wed, 21 Aug 2002 05:21:18 -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 FAA26304 for ; Wed, 21 Aug 2002 05:21:28 -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 GAA12906 for ; Wed, 21 Aug 2002 06:21:11 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 030486A904; Wed, 21 Aug 2002 15:20:59 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1D9906A901; Wed, 21 Aug 2002 15:20:53 +0300 (EEST) Message-ID: <3D6386C7.9030109@kolumbus.fi> Date: Wed, 21 Aug 2002 15:25:43 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladislav Yasevich Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Clarifications for section 5 (issue 102) References: <3D638432.6010905@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 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: > Vladislav Yasevich wrote: > > > 1. Multiple subsections use the symbol '|' in the cookie > > and key calculations. Does this symbol mean "concatinate" > > or "Logical OR"? (my guess is "Concatinate"). If my guess > > is correct, in what order are the bits concatinated (i.e > > cookie | none == ((cookie << 64) | nonce)? > > It should be defined. Suggested text follows: "Here > A | B denotes concatenation of the strings A and B, > and First64(A) denotes the first 64 bits of the string A." And to make the order specified as well: "Here A | B denotes the concatenation of the strings A and B, with the string A appearing first in the result. First64(X) denotes the first 64 bits of the string X." (Note that it is helpful to think about the cookies and other data items as strings rather than as numbers.) Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 21 09:03: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 JAA08364 for ; Wed, 21 Aug 2002 09:03:07 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00417; Wed, 21 Aug 2002 06:52:13 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28421; Wed, 21 Aug 2002 05:52:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LCp83c012380 for ; Wed, 21 Aug 2002 05:51:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LCp8aq012379 for mobile-ip-dist; Wed, 21 Aug 2002 05:51: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LCp23c012372 for ; Wed, 21 Aug 2002 05:51: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 FAA18062 for ; Wed, 21 Aug 2002 05:51:12 -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 GAA26433 for ; Wed, 21 Aug 2002 06:51:12 -0600 (MDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19) id ; Wed, 21 Aug 2002 08:51:11 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0BAA0E@ftmail.lab.flarion.com> From: "Alan O'Neill" To: Jari Arkko , "'mobile-ip@sunroof.eng.sun.com'" Cc: "'Dave Thaler'" , Erik Nordmark , fenner@research.att.com Subject: [mobile-ip] RE: moving on with the multicast issue (#63) Date: Wed, 21 Aug 2002 08:51:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Fine with me.. -----Original Message----- From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] Sent: 20 August 2002 22:04 To: 'mobile-ip@sunroof.eng.sun.com' Cc: Alan O'Neill; 'Dave Thaler'; Erik Nordmark; fenner@research.att.com Subject: moving on with the multicast issue (#63) A discussion has taken place on and off-list about the multicast mechanisms in MIPv6 and exactly what the base RFC must say and allow. The main discussion item has been whether to allow sending only via the HA, or also locally. We have come up with the following proposal in the discussion: 1. We clarify in the draft that HAO is not allowed for CoA-sourced multicast traffic. Reason: reduces complexity and we simply don't know how to do this at this time. 2. We allow HA tunneling AND CoA sourced traffic, but add an applicability statement that describes what limitations these mechanisms have. Reason: This does not prevent anything, but warns the implementers so that they can think about the implications for the multicast routing infrastructure. Later, when we have better technology we can revisit this statement. 3. We require MLD to be run without HAO. Reason: This makes multicast traffic that uses care-of address equivalent to any other local traffic. Also implied by item 1. -----text for 1------ (1) send directly on the foreign link being visited => (1) Send directly on the foreign link being visited. The application is aware of the care-of address and uses it for multicast traffic just like any other stationary address. The mobile node MUST NOT use Home Address destination option in such traffic. -----text for 2------- Note that direct sending from the foreign link is only applicable whilst the MN is at that foreign link. This is because the associated multicast tree is specific to that source location and any change of location and source address will invalidate the source specific tree or branch and the application context of the other multicast group members. This specification does not provide mechanisms to enable such local multicast session to survive hand-off, and to seamlessly continue from a new CCoA on each new foreign link. Any such mechanism, developed as an extension to this specification, needs to take into account the impact of fast moving mobile nodes on the Internet multicast routing protocols and their ability to maintain the integrity of source specific multicast trees and branches. Whilst the use of reverse tunnelling can ensure that multicast trees are independent of the MN's movement, in some case such tunnelling can have adverse affects. The latency of specific types of multicast applications such as multicast based discovery protocols will be impacted when the RTT between the foreign subnet and the HA is significant compared to that of the topology to be discovered. In addition, the delivery tree from the HA in such circumstances relies on unicast encapsulation from the HA to the MN and is therefore bandwidth inefficient compared to the native multicast forwarding in the foreign multicast system. -----text for 3------ If the multicast applications depend on the address of the joining node, the mobile node MAY treat the router as a correspondent node and establish a binding with it. The mobile node can then use the Home Address destination option in the sent control messages. => The mobile node MUST NOT use the Home Address destination option when sending MLD packets [ref]. From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 21 09:19: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 JAA08927 for ; Wed, 21 Aug 2002 09:19:30 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16960; Wed, 21 Aug 2002 07:20: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 GAA03930; Wed, 21 Aug 2002 06:20:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDJG3c012592 for ; Wed, 21 Aug 2002 06:19:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LDJG8x012591 for mobile-ip-dist; Wed, 21 Aug 2002 06:19:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDJA3c012584 for ; Wed, 21 Aug 2002 06:19:11 -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 GAA03728 for ; Wed, 21 Aug 2002 06:19:21 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26303 for ; Wed, 21 Aug 2002 07:19:20 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 08E786A9F; Wed, 21 Aug 2002 09:19:20 -0400 (EDT) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 05B0411B9; Wed, 21 Aug 2002 06:19:19 -0700 (PDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7LDJI00001324073; Wed, 21 Aug 2002 09:19:18 -0400 (EDT) Message-ID: <3D639355.9000004@hp.com> Date: Wed, 21 Aug 2002 09:19:17 -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: Jari Arkko Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] BADs only in BUs (issue 104) References: <3D5C103F.50304@hp.com> <3D636792.3020908@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Jari Arkko wrote: > Vladislav Yasevich wrote: > > > Yes, this is a left-over from the time that we only had BU authorization. > This needs to be fixed. Suggested new text: > > For this procedure, this option > can only appear in the Binding Update and Binding Acknowledgement > messages > and rules for calculating the Authenticator value are described in > Section 5.2.6. > Thanks, that works... -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 Aug 21 09:27: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 JAA09291 for ; Wed, 21 Aug 2002 09:27: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 HAA21289; Wed, 21 Aug 2002 07:28: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 GAA12705; Wed, 21 Aug 2002 06:28:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDR63c012740 for ; Wed, 21 Aug 2002 06:27:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LDR65l012739 for mobile-ip-dist; Wed, 21 Aug 2002 06:27: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDR03c012732 for ; Wed, 21 Aug 2002 06:27:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24740 for ; Wed, 21 Aug 2002 06:27:11 -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 HAA29940 for ; Wed, 21 Aug 2002 07:27:10 -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 CEF8C3743; Wed, 21 Aug 2002 08:27:09 -0500 (CDT) Received: from anw.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 2334AE0D; Wed, 21 Aug 2002 08:27:09 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7LDR850000696307; Wed, 21 Aug 2002 09:27:08 -0400 (EDT) Message-ID: <3D63952C.9000202@hp.com> Date: Wed, 21 Aug 2002 09:27:08 -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: Samita Chakrabarti Cc: jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: MIPv6 Draft 18 Comments References: <200208210159.g7L1xMD7346981@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: >> >>My suggestion is to rename 137 as "Invalid or missing authenticator", >>which would cover the case where BAD wasn't included in a BU to a >>CN. >> > > > Ok. Then this is valid for CN case, but not for HA case. How should HA > react if it receives a BU without BAD or IPsec (or any other security > mechanism in future) ? > > Do you think "No security association" error code would be valid for > this case ? > Why not just name error code 137 as "Authentication Failed" and return that error code if the security validation procedure (IPSec, BAD, etc...) failed. -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 Aug 21 09:29: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 JAA09466 for ; Wed, 21 Aug 2002 09:29:58 -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 GAA16000; Wed, 21 Aug 2002 06:29:20 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05574; Wed, 21 Aug 2002 06:29:17 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDSH3c012763 for ; Wed, 21 Aug 2002 06:28:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LDSH3E012762 for mobile-ip-dist; Wed, 21 Aug 2002 06:28: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDSA3c012752 for ; Wed, 21 Aug 2002 06:28: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 GAA24983 for ; Wed, 21 Aug 2002 06:28:21 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14212 for ; Wed, 21 Aug 2002 07:28:20 -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 3CB883BC6; Wed, 21 Aug 2002 09:28:20 -0400 (EDT) Received: from anw.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 6C7BFE1C; Wed, 21 Aug 2002 08:28:19 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7LDSI50000696396; Wed, 21 Aug 2002 09:28:18 -0400 (EDT) Message-ID: <3D639572.80108@hp.com> Date: Wed, 21 Aug 2002 09:28:18 -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: Jari Arkko Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] Clarifications for section 5 (issue 102) References: <3D638432.6010905@kolumbus.fi> <3D6386C7.9030109@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Thanks. That clarifies a lot. -vlad Jari Arkko wrote: > Jari Arkko wrote: > >> Vladislav Yasevich wrote: >> >> > 1. Multiple subsections use the symbol '|' in the cookie >> > and key calculations. Does this symbol mean "concatinate" >> > or "Logical OR"? (my guess is "Concatinate"). If my guess >> > is correct, in what order are the bits concatinated (i.e >> > cookie | none == ((cookie << 64) | nonce)? >> >> It should be defined. Suggested text follows: "Here >> A | B denotes concatenation of the strings A and B, >> and First64(A) denotes the first 64 bits of the string A." > > > And to make the order specified as well: "Here A | B denotes > the concatenation of the strings A and B, with the string A > appearing first in the result. First64(X) denotes the first 64 > bits of the string X." > > (Note that it is helpful to think about the cookies and other > data items as strings rather than as numbers.) > > Jari > > > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Aug 21 09:37: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 JAA09880 for ; Wed, 21 Aug 2002 09:37: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 GAA20344; Wed, 21 Aug 2002 06:36: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 GAA15417; Wed, 21 Aug 2002 06:36:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDZV3c013068 for ; Wed, 21 Aug 2002 06:35:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LDZVok013067 for mobile-ip-dist; Wed, 21 Aug 2002 06:35:31 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDZO3c013060 for ; Wed, 21 Aug 2002 06:35: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 GAA26706 for ; Wed, 21 Aug 2002 06:35:35 -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 HAA13663 for ; Wed, 21 Aug 2002 07:35:29 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 083456A901; Wed, 21 Aug 2002 16:35:26 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7E5126A904; Wed, 21 Aug 2002 16:35:14 +0300 (EEST) Message-ID: <3D639837.3080108@kolumbus.fi> Date: Wed, 21 Aug 2002 16:40:07 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladislav Yasevich Cc: Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: MIPv6 Draft 18 Comments References: <200208210159.g7L1xMD7346981@jurassic.eng.sun.com> <3D63952C.9000202@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 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: >> Ok. Then this is valid for CN case, but not for HA case. How should HA >> react if it receives a BU without BAD or IPsec (or any other security >> mechanism in future) ? >> Do you think "No security association" error code would be valid for >> this case ? >> > > Why not just name error code 137 as "Authentication Failed" and return > that error code if the security validation procedure (IPSec, BAD, etc...) > failed. IPsec has its own mechanisms (i.e. drop packets and not tell anyone about it) for dealing with authentication problems. So that's why I'm a bit hesitant to require that the MIPv6 code needs to know too much about what happened lower down in the stack. Jari From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 21 09:48:51 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10232 for ; Wed, 21 Aug 2002 09:48:50 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16503; Wed, 21 Aug 2002 06:48: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 GAA18309; Wed, 21 Aug 2002 06:48:05 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDl23c013267 for ; Wed, 21 Aug 2002 06:47:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LDl1Xd013266 for mobile-ip-dist; Wed, 21 Aug 2002 06:47: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LDku3c013259 for ; Wed, 21 Aug 2002 06:46: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 GAA17840 for ; Wed, 21 Aug 2002 06:47:04 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA19780 for ; Wed, 21 Aug 2002 07:47:02 -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 1E0861E78; Wed, 21 Aug 2002 08:47:02 -0500 (CDT) Received: from anw.zk3.dec.com (band.zk3.dec.com [16.140.128.6]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 74387F1C; Wed, 21 Aug 2002 08:47:01 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7LDl1V0001758184; Wed, 21 Aug 2002 09:47:01 -0400 (EDT) Message-ID: <3D6399D5.90604@hp.com> Date: Wed, 21 Aug 2002 09:47:01 -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: Jari Arkko Cc: Samita Chakrabarti , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: MIPv6 Draft 18 Comments References: <200208210159.g7L1xMD7346981@jurassic.eng.sun.com> <3D63952C.9000202@hp.com> <3D639837.3080108@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari I agree, if IPSec actuall failed, that packet will be just dropped at lower layer, but a different error code description is still valid for when there was not authentication done on the packet. The new description is also generic enough to cover possible future authentication mechanisms other then BAD and IPSec. -vlad Jari Arkko wrote: > Vladislav Yasevich wrote: > >>> Ok. Then this is valid for CN case, but not for HA case. How should HA >>> react if it receives a BU without BAD or IPsec (or any other security >>> mechanism in future) ? Do you think "No security association" error >>> code would be valid for >>> this case ? >>> >> >> Why not just name error code 137 as "Authentication Failed" and return >> that error code if the security validation procedure (IPSec, BAD, etc...) >> failed. > > > IPsec has its own mechanisms (i.e. drop packets and not tell anyone about > it) for dealing with authentication problems. So that's why I'm a bit > hesitant to require that the MIPv6 code needs to know too much about what > happened lower down in the stack. > > Jari > > > > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Aug 21 13:03: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 NAA16795 for ; Wed, 21 Aug 2002 13:03: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 LAA20205; Wed, 21 Aug 2002 11:04:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23646; Wed, 21 Aug 2002 10:04:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LH2N3c014095 for ; Wed, 21 Aug 2002 10:02:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7LH2Nd1014094 for mobile-ip-dist; Wed, 21 Aug 2002 10: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7LH2H3c014087 for ; Wed, 21 Aug 2002 10:02: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 KAA23086 for ; Wed, 21 Aug 2002 10:02: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 LAA13351 for ; Wed, 21 Aug 2002 11:02:25 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 967A96A904; Wed, 21 Aug 2002 20:02:19 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B536E6A901; Wed, 21 Aug 2002 20:02:05 +0300 (EEST) Message-ID: <3D63C8B2.5080106@kolumbus.fi> Date: Wed, 21 Aug 2002 20:06:58 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Samita Chakrabarti Cc: hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] issues 92, 94, 95 and text for sending BAs with R H References: <200208210128.g7L1SQD7342529@jurassic.eng.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 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: > >> > So perhaps we should stick with "link-local, site-local, or >> > global unicast >> > addresses". >> >>=> There were some complicaitons with Site-local addresses Ok, let's ignore site-local then. The rule for CNs is to verify that the address is a global unicast address. For HAs we'll allow link-local as well. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 22 05:12: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 FAA19196 for ; Thu, 22 Aug 2002 05:12:02 -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 CAA11862; Thu, 22 Aug 2002 02:11:24 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA26444; Thu, 22 Aug 2002 02:11:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7M9AG3c016269 for ; Thu, 22 Aug 2002 02:10:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7M9AGr0016268 for mobile-ip-dist; Thu, 22 Aug 2002 02:10: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7M9AA3c016261 for ; Thu, 22 Aug 2002 02:10:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22130 for ; Thu, 22 Aug 2002 02:10:21 -0700 (PDT) Received: from regyva.regy.canterbury.ac.nz (regyva.canterbury.ac.nz [132.181.30.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA11226 for ; Thu, 22 Aug 2002 03:10:20 -0600 (MDT) Received: from CONVERSION-DAEMON.it.canterbury.ac.nz by it.canterbury.ac.nz (PMDF V6.1-1 #39332) id <01KLM26WT3ZK93BGXQ@it.canterbury.ac.nz> for mobile-ip@sunroof.eng.sun.com; Thu, 22 Aug 2002 21:10:17 +1200 (NEW ZEALAND STANDARD TIME) Received: from francis (francis.elec.canterbury.ac.nz [132.181.52.108]) by it.canterbury.ac.nz (PMDF V6.1-1 #39332) with SMTP id <01KLM26X8U8M8ZFGK5@it.canterbury.ac.nz> for mobile-ip@sunroof.eng.sun.com; Thu, 22 Aug 2002 21:10:17 +1200 (NEW ZEALAND STANDARD TIME) Date: Thu, 22 Aug 2002 21:17:39 +1200 From: Francis Chai Subject: [mobile-ip] cellular ip testbed implementation To: mobile-ip@sunroof.eng.sun.com Message-id: <003901c249bc$c3104d60$6c34b584@elec.canterbury.ac.nz> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Content-type: multipart/alternative; boundary="Boundary_(ID_IYdaoP1mvYPnXpdeAVMJDA)" X-Priority: 3 X-MSMail-priority: Normal Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --Boundary_(ID_IYdaoP1mvYPnXpdeAVMJDA) Content-type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Is anyone familiar with cellular ip v1.1 for linux? I'm having = problems with configuring the software for cellular ip. The following is = my network layout gateway ------ router I --------------- I---------- I | BS1 BS2 MH The question I have is, what should be in the routing table in the = gateway? Where is the default route suppose to point to? At the moment, = I have the default route pointing at the router. However, how will the = gateway know the route to the mobile host? I could set up a route to the = mobile host manually with the next hop as either BS1 or BS2. But then = when I carry out handoff, the current route will not work anymore. I = have cipnode running on both BS1, BS2 and the gateway. So the question = is...how will the gateway know the nexthop to the mobile host? Best regards, Francis --Boundary_(ID_IYdaoP1mvYPnXpdeAVMJDA) Content-type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
    Is anyone familiar = with cellular=20 ip v1.1 for linux? I'm having problems with configuring the software for = cellular ip. The following is my = network=20 layout
 
          &nbs= p;      gateway=20 ------ router
          &nbs= p;       =20 I
   --------------- I----------
 =20 I            =             &= nbsp;  |
BS1    =    =20             = BS2
 
 
          =20 MH
 
 
The question I have is, what should be = in the=20 routing table in the gateway? Where is the default route suppose to = point to? At=20 the moment, I have the default route pointing at the router. However, = how will=20 the gateway know the route to the mobile host? I could set up a route to = the=20 mobile host manually with the next hop as either BS1 or BS2. But then = when I=20 carry out handoff, the current route will not work anymore. I have = cipnode=20 running on both BS1, BS2 and the gateway. So the question is...how will = the=20 gateway know the nexthop to the mobile host?
 
 
Best regards,
Francis
 
--Boundary_(ID_IYdaoP1mvYPnXpdeAVMJDA)-- From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 22 06:28:11 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20751 for ; Thu, 22 Aug 2002 06:28:10 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA21373; Thu, 22 Aug 2002 04:29: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 DAA06700; Thu, 22 Aug 2002 03:29:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MARu3c016579 for ; Thu, 22 Aug 2002 03:27:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MARuT4016578 for mobile-ip-dist; Thu, 22 Aug 2002 03:27: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MARo3c016571 for ; Thu, 22 Aug 2002 03:27: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 DAA06551 for ; Thu, 22 Aug 2002 03:28:00 -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 EAA03526 for ; Thu, 22 Aug 2002 04:27:58 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 733A16A904; Thu, 22 Aug 2002 13:27:51 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 18E936A901; Thu, 22 Aug 2002 13:27:46 +0300 (EEST) Message-ID: <3D64BDC8.7010001@kolumbus.fi> Date: Thu, 22 Aug 2002 13:32:40 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladislav Yasevich Cc: MobilIP Subject: Re: [mobile-ip] Additional question on BAs References: <3D612965.20807@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=1.1 required=5.0 tests=DOUBLE_CAPSWORD version=2.31 X-Spam-Level: * 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: > Hi > > If the BA is sent to the mobile node, in response to BU, with > the status of 137 (Invalid authenticator), 138 (Expired Home Nonce Index), > or 139 (Expired Care-of Nonce Index), shuld this BA contains > the Authorization Data option and authenticator? > > It looks to me like it should not because the CN was unable > to authenticate the BU. Right. Section 9.4.4. has been silent about this. Suggested text: The packet in which the Binding Acknowledgement is returned MUST meet the specific authentication requirements for Binding Acknowledgements, defined in Section 5.2. Furthermore, if the packet ... => If the Status field in the Binding Acknowledgement contains the value 137, 138, or 139, then the message MUST NOT include the Binding Authorization Data mobility option. Otherwise, the Binding Authorization Data mobility option MUST be included, and MUST meet the specific authentication requirements for Binding Acknowledgements as defined in Section 5.2.6. If the packet ... Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 22 14:01: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 OAA04678 for ; Thu, 22 Aug 2002 14:01:06 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19695; Thu, 22 Aug 2002 12:01: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 LAA01245; Thu, 22 Aug 2002 11:01:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MI0P3c017630 for ; Thu, 22 Aug 2002 11:00:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MI0P8P017629 for mobile-ip-dist; Thu, 22 Aug 2002 11:00: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MI0J3c017622 for ; Thu, 22 Aug 2002 11:00:19 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA22583 for ; Thu, 22 Aug 2002 11:00:28 -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 MAA18279 for ; Thu, 22 Aug 2002 12:00:28 -0600 (MDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id 37D212922; Thu, 22 Aug 2002 11:00:24 -0700 (PDT) Received: from anw.zk3.dec.com (banw4.zk3.dec.com [16.140.128.5]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 0CD101732; Thu, 22 Aug 2002 14:00:15 -0400 (EDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7MI0Au0002411915; Thu, 22 Aug 2002 14:00:14 -0400 (EDT) Message-ID: <3D6526A9.704@hp.com> Date: Thu, 22 Aug 2002 14:00: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: Jari Arkko Cc: MobilIP Subject: Re: [mobile-ip] Additional question on BAs References: <3D612965.20807@hp.com> <3D64BDC8.7010001@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari Slight problem the text you supplied. BAD option in the BAck should only be included if the BU containted a BAD option. So I would change the text slightly: If the Status field in the Binding Acknowledgement contains the value 137, 138, or 139, then the message MUST NOT include the Binding Authorization Data mobility option. Otherwise, the Binding Authorization Data mobility option MUST be included if the Binding Update message contained the option, and MUST meet the specific authentication requirements for Binding Acknowledgements as defined in Section 5.2.6. If the packet ... -vlad Jari Arkko wrote: > Vladislav Yasevich wrote: > >> Hi >> >> If the BA is sent to the mobile node, in response to BU, with >> the status of 137 (Invalid authenticator), 138 (Expired Home Nonce >> Index), >> or 139 (Expired Care-of Nonce Index), shuld this BA contains >> the Authorization Data option and authenticator? >> >> It looks to me like it should not because the CN was unable >> to authenticate the BU. > > > Right. > > Section 9.4.4. has been silent about this. Suggested text: > > > The packet in which the Binding Acknowledgement is returned > MUST meet the specific authentication requirements for Binding > Acknowledgements, defined in Section 5.2. Furthermore, if the packet > ... > > => > > If the Status field in the Binding Acknowledgement contains the value > 137, 138, or 139, then the message MUST NOT include > the Binding Authorization Data mobility option. Otherwise, > the Binding Authorization Data mobility option MUST be included, and > MUST meet the specific authentication requirements for Binding > Acknowledgements as defined in Section 5.2.6. > > If the packet ... > > Jari > > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Aug 22 14:25:33 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 OAA05553 for ; Thu, 22 Aug 2002 14:25: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 LAA13502; Thu, 22 Aug 2002 11:24:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11709; Thu, 22 Aug 2002 11:24:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MINc3c017863 for ; Thu, 22 Aug 2002 11:23:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MINbaE017862 for mobile-ip-dist; Thu, 22 Aug 2002 11: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MINW3c017855 for ; Thu, 22 Aug 2002 11:23:32 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11296 for ; Thu, 22 Aug 2002 11:23:42 -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 MAA29447 for ; Thu, 22 Aug 2002 12:23:40 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 0D8476A904; Thu, 22 Aug 2002 21:23:24 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5C4176A901; Thu, 22 Aug 2002 21:23:22 +0300 (EEST) Message-ID: <3D652D42.4040801@kolumbus.fi> Date: Thu, 22 Aug 2002 21:28:18 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vladislav Yasevich Cc: MobilIP Subject: Re: [mobile-ip] Additional question on BAs References: <3D612965.20807@hp.com> <3D64BDC8.7010001@kolumbus.fi> <3D6526A9.704@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 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: > Jari > > Slight problem the text you supplied. BAD option in > the BAck should only be included if the BU containted > a BAD option. True, but if the text was in 9.4.4 then BADs are required in the BUs in any case. I'm also assuming 137 covers missing BAD. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 22 14:40:31 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 OAA05962 for ; Thu, 22 Aug 2002 14:40:31 -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 LAA19564; Thu, 22 Aug 2002 11:39:48 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18136; Thu, 22 Aug 2002 11:39:45 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MIcV3c018038 for ; Thu, 22 Aug 2002 11:38:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MIcUOp018037 for mobile-ip-dist; Thu, 22 Aug 2002 11:38: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MIcP3c018030 for ; Thu, 22 Aug 2002 11:38:25 -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 LAA17607 for ; Thu, 22 Aug 2002 11:38:35 -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 LAA18912 for ; Thu, 22 Aug 2002 11:38:35 -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 E4BF74477; Thu, 22 Aug 2002 13:38:34 -0500 (CDT) Received: from anw.zk3.dec.com (banw4.zk3.dec.com [16.140.128.5]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 12B50EC7; Thu, 22 Aug 2002 13:38:34 -0500 (CDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7MIcXu0002418450; Thu, 22 Aug 2002 14:38:33 -0400 (EDT) Message-ID: <3D652FA9.6020408@hp.com> Date: Thu, 22 Aug 2002 14:38:33 -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: Jari Arkko Cc: MobilIP Subject: Re: [mobile-ip] Additional question on BAs References: <3D612965.20807@hp.com> <3D64BDC8.7010001@kolumbus.fi> <3D6526A9.704@hp.com> <3D652D42.4040801@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Jari If we assume that the CN will ALWAYS do RR, then your new text in section 9.4.4 would be enough. I was thinking of a possibility where there is some other mechanism which does not depend on RR and thus would not have sent the authenticator in the BU. So, it might good to actually state that the BAD option is include only if RR method was used and the message was successufly authenticated. -vlad Jari Arkko wrote: > Vladislav Yasevich wrote: > >> Jari >> >> Slight problem the text you supplied. BAD option in >> the BAck should only be included if the BU containted >> a BAD option. > > > True, but if the text was in 9.4.4 then BADs are required > in the BUs in any case. I'm also assuming 137 covers > missing BAD. > > Jari > > > > > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Aug 22 14:46: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 OAA06185 for ; Thu, 22 Aug 2002 14:46: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 MAA18903; Thu, 22 Aug 2002 12:47: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 LAA10767; Thu, 22 Aug 2002 11:47:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MIkR3c018245 for ; Thu, 22 Aug 2002 11:46:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MIkRID018244 for mobile-ip-dist; Thu, 22 Aug 2002 11: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MIkL3c018236 for ; Thu, 22 Aug 2002 11:46:21 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21987 for ; Thu, 22 Aug 2002 11:46:31 -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 MAA00731 for ; Thu, 22 Aug 2002 12:46:31 -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 LAA11810; Thu, 22 Aug 2002 11:46:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7MIkTE31107; Thu, 22 Aug 2002 11:46:29 -0700 X-mProtect: <200208221846> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd5ffT4b; Thu, 22 Aug 2002 11:46:27 PDT Message-ID: <3D653183.E8862660@iprg.nokia.com> Date: Thu, 22 Aug 2002 11:46:27 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Yasevich CC: MobilIP Subject: Re: [mobile-ip] Additional question on BAs References: <3D612965.20807@hp.com> <3D64BDC8.7010001@kolumbus.fi> <3D6526A9.704@hp.com> <3D652D42.4040801@kolumbus.fi> <3D652FA9.6020408@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 do not agree that use of the Binding Authentication Data option should be restricted in that way. For one thing, it should be usable whenever the nodes involved have enough information to carry out the computation, whether by manual configuration or some other proprietary means or some other future standard protocol. Regards, Charlie P. Vladislav Yasevich wrote: > > Jari > > If we assume that the CN will ALWAYS do RR, then your > new text in section 9.4.4 would be enough. > > I was thinking of a possibility where there is some > other mechanism which does not depend on RR and > thus would not have sent the authenticator in the BU. > > So, it might good to actually state that the BAD option > is include only if RR method was used and the message > was successufly authenticated. > > -vlad > > Jari Arkko wrote: > > Vladislav Yasevich wrote: > > > >> Jari > >> > >> Slight problem the text you supplied. BAD option in > >> the BAck should only be included if the BU containted > >> a BAD option. > > > > > > True, but if the text was in 9.4.4 then BADs are required > > in the BUs in any case. I'm also assuming 137 covers > > missing BAD. > > > > Jari > > > > > > > > > > > > > > -- > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 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 Aug 22 15:35: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 PAA07856 for ; Thu, 22 Aug 2002 15:35:11 -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 NAA15951; Thu, 22 Aug 2002 13:35: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 MAA25762; Thu, 22 Aug 2002 12:35:56 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MJVk3c018457 for ; Thu, 22 Aug 2002 12:31:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MJVknx018456 for mobile-ip-dist; Thu, 22 Aug 2002 12:31: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MJVc3c018449 for ; Thu, 22 Aug 2002 12:31:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25848 for ; Thu, 22 Aug 2002 12:31:48 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19565 for ; Thu, 22 Aug 2002 12:31:44 -0700 (PDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id D642F1115; Thu, 22 Aug 2002 14:31:33 -0500 (CDT) Received: from anw.zk3.dec.com (band.zk3.dec.com [16.140.128.6]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id A7C2D1248; Thu, 22 Aug 2002 12:31:32 -0700 (PDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7MJVWV0002027232; Thu, 22 Aug 2002 15:31:32 -0400 (EDT) Message-ID: <3D653C13.4090508@hp.com> Date: Thu, 22 Aug 2002 15:31: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: MobilIP , Jari Arkko Subject: Re: [mobile-ip] Additional question on BAs References: <3D612965.20807@hp.com> <3D64BDC8.7010001@kolumbus.fi> <3D6526A9.704@hp.com> <3D652D42.4040801@kolumbus.fi> <3D652FA9.6020408@hp.com> <3D653183.E8862660@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 Hello Charly I guess it depends on the specification of the "other" protocols. The text I sent was simply my interpretation. I did not realize that the original consideration was to re-use Binding Authorization Data in other authentication schemes. Upon re-reading the Section 6.2.7, I withdraw my objection to the clarified text. -vlad Charles E. Perkins wrote: > Hello Vlad, > > I do not agree that use of the Binding Authentication > Data option should be restricted in that way. For one > thing, it should be usable whenever the nodes involved > have enough information to carry out the computation, > whether by manual configuration or some other proprietary > means or some other future standard protocol. > > Regards, > Charlie P. > > > Vladislav Yasevich wrote: > >>Jari >> >>If we assume that the CN will ALWAYS do RR, then your >>new text in section 9.4.4 would be enough. >> >>I was thinking of a possibility where there is some >>other mechanism which does not depend on RR and >>thus would not have sent the authenticator in the BU. >> >>So, it might good to actually state that the BAD option >>is include only if RR method was used and the message >>was successufly authenticated. >> >>-vlad >> >>Jari Arkko wrote: >> >>>Vladislav Yasevich wrote: >>> >>> >>>>Jari >>>> >>>>Slight problem the text you supplied. BAD option in >>>>the BAck should only be included if the BU containted >>>>a BAD option. >>> >>> >>>True, but if the text was in 9.4.4 then BADs are required >>>in the BUs in any case. I'm also assuming 137 covers >>>missing BAD. >>> >>>Jari >>> >>> >>> >>> >>> >>> >> >>-- >>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >>Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead >>Hewlett Packard Tel: (603) 884-1079 >>Nashua, NH 03062 ZKO3-3/T07 > > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Aug 22 16:12: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 QAA09080 for ; Thu, 22 Aug 2002 16:12: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 OAA06204; Thu, 22 Aug 2002 14:13:10 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA09532; Thu, 22 Aug 2002 13:13:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MKBk3c018751 for ; Thu, 22 Aug 2002 13:11:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7MKBkJ6018750 for mobile-ip-dist; Thu, 22 Aug 2002 13:11: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MKBe3c018743 for ; Thu, 22 Aug 2002 13:11: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 NAA08470 for ; Thu, 22 Aug 2002 13:11:52 -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 NAA12158 for ; Thu, 22 Aug 2002 13:11:52 -0700 (PDT) Message-ID: <015201c24a17$e7fd36f0$296015ac@T23KEMPF> From: "James Kempf" To: "Charles E. Perkins" , "Vladislav Yasevich" Cc: "MobilIP" References: <3D612965.20807@hp.com> <3D64BDC8.7010001@kolumbus.fi> <3D6526A9.704@hp.com> <3D652D42.4040801@kolumbus.fi> <3D652FA9.6020408@hp.com> <3D653183.E8862660@iprg.nokia.com> Subject: Re: [mobile-ip] Additional question on BAs Date: Thu, 22 Aug 2002 13:08:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Agree. jak ----- Original Message ----- From: "Charles E. Perkins" To: "Vladislav Yasevich" Cc: "MobilIP" Sent: Thursday, August 22, 2002 11:46 AM Subject: Re: [mobile-ip] Additional question on BAs > Hello Vlad, > > I do not agree that use of the Binding Authentication > Data option should be restricted in that way. For one > thing, it should be usable whenever the nodes involved > have enough information to carry out the computation, > whether by manual configuration or some other proprietary > means or some other future standard protocol. > > Regards, > Charlie P. > > > Vladislav Yasevich wrote: > > > > Jari > > > > If we assume that the CN will ALWAYS do RR, then your > > new text in section 9.4.4 would be enough. > > > > I was thinking of a possibility where there is some > > other mechanism which does not depend on RR and > > thus would not have sent the authenticator in the BU. > > > > So, it might good to actually state that the BAD option > > is include only if RR method was used and the message > > was successufly authenticated. > > > > -vlad > > > > Jari Arkko wrote: > > > Vladislav Yasevich wrote: > > > > > >> Jari > > >> > > >> Slight problem the text you supplied. BAD option in > > >> the BAck should only be included if the BU containted > > >> a BAD option. > > > > > > > > > True, but if the text was in 9.4.4 then BADs are required > > > in the BUs in any case. I'm also assuming 137 covers > > > missing BAD. > > > > > > Jari > > > > > > > > > > > > > > > > > > > > > > -- > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 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 Aug 23 16:15: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 QAA16519 for ; Fri, 23 Aug 2002 16:15: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 NAA20995; Fri, 23 Aug 2002 13:14: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 NAA10385; Fri, 23 Aug 2002 13:14:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NKCr3c022136 for ; Fri, 23 Aug 2002 13:12:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7NKCrsl022135 for mobile-ip-dist; Fri, 23 Aug 2002 13: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NKCp3c022128 for ; Fri, 23 Aug 2002 13:12:51 -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 QAA10769 for ; Fri, 23 Aug 2002 16:13:01 -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 g7NKDAXA012017 for ; Fri, 23 Aug 2002 16:13:10 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g7NKDA69012016 for mobile-ip@sunroof.eng.sun.com; Fri, 23 Aug 2002 16:13:10 -0400 (EDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7MLWo3c019361 for ; Thu, 22 Aug 2002 14:32: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 OAA08579 for ; Thu, 22 Aug 2002 14:33:00 -0700 (PDT) Received: from er4hp030.eng.ohio-state.edu (er4hp030.eng.ohio-state.edu [164.107.161.31]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA20156 for ; Thu, 22 Aug 2002 15:32:59 -0600 (MDT) Received: (from ekici@localhost) by er4hp030.eng.ohio-state.edu (8.9.3 (PHNE_22672)/8.7.3) id RAA12994 for mobile-ip@sunroof.eng.sun.com; Thu, 22 Aug 2002 17:32:56 -0400 (EDT) Date: Thu, 22 Aug 2002 17:32:56 -0400 (EDT) From: Eylem Ekici Message-Id: <200208222132.RAA12994@er4hp030.eng.ohio-state.edu> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] SNPA 2003 CFP - First IEEE Workshop on Sensor Network Protocols and Applications 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 Our apologies if you have received multiple copies of this CFP. -------------------------------------------------------------------------- CALL FOR PAPERS IEEE ICC 2003 Workshop SNPA 2003 First IEEE International Workshop on Sensor Network Protocols and Applications in Conjunction with IEEE ICC 2003 May 11, 2003 -------------------------------------------------------------------------- URLs: SNPA 2003: http://www.icc2003.com/workshop1.html ICC 2003: http://www.icc2003.com Submission Deadline: October 22, 2002 -------------------------------------------------------------------------- SCOPE Wireless Sensor Networks (WSNs) are fast emerging as a new sensing paradigm based on the collaborative effort of large number of sensors deployed close to or inside the phenomenon to be observed, and have the potential of providing diverse services to numerous applications. The realization of WSNs require intensive technical research efforts especially in power aware scalable wireless ad hoc communications protocols due to their unusual application requirements and unique constraints such as - WSNs are generally composed of large number of nodes that have limited computational and storage capacity. - In many applications, sensor nodes are expected to be randomly scattered in unreachable regions. - The lifetime of a sensor network is generally limited to the battery lifetime of sensor nodes. SNPA 2003 is intended to provide a forum for researchers to present their contributions as technical papers related to communication protocols for WSNs, data management, access, aggregation and fusion techniques, and sensor network applications. The papers solicited in SNPA 2003 cover a variety of topics including but not limited to: - Communication protocols for Wireless Sensor Networks at all layers - Novel sensor network applications and services - Self organizing and scalable sensor network architectures - Software platforms and tools for sensor network application development - Energy efficient medium access control, error control, and traffic management protocols - Energy efficient system services such as localization and time synchronization - Robust distributed algorithms for collaborative processing - Mechanisms, protocols and algorithms for authenticated, secure communication - Application specific network and system services, including data-centric routing, attribute based addressing and location management - Data querying and dissemination - Data compression, association, aggregation and fusion SUBMISSION INSTRUCTIONS The papers should confirm with ICC 2003 paper format and can be up to 11 pages long. Authors should submit a PDF version of their paper to snpa03@cs.itu.edu.tr according to the following timetable Manuscript Due: October 22, 2002 Acceptance Notification: December 17, 2002 Final Manuscript Due: January 14, 2003 Workshop Date: May 11, 2003 ORGANIZATION PROGRAM CO-CHAIRS Erdal Cayirci Department of Computer Engineering Istanbul Technical University Istanbul E-mail: erdal@ece.gatech.edu Taieb Znati Div.of Adv.Net.Inf.& Res. NSF Arlington, VA 22230 E-mail: tznati@nsf.gov TECHNICAL PROGRAM COMMITTEE * Sebnem Baydere (Yeditepe University) * Azzedine Boukerche (University of North Texas) * Erdal Cayirci (Istanbul Technical University) * Eylem Ekici (Ohio State University) * Deborah Estrin (UCLA) * John Heidemann (ISI) * Bashkar Khrisnamachari (Cornell) * Sri Kumar (DARPA) * Geng-Sheng Kuo (National Chengchi University) * Stephen Olariu (Old Dominion University) * Sergio Palazzo (University of Catania) * Chiara Petrioli (Roma University) * Parmesh Ramanathan (University of Wisconsin) * Suresh Singh (Portland State University) * Stephen Wicker (Cornell) * Adam Wolisz (Technical University of Berlin) * Michele Zorzi (Universita' di Ferrara) PUBLICITY CO-CHAIR Eylem Ekici Ohio State University E-mail: ekici@ee.eng.ohio-state.edu SPONSORS Sponsored by the following IEEE Communications Society Technical Committees: * Tactical Communications * Personal Communications (Pending) * Radio Communications (Pending) From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 23 16:16:33 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 QAA16559 for ; Fri, 23 Aug 2002 16: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 NAA02153; Fri, 23 Aug 2002 13:15: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 NAA29502; Fri, 23 Aug 2002 13:15:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NKE73c022153 for ; Fri, 23 Aug 2002 13:14:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7NKE7I6022152 for mobile-ip-dist; Fri, 23 Aug 2002 13:14: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NKE43c022145 for ; Fri, 23 Aug 2002 13:14:05 -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 QAA11003 for ; Fri, 23 Aug 2002 16:14:15 -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 g7NKEOXA012022 for ; Fri, 23 Aug 2002 16:14:24 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g7NKEOq0012021 for mobile-ip@sunroof.eng.sun.com; Fri, 23 Aug 2002 16:14:24 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KLBx3c009418 for ; Tue, 20 Aug 2002 14:11: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 OAA17736 for ; Tue, 20 Aug 2002 14:12:08 -0700 (PDT) Received: from igw3.watson.ibm.com (igw3.watson.ibm.com [198.81.209.18]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00446 for ; Tue, 20 Aug 2002 14:12:08 -0700 (PDT) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw3.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g7KLC6F13748 for ; Tue, 20 Aug 2002 17:12:06 -0400 Received: from scarpia.watson.ibm.com (scarpia.watson.ibm.com [9.2.9.124]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id g7KLC5V127936 for ; Tue, 20 Aug 2002 17:12:05 -0400 Received: (from ayoussef@localhost) by scarpia.watson.ibm.com (AIX4.3/8.9.3/8.9.3/01-10-2000) id RAA49104 for mobile-ip@sunroof.eng.sun.com; Tue, 20 Aug 2002 17:11:55 -0400 Date: Tue, 20 Aug 2002 17:11:55 -0400 From: Alaa Youssef Message-Id: <200208202111.RAA49104@scarpia.watson.ibm.com> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Infocom 2003 Call For Tutorials Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Dear Colleague, Please accept my apology if you receive multiple copies of this announcement. --------------- INFOCOM 2003 -- Call For Tutorial Proposals The 22nd Annual Joint Conference of the IEEE Computer and Communications Societies Tutorial Proposal Deadline: September 30, 2002 Conference dates: April 1-3, 2003 We are pleased to accept proposals for tutorial presentations at IEEE Infocom 2003 in San Francisco. Infocom draws a diverse and large audience each year and is the premier networking conference of the IEEE. Past tutorial authors include some of the most outstanding researchers and industry leaders in the fields of networking and security. Potential instructors are requested to submit a tutorial proposal of at most 3 pages, including a biographical sketch, tutorial abstract, and tutorial outline to the Tutorial Co-Chairs, Brian Neil Levine [brian@cs.umass.edu] and Christophe Diot [cdiot@sprintlabs.com]. Deadline for accepting Tutorial proposals is a hard deadline of September 30, 2002. Evaluation of proposals will be based on the expertise and experience of the instructors, and on the relevance and timeliness of the subject matter. Authors are encouraged to reviews abstracts of tutorials from last infocom to gain an idea of scope and level of expertise we desire. Please keep in mind, our goal is to offer the most up-to-date, relevant, and interesting array of topics possible. From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 23 16:21:41 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 QAA16668 for ; Fri, 23 Aug 2002 16:21:40 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.37]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23310; Fri, 23 Aug 2002 14:18:15 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7NKHqkZ007176; Fri, 23 Aug 2002 13:18:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NKGa3c022422 for ; Fri, 23 Aug 2002 13:16:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7NKGamq022421 for mobile-ip-dist; Fri, 23 Aug 2002 13:16: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NKGW3c022401 for ; Fri, 23 Aug 2002 13:16:32 -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 QAA11511 for ; Fri, 23 Aug 2002 16:16:43 -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 g7NKGqXA012027 for ; Fri, 23 Aug 2002 16:16:52 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g7NKGp4F012026 for mobile-ip@sunroof.eng.sun.com; Fri, 23 Aug 2002 16:16:51 -0400 (EDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7KF063c007751; Tue, 20 Aug 2002 08:00:06 -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 IAA12162; Tue, 20 Aug 2002 08:00:16 -0700 (PDT) Received: from mail2 ([149.99.32.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01495; Tue, 20 Aug 2002 09:00:15 -0600 (MDT) Received: from atp (unverified [149.99.32.50]) by mail2 (Rockliffe SMTPRA 4.2.2) with ESMTP id ; Tue, 20 Aug 2002 08:29:54 -0700 Message-ID: <2011843.1029855891531.JavaMail.Administrator@atp> Date: Tue, 20 Aug 2002 08:04:51 -0700 (PDT) From: bkhabs Reply-To: bkhabs@nc.rr.com To: Francis.Dupont@enst-bretagne.fr, msa@burp.tkv.asdf.org Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization Cc: mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: E-mailanywhere V2.0 (Windows) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Tue, 20 Aug 2002 17:10:31 0300 Markku Savela wrote. From: Francis Dupont Another detail: before doing DAD, the solicited group must be joined and this is another cause of collisions when implementations are buggy (i.e., no new report should be sent because the node is already a member of the group). What report? Solicited node is LINKLOCAL group, there is no need to send any joins on those? Or is some weird multilink hack again breaking the basic assumptions about Link Local? RFC 2710 requires that nodes listening to a multicast group of scope 2 or greater (excluding ALL-NODES) to participate in the MLD protocol. It is intended to allow for proper behavior with the use of IGMP/MLD snooping switches. Brian From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 23 16:22: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 QAA16682 for ; Fri, 23 Aug 2002 16:21:59 -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 OAA25293; Fri, 23 Aug 2002 14:22: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 NAA01933; Fri, 23 Aug 2002 13:22:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NKLe3c022840 for ; Fri, 23 Aug 2002 13:21:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7NKLe9l022839 for mobile-ip-dist; Fri, 23 Aug 2002 13:21: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 eastmail2.East.Sun.COM (eastmail2.East.Sun.COM [129.148.1.241]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NKLb3c022832 for ; Fri, 23 Aug 2002 13:21:38 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA12470 for ; Fri, 23 Aug 2002 16:21:47 -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 g7NKLuXA012034 for ; Fri, 23 Aug 2002 16:21:56 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g7NKLtPW012033 for mobile-ip@sunroof.eng.sun.com; Fri, 23 Aug 2002 16:21:55 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7J9gP3c029070 for ; Mon, 19 Aug 2002 02:42:25 -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 CAA23394 for ; Mon, 19 Aug 2002 02:42:36 -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 CAA25547 for ; Mon, 19 Aug 2002 02:42:35 -0700 (PDT) Received: by p2.piuha.net (Postfix, from userid 962) id B0FF86A906; Mon, 19 Aug 2002 12:42:33 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 92F8F6A904; Mon, 19 Aug 2002 12:42:30 +0300 (EEST) Message-ID: <3D60BEA9.1050307@kolumbus.fi> Date: Mon, 19 Aug 2002 12:47:21 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: vriz@lit.a-star.edu.sg Cc: Mobile IP Mailing List Subject: Re: [mobile-ip] CN to MN (Sending Binding Acknowledgement) References: <351713a06f.3a06f35171@lit.org.sg> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Appologies from the list admin: Somehow this got mis-filtered, but is important for the list! vriz@lit.a-star.edu.sg wrote: No. Per issue #92 CNs will not respond to HoA if the src is unsuitable. That means checking of whether the src address is legal for routing purpose, is compulsory no matter whether if it's (src address's) a HoA or not? Yes. Therefore, binding cache information is not to be used when sending BAck. Yes. The src address must be checked if it's legal. Yes. Determination of whether RH2 is to be used only if the BU contains a dest opt for HoA. Yes. If there's no dest opt for HoA, then BAck is sent directly to the src address. Yes. As Erik pointed out, is it necessary to use RH2 if the BAck is to return a failure status code? This is debatable, I think. I'm not sure I see why we would _have_ to send it either with RH2 or without. Couldn't we simply do it the same way as we do for the regular BA? Will there be any security loophole in this case? I don't think we have any security loophole if we always respond to the same source address that was in the request. Adding RH2 doesn't really cause anything terrible to happen, as the result will stay within the same node. Jari From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 23 17:18:58 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 RAA17988 for ; Fri, 23 Aug 2002 17:18:58 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01810; Fri, 23 Aug 2002 14:18:18 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA00679; Fri, 23 Aug 2002 14:18:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NLH53c023325 for ; Fri, 23 Aug 2002 14:17:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7NLH58O023324 for mobile-ip-dist; Fri, 23 Aug 2002 14:17: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7NLGv3c023314 for ; Fri, 23 Aug 2002 14:16:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19539 for ; Fri, 23 Aug 2002 14:17:07 -0700 (PDT) Received: from esunmail ([129.147.58.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01941 for ; Fri, 23 Aug 2002 15:17:07 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.122]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 0.8 (built Jul 12 2002)) with ESMTP id <0H1B00G5AF4IVA@edgemail1.Central.Sun.COM> for mobile-ip@sunroof.eng.sun.com; Fri, 23 Aug 2002 15:17:07 -0600 (MDT) Received: from h003065150df1.ne.client2.attbi.com ([129.148.174.195]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 0.2 (built Apr 26 2002)) with ESMTPSA id <0H1B007ITF4HYQ@mail.sun.net> for mobile-ip@sunroof.eng.sun.com; Fri, 23 Aug 2002 15:17:06 -0600 (MDT) Date: Fri, 23 Aug 2002 17:18:08 -0400 From: "Steven M. Glass" Subject: [mobile-ip] Web archives accessible again. To: mobile-ip@sunroof.eng.sun.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.482) 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 As some of you noticed, the archives were unaccessible, however that problem has been fixed. Note the issue isn't completely resolved yet as there are some email messages that exist on our new internal mirror that for some reason aren't on playground.sun.com, but when the rsync is done they'll be back. If you recall, as with the last issue with our server over a year ago, it was an rsync problem again, this time between a new internal mirror and playground [apparently] due to a permissions issues. I'll keep an eye on it, and hopefully this head of the hydra won't grow back! Please note - requesting an archive via email does work, so it's a work-around in cases like this; I don't believe they were ever down. I've confirmed email to majordomo@sunroof.eng.sun.com for the August archives does get you all the most recent postings! Expect two emails in response, e.g. >>>>get mobile-ip mobile-ip.200208 List 'mobile-ip' file 'mobile-ip.200208' >>>>is being sent as a separate message. See http://playground.sun.com/mobile-ip/instructions.html if you'd like to do this. Warning: August 2002 is already 653K! Cheers, Steve PS(FYI: we're now blocking close to 15 spam's from the list every day!) From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 24 03:44: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 DAA06392 for ; Sat, 24 Aug 2002 03:44:18 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.26]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA27295; Sat, 24 Aug 2002 01:39:31 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7O7dBuF028965; Sat, 24 Aug 2002 00:39:28 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7O7bx3c024306 for ; Sat, 24 Aug 2002 00:37:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7O7bwhm024305 for mobile-ip-dist; Sat, 24 Aug 2002 00:37: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7O7br3c024298 for ; Sat, 24 Aug 2002 00:37:53 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA12844 for ; Sat, 24 Aug 2002 00:38:03 -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 BAA27032 for ; Sat, 24 Aug 2002 01:38:02 -0600 (MDT) Received: by p2.piuha.net (Postfix, from userid 962) id 6935B6A904; Sat, 24 Aug 2002 10:37:45 +0300 (EEST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id AFA356A901; Sat, 24 Aug 2002 10:37:43 +0300 (EEST) Message-ID: <3D6738F1.6020202@kolumbus.fi> Date: Sat, 24 Aug 2002 10:42:41 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mobile-ip@sunroof.eng.sun.com'" Cc: "Tero Kauppinen (LMF)" Subject: [mobile-ip] new text for 85, 86 new issue 105, and state machines Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none version=2.31 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit There's new text proposals for the below issues: http://www.piuha.net/~jarkko/publications/mipv6/issues/issue85.txt http://www.piuha.net/~jarkko/publications/mipv6/issues/issue86.txt and there's also a new issue filed against the state machine: http://www.piuha.net/~jarkko/publications/mipv6/issues/issue105.txt In order to close issue #76 I'd like you to send me (private) e-mail that tells whether you'd like (a) just keep the text and remove any state machines, (b) add the state machines a non-normative introduction to section 11, or (c) continue the current approach and have normative text and non-normative state machines as separate sections. Finally, I have also added a new field in the issue list that describes whether or not we have a concrete text proposal available to fix it. We intend to post text for the remaining issues in the next week or so. Thanks, Jari From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 25 11:46: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 LAA10610 for ; Sun, 25 Aug 2002 11:46: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 IAA17543; Sun, 25 Aug 2002 08:46: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 IAA23778; Sun, 25 Aug 2002 08:46:19 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7PFjH3c026661 for ; Sun, 25 Aug 2002 08:45:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7PFjHn3026660 for mobile-ip-dist; Sun, 25 Aug 2002 08:45:17 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7PFjB3c026653 for ; Sun, 25 Aug 2002 08:45:11 -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 IAA09291 for ; Sun, 25 Aug 2002 08:45:22 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA17378 for ; Sun, 25 Aug 2002 08:45:21 -0700 (PDT) Received: from bohemian.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 25 Aug 2002 16:45:17 +0100 Message-ID: <3D68FB8D.38329EBA@cs.ucl.ac.uk> Date: Sun, 25 Aug 2002 16:45:17 +0100 From: Theo Pagtzis Reply-To: t.pagtzis@cs.ucl.ac.uk Organization: UCL/Mobile Systems Group X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.4-STABLE i386) X-Accept-Language: el, en MIME-Version: 1.0 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] LMM requirements: security issue References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> 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 In addition to what I have mentioned previously I would like to add that I believe that two more requirements are conflicting about security: In A: it is required that the LMM agent does not interfere with the security bindings between the MN and the peers whereas on B: it is required that the MN preserves location privacy under LMM. I cannot see how one can maintain location privacy (B) of the MN without breaking the end-to-end principle (A) in terms of security bindings. If the LMM agent is not to interfere with the security bindings of the MN-peers that means it cannot "hide" the MN. No interference by the LMM agent in the security bindings to means that the bindings are effected end-to-end, ie. the MN with a peer CN (and the respective on-link CoAs), or the MN and the HA. But the MN has to provide the regional CoA which is the addr of the LMM agent. That implies that any security binding effected...is effected between the LMM agent and the CN/HA. This is clearly violation of the end-2-end principle, since the peers think they communicate with one node, while they communicate with another in terms of security bindings. Thus, if one wants to keep location privacy in the requirements, I believe he has to kiss goodbye end-to-end security bindings. The opposite may also be the case; however both of the cases are mutualy exclusive. We _cannot_ have both worlds...unless somebody can convince for the opposite without violating the end-2-end principle. In fact when it comes to security between the MN and the peers, this is the first time that peers MUST know who they are talking to (i.e. not the MN, but a trusted representative of the MN), and thus the peers have to be injected with special functionality over security functions. That is to say, that LMM is transparent to the peers until the time the scheme requires security between the MN and the peers. theo UCL/Mobile Systems Group From owner-mobile-ip@sunroof.eng.sun.com Sun Aug 25 21:02: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 VAA17951 for ; Sun, 25 Aug 2002 21:02: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 SAA26196; Sun, 25 Aug 2002 18:01: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 SAA08895; Sun, 25 Aug 2002 18:01:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7Q10W3c027350 for ; Sun, 25 Aug 2002 18:00:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7Q10W6U027349 for mobile-ip-dist; Sun, 25 Aug 2002 18:00: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7Q10Q3c027342 for ; Sun, 25 Aug 2002 18:00:26 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA08691 for ; Sun, 25 Aug 2002 18:00:36 -0700 (PDT) Received: from ALPHA9.CC.MONASH.EDU.AU (alpha9.cc.monash.edu.au [130.194.1.9]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA12867 for ; Sun, 25 Aug 2002 19:00:34 -0600 (MDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KLR2241HKE90QC8V@vaxh.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Mon, 26 Aug 2002 11:00:22 +1000 Received: from blammo (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 6B24112C002; Mon, 26 Aug 2002 11:00:22 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 128A612C002; Mon, 26 Aug 2002 11:00:20 +1000 (EST) Date: Mon, 26 Aug 2002 11:00:19 +1000 From: Greg Daley Subject: Re: [mobile-ip] LMM requirements: security issue To: t.pagtzis@cs.ucl.ac.uk Cc: mobile-ip@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D697DA3.2040907@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi Theo, It is very simple in Basic Mode HMIPv6 for example, to have a system which allows HA and CN bindings to an address at the LMM Agent (the MAP), without modification to the binding mechanism provided for MIPv6. This is because there is a 1-to-1 mapping between the RCoA and the MN in HMIPv6 Basic Mode. As just another CoA the MN's RCoA (at the LMM) is required to undergo Return Reachability tests to CNs. Therefore the HMIPv6 protocol must support the use of RR as an exisiting authorization protocol, without interfering in the process. Since the RCoA Addresses provided in Basic HMIPv6 are uniquely mapped to the MN all packets to that address (even without mobility headers) are delivered to the MN. All security associations are between the MN and the CN (e-to-e), if the MN can send CoT messages reverse tunnelled to the MAP. IKE negotiated IPSec associations are also negotiated directly, without the interference from the LMM Agent. In the case with the current HMIPv6 extended mode, the RCoA is shared, and therefore the RR CoT may not be performed without interference from the Extended MAP. This means that Extended Mode HMIPv6 breaks this LMM requirement as specified today. As it stands, I think that HMIPv6 extended mode is about to be modified. The statement in the LMM draft sounds OK, but is it really necessary, if the MN has identified the LMM agent, and trusts it? Couldn't the security associations be formed with the help of the LMM, since it owns the address which is being used for a regional care-of-address (or defends it on the LMM's link, which amounts to the same thing), and also has an trust relationship which allows the MN to use the RCoA? So, seeing that we can have two worlds (with the HMIPv6 Basic mode LMM case) where e-to-e security associations and location privacy is maintained, is it necessary or desirable to have the e-to-e security association/negotiation , precluding the mediation of the LMM agent? Greg Daley Theo Pagtzis wrote: > In addition to what I have mentioned previously I would like to add that > I believe that two more requirements are conflicting about security: > > In A: > it is required that the LMM agent does not interfere with the > security bindings between the MN and the peers > > whereas on B: > > it is required that the MN preserves location privacy under LMM. > > I cannot see how one can maintain location privacy (B) of the MN without > breaking the end-to-end principle (A) in terms of security bindings. If > the LMM agent is not to interfere with the security bindings of the > MN-peers that means it cannot "hide" the MN. > > No interference by the LMM agent in the security bindings to means that > the bindings are effected end-to-end, ie. the MN with a peer CN (and the > respective on-link CoAs), or the MN and the HA. But the MN has to > provide the regional CoA which is the addr of the LMM agent. That > implies that any security binding effected...is effected between the LMM > agent and the CN/HA. This is clearly violation of the end-2-end > principle, since the peers think they communicate with one node, while > they communicate with another in terms of security bindings. > > Thus, if one wants to keep location privacy in the requirements, I > believe he has to kiss goodbye end-to-end security bindings. The > opposite may also be the case; however both of the cases are mutualy > exclusive. We _cannot_ have both worlds...unless somebody can convince > for the opposite without violating the end-2-end principle. > > In fact when it comes to security between the MN and the peers, this is > the first time that peers MUST know who they are talking to (i.e. not > the MN, but a trusted representative of the MN), and thus the peers have > to be injected with special functionality over security functions. That > is to say, that LMM is transparent to the peers until the time the > scheme requires security between the MN and the peers. > > > > theo > UCL/Mobile Systems Group > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 26 09:19: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 JAA08002 for ; Mon, 26 Aug 2002 09:19:39 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21432; Mon, 26 Aug 2002 07:20: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 GAA26378; Mon, 26 Aug 2002 06:20:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QDJO3c028278 for ; Mon, 26 Aug 2002 06:19:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QDJNQD028277 for mobile-ip-dist; Mon, 26 Aug 2002 06:19: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.37]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QDJH3c028270 for ; Mon, 26 Aug 2002 06:19:18 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7QDJSkT003165 for ; Mon, 26 Aug 2002 06:19:29 -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 HAA26738 for ; Mon, 26 Aug 2002 07:19:22 -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 g7QDJERc000662; Mon, 26 Aug 2002 15:19:19 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 26 Aug 2002 15:19:14 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0919@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'t.pagtzis@cs.ucl.ac.uk'" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue Date: Mon, 26 Aug 2002 15:19:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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: Theo, > In addition to what I have mentioned previously I would > like to add that > I believe that two more requirements are conflicting about security: > > In A: > it is required that the LMM agent does not interfere with the > security bindings between the MN and the peers > > whereas on B: > > it is required that the MN preserves location privacy under LMM. > > I cannot see how one can maintain location privacy (B) of > the MN without > breaking the end-to-end principle (A) in terms of security > bindings. => These are requirements and are not meant to show how it can be done. Of course we don't want to place impossible requirements, but as Greg explained, this is already doable to a large extent with the existing HMIPv6, so I don't think it's impossible. Hesham From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 26 09:32: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 JAA08222 for ; Mon, 26 Aug 2002 09:32: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 HAA03113; Mon, 26 Aug 2002 07:33:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29201; Mon, 26 Aug 2002 06:33:39 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QDTi3c028465 for ; Mon, 26 Aug 2002 06:29:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QDThw0028464 for mobile-ip-dist; Mon, 26 Aug 2002 06:29: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.26]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QDTM3c028457 for ; Mon, 26 Aug 2002 06:29:23 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7QDTWu9018553 for ; Mon, 26 Aug 2002 06:29:33 -0700 (PDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25665 for ; Mon, 26 Aug 2002 07:29:26 -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 g7QDT0CG018285; Mon, 26 Aug 2002 22:29:06 +0900 (KST) Message-ID: <005001c24d04$89c78f00$ad29024b@yhhan> From: "Youn-Hee Han" To: Cc: , References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Mon, 26 Aug 2002 22:28:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g7QDTc3c028458 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Hi Theo and Greg, I agree with Greg's opinion. The HMIPv6 is a good representative of LMM, and the RCoA in Basic HMIPv6 is uniquely assigned to the MN. Therefore, IPSec associations are also negotiated directly between MN and CN, without the interference from the LMM Agent. And, I think that the Extended mode in HMIPv6 must be not involved in the LMM requirements, but in NEMO (network mobility) requirements. As you know, the mode is schemed out for supporting a mobile network by having the Mobile Router act as MAP within the visited network. Youn-Hee Han Samsung AIT. ----- Original Message ----- From: "Greg Daley" To: Cc: Sent: Monday, August 26, 2002 10:00 AM Subject: Re: [mobile-ip] LMM requirements: security issue > Hi Theo, > > It is very simple in Basic Mode HMIPv6 for example, to have > a system which allows HA and CN bindings to an address at > the LMM Agent (the MAP), without modification to the binding > mechanism provided for MIPv6. > > This is because there is a 1-to-1 mapping between the > RCoA and the MN in HMIPv6 Basic Mode. > > As just another CoA the MN's RCoA (at the LMM) is required > to undergo Return Reachability tests to CNs. Therefore the > HMIPv6 protocol must support the use of RR as an exisiting > authorization protocol, without interfering in the process. > > Since the RCoA Addresses provided in Basic HMIPv6 are > uniquely mapped to the MN all packets to that address > (even without mobility headers) are delivered to the MN. > > All security associations are between the MN and the CN > (e-to-e), if the MN can send CoT messages reverse tunnelled > to the MAP. IKE negotiated IPSec associations are also > negotiated directly, without the interference from the > LMM Agent. > > In the case with the current HMIPv6 extended mode, the RCoA > is shared, and therefore the RR CoT may not be performed > without interference from the Extended MAP. This means that > Extended Mode HMIPv6 breaks this LMM requirement as specified > today. > > As it stands, I think that HMIPv6 extended mode is about to > be modified. > > The statement in the LMM draft sounds OK, but is it really > necessary, if the MN has identified the LMM agent, and trusts > it? Couldn't the security associations be formed with the > help of the LMM, since it owns the address which > is being used for a regional care-of-address (or defends it > on the LMM's link, which amounts to the same thing), > and also has an trust relationship which allows the MN to > use the RCoA? > > So, seeing that we can have two worlds (with the HMIPv6 Basic > mode LMM case) where e-to-e security associations and location > privacy is maintained, > is it necessary or desirable to have the e-to-e security > association/negotiation , precluding the mediation of the > LMM agent? > > Greg Daley > > > Theo Pagtzis wrote: > > In addition to what I have mentioned previously I would like to add that > > I believe that two more requirements are conflicting about security: > > > > In A: > > it is required that the LMM agent does not interfere with the > > security bindings between the MN and the peers > > > > whereas on B: > > > > it is required that the MN preserves location privacy under LMM. > > > > I cannot see how one can maintain location privacy (B) of the MN without > > breaking the end-to-end principle (A) in terms of security bindings. If > > the LMM agent is not to interfere with the security bindings of the > > MN-peers that means it cannot "hide" the MN. > > > > No interference by the LMM agent in the security bindings to means that > > the bindings are effected end-to-end, ie. the MN with a peer CN (and the > > respective on-link CoAs), or the MN and the HA. But the MN has to > > provide the regional CoA which is the addr of the LMM agent. That > > implies that any security binding effected...is effected between the LMM > > agent and the CN/HA. This is clearly violation of the end-2-end > > principle, since the peers think they communicate with one node, while > > they communicate with another in terms of security bindings. > > > > Thus, if one wants to keep location privacy in the requirements, I > > believe he has to kiss goodbye end-to-end security bindings. The > > opposite may also be the case; however both of the cases are mutualy > > exclusive. We _cannot_ have both worlds...unless somebody can convince > > for the opposite without violating the end-2-end principle. > > > > In fact when it comes to security between the MN and the peers, this is > > the first time that peers MUST know who they are talking to (i.e. not > > the MN, but a trusted representative of the MN), and thus the peers have > > to be injected with special functionality over security functions. That > > is to say, that LMM is transparent to the peers until the time the > > scheme requires security between the MN and the peers. > > > > > > > > theo > > UCL/Mobile Systems Group > > > > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 26 10:58: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 KAA09814 for ; Mon, 26 Aug 2002 10:58:10 -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 IAA09188; Mon, 26 Aug 2002 08:59: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 HAA27846; Mon, 26 Aug 2002 07:59:09 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QEw13c028742 for ; Mon, 26 Aug 2002 07:58:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QEw10q028741 for mobile-ip-dist; Mon, 26 Aug 2002 07: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QEvr3c028734 for ; Mon, 26 Aug 2002 07:57:54 -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 HAA04634 for ; Mon, 26 Aug 2002 07:58:03 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23532 for ; Mon, 26 Aug 2002 07:58:03 -0700 (PDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id C9C548DF1; Mon, 26 Aug 2002 10:58:02 -0400 (EDT) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 981D2EBC; Mon, 26 Aug 2002 07:58:01 -0700 (PDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id KAA0000914641; Mon, 26 Aug 2002 10:58:00 -0400 (EDT) Message-ID: <3D6A41F8.6956A6E2@hp.com> Date: Mon, 26 Aug 2002 10:58:00 -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: Jari Arkko Cc: "'mobile-ip@sunroof.eng.sun.com'" Subject: Re: [mobile-ip] new text for 85, 86 new issue 105, and state machines References: <3D6738F1.6020202@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: > There's new text proposals for the below issues: > > http://www.piuha.net/~jarkko/publications/mipv6/issues/issue85.txt Hi Jari, issue85.txt says: " And then change the text in 9.4.6 from If the correspondent node receives a packet with a Home Address destination option it MUST verify that it has a binding for that mobile node. Specifically, it MUST have a binding entry for the mobile node's home address (as obtained from the Home Address option) at the mobile node's care-of address (from the IP source address of the packet). If the correspondent node does not find such a binding entry, it MUST discard the packet. It MUST also return a Binding Error message (Section 6.1.9), subject to rate limiting in the same manner as is done for ICMPv6 messages [14]. to Sections 9.2.1 and 9.4.6 describe error conditions that lead to a need to send a Binding Error message. A Binding Error message is sent to the address that appeared in the IPv6 Source address field of the offending packet. The Home Address field in the Binding Error message MUST be copied from the Home Address field in the Home Address destination option of the offending packet, or set to the unspecified address if no such option appeared in the packet. Binding Error messages are subject to rate limiting in the same manner as is done for ICMPv6 messages [14]. " BPH> But 9.4.6 now references itself? I think you meant to say: "Sections 9.2.1 and 9.2.2 describe..." issue85.txt also says: " In 9.2.1 change 1. If an MH message of unknown type is received (Section 6.1, the correspondent node SHOULD issue a Binding Error message to the packet's Source Address with Status field set to 2. Finally, the correspondent node MUST discard the packet. to 1. If an MH message of unknown type is received the correspondent node SHOULD issue a Binding Error message as described in Section 9.4.6, with Status field set to 2. Finally, the correspondent node MUST discard the packet. " BPH> I just have an editorial change for this, I thought the reference to 6.1 was useful: 1. If an MH message of unknown type is received (Section 6.1), the correspondent node SHOULD issue a Binding Error message as described in Section 9.4.6, with Status field set to 2. Finally, the correspondent node MUST discard the packet. The rest looks good, thanks, -Brian From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 26 12:06: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 MAA12550 for ; Mon, 26 Aug 2002 12:06:25 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.26]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27809; Mon, 26 Aug 2002 10:02:59 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7QG2iuF006471; Mon, 26 Aug 2002 09:02:57 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QG1k3c029078 for ; Mon, 26 Aug 2002 09:01:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QG1k9X029077 for mobile-ip-dist; Mon, 26 Aug 2002 09:01: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QG1f3c029070 for ; Mon, 26 Aug 2002 09:01:41 -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 JAA29670 for ; Mon, 26 Aug 2002 09:01:51 -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 KAA21551 for ; Mon, 26 Aug 2002 10:01:51 -0600 (MDT) Message-ID: <004a01c24d19$a7804e00$296015ac@T23KEMPF> From: "James Kempf" To: , References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Mon, 26 Aug 2002 09:00: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 Theo, > No interference by the LMM agent in the security bindings to means that > the bindings are effected end-to-end, ie. the MN with a peer CN (and the > respective on-link CoAs), or the MN and the HA. But the MN has to > provide the regional CoA which is the addr of the LMM agent. That > implies that any security binding effected...is effected between the LMM > agent and the CN/HA. This is clearly violation of the end-2-end > principle, since the peers think they communicate with one node, while > they communicate with another in terms of security bindings. > I don't see how this follows. It the MN is performing the regional care of address binding update, it can provide the proper security credentials. With the Home Agent, it uses the IPsec security association required for Mobile IPv6. With any correspondent nodes, it uses RR or some other algorithm. Am I missing something? jak From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 26 12:17: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 MAA13160 for ; Mon, 26 Aug 2002 12:17:14 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25319; Mon, 26 Aug 2002 10:18: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 JAA10140; Mon, 26 Aug 2002 09:18:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QGH33c029333 for ; Mon, 26 Aug 2002 09:17:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QGH2d7029332 for mobile-ip-dist; Mon, 26 Aug 2002 09:17: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QGGu3c029325 for ; Mon, 26 Aug 2002 09:16:57 -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 JAA09880 for ; Mon, 26 Aug 2002 09:17:07 -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 JAA03413 for ; Mon, 26 Aug 2002 09:17:07 -0700 (PDT) Message-ID: <006a01c24d1b$c3baf320$296015ac@T23KEMPF> From: "James Kempf" To: , Cc: References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Mon, 26 Aug 2002 09:15:16 -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 > The statement in the LMM draft sounds OK, but is it really > necessary, if the MN has identified the LMM agent, and trusts > it? Couldn't the security associations be formed with the > help of the LMM, since it owns the address which > is being used for a regional care-of-address (or defends it > on the LMM's link, which amounts to the same thing), > and also has an trust relationship which allows the MN to > use the RCoA? > No, end to end security is end to end. It can't be compromised by involving someone in the middle. But, as you say, breaking it in the middle isn't required for basic mode anyway. As for extended mode, I'm always in favor of making protocols simpler and I have never really seen the need for it anyway, so I think it could profitably be dropped from the specification. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 26 13:12: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 NAA14561 for ; Mon, 26 Aug 2002 13:12: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 LAA08705; Mon, 26 Aug 2002 11:13:02 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28465; Mon, 26 Aug 2002 10:13:00 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHBq3c029657 for ; Mon, 26 Aug 2002 10:11:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QHBqps029656 for mobile-ip-dist; Mon, 26 Aug 2002 10:11: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QHBk3c029649 for ; Mon, 26 Aug 2002 10:11:46 -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 KAA18733 for ; Mon, 26 Aug 2002 10:11:57 -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 LAA26469 for ; Mon, 26 Aug 2002 11:11:56 -0600 (MDT) Message-ID: <00d401c24d23$6a281100$296015ac@T23KEMPF> From: "James Kempf" To: "Youn-Hee Han" , Cc: , References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <005001c24d04$89c78f00$ad29024b@yhhan> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Mon, 26 Aug 2002 10:09: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 > And, I think that the Extended mode in HMIPv6 must be not involved > in the LMM requirements, but in NEMO (network mobility) requirements. > As you know, the mode is schemed out for supporting a mobile network > by having the Mobile Router act as MAP within the visited network. > I agree. I think extended mode should be taken out of the HMIP draft and moved into NEMO, since it seems primarily motivated by a desire to support mobile routers. jak From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 26 15:38:50 2002 Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20372 for ; Mon, 26 Aug 2002 15:38:49 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10430; Mon, 26 Aug 2002 13:39: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 MAA20925; Mon, 26 Aug 2002 12:39:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QJcI3c000265 for ; Mon, 26 Aug 2002 12:38:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QJcH3W000264 for mobile-ip-dist; Mon, 26 Aug 2002 12:38: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.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QJcC3c000255 for ; Mon, 26 Aug 2002 12:38:12 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29391 for ; Mon, 26 Aug 2002 12:38:22 -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 NAA09590 for ; Mon, 26 Aug 2002 13:38:22 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA05817; Mon, 26 Aug 2002 12:38:21 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7QJcLw12873; Mon, 26 Aug 2002 12:38:21 -0700 X-mProtect: <200208261938> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.179, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdg2DlkD; Mon, 26 Aug 2002 12:38:17 PDT Message-ID: <3D6A83A1.6040008@iprg.nokia.com> Date: Mon, 26 Aug 2002 12:38:09 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: "Hesham Soliman (EAB)" CC: Vladislav Yasevich , mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Question about MIPv6 draft 18 References: <4DA6EA82906FD511BE2F00508BCF0538044F08D5@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 > => There are possibly 2^^64 addresses on a single > link :) all can be CoAs. So it doesn't have to move > anywhere. simple solution is rate limiting at the CN. there cant possibly be 2^64 mobile nodes connecting from the same /64 prefix. Vijay > > Hesham > > > > > > regards > > Vijay > > > From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 26 15:48: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 PAA20639 for ; Mon, 26 Aug 2002 15:48:17 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16836; Mon, 26 Aug 2002 13:49: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 MAA29073; Mon, 26 Aug 2002 12:49:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QJm73c000452 for ; Mon, 26 Aug 2002 12:48:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7QJm73s000451 for mobile-ip-dist; Mon, 26 Aug 2002 12:48:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7QJm13c000444 for ; Mon, 26 Aug 2002 12:48:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01643; Mon, 26 Aug 2002 12:48: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 NAA18968; Mon, 26 Aug 2002 13:48: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 MAA06323; Mon, 26 Aug 2002 12:48:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7QJmAG22975; Mon, 26 Aug 2002 12:48:10 -0700 X-mProtect: <200208261948> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.179, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEKVvmb; Mon, 26 Aug 2002 12:48:06 PDT Message-ID: <3D6A85EE.3090000@iprg.nokia.com> Date: Mon, 26 Aug 2002 12:47:58 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Samita Chakrabarti CC: jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] Re: MIPv6 Draft 18 Comments References: <200208210159.g7L1xMD7346981@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 > Ok. Then this is valid for CN case, but not for HA case. How should HA > react if it receives a BU without BAD or IPsec (or any other security > mechanism in future) ? I prefer just dropping the BU. there is no need for the HA to send a BA with yet another error status. Vijay From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 26 20:26: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 UAA26939 for ; Mon, 26 Aug 2002 20:26:51 -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 RAA09881; Mon, 26 Aug 2002 17:26: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 RAA19740; Mon, 26 Aug 2002 17:26:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7R0PB3c001046 for ; Mon, 26 Aug 2002 17:25:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7R0PB7C001045 for mobile-ip-dist; Mon, 26 Aug 2002 17:25: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.26]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7R0P53c001038 for ; Mon, 26 Aug 2002 17:25:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7R0PGu9022939 for ; Mon, 26 Aug 2002 17:25:16 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA05716 for ; Mon, 26 Aug 2002 18:25:10 -0600 (MDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxc.cc.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KLSF2OHTT69DIOEM@vaxc.cc.monash.edu.au> for mobile-ip@sunroof.eng.sun.com; Tue, 27 Aug 2002 10:24:18 +1000 Received: from blammo (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 8494512C008; Tue, 27 Aug 2002 10:24:14 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id D931412C008; Tue, 27 Aug 2002 10:23:52 +1000 (EST) Date: Tue, 27 Aug 2002 10:23:52 +1000 From: Greg Daley Subject: Re: [mobile-ip] LMM requirements: security issue To: James Kempf Cc: Youn-Hee Han , mobile-ip@sunroof.eng.sun.com, "Hesham Soliman (EAB)" Reply-to: greg.daley@eng.monash.edu.au Message-id: <3D6AC698.8040709@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <3D6275D3.8A5B84DA@cs.ucl.ac.uk> <3D68FB8D.38329EBA@cs.ucl.ac.uk> <3D697DA3.2040907@eng.monash.edu.au> <005001c24d04$89c78f00$ad29024b@yhhan> <00d401c24d23$6a281100$296015ac@T23KEMPF> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hi James and Youn-Hee Han, > I agree. I think extended mode should be taken out > of the HMIP draft and moved into NEMO, since it > seems primarily motivated by a desire to support mobile > routers. > > jak We may have to talk in NEMO about the authorization of route optimization with extended mode HMIPv6. Since it seems that the current MIP authorization mechanisms fail if you have a one (R)CoA to many MN relationship. If Extended Mode HMIPv6 is useful, then it will still have to overcome this issue whether here or in the other place (NEMO). Hesham, How do you see the future of HMIPv6 extended mode in Mobile-ip WG? Greg Daley From owner-mobile-ip@sunroof.eng.sun.com Mon Aug 26 21:56: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 VAA28630 for ; Mon, 26 Aug 2002 21:56:20 -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 TAA27413; Mon, 26 Aug 2002 19: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 SAA27376; Mon, 26 Aug 2002 18:57:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7R1tq3c001296 for ; Mon, 26 Aug 2002 18:55:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1/Submit) id g7R1tp8S001295 for mobile-ip-dist; Mon, 26 Aug 2002 18:55:51 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.37]) by sunroof.eng.sun.com (8.12.6.Beta1+Sun/8.12.6.Beta1) with ESMTP id g7R1ti3c001288 for ; Mon, 26 Aug 2002 18:55:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7R1tskT015379 for ; Mon, 26 Aug 2002 18:55:55 -0700 (PDT) Received: from mail.64translator.com (94.180.32.202.ts.2iij.net [202.32.180.94]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA08236 for ; Mon, 26 Aug 2002 19:55:48 -0600 (MDT) Received: from bahamas.64translator.com (itgw [10.21.254.82]) by mail.64translator.com (8.12.5/8.12.5) with ESMTP id g7R1tjOr016160 for ; Tue, 27 Aug 2002 10:55:46 +0900 (JST) X-Authentication-Warning: ns.64translator.com: Host itgw [10.21.254.82] claimed to be bahamas.64translator.com Received: from odin.acid4u.jp (ttb.64translator.com [10.21.0.4]) by bahamas.64translator.com (8.11.6/8.11.6) with SMTP id g7R1tfN06185 for ; Tue, 27 Aug 2002 10:55:45 +0900 (JST) Date: Tue, 27 Aug 2002 10:55:36 +0900 From: Yukiyo Akisada To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] calclating Authenticator field Message-Id: <20020827105536.7b9f4f32.Yukiyo.Akisada@jp.yokogawa.com> Organization: Yokogawa Electric Corporation X-Mailer: Sylpheed version 0.8.1 (GTK+ 1.2.10; i686-pc-linux-gnu) 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. I have one question about calclating Authenticator field. says, 5.2.6. Applying Return Routability for Correspondent Bindings ---------------------------------------------------------------- "BU" is the content of the Binding Update message, excluding (1) the IP header, (2) any extension headers between the IP header the Mobility Header, and (3) the Authenticator field inside the Binding Update. Does (3) mean that BU contains Type and Len field in Binding Authorization Data, or not contain them ? Regards. ---- Yukiyo Akisada From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 27 05:18: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 FAA15764 for ; Tue, 27 Aug 2002 05:18:25 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20534; Tue, 27 Aug 2002 03: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 CAA22605; Tue, 27 Aug 2002 02:19:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7R9IMwf002027 for ; Tue, 27 Aug 2002 02:18:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7R9IMYX002026 for mobile-ip-dist; Tue, 27 Aug 2002 02:18:22 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7R9I4wf002002; Tue, 27 Aug 2002 02:18:04 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA14081; Tue, 27 Aug 2002 02:18:14 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20006; Tue, 27 Aug 2002 03:18:05 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 53DE54B25; Tue, 27 Aug 2002 18:17:46 +0900 (JST) To: Markku Savela Cc: Francis.Dupont@enst-bretagne.fr, mrw@windriver.com, Erik.Nordmark@sun.com, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: msa's message of Tue, 27 Aug 2002 12:14:34 +0300. <200208270914.MAA18501@burp.tkv.asdf.org> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization From: itojun@iijlab.net Date: Tue, 27 Aug 2002 18:17:46 +0900 Message-Id: <20020827091746.53DE54B25@coconut.itojun.org> Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: >> PS: the reason is that layer-2 devices need to know if they can >> remove multicast packets to nodes which are not listening for them >> (cf draft-ietf-magma-snoop-02.txt). > >In my view this is crap! Why must IP layer bend over so much for some >kludgy layer-2 devices? If there are such devices, they could quite >easily detect the equivalent of solicited node participants from the >normal ND traffic! because otherwise multicast traffic will be flooded to every switch ports. >I'm going to ingore RFC 2710 on this point. I do not send MLD for link >local multicast groups. then your device will have trouble operating on coming switches that support MLD snooping, and it will be very difficult to track the issue down (extraordinary support load to your colleagues). i suggest you to follow RFC2710. itojun From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 27 05:20: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 FAA15811 for ; Tue, 27 Aug 2002 05:20:09 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.37]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18934; Tue, 27 Aug 2002 03:16:09 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7R9FmkZ022847; Tue, 27 Aug 2002 02:16:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7R9Ebwf001957 for ; Tue, 27 Aug 2002 02:14:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7R9EbXZ001956 for mobile-ip-dist; Tue, 27 Aug 2002 02:14: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.6+Sun/8.12.6) with ESMTP id g7R9EWwf001949; Tue, 27 Aug 2002 02:14:32 -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 CAA13780; Tue, 27 Aug 2002 02:14:42 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA18087; Tue, 27 Aug 2002 03:14:39 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id MAA18501; Tue, 27 Aug 2002 12:14:34 +0300 Date: Tue, 27 Aug 2002 12:14:34 +0300 Message-Id: <200208270914.MAA18501@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr CC: mrw@windriver.com, Erik.Nordmark@sun.com, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, itojun@iijlab.net, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <200208201427.g7KERb6o002654@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Tue, 20 Aug 2002 16:27:37 +0200) Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <200208201427.g7KERb6o002654@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Returning to this.. > From: Francis Dupont > > => from RFC 2710: > > MLD messages ARE sent for multicast addresses whose scope is 2 > (link-local), including Solicited-Node multicast addresses [ADDR- > ARCH], except for the link-scope, all-nodes address (FF02::1). > > Francis.Dupont@enst-bretagne.fr > > PS: the reason is that layer-2 devices need to know if they can > remove multicast packets to nodes which are not listening for them > (cf draft-ietf-magma-snoop-02.txt). In my view this is crap! Why must IP layer bend over so much for some kludgy layer-2 devices? If there are such devices, they could quite easily detect the equivalent of solicited node participants from the normal ND traffic! I'm going to ingore RFC 2710 on this point. I do not send MLD for link local multicast groups. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 27 05:46: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 FAA16294 for ; Tue, 27 Aug 2002 05:46:56 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.37]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14607; Tue, 27 Aug 2002 02:35:03 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7R9YikZ024530; Tue, 27 Aug 2002 02:35:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7R9XYwf002372 for ; Tue, 27 Aug 2002 02:33:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7R9XYnL002371 for mobile-ip-dist; Tue, 27 Aug 2002 02:33: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.6+Sun/8.12.6) with ESMTP id g7R9XTwf002364; Tue, 27 Aug 2002 02:33:29 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13547; Tue, 27 Aug 2002 02:33:39 -0700 (PDT) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA09089; Tue, 27 Aug 2002 03:33:38 -0600 (MDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id MAA18566; Tue, 27 Aug 2002 12:33:34 +0300 Date: Tue, 27 Aug 2002 12:33:34 +0300 Message-Id: <200208270933.MAA18566@burp.tkv.asdf.org> From: Markku Savela To: itojun@iijlab.net CC: Francis.Dupont@enst-bretagne.fr, mrw@windriver.com, Erik.Nordmark@sun.com, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-reply-to: <20020827091746.53DE54B25@coconut.itojun.org> Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization References: <20020827091746.53DE54B25@coconut.itojun.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: > From: itojun@iijlab.net > >I'm going to ingore RFC 2710 on this point. I do not send MLD for link > >local multicast groups. > > then your device will have trouble operating on coming switches > that support MLD snooping, and it will be very difficult to > track the issue down (extraordinary support load to your colleagues). > i suggest you to follow RFC2710. Although, I don't see much sense in using MLD other link local multicast groups, I'm here primarily talking about the solicited node groups. In my view, sending MLD on those is waste, because the *SAME* information is quite clearly available to the "snoopers" from the neighbor discovery traffic (DAD, NA, NS). In my system MLD is a separate component, I would like to be able to use IPv6 stack *without* MLD. (Which it does quite well, unless these layer-2 kludges come in and mess things). From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 27 08:23: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 IAA19843 for ; Tue, 27 Aug 2002 08:23:10 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.37]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02607; Tue, 27 Aug 2002 06:18:17 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7RCHwkZ009219; Tue, 27 Aug 2002 05:18:16 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RCH5wf002820 for ; Tue, 27 Aug 2002 05:17:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RCH4Yo002819 for mobile-ip-dist; Tue, 27 Aug 2002 05:17: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.6+Sun/8.12.6) with ESMTP id g7RCGwwf002812 for ; Tue, 27 Aug 2002 05:16:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12575 for ; Tue, 27 Aug 2002 05:17:08 -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 GAA13211 for ; Tue, 27 Aug 2002 06:17:02 -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 g7RCE8rU005570; Tue, 27 Aug 2002 14:14:28 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 27 Aug 2002 14:13:53 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F0925@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'greg.daley@eng.monash.edu.au'" , James Kempf Cc: Youn-Hee Han , mobile-ip@sunroof.eng.sun.com, "Hesham Soliman (EAB)" Subject: RE: [mobile-ip] LMM requirements: security issue Date: Tue, 27 Aug 2002 14:13:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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: > We may have to talk in NEMO about the authorization > of route optimization with extended mode HMIPv6. > Since it seems that the current MIP authorization > mechanisms fail if you have a one (R)CoA to many > MN relationship. > > If Extended Mode HMIPv6 is useful, then it will > still have to overcome this issue whether here or > in the other place (NEMO). > > Hesham, > > How do you see the future of HMIPv6 extended mode in > Mobile-ip WG? => Well, of course I'll take it out if everyone wants it out, but I have to clarify the original intention for extended mode. This was not only done for mobile networks, but the support for mobile networks was seen as an added advantage. After the recent changes in the MIPv6 spec, and the changes that we were planning for the draft, I think the other main advantage of extended mode is that it will remove the extra tunnel if packets are forwarded by the HA. So if the MN is communicating with a CN that does not implement RO or doesn't want to perform RR, there would still be one tunnel only with Extended mode, whereas with Basic mode, the packet will be tunnelled twice, once by the HA and then by the MAP. So that's one of the main reasons for having both options. Especially since they make very little difference to the MN implementation (in the next revision of the draft anyway). So do you still think it's not needed? We should really consider this carefully. I think there are 2 options: 1. Remove Extended mode 2. Keep it but remove any reference to mobile networks I'm fine with either one as long as we consider the consequences. 2) is probably less drastic IMHO. Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 27 08:38: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 IAA20918 for ; Tue, 27 Aug 2002 08:38: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 GAA00152; Tue, 27 Aug 2002 06:39:42 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA16523; Tue, 27 Aug 2002 05:39:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RCcbwf002989 for ; Tue, 27 Aug 2002 05:38:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RCcbtJ002988 for mobile-ip-dist; Tue, 27 Aug 2002 05:38: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.26]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RCcWwf002981 for ; Tue, 27 Aug 2002 05:38:32 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7RCchu9028314 for ; Tue, 27 Aug 2002 05:38:43 -0700 (PDT) Received: from shonan.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13493 for ; Tue, 27 Aug 2002 06:38:37 -0600 (MDT) Received: from localhost (wanwan.sfc.wide.ad.jp [203.178.142.131]) by shonan.sfc.wide.ad.jp (Postfix) with ESMTP id 90BD25D00D; Tue, 27 Aug 2002 21:38:35 +0900 (JST) Date: Tue, 27 Aug 2002 21:37:21 +0900 (JST) Message-Id: <20020827.213721.93842358.ernst@sfc.wide.ad.jp> To: hesham.soliman@era.ericsson.se, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] LMM requirements: security issue From: Thierry Ernst In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538044F0925@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF0538044F0925@Esealnt861.al.sw.ericsson.se> X-Mailer: Mew version 2.2 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 From: "Hesham Soliman (EAB)" > 1. Remove Extended mode > 2. Keep it but remove any reference to mobile networks > > I'm fine with either one as long as we consider the consequences. > 2) is probably less drastic IMHO. I would like to see the references to mobile networks kept in the document as long as NEMO doesn't become a WG, but **ALL** references moved to the annex. In the present draft, it's really unclear to understand what extended mode is for because there are always references to mobile networks from place to places. In one single section, two distinct uses are described at once: Extended Mode for MN and Extended Mode for a mobile network. From a reader's point of view, it's tough. I would recommend to describe what is extended mode without references to mobile networks, and to describe in the annex a possible use of extended mode for mobiles networks. Another solution is to write a separate draft for mobile networks using extended mode, but for sure I would like to see this work in some document. Thierry From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 27 08:48: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 IAA21379 for ; Tue, 27 Aug 2002 08:48:45 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA19008; Tue, 27 Aug 2002 06:49: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 FAA18414; Tue, 27 Aug 2002 05:49:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RCmhwf003152 for ; Tue, 27 Aug 2002 05:48:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RCmhOW003151 for mobile-ip-dist; Tue, 27 Aug 2002 05:48: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.26]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RCmbwf003144 for ; Tue, 27 Aug 2002 05:48:37 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7RCmmu9029137 for ; Tue, 27 Aug 2002 05:48:48 -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 GAA16009 for ; Tue, 27 Aug 2002 06:48:29 -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 g7RCmORb000164; Tue, 27 Aug 2002 14:48:24 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 27 Aug 2002 14:48:24 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F092A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'Thierry Ernst'" , "Hesham Soliman (EAB)" , mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] LMM requirements: security issue Date: Tue, 27 Aug 2002 14:48:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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: > From: "Hesham Soliman (EAB)" > > 1. Remove Extended mode > > 2. Keep it but remove any reference to mobile networks > > > > I'm fine with either one as long as we consider the consequences. > > 2) is probably less drastic IMHO. > > I would like to see the references to mobile networks kept in the > document as long as NEMO doesn't become a WG, but **ALL** references > moved to the annex. > > In the present draft, it's really unclear to understand > what extended > mode is for because there are always references to mobile networks > from place to places. In one single section, two distinct uses are > described at once: Extended Mode for MN and Extended Mode > for a mobile > network. From a reader's point of view, it's tough. => Agreed with all of the above. > > I would recommend to describe what is extended mode without > references > to mobile networks, and to describe in the annex a possible use of > extended mode for mobiles networks. > > Another solution is to write a separate draft for mobile networks > using extended mode, but for sure I would like to see this work in > some document. => Makes sense, this was basically my intention with 2) above. So we can describe Extended mode and put all the mobile networks stuff in another draft or in the appendix. Is this ok with everyone? Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 27 09:18: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 JAA22672 for ; Tue, 27 Aug 2002 09:18:39 -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 HAA01224; Tue, 27 Aug 2002 07:19:34 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11370; Tue, 27 Aug 2002 06:19:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RDIOwf003344 for ; Tue, 27 Aug 2002 06:18:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RDIOAC003343 for mobile-ip-dist; Tue, 27 Aug 2002 06: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.6+Sun/8.12.6) with ESMTP id g7RDIIwf003336 for ; Tue, 27 Aug 2002 06:18: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 GAA11245 for ; Tue, 27 Aug 2002 06:18:30 -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 HAA21070 for ; Tue, 27 Aug 2002 07:18:28 -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 g7RDIRRc015887 for ; Tue, 27 Aug 2002 15:18:27 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Tue, 27 Aug 2002 15:18:27 +0200 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538044F092B@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (EAB)" To: "'mobile-ip@sunroof.eng.sun.com'" Subject: [mobile-ip] new IPR statement Date: Tue, 27 Aug 2002 15:18:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) 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 promised before IETF, here is the new IPR statement for hmipv6. http://www.ietf.org/ietf/IPR/ERICSSON-hmipv6.txt Hesham From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 27 12:31: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 MAA00662 for ; Tue, 27 Aug 2002 12:31: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 KAA27914; Tue, 27 Aug 2002 10:32:32 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11217; Tue, 27 Aug 2002 09:32:27 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RGVGwf004072 for ; Tue, 27 Aug 2002 09:31:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RGVGrL004071 for mobile-ip-dist; Tue, 27 Aug 2002 09:31:16 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RGVAwf004064 for ; Tue, 27 Aug 2002 09:31:10 -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 JAA06153 for ; Tue, 27 Aug 2002 09:31:21 -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 JAA15958 for ; Tue, 27 Aug 2002 09:31:21 -0700 (PDT) Message-ID: <008b01c24de6$e0d3a9e0$a26015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(EAB\)" , "'Thierry Ernst'" , References: <4DA6EA82906FD511BE2F00508BCF0538044F092A@Esealnt861.al.sw.ericsson.se> Subject: Re: [mobile-ip] LMM requirements: security issue Date: Tue, 27 Aug 2002 09:29:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Agree, but I would like to see the mobile networks work be in a separate draft. jak ----- Original Message ----- From: "Hesham Soliman (EAB)" To: "'Thierry Ernst'" ; "Hesham Soliman (EAB)" ; Sent: Tuesday, August 27, 2002 5:48 AM Subject: RE: [mobile-ip] LMM requirements: security issue > => Agreed with all of the above. > > > > > I would recommend to describe what is extended mode without > > references > > to mobile networks, and to describe in the annex a possible use of > > extended mode for mobiles networks. > > > > Another solution is to write a separate draft for mobile networks > > using extended mode, but for sure I would like to see this work in > > some document. > > => Makes sense, this was basically my intention with > 2) above. So we can describe Extended mode and put all > the mobile networks stuff in another draft or in the > appendix. > > Is this ok with everyone? > > Hesham > From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 27 15:08: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 PAA07729 for ; Tue, 27 Aug 2002 15:08:13 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05312; Tue, 27 Aug 2002 13:09: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 MAA16590; Tue, 27 Aug 2002 12:09:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RJ7uwf004865 for ; Tue, 27 Aug 2002 12:07:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RJ7uwe004864 for mobile-ip-dist; Tue, 27 Aug 2002 12:07: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 jurassic.eng.sun.com (jurassic [129.146.17.55]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RJ7owf004855 for ; Tue, 27 Aug 2002 12:07:50 -0700 (PDT) Received: from shubho (shubho.Eng.Sun.COM [129.146.85.207]) by jurassic.eng.sun.com (8.12.6+Sun/8.12.6) with SMTP id g7RJ81PI552476; Tue, 27 Aug 2002 12:08:01 -0700 (PDT) Message-Id: <200208271908.g7RJ81PI552476@jurassic.eng.sun.com> Date: Tue, 27 Aug 2002 12:10:47 -0700 (PDT) From: Samita Chakrabarti Reply-To: Samita Chakrabarti Subject: Re: [mobile-ip] Re: MIPv6 Draft 18 Comments To: vijayd@iprg.nokia.com Cc: jari.arkko@kolumbus.fi, mobile-ip@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 94oOZsEdwvsHnxbEPwhnrg== 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: > > > Ok. Then this is valid for CN case, but not for HA case. How should HA > > react if it receives a BU without BAD or IPsec (or any other security > > mechanism in future) ? > > > > I prefer just dropping the BU. there is no need for the HA to send > a BA with yet another error status. > I am ok with HA dropping the BU in the absence of any security association. Perhaps HA should log the event, but this is implementation specific. -Samita From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 27 15:10: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 PAA07799 for ; Tue, 27 Aug 2002 15:10:05 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.26]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17300; Tue, 27 Aug 2002 11:58:53 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7RIwSuF024095; Tue, 27 Aug 2002 11:58:51 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RIv7wf004653 for ; Tue, 27 Aug 2002 11:57:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RIv7w7004652 for mobile-ip-dist; Tue, 27 Aug 2002 11:57:07 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RIuowf004629; Tue, 27 Aug 2002 11:56: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 LAA27554; Tue, 27 Aug 2002 11:57:01 -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 MAA28269; Tue, 27 Aug 2002 12:57:00 -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 OAA06546 for <1timer>; Tue, 27 Aug 2002 14:44:44 -0400 (EDT) Message-Id: <200208271844.OAA06546@ietf.org> From: Phil Roberts To: IETF WG Participants: ; Subject: [mobile-ip] Nomcom call for volunteers Date: Tue, 27 Aug 2002 14:44:44 -0400 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 27 16:35: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 QAA11571 for ; Tue, 27 Aug 2002 16:35:12 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06361; Tue, 27 Aug 2002 13:35: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 NAA19636; Tue, 27 Aug 2002 13:35:02 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RKXpwf005240 for ; Tue, 27 Aug 2002 13:33:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RKXoaX005239 for mobile-ip-dist; Tue, 27 Aug 2002 13:33: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.6+Sun/8.12.6) with ESMTP id g7RKXjwf005232 for ; Tue, 27 Aug 2002 13:33:45 -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 NAA19340 for ; Tue, 27 Aug 2002 13:33:56 -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 OAA21066 for ; Tue, 27 Aug 2002 14:33:56 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 939246A905; Tue, 27 Aug 2002 23:33:49 +0300 (EEST) Message-ID: <3D6BE35D.2010500@kolumbus.fi> Date: Tue, 27 Aug 2002 23:38:53 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Yukiyo Akisada Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] calclating Authenticator field References: <20020827105536.7b9f4f32.Yukiyo.Akisada@jp.yokogawa.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 Yukiyo Akisada wrote: > Hi, all. > > I have one question about calclating Authenticator field. > > says, > > 5.2.6. Applying Return Routability for Correspondent Bindings > ---------------------------------------------------------------- > "BU" is the content of the > Binding Update message, excluding (1) the IP header, (2) any > extension headers between the IP header the Mobility Header, > and (3) the Authenticator field inside the Binding Update. > > Does (3) mean that BU contains Type and Len field in Binding Authorization Data, > or not contain them ? It does contain even the beginning of the MH. Perhaps the text should say "... the content of the Binding Update *packet*, excluding..." to clarify that we are not just talking about the BU itself? Jari From owner-mobile-ip@sunroof.eng.sun.com Tue Aug 27 17:04: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 RAA12610 for ; Tue, 27 Aug 2002 17:04:27 -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 PAA07899; Tue, 27 Aug 2002 15:05: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 OAA26531; Tue, 27 Aug 2002 14:05:31 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RL4Lwf005450 for ; Tue, 27 Aug 2002 14:04:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RL4LJ1005449 for mobile-ip-dist; Tue, 27 Aug 2002 14:04: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.6+Sun/8.12.6) with ESMTP id g7RL4Gwf005442 for ; Tue, 27 Aug 2002 14:04: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 OAA10765 for ; Tue, 27 Aug 2002 14:04:26 -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 OAA25058 for ; Tue, 27 Aug 2002 14:04:25 -0700 (PDT) Received: (from wells@localhost) by io.irean.vt.edu (8.11.6/8.11.6) id g7RL4OD01085 for mobile-ip@sunroof.eng.sun.com; Tue, 27 Aug 2002 17:04:24 -0400 Date: Tue, 27 Aug 2002 17:04:24 -0400 From: John Wells To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Mobile IP dynamic home address assignment Message-ID: <20020827170424.A1072@io.irean.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hi all, Section 5.1 of the Mobile AAA requirements RFC (2977) talks about the ability to dynamically assign a home address to a mobile node. The Diameter draft describes a way to assign a home agent, but is it possible for a mobile node to leave blank its home address so the home agent can assign it? 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 Tue Aug 27 17:16:28 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13016 for ; Tue, 27 Aug 2002 17:16:28 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14416; Tue, 27 Aug 2002 15:17: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 OAA13113; Tue, 27 Aug 2002 14:17:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7RLGIwf005634 for ; Tue, 27 Aug 2002 14:16:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7RLGI5J005633 for mobile-ip-dist; Tue, 27 Aug 2002 14:16: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.6+Sun/8.12.6) with ESMTP id g7RLGCwf005626 for ; Tue, 27 Aug 2002 14:16:13 -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 OAA12860 for ; Tue, 27 Aug 2002 14:16:23 -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 PAA16836 for ; Tue, 27 Aug 2002 15:16:22 -0600 (MDT) Message-ID: <012001c24e0e$df7e9a00$776015ac@AlperVAIO> From: "Alper E. YEGIN" To: "John Wells" , References: <20020827170424.A1072@io.irean.vt.edu> Subject: Re: [mobile-ip] Mobile IP dynamic home address assignment Date: Tue, 27 Aug 2002 14:15: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 > Hi all, > > Section 5.1 of the Mobile AAA requirements RFC (2977) talks about the > ability to dynamically assign a home address to a mobile node. The > Diameter draft describes a way to assign a home agent, but is it possible > for a mobile node to leave blank its home address so the home agent can > assign it? Yes, please see RFC2794 Mobile IP Network Access Identifier Extension for IPv4. Since the NAI is typically used to uniquely identify the mobile node, the mobile node's home address is not always necessary to provide that function. Thus, it is possible for a mobile node to authenticate itself, and be authorized for connection to the foreign domain, without even having a home address. A message containing the Mobile Node NAI extension MAY set the Home Address field to zero (0) in the Registration Request, to request that a home address be assigned. alper From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 28 07:59: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 HAA25439 for ; Wed, 28 Aug 2002 07:59: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 FAA09504; Wed, 28 Aug 2002 05:59:54 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA21067; Wed, 28 Aug 2002 04:59:50 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SBwlwf007393 for ; Wed, 28 Aug 2002 04:58:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7SBwl3B007392 for mobile-ip-dist; Wed, 28 Aug 2002 04:58:47 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SBwewf007385 for ; Wed, 28 Aug 2002 04:58:40 -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 EAA27429 for ; Wed, 28 Aug 2002 04:58:50 -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 EAA09604 for ; Wed, 28 Aug 2002 04:58:49 -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 HAA24952; Wed, 28 Aug 2002 07:57:19 -0400 (EDT) Message-Id: <200208281157.HAA24952@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-req-00.txt Date: Wed, 28 Aug 2002 07:57:18 -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 and Requirements for Mobile IPv4 Traversal Across IPsec-based VPN Gateways Author(s) : A. Patel et al. Filename : draft-ietf-mobileip-vpn-problem-statement-req-00.txt Pages : 13 Date : 2002-8-27 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 Virtual Private Network (VPN) technology is increasing. This implies that Mobile IP and VPN technologies have to coexist and co-function in order to provide mobility and security to the enterprise mobile users. The goal of this draft is threefold. The first is to describe possible deployment scenarios for Mobile IP and VPN in enterprise and operator environments. The second is to identify example usage scenarios for enterprise users roaming outside the 'home' network (e.g., corporate Intranet), and articulate the problems resulting from Mobile IP and VPN coexistence. The third is to specify a set of framework requirements to evaluate proposed solutions, supporting multi- vendor seamless IPv4 mobility across IPsec-based VPN Gateways. Hereafter, a 'VPN' term in this draft refers to an IPsec-based VPN Gateway. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-vpn-problem-statement-req-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-req-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-req-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: <2002-8-27144757.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobileip-vpn-problem-statement-req-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobileip-vpn-problem-statement-req-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-8-27144757.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 28 10:36: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 KAA01982 for ; Wed, 28 Aug 2002 10:36:59 -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 IAA27781; Wed, 28 Aug 2002 08:37: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 HAA20933; Wed, 28 Aug 2002 07:37:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SEahwf007609 for ; Wed, 28 Aug 2002 07:36:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7SEahVF007608 for mobile-ip-dist; Wed, 28 Aug 2002 07:36: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.6+Sun/8.12.6) with ESMTP id g7SEacwf007601 for ; Wed, 28 Aug 2002 07:36:38 -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 HAA22634 for ; Wed, 28 Aug 2002 07:36:48 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13584 for ; Wed, 28 Aug 2002 08:36:47 -0600 (MDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g7SEacwH017205 for ; Wed, 28 Aug 2002 10:36:39 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id KAA24742 for ; Wed, 28 Aug 2002 10:37:00 -0400 (EDT) Date: Wed, 28 Aug 2002 10:36:35 -0400 To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] comments on mobileip-vpn-problem-statement-req Message-ID: <20020828143635.GA1307@catfish> Mail-Followup-To: mobile-ip@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 26 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: I have two comments on draft-ietf-mobileip-vpn-problem-statement-req-00.txt. First, I'm not sure the model explained in Figure 3.2c (the MN in non-trusted FA region) is a valid one. If there is no trust relationship or security association between the FA in an outside network and the HA in the enterprise network, Mobile IP registration is not possible between the FA and HA regardless of whether Mobile IP runs over VPN or not. So it seems that we do not have to consider this scenario. Second, Problem 2 in section 4 can be solved if we use Mobile IP over IPsec over PPP over L2TP, where an IPsec tunnel is created in the enterprise address space, if the mobile proposes to use the same IP address in the enterprise space during the PPP IPCP negotiation (and the VPN gateway accepts the IP address) each time the L2TP tunnel is re-established when handoff occurs. This can eliminate the need for re-negotiating the IPsec SA when handoff occurs, since the IP address used by the IPsec tunnel does not change. This may not be pure IPsec-based VPN, but still Mobile IP over IPsec. Are there any reason for focusing on IPsec-based VPN? I think it would be more useful if the draft is written in more generic manner so that the considration is applicable to other VPN methods also. Regards, Yoshihiro Ohba From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 28 11:00: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 LAA02994 for ; Wed, 28 Aug 2002 11:00:27 -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 JAA12413; Wed, 28 Aug 2002 09: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 IAA29277; Wed, 28 Aug 2002 08:01:15 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SF0Bwf007680 for ; Wed, 28 Aug 2002 08:00:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7SF0BH2007679 for mobile-ip-dist; Wed, 28 Aug 2002 08:00:11 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SF05wf007672 for ; Wed, 28 Aug 2002 08:00:05 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27868 for ; Wed, 28 Aug 2002 08:00:15 -0700 (PDT) Received: from amber.ccs.neu.edu (amber.ccs.neu.edu [129.10.116.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19803 for ; Wed, 28 Aug 2002 09:00:14 -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 12E4F1AABD; Wed, 28 Aug 2002 11:00:14 -0400 (EDT) Message-Id: <5.0.2.1.0.20020828104614.05041eb8@mail.ccs.neu.edu> X-Sender: noubir@mail.ccs.neu.edu X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 28 Aug 2002 10:49:53 -0400 To: mobile-ip@sunroof.eng.sun.com, ipsec@lists.tislabs.com From: "G. Noubir" Subject: [mobile-ip] Wireless Security workshop -- advance registration deadline soon [August 31] 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: Advance registration deadline soon (visit http://www.crhc.uiuc.edu/~nhv/wise for more information) --------------------------------------------------------------- Call for Participation ACM 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 ACM SIGMOBILE 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. For registration information, please visit http://www.crhc.uiuc.edu/~nhv/wise Preliminary Program -------------------------------------------------------------------------------- Paper Session 1 (8:30 - 10:00 a.m.) Session Chair: David B. Johnson (Rice University) Securing Ad-Hoc Routing Protocols, Manel Guerrero Zapata and N. Asokan (Nokia Research Center, Finland) Self-Organized Network Layer Security in Mobile Ad Hoc Networks, Hao Yang, Xiaoqiao Meng and Songwu Lu (University of California at Los Angeles) An On-Demand Secure Routing Protocol Resilent to Byzantine Failures, Baruch Awerbuch, David Holmer, Cristina Nita-Rotaru and Herbert Rubens (Johns Hopkins University) -------------------------------------------------------------------------------- Poster Session (10:15 - 11:15 a.m.) Self-Organized Public-Key Management in Ad Hoc Wireless Networks, S. Capkun, L. Buttyan and J.-P. Hubaux (Swiss Federal Institute of Technology - Lausanne) Providing Multi-Layer Security Support for Wireless Communications Across Multiple Domains, J. Kong, M. Gerla, R. Gadh, B. S. Prahbu (University of California, Los Angeles) Reflection: Secure, Lightweight Wireless Network Administration, J. W. Mickens, B. D. Noble, A. J. Lanzone, K.-Y. Tye (University of Michigan, Ann Arbor) Risk Based Probabilistic Routing for Ad-Hoc Networks, Z. Yu, T. Jiang, X. Wu and W. A. Arbaugh (University of Maryland, College Park) Performance Evaluation of Secure Routing for Mobile Ad Hoc Networks, P. Papadimitratos and Z. J. Haas (Cornell University) Security Protocol for Charging and Participation Incentive in Ad Hoc Stub Network, B. Lamparter, K. Paul, D. Westhoff (NEC Europe Ltd.) -------------------------------------------------------------------------------- Invited Presentations (11:15 a.m. - 12:15 p.m.) Session Chair: Brian Van Leeuwen (Sandia National Laboratories) Information Assurance and Research Opportunities, Douglas Maughan, Defence Advanced Research Projects Agency Perspectives on Wireless Security, Taieb Znati, National Science Foundation and University of Pittsburgh -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- Paper Session 2 (1:30 - 3:00 p.m.) Session Chair: Chip Elliott (BBN Technologies) Survivable Mobile Wireless Networks: Issues, Challenges, and Research Directions, Rajesh Krishnan, Regina Rosales Hain, Alden W. Jackson, David Levin, Ram Ramanathan, John Zao and James P. G. Sterbenz (BBN Technologies) Secure Wireless Gateway, Austin Godber and Partha Dasgupta (Arizona State University) DoS and Authentication in Wireless Public Access Networks, Daniel B. Faria and David R. Cheriton (Stanford University) -------------------------------------------------------------------------------- Paper Session 3 (3:30 - 5:30 p.m.) Session Chair: Yair Amir (Johns Hopkins University) A Distributed Monitoring Mechanism in Wireless Sensor Networks, Chih-fan Hsin and Mingyan Liu (University of Michigan at Ann Arbor) Using Signal Processing to Analyze Wireless Data Traffic, Craig Partridge, David Cousins, Alden W. Jackson, Rajesh Krishnan, Tushar Saxena, and W. Timothy Strayer (BBN Technologies) Securing IPv6 Neighor Discovery, Jari Arkko (Ericsson Research NomadicLab), Tuomas Aura (Microsoft Research Cambridge), James Kempf (DoCoMoLabs U.S.A.), Vesa-Matti Mantyla, Pekka Nikander (Ericsson Research NomadicLab) and Michael Roe (Microsoft Research Cambridge) Performance Analysis of Elliptic Curve Cryptography for SSL, Vipul Gupta, Sumit Gupta, Sheueling Chang and Douglas Stebila (Sun Microsystems) -------------------------------------------------------------------------------- From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 28 11:10: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 LAA03423 for ; Wed, 28 Aug 2002 11:10:29 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06840; Wed, 28 Aug 2002 08:09:39 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01220; Wed, 28 Aug 2002 08:09:36 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SF8fwf007743 for ; Wed, 28 Aug 2002 08:08:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7SF8fRP007742 for mobile-ip-dist; Wed, 28 Aug 2002 08:08: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.6+Sun/8.12.6) with ESMTP id g7SF8Zwf007735 for ; Wed, 28 Aug 2002 08:08: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 IAA01102 for ; Wed, 28 Aug 2002 08:08:45 -0700 (PDT) Received: from c001.snv.cp.net (h007.c001.snv.cp.net [209.228.32.121]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA06290 for ; Wed, 28 Aug 2002 08:08:44 -0700 (PDT) Received: (cpmta 22567 invoked from network); 28 Aug 2002 08:08:43 -0700 Received: from 63.143.179.146 (HELO QiangVAIO) by smtp.register-admin.com (209.228.32.121) with SMTP; 28 Aug 2002 08:08:43 -0700 X-Sent: 28 Aug 2002 15:08:43 GMT Message-ID: <014801c24ea4$cc7b2220$4864a8c0@QiangVAIO> From: "Qiang Zhang" To: , "Yoshihiro Ohba" Cc: "Adrangi, Farid" , "Iyer, Prakash" , , "'Milind Kulkarni'" , , References: <20020828143635.GA1307@catfish> Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req Date: Wed, 28 Aug 2002 11:08:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yoshihiro, Some comments below, thanks Qiang ----- Original Message ----- From: "Yoshihiro Ohba" To: Sent: Wednesday, August 28, 2002 10:36 AM Subject: [mobile-ip] comments on mobileip-vpn-problem-statement-req > I have two comments on > draft-ietf-mobileip-vpn-problem-statement-req-00.txt. > > First, I'm not sure the model explained in Figure 3.2c (the MN in > non-trusted FA region) is a valid one. If there is no trust > relationship or security association between the FA in an outside > network and the HA in the enterprise network, Mobile IP registration > is not possible between the FA and HA regardless of whether Mobile IP > runs over VPN or not. So it seems that we do not have to consider > this scenario. ==> Non-trusted FA refers to the scenario that the FA outside has no any SA with enterprise network (e.g. VPN gateway at the border). Thus the MN, in order to work with HA, is responsible for setting up the VPN connection in order to tunnel MIP traffic through the VPN gateway and reach the HA. In addtion an offnote, as a matter of fact, if the HA allowes, FA-HA SA such as MD5 binding is optional. > > Second, Problem 2 in section 4 can be solved if we use Mobile IP over > IPsec over PPP over L2TP, where an IPsec tunnel is created in the > enterprise address space, if the mobile proposes to use the same IP > address in the enterprise space during the PPP IPCP negotiation (and > the VPN gateway accepts the IP address) each time the L2TP tunnel is > re-established when handoff occurs. This can eliminate the need for > re-negotiating the IPsec SA when handoff occurs, since the IP address > used by the IPsec tunnel does not change. This may not be pure > IPsec-based VPN, but still Mobile IP over IPsec. Are there any reason > for focusing on IPsec-based VPN? I think it would be more useful if > the draft is written in more generic manner so that the considration > is applicable to other VPN methods also. ==>The problem statement tends to collect problematic scenarios which MIP may have difficulty working with properly. Reason to put IPsec because there are other VPNs around such as MPLS (if they do consider it a VPN) and L2TP. This scenario you depicted uses L2TP as tunneling mechanism for IPsec VPN, maybe considered as a solution which will go in different drafts. > > Regards, > Yoshihiro Ohba > From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 28 11:52: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 LAA05954 for ; Wed, 28 Aug 2002 11:52: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 JAA03057; Wed, 28 Aug 2002 09:53: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 IAA15876; Wed, 28 Aug 2002 08:53:20 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SFqDwf007877 for ; Wed, 28 Aug 2002 08:52:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7SFqDv3007876 for mobile-ip-dist; Wed, 28 Aug 2002 08:52: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.6+Sun/8.12.6) with ESMTP id g7SFq7wf007869 for ; Wed, 28 Aug 2002 08:52:08 -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 IAA14744 for ; Wed, 28 Aug 2002 08:52:18 -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 JAA02261 for ; Wed, 28 Aug 2002 09:52:17 -0600 (MDT) Message-ID: <004801c24eaa$a9aadff0$396015ac@T23KEMPF> From: "James Kempf" To: Subject: [mobile-ip] More on HMIPv6 Extended Mode Date: Wed, 28 Aug 2002 08:50:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit So I believe we've agreed to move the routing related material out of the main body of the text. But the issue of how to deal with security in Extended Mode remains. Anybody have any ideas? jak From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 28 13:56: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 NAA11903 for ; Wed, 28 Aug 2002 13:56:26 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA20649; Wed, 28 Aug 2002 11:57: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 KAA27541; Wed, 28 Aug 2002 10:57:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SHu3wf008135 for ; Wed, 28 Aug 2002 10:56:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7SHu2je008134 for mobile-ip-dist; Wed, 28 Aug 2002 10:56:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SHtuwf008127 for ; Wed, 28 Aug 2002 10:55:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08732 for ; Wed, 28 Aug 2002 10:56:05 -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 LAA21059 for ; Wed, 28 Aug 2002 11:56:05 -0600 (MDT) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 8FE3B27C5; Wed, 28 Aug 2002 10:56:04 -0700 (PDT) Received: from kitche.zk3.dec.com (kitche.zk3.dec.com [16.140.160.163]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 9BE2484A; Wed, 28 Aug 2002 10:56:03 -0700 (PDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id NAA0001561786; Wed, 28 Aug 2002 13:56:02 -0400 (EDT) Message-ID: <3D6D0EB2.CC902C99@hp.com> Date: Wed, 28 Aug 2002 13:56:02 -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: Jari Arkko Cc: mobile ip Subject: [mobile-ip] Home bindings when L=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 There seems to be a problem in Section 10.2 of the Mobile IPv6 draft regarding which addresses should be defended for Home bindings. There is a paragraph that tells what to do when S=0/1 and L=0/1, the problem is that when L=0 we should only defend the given home address in the BU since we cannot derive the interface id from the address to construct other addresses (for example, the MN is using a private address). So I propose that this section can be compressed to three cases: "The specific addresses which are to be tested before accepting the Binding Update, and later to be defended by performing Duplicate Address Detection, depend on the settings of the `S' and `L' bits, as follows: - L=0: Defend the given address. The 'S' bit is ignored in this case since we cannot derive other on-link addresses without knowing the interface identifier (IID). - S=0 & L=1: Defend all non link-local unicast addresses possible on link and the derived link-local. - S=1 & L=1: Defend both the given non link-local unicast (home) address and the derived link-local." Furthermore, in Section 11.6.1, the paragraph on setting S=0 should be updated to say that L MUST be 1 in this case or S will be ignored. BTW, the very next paragraph (about the L-bit) makes the recommendation that the L-bit SHOULD NOT be set if using RFC 3041 addresses, maybe that should change to MUST NOT since we should not defend a link-local address derived from that type of global address. I talked with Vlad Yasevich about this, who originally proposed the L-bit, and this was his intention when he proposed it. Any comments? -Brian From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 28 15:01:46 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 PAA14389 for ; Wed, 28 Aug 2002 15:01:45 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA02060; Wed, 28 Aug 2002 13:02: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 MAA23203; Wed, 28 Aug 2002 12:02:29 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SJ1Gwf008364 for ; Wed, 28 Aug 2002 12:01:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7SJ1GuO008363 for mobile-ip-dist; Wed, 28 Aug 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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SJ1Awf008356 for ; Wed, 28 Aug 2002 12:01:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22773 for ; Wed, 28 Aug 2002 12:01:20 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01301 for ; Wed, 28 Aug 2002 13:01:20 -0600 (MDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g7SIr1wH008599; Wed, 28 Aug 2002 14:53:01 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id OAA25251; Wed, 28 Aug 2002 14:53:21 -0400 (EDT) Date: Wed, 28 Aug 2002 14:52:55 -0400 To: Qiang Zhang Cc: mobile-ip@sunroof.eng.sun.com, Yoshihiro Ohba , "Adrangi, Farid" , "Iyer, Prakash" , kleung@cisco.com, "'Milind Kulkarni'" , alpesh@cisco.com, jlau@cup.hp.com Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req Message-ID: <20020828185255.GA1018@catfish> Mail-Followup-To: Qiang Zhang , mobile-ip@sunroof.eng.sun.com, Yoshihiro Ohba , "Adrangi, Farid" , "Iyer, Prakash" , kleung@cisco.com, 'Milind Kulkarni' , alpesh@cisco.com, jlau@cup.hp.com References: <20020828143635.GA1307@catfish> <014801c24ea4$cc7b2220$4864a8c0@QiangVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <014801c24ea4$cc7b2220$4864a8c0@QiangVAIO> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 48 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Qiang, Thank you for your reply. On Wed, Aug 28, 2002 at 11:08:35AM -0400, Qiang Zhang wrote: > ==> Non-trusted FA refers to the scenario that the FA outside has no any SA > with enterprise network (e.g. VPN gateway at the border). Thus the MN, in > order to work with HA, is responsible for setting up the VPN connection in > order to tunnel MIP traffic through the VPN gateway and reach the HA. > > In addtion an offnote, as a matter of fact, if the HA allowes, FA-HA SA such > as MD5 binding is optional. OK. But I still do not understand this usage, because when we use VPN we usually assume that all packets (including Mobile IP) in the enterprise address space are transparently carried over the VPN tunnel through the Internet. So why the untrusted FA outside the enterprise network should involve Mobile IP running inside the enterprise network through VPN? > > > > > Second, Problem 2 in section 4 can be solved if we use Mobile IP over > > IPsec over PPP over L2TP, where an IPsec tunnel is created in the > > enterprise address space, if the mobile proposes to use the same IP > > address in the enterprise space during the PPP IPCP negotiation (and > > the VPN gateway accepts the IP address) each time the L2TP tunnel is > > re-established when handoff occurs. This can eliminate the need for > > re-negotiating the IPsec SA when handoff occurs, since the IP address > > used by the IPsec tunnel does not change. This may not be pure > > IPsec-based VPN, but still Mobile IP over IPsec. Are there any reason > > for focusing on IPsec-based VPN? I think it would be more useful if > > the draft is written in more generic manner so that the considration > > is applicable to other VPN methods also. > > ==>The problem statement tends to collect problematic scenarios which MIP > may have difficulty working with properly. Reason to put IPsec because there > are other VPNs around such as MPLS (if they do consider it a VPN) and L2TP. > This scenario you depicted uses L2TP as tunneling mechanism for IPsec VPN, > maybe considered as a solution which will go in different drafts. OK. Then I think such an explanation about why the draft focuses on IPsec-based VPN would be helpful. Thanks, Yoshihiro Ohba From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 28 15:24: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 PAA15071 for ; Wed, 28 Aug 2002 15:24:37 -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 NAA15952; Wed, 28 Aug 2002 13:25: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 MAA00555; Wed, 28 Aug 2002 12:25:06 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SJNkwf008461 for ; Wed, 28 Aug 2002 12:23:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7SJNkMV008460 for mobile-ip-dist; Wed, 28 Aug 2002 12:23: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.6+Sun/8.12.6) with ESMTP id g7SJNewf008453 for ; Wed, 28 Aug 2002 12:23:40 -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 MAA14373 for ; Wed, 28 Aug 2002 12:23:50 -0700 (PDT) Received: from c001.snv.cp.net (h000.c001.snv.cp.net [209.228.32.114]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA26377 for ; Wed, 28 Aug 2002 12:23:50 -0700 (PDT) Received: (cpmta 29874 invoked from network); 28 Aug 2002 12:23:49 -0700 Received: from 63.143.179.146 (HELO QiangVAIO) by smtp.register-admin.com (209.228.32.114) with SMTP; 28 Aug 2002 12:23:49 -0700 X-Sent: 28 Aug 2002 19:23:49 GMT Message-ID: <022901c24ec8$6fed3ec0$4864a8c0@QiangVAIO> From: "Qiang Zhang" To: "Yoshihiro Ohba" Cc: , "Yoshihiro Ohba" , "Adrangi, Farid" , "Iyer, Prakash" , , "'Milind Kulkarni'" , , References: <20020828143635.GA1307@catfish> <014801c24ea4$cc7b2220$4864a8c0@QiangVAIO> <20020828185255.GA1018@catfish> Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req Date: Wed, 28 Aug 2002 15:23:37 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yoshihiro, Are you sending mails from Japan? Regarding the first question, pls see comment Thanks Qiang ----- Original Message ----- From: "Yoshihiro Ohba" To: "Qiang Zhang" Cc: ; "Yoshihiro Ohba" ; "Adrangi, Farid" ; "Iyer, Prakash" ; ; "'Milind Kulkarni'" ; ; Sent: Wednesday, August 28, 2002 2:52 PM Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req > > Qiang, > > Thank you for your reply. > > On Wed, Aug 28, 2002 at 11:08:35AM -0400, Qiang Zhang wrote: > > > ==> Non-trusted FA refers to the scenario that the FA outside has no any SA > > with enterprise network (e.g. VPN gateway at the border). Thus the MN, in > > order to work with HA, is responsible for setting up the VPN connection in > > order to tunnel MIP traffic through the VPN gateway and reach the HA. > > > > In addtion an offnote, as a matter of fact, if the HA allowes, FA-HA SA such > > as MD5 binding is optional. > > OK. But I still do not understand this usage, because when we use VPN > we usually assume that all packets (including Mobile IP) in the > enterprise address space are transparently carried over the VPN tunnel > through the Internet. So why the untrusted FA outside the enterprise > network should involve Mobile IP running inside the enterprise network > through VPN? ==> When the FA is in the middle( like below) and MN is the VPN tunnel end, apparently FA who is adding the MIP tunnel will intervene the VPN tunnel between MN and VPNGW. MN---FA ------------------------VPNGW----HA > > > > > > > > > Second, Problem 2 in section 4 can be solved if we use Mobile IP over > > > IPsec over PPP over L2TP, where an IPsec tunnel is created in the > > > enterprise address space, if the mobile proposes to use the same IP > > > address in the enterprise space during the PPP IPCP negotiation (and > > > the VPN gateway accepts the IP address) each time the L2TP tunnel is > > > re-established when handoff occurs. This can eliminate the need for > > > re-negotiating the IPsec SA when handoff occurs, since the IP address > > > used by the IPsec tunnel does not change. This may not be pure > > > IPsec-based VPN, but still Mobile IP over IPsec. Are there any reason > > > for focusing on IPsec-based VPN? I think it would be more useful if > > > the draft is written in more generic manner so that the considration > > > is applicable to other VPN methods also. > > > > ==>The problem statement tends to collect problematic scenarios which MIP > > may have difficulty working with properly. Reason to put IPsec because there > > are other VPNs around such as MPLS (if they do consider it a VPN) and L2TP. > > This scenario you depicted uses L2TP as tunneling mechanism for IPsec VPN, > > maybe considered as a solution which will go in different drafts. > > OK. Then I think such an explanation about why the draft focuses on > IPsec-based VPN would be helpful. > > Thanks, > Yoshihiro Ohba > From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 28 16:46: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 QAA18425 for ; Wed, 28 Aug 2002 16:46:14 -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 OAA18219; Wed, 28 Aug 2002 14:46: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 NAA28042; Wed, 28 Aug 2002 13:46:48 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SKjcwf008616 for ; Wed, 28 Aug 2002 13:45:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7SKjc2Q008615 for mobile-ip-dist; Wed, 28 Aug 2002 13:45:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SKjXwf008608 for ; Wed, 28 Aug 2002 13:45: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 NAA25357 for ; Wed, 28 Aug 2002 13:45:44 -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 OAA00902 for ; Wed, 28 Aug 2002 14:45: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 NAA21712; Wed, 28 Aug 2002 13:45:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7SKjgF04214; Wed, 28 Aug 2002 13:45:42 -0700 X-mProtect: <200208282045> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.21.195.116, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqwIgh1; Wed, 28 Aug 2002 13:45:23 PDT Message-ID: <3D6D3653.7060707@iprg.nokia.com> Date: Wed, 28 Aug 2002 13:45:07 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: Brian Haley CC: Jari Arkko , mobile ip Subject: Re: [mobile-ip] Home bindings when L=0 References: <3D6D0EB2.CC902C99@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 it would be nice to separate the 'L' bit and the 'S' bit. so, heres another suggestion. what if we specify "the MN MUST set L=0 and S=1 if it is using RFC 3041 generated home address" when the MN sets the L=1 or S=0, the HA blindly derives other addresses and defend them. Vijay ps: Brian, I am fine with your suggestions too. Brian Haley wrote: > There seems to be a problem in Section 10.2 of the Mobile IPv6 draft > regarding which addresses should be defended for Home bindings. > There is a paragraph that tells what to do when S=0/1 and L=0/1, the > problem is that when L=0 we should only defend the given home > address in the BU since we cannot derive the interface id from the > address to construct other addresses (for example, the MN is using > a private address). > > So I propose that this section can be compressed to three cases: > > "The specific addresses which are to be tested before accepting the > Binding Update, and later to be defended by performing Duplicate > Address Detection, depend on the settings of the `S' and `L' bits, as > follows: > > - L=0: Defend the given address. The 'S' bit is ignored in this case > since we cannot derive other on-link addresses without knowing > the interface identifier (IID). > > - S=0 & L=1: Defend all non link-local unicast addresses possible > on link and the derived link-local. > > - S=1 & L=1: Defend both the given non link-local unicast (home) > address and the derived link-local." > > Furthermore, in Section 11.6.1, the paragraph on setting S=0 should > be updated to say that L MUST be 1 in this case or S will be ignored. > BTW, the very next paragraph (about the L-bit) makes the > recommendation that the L-bit SHOULD NOT be set if using RFC > 3041 addresses, maybe that should change to MUST NOT since we > should not defend a link-local address derived from that type of > global address. > > I talked with Vlad Yasevich about this, who originally proposed the > L-bit, and this was his intention when he proposed it. > > Any comments? > > -Brian > > From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 28 17:14: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 RAA19490 for ; Wed, 28 Aug 2002 17:14:33 -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 OAA26493; Wed, 28 Aug 2002 14:13: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 OAA05942; Wed, 28 Aug 2002 14:13:41 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SLCPwf008698 for ; Wed, 28 Aug 2002 14:12:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7SLCPrZ008697 for mobile-ip-dist; Wed, 28 Aug 2002 14:12: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.6+Sun/8.12.6) with ESMTP id g7SLCHwf008690 for ; Wed, 28 Aug 2002 14:12:17 -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 OAA27513 for ; Wed, 28 Aug 2002 14:12:26 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA02560 for ; Wed, 28 Aug 2002 15:12:25 -0600 (MDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id A49133760; Wed, 28 Aug 2002 16:12:16 -0500 (CDT) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id B88ACEF6; Wed, 28 Aug 2002 17:12:15 -0400 (EDT) Received: from hp.com by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id RAA0000866051; Wed, 28 Aug 2002 17:12:15 -0400 (EDT) Message-ID: <3D6D3C86.213D1738@hp.com> Date: Wed, 28 Aug 2002 17:11:34 -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 , mobile ip Subject: Re: [mobile-ip] Home bindings when L=0 References: <3D6D0EB2.CC902C99@hp.com> <3D6D3653.7060707@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: > it would be nice to separate the 'L' bit and the 'S' bit. But they are tied together because S=0 relies on being able to know the IID to derive the other addresses from it. > so, heres another suggestion. what if we specify "the MN MUST > set L=0 and S=1 if it is using RFC 3041 generated home address" That's fine with me, but we also have to specify what to do if we see the invalid setting, we shouldn't need to drop the packet for something like this. > when the MN sets the L=1 or S=0, the HA blindly derives other > addresses and defend them. I would hope the HA isn't "blind" about what to do in all cases, but I'm sure everyone's implementation of S=0 will vary slightly. The way we figure it, it will take deployment to shake-out this code anyways, although I'd rather get it right the first time... > ps: Brian, I am fine with your suggestions too. That's good :) -Brian From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 28 19:33: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 TAA24547 for ; Wed, 28 Aug 2002 19:33: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 RAA14188; Wed, 28 Aug 2002 17:34: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 QAA21570; Wed, 28 Aug 2002 16:34:04 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SNWjwf009093 for ; Wed, 28 Aug 2002 16:32:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7SNWjWd009092 for mobile-ip-dist; Wed, 28 Aug 2002 16:32:45 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7SNWdwf009085 for ; Wed, 28 Aug 2002 16:32:39 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA21155 for ; Wed, 28 Aug 2002 16:32:50 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA06019 for ; Wed, 28 Aug 2002 17:32:49 -0600 (MDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g7SNOVwH000930; Wed, 28 Aug 2002 19:24:41 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id TAA25778; Wed, 28 Aug 2002 19:24:52 -0400 (EDT) Date: Wed, 28 Aug 2002 19:24:26 -0400 To: Qiang Zhang Cc: Yoshihiro Ohba , mobile-ip@sunroof.eng.sun.com, "Adrangi, Farid" , "Iyer, Prakash" , kleung@cisco.com, "'Milind Kulkarni'" , alpesh@cisco.com, jlau@cup.hp.com Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req Message-ID: <20020828232426.GA892@catfish> Mail-Followup-To: Qiang Zhang , Yoshihiro Ohba , mobile-ip@sunroof.eng.sun.com, "Adrangi, Farid" , "Iyer, Prakash" , kleung@cisco.com, 'Milind Kulkarni' , alpesh@cisco.com, jlau@cup.hp.com References: <20020828143635.GA1307@catfish> <014801c24ea4$cc7b2220$4864a8c0@QiangVAIO> <20020828185255.GA1018@catfish> <022901c24ec8$6fed3ec0$4864a8c0@QiangVAIO> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <022901c24ec8$6fed3ec0$4864a8c0@QiangVAIO> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 36 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Qiang, On Wed, Aug 28, 2002 at 03:23:37PM -0400, Qiang Zhang wrote: > Yoshihiro, > > Are you sending mails from Japan? > > Regarding the first question, pls see comment > > Thanks > Qiang > ----- Original Message ----- > > > OK. But I still do not understand this usage, because when we use VPN > > we usually assume that all packets (including Mobile IP) in the > > enterprise address space are transparently carried over the VPN tunnel > > through the Internet. So why the untrusted FA outside the enterprise > > network should involve Mobile IP running inside the enterprise network > > through VPN? > > ==> When the FA is in the middle( like below) and MN is the VPN tunnel end, > apparently FA who is adding > the MIP tunnel will intervene the VPN tunnel between MN and VPNGW. > > MN---FA ------------------------VPNGW----HA > Although this does not answer to my question, I think we should not dig into this twisted model. Instead, just running Mobile IP with co-located mode over VPN seems to be much cleaner. Thanks, Yoshihiro Ohba P.S. I'm sending emails from new jersey. From owner-mobile-ip@sunroof.eng.sun.com Wed Aug 28 20:15:05 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 UAA25423 for ; Wed, 28 Aug 2002 20:15:05 -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 RAA26378; Wed, 28 Aug 2002 17:14:11 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04385; Wed, 28 Aug 2002 17:14:07 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7T0Cawf009214 for ; Wed, 28 Aug 2002 17:12:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7T0CaDe009213 for mobile-ip-dist; Wed, 28 Aug 2002 17:12:36 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7T0CUwf009206 for ; Wed, 28 Aug 2002 17:12:30 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA07578 for ; Wed, 28 Aug 2002 17:12:41 -0700 (PDT) Received: from mail1.hd.intel.com (hdfdns01.hd.intel.com [192.52.58.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA22958 for ; Wed, 28 Aug 2002 18:12:40 -0600 (MDT) Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by mail1.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g7T0Cd524848 for ; Thu, 29 Aug 2002 00:12:39 GMT Received: from fmsmsx28.fm.intel.com ([132.233.42.28]) by fmsmsxvs040.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002082817113413323 ; Wed, 28 Aug 2002 17:11:34 -0700 Received: by fmsmsx28.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Aug 2002 17:12:37 -0700 Message-ID: From: "Adrangi, Farid" To: "'Yoshihiro Ohba'" , Qiang Zhang Cc: mobile-ip@sunroof.eng.sun.com, "Iyer, Prakash" , kleung@cisco.com, "'Milind Kulkarni'" , alpesh@cisco.com, jlau@cup.hp.com Subject: RE: [mobile-ip] comments on mobileip-vpn-problem-statement-req Date: Wed, 28 Aug 2002 17:12:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Hello Yoshihiro, Please see my comment below (marked by Farid Writes>). thanks, Farid -----Original Message----- From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] Sent: Wednesday, August 28, 2002 4:24 PM To: Qiang Zhang Cc: Yoshihiro Ohba; mobile-ip@sunroof.eng.sun.com; Adrangi, Farid; Iyer, Prakash; kleung@cisco.com; 'Milind Kulkarni'; alpesh@cisco.com; jlau@cup.hp. com Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req Qiang, On Wed, Aug 28, 2002 at 03:23:37PM -0400, Qiang Zhang wrote: > Yoshihiro, > > Are you sending mails from Japan? > > Regarding the first question, pls see comment > > Thanks > Qiang > ----- Original Message ----- > > > OK. But I still do not understand this usage, because when we use VPN > > we usually assume that all packets (including Mobile IP) in the > > enterprise address space are transparently carried over the VPN tunnel > > through the Internet. So why the untrusted FA outside the enterprise > > network should involve Mobile IP running inside the enterprise network > > through VPN? > > ==> When the FA is in the middle( like below) and MN is the VPN tunnel end, > apparently FA who is adding > the MIP tunnel will intervene the VPN tunnel between MN and VPNGW. > > MN---FA ------------------------VPNGW----HA > Although this does not answer to my question, I think we should not dig into this twisted model. Instead, just running Mobile IP with co-located mode over VPN seems to be much cleaner. Farid Writes > I guess the point here is that you cannot assume that the MN outside the intranet can always use co-located mode over VPN. MN may roam into a foreign network in which it MUST use FA services to route MIP packets. Thanks, Yoshihiro Ohba P.S. I'm sending emails from new jersey. From weilaiyang@yahoo.com.cn Thu Aug 29 04: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 EAA13217 for ; Thu, 29 Aug 2002 04: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 CAA24763; Thu, 29 Aug 2002 02:26: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 BAA04286; Thu, 29 Aug 2002 01:26:06 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7T8P6wf009729 for ; Thu, 29 Aug 2002 01:25:06 -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 BAA04126 for ; Thu, 29 Aug 2002 01:25:17 -0700 (PDT) Received: from 58.19.38.29 ([61.175.117.210]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA22661 for ; Thu, 29 Aug 2002 02:25:15 -0600 (MDT) Message-Id: <200208290825.CAA22661@patan.sun.com> From: David To: mobile-ip-dist@sunroof.eng.sun.com Reply-To: weilaiyang@yahoo.com.cn Subject: SILK BUSINESS Date: Thu, 29 Aug 2002 16:19:44 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="cea637c0-bb68-11d6-a919-005022401bcf" This is a multi-part message in MIME format --cea637c0-bb68-11d6-a919-005022401bcf Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Dear Sir Do you want to import SILK products from China? If you are interested in this = line. pls. feel free to contact me. We hope we can set up some kind of = partnership to promote both benefit.. ZHEJIANG WEILAI GROUP COMPANY Established in 1986, Zhejiang Weilai Group Company is a medium-size = enterprise embracing silk reeling, yarn spinning, weaving, knitting and = garment manufacturing.It integtares industry and trade and engages in the = business of importing and exporting textiles and garments of various styles = and specifications Sincerely wish to strengthen business relations with = counterparts the world wide. http://www.weilaigroup.com E-mail: weilaiyang@yahoo.com.cn TEL:86-572-2010990 FAX:86-572-2022383 David Yang --cea637c0-bb68-11d6-a919-005022401bcf-- From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 29 09:09: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 JAA20567 for ; Thu, 29 Aug 2002 09:09:40 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25044; Thu, 29 Aug 2002 07:10:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA07473; Thu, 29 Aug 2002 06:10:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TD9Owf010226 for ; Thu, 29 Aug 2002 06:09:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TD9OC2010225 for mobile-ip-dist; Thu, 29 Aug 2002 06:09: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.6+Sun/8.12.6) with ESMTP id g7TD9Jwf010218 for ; Thu, 29 Aug 2002 06:09:19 -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 GAA28561 for ; Thu, 29 Aug 2002 06:09:30 -0700 (PDT) Received: from ztxmail03.ztx.compaq.com (ztxmail03.ztx.compaq.com [161.114.1.207]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA18024 for ; Thu, 29 Aug 2002 07:09:29 -0600 (MDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 98F264195; Thu, 29 Aug 2002 08:09:28 -0500 (CDT) Received: from anw.zk3.dec.com (banw4.zk3.dec.com [16.140.128.5]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id D65CDD2E; Thu, 29 Aug 2002 09:09:27 -0400 (EDT) Received: from hp.com by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id g7TD9RM0002147269; Thu, 29 Aug 2002 09:09:27 -0400 (EDT) Message-ID: <3D6E1D07.7070508@hp.com> Date: Thu, 29 Aug 2002 09:09:27 -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: Brian Haley , Jari Arkko , mobile ip Subject: Re: [mobile-ip] Home bindings when L=0 References: <3D6D0EB2.CC902C99@hp.com> <3D6D3653.7060707@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 Vijay Devarapalli wrote: > it would be nice to separate the 'L' bit and the 'S' bit. > > so, heres another suggestion. what if we specify "the MN MUST > set L=0 and S=1 if it is using RFC 3041 generated home address" This is fine with me as well, but hopefully this will not get us into the rut of specifiying bit values for other different address types. That's my only concern... > > Vijay > > ps: Brian, I am fine with your suggestions too. I agree with Brians' wording as well. I must have missed this inconsitency when the we were talking about the L bit. -vlad > > Brian Haley wrote: > >> There seems to be a problem in Section 10.2 of the Mobile IPv6 draft >> regarding which addresses should be defended for Home bindings. >> There is a paragraph that tells what to do when S=0/1 and L=0/1, the >> problem is that when L=0 we should only defend the given home >> address in the BU since we cannot derive the interface id from the >> address to construct other addresses (for example, the MN is using >> a private address). >> >> So I propose that this section can be compressed to three cases: >> >> "The specific addresses which are to be tested before accepting the >> Binding Update, and later to be defended by performing Duplicate >> Address Detection, depend on the settings of the `S' and `L' bits, as >> follows: >> >> - L=0: Defend the given address. The 'S' bit is ignored in this >> case >> since we cannot derive other on-link addresses without knowing >> the interface identifier (IID). >> >> - S=0 & L=1: Defend all non link-local unicast addresses possible >> on link and the derived link-local. >> >> - S=1 & L=1: Defend both the given non link-local unicast (home) >> address and the derived link-local." >> >> Furthermore, in Section 11.6.1, the paragraph on setting S=0 should >> be updated to say that L MUST be 1 in this case or S will be ignored. >> BTW, the very next paragraph (about the L-bit) makes the >> recommendation that the L-bit SHOULD NOT be set if using RFC >> 3041 addresses, maybe that should change to MUST NOT since we >> should not defend a link-local address derived from that type of >> global address. >> >> I talked with Vlad Yasevich about this, who originally proposed the >> L-bit, and this was his intention when he proposed it. >> >> Any comments? >> >> -Brian >> >> > > > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Aug 29 10:49:51 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24938 for ; Thu, 29 Aug 2002 10:49:50 -0400 (EDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA28622; Thu, 29 Aug 2002 07:49:01 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24420; Thu, 29 Aug 2002 07:48:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TElrwf010396 for ; Thu, 29 Aug 2002 07:47:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TElrOW010395 for mobile-ip-dist; Thu, 29 Aug 2002 07:47: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.6+Sun/8.12.6) with ESMTP id g7TEllwf010388 for ; Thu, 29 Aug 2002 07:47:47 -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 HAA24162 for ; Thu, 29 Aug 2002 07:47:58 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA04682 for ; Thu, 29 Aug 2002 08:47:57 -0600 (MDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g7TEdTwH022975; Thu, 29 Aug 2002 10:39:30 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id KAA26789; Thu, 29 Aug 2002 10:39:51 -0400 (EDT) Date: Thu, 29 Aug 2002 10:39:26 -0400 To: "Adrangi, Farid" Cc: "'Yoshihiro Ohba'" , Qiang Zhang , mobile-ip@sunroof.eng.sun.com, "Iyer, Prakash" , kleung@cisco.com, "'Milind Kulkarni'" , alpesh@cisco.com, jlau@cup.hp.com Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req Message-ID: <20020829143926.GA1631@catfish> Mail-Followup-To: "Adrangi, Farid" , 'Yoshihiro Ohba' , Qiang Zhang , mobile-ip@sunroof.eng.sun.com, "Iyer, Prakash" , kleung@cisco.com, 'Milind Kulkarni' , alpesh@cisco.com, jlau@cup.hp.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 25 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Hello Farid, > Farid Writes > I guess the point here is that you cannot assume that > the MN outside the intranet can always use co-located mode over VPN. > MN may roam into a foreign network in which it MUST use FA services > to route MIP packets. OK. Basically, there is a phylosophycal conflict in Problem 2. VPN is used because the enterprise network needs to be logically separated from the Internet. On the other hand, Problem 2 of the draft is trying to privide seamless connectivity with Mobile IP spread over the enterprise network and the Internet as if those two networks were the single network. I don't believe both separation and seamless connectivity can be achieved. This makes me confused on what is the actual problem that Problem 2 addresses. I think we can solve either (i) Mobile IP (in the enterprise domain) over VPN, OR (ii) Mobile IP (in the enterprise domain) over VPN over Mobile IP (in the provider domain), but cannot solve seamless Mobile IP over VPN due to the phylosophycal conflict. Anyway, I think Problem 2 requires more clarification. Thanks, Yoshihiro Ohba From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 29 11:08:12 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25765 for ; Thu, 29 Aug 2002 11:08:12 -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 JAA16939; Thu, 29 Aug 2002 09:08: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 IAA26771; Thu, 29 Aug 2002 08:08:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TF7Xwf010475 for ; Thu, 29 Aug 2002 08:07:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TF7XaL010474 for mobile-ip-dist; Thu, 29 Aug 2002 08:07: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.6+Sun/8.12.6) with ESMTP id g7TF7Rwf010467 for ; Thu, 29 Aug 2002 08:07:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12052 for ; Thu, 29 Aug 2002 08:07:38 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10237 for ; Thu, 29 Aug 2002 09:07:37 -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 g7TF7au27297; Thu, 29 Aug 2002 10:07:36 -0500 (CDT) Message-ID: <3D6E38E8.5060500@alcatel.com> Date: Thu, 29 Aug 2002 10:08: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: "Adrangi, Farid" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req References: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-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 Farid, In addition to Yoshi's comments, I have some comments: 1. In section 2 on deployment scenarios, what about HA's address? Do you assume that HA does not have a public address? Also HoA? Is it private? If your answer is yes then you are talking about a private MIP network, is it of interest to IETF? 2. In section 4.1 you state that your draft is not suggesting an IPsec over MIP solution. Why not? I think that there are some commercial products offering this. 3. For scenarios of 2.2 - 2.4, what does the draft offer as to IPsec over MIP or MIP over IPsec? 4. I am just curious if it is at all possible to establish MIP from somebody else's intranet, assuming no change to the present VPN solutions? Regards, --behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 29 11:12:35 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26005 for ; Thu, 29 Aug 2002 11:12:35 -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 JAA19595; Thu, 29 Aug 2002 09:13: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 IAA01017; Thu, 29 Aug 2002 08:13:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TFCCwf010512 for ; Thu, 29 Aug 2002 08:12:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TFCCpd010511 for mobile-ip-dist; Thu, 29 Aug 2002 08:12: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.6+Sun/8.12.6) with ESMTP id g7TFC6wf010504 for ; Thu, 29 Aug 2002 08:12:06 -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 IAA00833 for ; Thu, 29 Aug 2002 08:12:17 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18989 for ; Thu, 29 Aug 2002 09:12:16 -0600 (MDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g7TF45wH024899; Thu, 29 Aug 2002 11:04:06 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id LAA26867; Thu, 29 Aug 2002 11:04:28 -0400 (EDT) Date: Thu, 29 Aug 2002 11:04:03 -0400 To: "Adrangi, Farid" , "'Yoshihiro Ohba'" , Qiang Zhang , mobile-ip@sunroof.eng.sun.com, "Iyer, Prakash" , kleung@cisco.com, "'Milind Kulkarni'" , alpesh@cisco.com, jlau@cup.hp.com Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req Message-ID: <20020829150403.GB1999@catfish> Mail-Followup-To: "Adrangi, Farid" , 'Yoshihiro Ohba' , Qiang Zhang , mobile-ip@sunroof.eng.sun.com, "Iyer, Prakash" , kleung@cisco.com, 'Milind Kulkarni' , alpesh@cisco.com, jlau@cup.hp.com References: <20020829143926.GA1631@catfish> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: <20020829143926.GA1631@catfish> User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 29 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Correction: Problem 2 -> Problem 1. On Thu, Aug 29, 2002 at 10:39:26AM -0400, Yoshihiro Ohba wrote: > Hello Farid, > > > Farid Writes > I guess the point here is that you cannot assume that > > the MN outside the intranet can always use co-located mode over VPN. > > MN may roam into a foreign network in which it MUST use FA services > > to route MIP packets. > > OK. Basically, there is a phylosophycal conflict in Problem 2. VPN > is used because the enterprise network needs to be logically separated > from the Internet. On the other hand, Problem 2 of the draft is > trying to privide seamless connectivity with Mobile IP spread over the > enterprise network and the Internet as if those two networks were the > single network. I don't believe both separation and seamless > connectivity can be achieved. > > This makes me confused on what is the actual problem that Problem 2 > addresses. I think we can solve either (i) Mobile IP (in the > enterprise domain) over VPN, OR (ii) Mobile IP (in the enterprise > domain) over VPN over Mobile IP (in the provider domain), but cannot > solve seamless Mobile IP over VPN due to the phylosophycal conflict. > > Anyway, I think Problem 2 requires more clarification. > > Thanks, > Yoshihiro Ohba > From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 29 11:54:51 2002 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28120 for ; Thu, 29 Aug 2002 11:54:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06981; Thu, 29 Aug 2002 08:53:59 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA08459; Thu, 29 Aug 2002 08:53:54 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TFqnwf010579 for ; Thu, 29 Aug 2002 08:52:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TFqn9I010578 for mobile-ip-dist; Thu, 29 Aug 2002 08:52: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.6+Sun/8.12.6) with ESMTP id g7TFqiwf010571 for ; Thu, 29 Aug 2002 08:52:44 -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 IAA12505 for ; Thu, 29 Aug 2002 08:52:55 -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 IAA06216 for ; Thu, 29 Aug 2002 08:52:54 -0700 (PDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id D15D26A90A; Thu, 29 Aug 2002 18:52:45 +0300 (EEST) Message-ID: <3D6E4380.1090007@kolumbus.fi> Date: Thu, 29 Aug 2002 18:53:36 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Haley Cc: Vijay Devarapalli , mobile ip Subject: Re: [mobile-ip] Home bindings when L=0 References: <3D6D0EB2.CC902C99@hp.com> <3D6D3653.7060707@iprg.nokia.com> <3D6D3C86.213D1738@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 I agree with Brian's suggestion for 10.2 and 11.6.1. A few comments on the discussion: Vijay wrote: >so, heres another suggestion. what if we specify "the MN MUST >set L=0 and S=1 if it is using RFC 3041 generated home address Yes, we should make this explicit in 11.6.1. Brian wrote: > That's fine with me, but we also have to specify what to do if > we see the invalid setting, we shouldn't need to drop the packet > for something like this. We can't tell if the MN did this wrong, because we can't tell 3041 addresses from other addresses. However, the HA can receive an L=0 and S=0 which is in a way invalid. But your new 3-entry table already takes care of this, as it doesn't consider the S bit at all if L=0. So we should be OK now. Jari From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 29 14:07:49 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 OAA04787 for ; Thu, 29 Aug 2002 14:07:49 -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 MAA03375; Thu, 29 Aug 2002 12:08:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20499; Thu, 29 Aug 2002 11:08:23 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TI7Bwf010778 for ; Thu, 29 Aug 2002 11:07:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TI7B6F010777 for mobile-ip-dist; Thu, 29 Aug 2002 11:07: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.6+Sun/8.12.6) with ESMTP id g7TI74wf010770 for ; Thu, 29 Aug 2002 11:07: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 LAA20053 for ; Thu, 29 Aug 2002 11:07:15 -0700 (PDT) Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14915 for ; Thu, 29 Aug 2002 11:07:14 -0700 (PDT) Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g7TI7Di18706 for ; Thu, 29 Aug 2002 18:07:14 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002082911062130209 ; Thu, 29 Aug 2002 11:06:23 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Aug 2002 11:07:09 -0700 Message-ID: From: "Adrangi, Farid" To: "'Yoshihiro Ohba'" Cc: Qiang Zhang , mobile-ip@sunroof.eng.sun.com, "Iyer, Prakash" , kleung@cisco.com, "'Milind Kulkarni'" , alpesh@cisco.com, jlau@cup.hp.com Subject: RE: [mobile-ip] comments on mobileip-vpn-problem-statement-req Date: Thu, 29 Aug 2002 11:07:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Hello Yoshihiro, Please see my replies below. Best regards, Farid -----Original Message----- From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] Sent: Thursday, August 29, 2002 7:39 AM To: Adrangi, Farid Cc: 'Yoshihiro Ohba'; Qiang Zhang; mobile-ip@sunroof.eng.sun.com; Iyer, Prakash; kleung@cisco.com; 'Milind Kulkarni'; alpesh@cisco.com; jlau@cup.hp. com Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req Hello Farid, > Farid Writes > I guess the point here is that you cannot assume that > the MN outside the intranet can always use co-located mode over VPN. > MN may roam into a foreign network in which it MUST use FA services > to route MIP packets. OK. Basically, there is a phylosophycal conflict in Problem 2. VPN is used because the enterprise network needs to be logically separated from the Internet. On the other hand, Problem 2 of the draft is trying to privide seamless connectivity with Mobile IP spread over the enterprise network and the Internet as if those two networks were the single network. I don't believe both separation and seamless connectivity can be achieved. Farid Writes > Why is so? why do you think that is not achievable? We are treating the two network (intranet and interent) as a single network from Mobile IP perspective, but there are still separated from each other (in this case, by an IPsec-based VPN gateway). In other words, MNs roaming outside will still need a secure way to access resources inside the intranet. This makes me confused on what is the actual problem that Problem 2 addresses. I think we can solve either (i) Mobile IP (in the enterprise domain) over VPN, OR (ii) Mobile IP (in the enterprise domain) over VPN over Mobile IP (in the provider domain), but cannot solve seamless Mobile IP over VPN due to the phylosophycal conflict. FArid Writes> I think here you are again jumping into the solution space (i.e., what is doable or not doable). Here we are trying to define a problem statement pertaining to MObile IP and IPsec-based VPN co-existence. Anyway, I think Problem 2 requires more clarification. FArid Writes > Ok. Perhaps, you can help us understand exactly what clarification needs to be done. Thanks, Yoshihiro Ohba From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 29 15:04: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 PAA07060 for ; Thu, 29 Aug 2002 15:04:22 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21775; Thu, 29 Aug 2002 12:03:17 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12918; Thu, 29 Aug 2002 12:03:11 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJ20wf010887 for ; Thu, 29 Aug 2002 12:02:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TJ1xAV010886 for mobile-ip-dist; Thu, 29 Aug 2002 12:01: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.6+Sun/8.12.6) with ESMTP id g7TJ1rwf010879 for ; Thu, 29 Aug 2002 12:01:53 -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 MAA12432 for ; Thu, 29 Aug 2002 12:02:04 -0700 (PDT) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21025 for ; Thu, 29 Aug 2002 12:02:03 -0700 (PDT) Received: from tari.research.telcordia.com (tari [207.3.232.66]) by thumper.research.telcordia.com (8.12.1/8.12.1) with ESMTP id g7TIrcwH013590; Thu, 29 Aug 2002 14:53:38 -0400 (EDT) Received: from localhost (ohba@tari-dhcp-104.research.telcordia.com [207.3.232.104]) by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id OAA27379; Thu, 29 Aug 2002 14:53:59 -0400 (EDT) Date: Thu, 29 Aug 2002 14:53:35 -0400 To: "Adrangi, Farid" Cc: "'Yoshihiro Ohba'" , Qiang Zhang , mobile-ip@sunroof.eng.sun.com, "Iyer, Prakash" , kleung@cisco.com, "'Milind Kulkarni'" , alpesh@cisco.com, jlau@cup.hp.com Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req Message-ID: <20020829185335.GB657@catfish> Mail-Followup-To: "Adrangi, Farid" , 'Yoshihiro Ohba' , Qiang Zhang , mobile-ip@sunroof.eng.sun.com, "Iyer, Prakash" , kleung@cisco.com, 'Milind Kulkarni' , alpesh@cisco.com, jlau@cup.hp.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i From: Yoshihiro Ohba X-Dispatcher: imput version 20000414(IM141) Lines: 75 X-Virus-Scanned: by AMaViS-perl11-milter (http://amavis.org/) Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Farid, Please see my comments below. On Thu, Aug 29, 2002 at 11:07:00AM -0700, Adrangi, Farid wrote: > Hello Yoshihiro, > Please see my replies below. > Best regards, > Farid > > -----Original Message----- > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com] > Sent: Thursday, August 29, 2002 7:39 AM > To: Adrangi, Farid > Cc: 'Yoshihiro Ohba'; Qiang Zhang; mobile-ip@sunroof.eng.sun.com; Iyer, > Prakash; kleung@cisco.com; 'Milind Kulkarni'; alpesh@cisco.com; jlau@cup.hp. > com > Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req > > > Hello Farid, > > > Farid Writes > I guess the point here is that you cannot assume that > > the MN outside the intranet can always use co-located mode over VPN. > > MN may roam into a foreign network in which it MUST use FA services > > to route MIP packets. > > OK. Basically, there is a phylosophycal conflict in Problem 2. VPN > is used because the enterprise network needs to be logically separated > from the Internet. On the other hand, Problem 2 of the draft is > trying to privide seamless connectivity with Mobile IP spread over the > enterprise network and the Internet as if those two networks were the > single network. I don't believe both separation and seamless > connectivity can be achieved. > > Farid Writes > Why is so? why do you think that is not achievable? > We are treating the two network (intranet and interent) as a single > network from Mobile IP perspective, but there are still separated > from each other (in this case, by an IPsec-based VPN gateway). In > other words, MNs roaming outside will still need a secure way to > access resources inside the intranet. If the last sentence above is the goal, it is not necessarily to treat intranet and interent as a single network from Mobile IP perspective. For example, Mobile IP (in the enterprise domain) over VPN over Mobile IP (in the provider domain) can solve the problem when the provider in the visiting network forces FA services to the MN. Perhaps Bahcet has a similer view as mine. The other issue is on security. Allowing the internal HA to communicate with external untrusted FA can be a security hole which would be unacceptable for enterprise use. > > This makes me confused on what is the actual problem that Problem 2 > addresses. I think we can solve either (i) Mobile IP (in the > enterprise domain) over VPN, OR (ii) Mobile IP (in the enterprise > domain) over VPN over Mobile IP (in the provider domain), but cannot > solve seamless Mobile IP over VPN due to the phylosophycal conflict. > > FArid Writes> I think here you are again jumping into the solution > space (i.e., what is doable or not doable). Here we are trying to define > a problem statement pertaining to MObile IP and IPsec-based VPN > co-existence. > > Anyway, I think Problem 2 requires more clarification. > > FArid Writes > Ok. Perhaps, you can help us understand exactly what > clarification needs to be done. Clarification is needed for why it is necessary to treat intranet and interent as a single network for Mobile IP only, while non-MIP services does not require that. Thanks. Yoshihiro Ohba From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 29 15:14: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 PAA07442 for ; Thu, 29 Aug 2002 15:14:20 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA27817; Thu, 29 Aug 2002 12:13:36 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16206; Thu, 29 Aug 2002 12:13:33 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJC9wf011019 for ; Thu, 29 Aug 2002 12:12:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TJC9Sk011018 for mobile-ip-dist; Thu, 29 Aug 2002 12: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.6+Sun/8.12.6) with ESMTP id g7TJC3wf011011 for ; Thu, 29 Aug 2002 12:12:03 -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 MAA15606 for ; Thu, 29 Aug 2002 12:12:14 -0700 (PDT) Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23109 for ; Thu, 29 Aug 2002 13:12:13 -0600 (MDT) Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g7TJCD916996 for ; Thu, 29 Aug 2002 19:12:13 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002082912112313637 ; Thu, 29 Aug 2002 12:11:23 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Aug 2002 12:12:11 -0700 Message-ID: From: "Adrangi, Farid" To: "'Behcet Sarikaya'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] comments on mobileip-vpn-problem-statement-req Date: Thu, 29 Aug 2002 12:12:05 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Hello behcet, Please see my replies (marked by Farid Writes>). Please let me know if you still have any questions. Best regards, FArid -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Thursday, August 29, 2002 8:08 AM To: Adrangi, Farid Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req Hello Farid, In addition to Yoshi's comments, I have some comments: 1. In section 2 on deployment scenarios, what about HA's address? Do you assume that HA does not have a public address? Also HoA? Is it private? If your answer is yes then you are talking about a private MIP network, is it of interest to IETF? Farid Writes> It depends on which particular deployment scenario(s) you are referring to in section 2. For example, section 2.1 describes a deoployment scenario in which all HAs are inside intratnet protected by a VPN gateway. In this case, you have a private MIP network (i.e., your intranet) -- and the mobility within the intranet is solved by RFC 3220. However, enabling MN to roam outside the intranet, or enabling MN to roam inside and outside the intranet might also be desried -- this requires Mobile IP and VPN to co-exist, and this draft attempts to describe the problems resulting from this co-existence. 2. In section 4.1 you state that your draft is not suggesting an IPsec over MIP solution. Why not? I think that there are some commercial products offering this. Farid Writes > This is a problem statement draft -- we have tried to make it clear that we are not suggesting any solution (i.e., IPsec over MIP or vice a versa). 3. For scenarios of 2.2 - 2.4, what does the draft offer as to IPsec over MIP or MIP over IPsec? Farid Writes> The draf is NOT offering any solutions, but it is simply defining problems resulting from MObile IP and VPN co-existence. 4. I am just curious if it is at all possible to establish MIP from somebody else's intranet, assuming no change to the present VPN solutions? Farid Writes> That's someting that we need to discuss when we start evaluating the solution proposals. Regards, --behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 29 15:50: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 PAA08618 for ; Thu, 29 Aug 2002 15:50: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 NAA22639; Thu, 29 Aug 2002 13:51:19 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05633; Thu, 29 Aug 2002 12:51:14 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJnPwf011293 for ; Thu, 29 Aug 2002 12:49:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TJnPNj011292 for mobile-ip-dist; Thu, 29 Aug 2002 12:49: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.6+Sun/8.12.6) with ESMTP id g7TJnKwf011285 for ; Thu, 29 Aug 2002 12:49:20 -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 MAA05085 for ; Thu, 29 Aug 2002 12:49:31 -0700 (PDT) Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10968 for ; Thu, 29 Aug 2002 12:49:31 -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 g7TJnOM29706; Thu, 29 Aug 2002 14:49:24 -0500 (CDT) Message-ID: <3D6E7AEC.3020104@alcatel.com> Date: Thu, 29 Aug 2002 14:50: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: "Adrangi, Farid" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req References: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-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 Farid, Thanks for your reply. Two more quick questions: 1. Section 2.1 the draft states This (i.e. private MIP network) can be considered a typical deployment scenario in enterprise environments with a large and growing number of mobile users. Is this really true? I would not say so. 2. In Section 4.1 on p.9 the draft states It is important to note that the mobile node connecting to the home network is forced to establish an IPsec tunnel SA to the VPN gateway first. This means that handover occurs first for VPN, which I think, defeats the purpose of MIP. What do you think? Regards, --behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 29 17:13: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 RAA11462 for ; Thu, 29 Aug 2002 17:13:51 -0400 (EDT) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA03748; Thu, 29 Aug 2002 15:14: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 OAA23073; Thu, 29 Aug 2002 14:14:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TLDTwf011947 for ; Thu, 29 Aug 2002 14:13:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7TLDSlb011946 for mobile-ip-dist; Thu, 29 Aug 2002 14:13: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.6+Sun/8.12.6) with ESMTP id g7TLDNwf011939 for ; Thu, 29 Aug 2002 14:13:23 -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 OAA01925 for ; Thu, 29 Aug 2002 14:13:33 -0700 (PDT) Received: from caduceus.fm.intel.com (fmr02.intel.com [192.55.52.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29086 for ; Thu, 29 Aug 2002 14:13:32 -0700 (PDT) Received: from petasus.fm.intel.com (petasus.fm.intel.com [10.1.192.37]) by caduceus.fm.intel.com (8.11.6/8.11.6/d: outer.mc,v 1.49 2002/08/23 20:32:26 root Exp $) with ESMTP id g7TLAVe22831; Thu, 29 Aug 2002 21:10:31 GMT Received: from FMSMSX017.fm.intel.com (fmsmsx017.fm.intel.com [132.233.42.196]) by petasus.fm.intel.com (8.11.6/8.11.6/d: inner.mc,v 1.23 2002/08/23 20:31:44 root Exp $) with ESMTP id g7TLALA27646; Thu, 29 Aug 2002 21:10:22 GMT Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Aug 2002 14:13:31 -0700 Message-ID: From: "Adrangi, Farid" To: "'Behcet Sarikaya'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] comments on mobileip-vpn-problem-statement-req Date: Thu, 29 Aug 2002 14:13:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Hello behcet, Please see my replies below. regards, FArid -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Thursday, August 29, 2002 12:50 PM To: Adrangi, Farid Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req Hello Farid, Thanks for your reply. Two more quick questions: 1. Section 2.1 the draft states This (i.e. private MIP network) can be considered a typical deployment scenario in enterprise environments with a large and growing number of mobile users. Is this really true? I would not say so. Farid Writes > we said that based on feedback that we got from our and some other large corporation IT folks. If you think this will not be a typical deployment scenario for large enterprise, then what do you think the typical scenario would be? 2. In Section 4.1 on p.9 the draft states It is important to note that the mobile node connecting to the home network is forced to establish an IPsec tunnel SA to the VPN gateway first. This means that handover occurs first for VPN, which I think, defeats the purpose of MIP. What do you think? Farid Writes > This implies that IPsec needs to be re-negotiated as the MN moves from one subnet to another -- which in turn impacts the overall handover performance. The solution proposal (whatever it is) needs to address this problem. So, you can view this as a problem that needs to be addressed/solved. Regards, --behcet From owner-mobile-ip@sunroof.eng.sun.com Thu Aug 29 23:15: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 XAA21243 for ; Thu, 29 Aug 2002 23:15:54 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15213; Thu, 29 Aug 2002 20:06:10 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7U35gJl008367; Thu, 29 Aug 2002 20:06:08 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U34nwf012811 for ; Thu, 29 Aug 2002 20:04:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7U34n4L012810 for mobile-ip-dist; Thu, 29 Aug 2002 20:04: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 eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7U34kwf012803 for ; Thu, 29 Aug 2002 20:04:47 -0700 (PDT) Received: from onion.East.Sun.COM (onion.East.Sun.COM [129.148.174.110]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA11696 for ; Thu, 29 Aug 2002 23:04: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 g7U358XA015888 for ; Thu, 29 Aug 2002 23:05:08 -0400 (EDT) Received: (from glass@localhost) by onion.East.Sun.COM (8.12.2+Sun/8.12.2/Submit) id g7U358MP015887 for mobile-ip@sunroof.eng.sun.com; Thu, 29 Aug 2002 23:05:08 -0400 (EDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7TJxhwf011393 for ; Thu, 29 Aug 2002 12:59:43 -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 MAA29881 for ; Thu, 29 Aug 2002 12:59:54 -0700 (PDT) Received: from tiquini.ece.arizona.edu (tiquini.ece.arizona.edu [128.196.29.23]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24763 for ; Thu, 29 Aug 2002 12:59:54 -0700 (PDT) Received: from ece2.ece.arizona.edu (ece2 [128.196.28.165]) by tiquini.ece.arizona.edu (8.12.5/8.12.5) with ESMTP id g7TJxr4d002248 for ; Thu, 29 Aug 2002 12:59:53 -0700 (MST) Received: (from confs@localhost) by ece2.ece.arizona.edu (8.11.6+Sun/8.10.2) id g7TJxhe10270 for mobile-ip@sunroof.eng.sun.com; Thu, 29 Aug 2002 12:59:52 -0700 (MST) Date: Thu, 29 Aug 2002 12:59:52 -0700 (MST) From: "Marwan M. Krunz" Message-Id: <200208291959.g7TJxhe10270@ece2.ece.arizona.edu> To: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] MobiCom 2002 - Early Registration Two Days Away Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Dear Colleague, This is a friendly reminder that the cut-off date for MobiCom 2002 early registration and hotel reservation is *** Aug. 31 **** We cordially invite to participate in this exciting event. For conference registration, see: http://www.regmaster.com/mobicom2002.html For hotel registration, see: http://www.acm.org/sigmobile/mobicom/2002/hotelinfo/ Regards, Marwan Krunz and Chuanyi Ji Publicity Chairs MobiCom 2002 From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 30 11:38: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 LAA21929 for ; Fri, 30 Aug 2002 11:38:18 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25010; Fri, 30 Aug 2002 08:26:57 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UFQRJl028414; Fri, 30 Aug 2002 08:26:55 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UFPXwf014258 for ; Fri, 30 Aug 2002 08:25:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UFPXbq014257 for mobile-ip-dist; Fri, 30 Aug 2002 08:25: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UFPPwf014250 for ; Fri, 30 Aug 2002 08:25:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UFPZJf028185 for ; Fri, 30 Aug 2002 08:25:36 -0700 (PDT) Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA22362 for ; Fri, 30 Aug 2002 09:25:29 -0600 (MDT) Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 16:25:29 +0100 Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Aug 2002 16:25:29 +0100 Received: from TVP-MSG-01.europe.corp.microsoft.com ([157.58.40.130]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 16:25:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [mobile-ip] How to handle RoutingHeader Type zero Date: Fri, 30 Aug 2002 16:25:30 +0100 Message-ID: Thread-Topic: How to handle RoutingHeader Type zero Thread-Index: AcJPdIdi+HlgBYJsR+qEeBMoezYhBQAvQsNw From: "Greg O'Shea" To: "mobile ip" X-OriginalArrivalTime: 30 Aug 2002 15:25:29.0597 (UTC) FILETIME=[792A52D0:01C25039] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7UFPPwf014251 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit Draft 18 sections 4.1, 9.6, 11.2.3 and 14.7 explain why type 2 routing headers are a good idea and how they should be validated. But the spec does not say what the MN must do if a RH type 0 is received where a RH type 2 is expected. As I read things (strictly) a type zero with a LastSeg=HoA could go all the way through with less validation than a type 2. From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 30 11:46: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 LAA22345 for ; Fri, 30 Aug 2002 11:46:31 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA15528; Fri, 30 Aug 2002 09:38:43 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UFcSJl001466; Fri, 30 Aug 2002 08:38:40 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UFbawf014348 for ; Fri, 30 Aug 2002 08:37:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UFbavp014347 for mobile-ip-dist; Fri, 30 Aug 2002 08:37: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.6+Sun/8.12.6) with ESMTP id g7UFbUwf014340 for ; Fri, 30 Aug 2002 08:37:30 -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 IAA26946 for ; Fri, 30 Aug 2002 08:37:41 -0700 (PDT) From: Basavaraj.Patil@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02914 for ; Fri, 30 Aug 2002 08:37:40 -0700 (PDT) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g7UFcCx12676 for ; Fri, 30 Aug 2002 10:38:16 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 30 Aug 2002 10:37:35 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.5329); Fri, 30 Aug 2002 08:36:33 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [mobile-ip] How to handle RoutingHeader Type zero Date: Fri, 30 Aug 2002 10:36:33 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44013EF9BD@daebe007.americas.nokia.com> Thread-Topic: How to handle RoutingHeader Type zero Thread-Index: AcJPdIdi+HlgBYJsR+qEeBMoezYhBQAvQsNwAAIgjSA= To: , X-OriginalArrivalTime: 30 Aug 2002 15:36:33.0827 (UTC) FILETIME=[0513C730:01C2503B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7UFbVwf014341 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit From: http://www.piuha.net/~jarkko/publications/mipv6/security-considerations-new.txt " 15.7 Type 2 Routing Header The definition of the Type 2 Routing Header is described in Section 6.4. This definition and the associated processing rules have been chosen so that the header can not be used for what is traditionally viewed as source routing. In particular, the IPv6 the Home Address in the routing header will always have to be assigned to the home address of the receiving node. Otherwise the packet will be dropped. Generally, source routing has a number of security concerns. These include the automatic reversal of unauthenticated source routes (which is an issue for IPv4, but not for IPv6). Another concern is the ability to use source routing to "jump" between nodes inside, as well as outside a firewall. These security concerns are not issues in Mobile IPv6, due to the rules mentioned above. In essence the semantics of the type 2 routing header is the same as a special form of IP-in-IP tunneling where the inner and outer source addresses are the same. This implies that a device which implements filtering of packets should be able to distinguish between a Type 2 Routing header and other Routing headers, as required in section 8.3. This is necessary in order to allow Mobile IPv6 traffic while still having the option to filter out other uses of Routing headers. " So are you suggesting that the spec make a recommendation that MNs MUST NOT process packets with RH type 0? > > Draft 18 sections 4.1, 9.6, 11.2.3 and 14.7 explain why type 2 routing > headers are a good idea and how they should be validated. But the spec > does not say what the MN must do if a RH type 0 is received where a RH > type 2 is expected. As I read things (strictly) a type zero with a > LastSeg=HoA could go all the way through with less validation than a > type 2. > > From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 30 12:00: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 MAA22955 for ; Fri, 30 Aug 2002 12:00:20 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09092; Fri, 30 Aug 2002 09:57:53 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UFvUuN012652; Fri, 30 Aug 2002 08:57:52 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UFudwf014494 for ; Fri, 30 Aug 2002 08:56:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UFucja014493 for mobile-ip-dist; Fri, 30 Aug 2002 08:56:38 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UFuXwf014486 for ; Fri, 30 Aug 2002 08:56:33 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04917 for ; Fri, 30 Aug 2002 08:56:44 -0700 (PDT) Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11921 for ; Fri, 30 Aug 2002 08:56:43 -0700 (PDT) Received: from alcatel.com (localhost [127.0.0.1]) by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id g7UFufu06696; Fri, 30 Aug 2002 10:56:41 -0500 (CDT) Message-ID: <3D6F95E8.7080100@alcatel.com> Date: Fri, 30 Aug 2002 10:57:28 -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: "Adrangi, Farid" CC: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req References: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-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 Farid, I could not find any direct requirement in RFC 3220 for HAs to have a public address (although there are implicit requirements such as dynamic home agent discovery) however I could find the following requirement for HAs in CDMA2000 Wireless IP standard (IS 835B): The HA shall support basic MIP [RFC 2002-2006], reverse tunneling [RFC 3024], FAC [RFC 3012], and Mobile IP NAI Extension [RFC 2794]. In order to provide public network access and to provide private network access across the public network, the HA shall use a globally routable and visible IP address. Regards, Adrangi, Farid wrote: >Hello behcet, >Please see my replies below. >regards, >FArid > >-----Original Message----- >From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] >Sent: Thursday, August 29, 2002 12:50 PM >To: Adrangi, Farid >Cc: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req > > >Hello Farid, >Thanks for your reply. Two more quick questions: >1. Section 2.1 the draft states >This (i.e. private MIP network) can be considered a typical deployment >scenario in >enterprise environments with a large and growing number of mobile >users. >Is this really true? I would not say so. > >Farid Writes > we said that based on feedback that we got from our and >some other large corporation IT folks. If you think this will not be a >typical deployment scenario for large enterprise, then what do you think >the typical scenario would be? > >2. In Section 4.1 on p.9 the draft states >It is important to note that the mobile node connecting to the >home network is forced to establish an IPsec tunnel SA to the >VPN gateway first. > >This means that handover occurs first for VPN, which I think, defeats >the purpose of MIP. >What do you think? > >Farid Writes > This implies that IPsec needs to be re-negotiated as the MN >moves > from one subnet to another -- which in turn impacts the overall handover >performance. >The solution proposal (whatever it is) needs to address this problem. So, >you can >view this as a problem that needs to be addressed/solved. > >Regards, > > >--behcet > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 30 12:31:42 2002 Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24394 for ; Fri, 30 Aug 2002 12:31:41 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15577; Fri, 30 Aug 2002 10:28:36 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UGSMuN020217; Fri, 30 Aug 2002 09:28:34 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UGRRwf014627 for ; Fri, 30 Aug 2002 09:27:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UGRR2U014626 for mobile-ip-dist; Fri, 30 Aug 2002 09:27: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UGRMwf014619 for ; Fri, 30 Aug 2002 09:27:22 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UGRXPG014148 for ; Fri, 30 Aug 2002 09:27:33 -0700 (PDT) Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02598 for ; Fri, 30 Aug 2002 09:27:32 -0700 (PDT) Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g7UGRVF16962 for ; Fri, 30 Aug 2002 16:27:31 GMT Received: from fmsmsx26.fm.intel.com ([132.233.42.26]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002083009264104908 ; Fri, 30 Aug 2002 09:26:41 -0700 Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Aug 2002 09:27:29 -0700 Message-ID: From: "Adrangi, Farid" To: "'Behcet Sarikaya'" Cc: mobile-ip@sunroof.eng.sun.com Subject: RE: [mobile-ip] comments on mobileip-vpn-problem-statement-req Date: Fri, 30 Aug 2002 09:27:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) 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: Hello Behcet, Please see my reply below. Please let me know if you have any questions. regards, FArid -----Original Message----- From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] Sent: Friday, August 30, 2002 8:57 AM To: Adrangi, Farid Cc: mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req Hi Farid, I could not find any direct requirement in RFC 3220 for HAs to have a public address (although there are implicit requirements such as dynamic home agent discovery) Farid Writes> That's right. As I mentioned it before, you can provide IP mobility as per Mobile IP specifications [RFC3220] within the intranet ( a private address space). RFC3220 requires /assumes HAs to be *directly* reachable by the MNs -- that is, it does not provide any solutions for middle-box (e.g., NAT, VPN) traversal. In the Intranet case, the HAs are directly reachable within the Intranet private address space (assuming that there aren't any intervening NAT boxes). however I could find the following requirement for HAs in CDMA2000 Wireless IP standard (IS 835B): The HA shall support basic MIP [RFC 2002-2006], reverse tunneling [RFC 3024], FAC [RFC 3012], and Mobile IP NAI Extension [RFC 2794]. In order to provide public network access and to provide private network access across the public network, the HA shall use a globally routable and visible IP address. Farid Writes > I am not familiar with the requirement for HAs in CDMA2000, so I can't tell you why they require HA to be reachable globally. Regards, Adrangi, Farid wrote: >Hello behcet, >Please see my replies below. >regards, >FArid > >-----Original Message----- >From: Behcet Sarikaya [mailto:behcet.sarikaya@alcatel.com] >Sent: Thursday, August 29, 2002 12:50 PM >To: Adrangi, Farid >Cc: mobile-ip@sunroof.eng.sun.com >Subject: Re: [mobile-ip] comments on mobileip-vpn-problem-statement-req > > >Hello Farid, >Thanks for your reply. Two more quick questions: >1. Section 2.1 the draft states >This (i.e. private MIP network) can be considered a typical deployment >scenario in >enterprise environments with a large and growing number of mobile >users. >Is this really true? I would not say so. > >Farid Writes > we said that based on feedback that we got from our and >some other large corporation IT folks. If you think this will not be a >typical deployment scenario for large enterprise, then what do you think >the typical scenario would be? > >2. In Section 4.1 on p.9 the draft states >It is important to note that the mobile node connecting to the >home network is forced to establish an IPsec tunnel SA to the >VPN gateway first. > >This means that handover occurs first for VPN, which I think, defeats >the purpose of MIP. >What do you think? > >Farid Writes > This implies that IPsec needs to be re-negotiated as the MN >moves > from one subnet to another -- which in turn impacts the overall handover >performance. >The solution proposal (whatever it is) needs to address this problem. So, >you can >view this as a problem that needs to be addressed/solved. > >Regards, > > >--behcet > -- Behcet From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 30 13:32: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 NAA26893 for ; Fri, 30 Aug 2002 13:32:24 -0400 (EDT) Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24261; Fri, 30 Aug 2002 11:33:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14102; Fri, 30 Aug 2002 10:33:01 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UHVewf014783 for ; Fri, 30 Aug 2002 10:31:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UHVdFf014782 for mobile-ip-dist; Fri, 30 Aug 2002 10:31: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.6+Sun/8.12.6) with ESMTP id g7UHVVwf014772 for ; Fri, 30 Aug 2002 10:31:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13472 for ; Fri, 30 Aug 2002 10:31:41 -0700 (PDT) Received: from mail-dub.microsoft.com (mail-dub.microsoft.com [213.199.128.160]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00375 for ; Fri, 30 Aug 2002 11:31:39 -0600 (MDT) Received: from dub-imc-01.europe.corp.microsoft.com ([65.53.196.35]) by mail-dub.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 18:31:38 +0100 Received: from 65.53.196.35 by dub-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Aug 2002 18:31:38 +0100 Received: from TVP-MSG-01.europe.corp.microsoft.com ([157.58.40.130]) by dub-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 18:31:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: [mobile-ip] Ordering of Mobility Header Date: Fri, 30 Aug 2002 18:31:38 +0100 Message-ID: Thread-Topic: Ordering of Mobility Header Thread-Index: AcJQSqw3ZcL8AT/uRl+qj2brY1WiVQ== From: "Greg O'Shea" To: "mobile ip" X-OriginalArrivalTime: 30 Aug 2002 17:31:38.0396 (UTC) FILETIME=[188565C0:01C2504B] 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. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2504B.1890C2FC" ------_=_NextPart_001_01C2504B.1890C2FC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there a recommended ordering of MH with respect to other header types? ------_=_NextPart_001_01C2504B.1890C2FC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ordering of Mobility Header

Is there a recommended ordering of MH = with respect to other header types?

------_=_NextPart_001_01C2504B.1890C2FC-- --------------InterScan_NT_MIME_Boundary-- From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 30 13:36: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 NAA27101 for ; Fri, 30 Aug 2002 13:36:39 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05319; Fri, 30 Aug 2002 11:34:06 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UHX0PM003179; Fri, 30 Aug 2002 10:34:03 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UHVcwf014780 for ; Fri, 30 Aug 2002 10:31:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UHVbbV014779 for mobile-ip-dist; Fri, 30 Aug 2002 10:31: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UHVTwf014765 for ; Fri, 30 Aug 2002 10:31:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UHVdPG002732 for ; Fri, 30 Aug 2002 10:31:39 -0700 (PDT) Received: from mail-lul.microsoft.com (mail-lul.microsoft.com [212.157.154.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00321 for ; Fri, 30 Aug 2002 11:31:33 -0600 (MDT) Received: from lul-imc-01.europe.corp.microsoft.com ([65.53.188.37]) by mail-lul.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 19:31:31 +0200 Received: from 65.53.188.37 by lul-imc-01.europe.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 30 Aug 2002 19:31:31 +0200 Received: from TVP-MSG-01.europe.corp.microsoft.com ([157.58.40.130]) by lul-imc-01.europe.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 30 Aug 2002 19:31:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [mobile-ip] How to handle RoutingHeader Type zero Date: Fri, 30 Aug 2002 18:31:31 +0100 Message-ID: Thread-Topic: [mobile-ip] How to handle RoutingHeader Type zero Thread-Index: AcJPdIdi+HlgBYJsR+qEeBMoezYhBQAvQsNwAAIgjSAAA42J0A== From: "Greg O'Shea" To: , X-OriginalArrivalTime: 30 Aug 2002 17:31:31.0742 (UTC) FILETIME=[148E13E0:01C2504B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g7UHVUwf014766 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 8bit If a type zero gets through the filters then it's not obvious why the MN need reject the packet, except perhaps that the final segment might not be to a HoA which the MN isn't required to check for a type zero. Section 9.6 seems to leave open the possibility that a type zero RH will be sent by a CN ("For example, assuming ... if no other use...") but Section 11.2.3 assumes that a MN will never receive a routing header other than type 2. Can anyone clarify the intent? >-----Original Message----- >From: Basavaraj.Patil@nokia.com [mailto:Basavaraj.Patil@nokia.com] >Sent: 30 August 2002 16:37 >To: Greg O'Shea; mobile-ip@sunroof.eng.sun.com >Subject: RE: [mobile-ip] How to handle RoutingHeader Type zero > > > >From: >http://www.piuha.net/~jarkko/publications/mipv6/security-consid erations-new.txt >" >15.7 Type 2 Routing Header > >The definition of the Type 2 Routing Header is described in >Section 6.4. This definition and the associated processing >rules have been chosen so that the header can not be used for >what is traditionally viewed as source routing. In particular, >the IPv6 the Home Address in the routing header will always >have to be assigned to the home address of the receiving node. >Otherwise the packet will be dropped. > >Generally, source routing has a number of security concerns. >These include the automatic reversal of unauthenticated source >routes (which is an issue for IPv4, but not for IPv6). Another >concern is the ability to use source routing to "jump" between >nodes inside, as well as outside a firewall. These security >concerns are not issues in Mobile IPv6, due to the rules >mentioned above. > >In essence the semantics of the type 2 routing header is the >same as a special form of IP-in-IP tunneling where the inner >and outer source addresses are the same. This implies that a >device which implements filtering of packets should be able to >distinguish between a Type 2 Routing header and other Routing >headers, as required in section 8.3. This is necessary in >order to allow Mobile IPv6 traffic while still having the >option to filter out other uses of Routing headers. " > >So are you suggesting that the spec make a recommendation that MNs >MUST NOT process packets with RH type 0? > >> >> Draft 18 sections 4.1, 9.6, 11.2.3 and 14.7 explain why type >2 routing >> headers are a good idea and how they should be validated. >But the spec >> does not say what the MN must do if a RH type 0 is received >where a RH >> type 2 is expected. As I read things (strictly) a type zero with a >> LastSeg=HoA could go all the way through with less validation than a >> type 2. >> >> > From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 30 13:57: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 NAA28066 for ; Fri, 30 Aug 2002 13:57:11 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17533; Fri, 30 Aug 2002 11:54:45 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UHsUuN015249; Fri, 30 Aug 2002 10:54:44 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UHrZwf014918 for ; Fri, 30 Aug 2002 10:53:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UHrZQp014917 for mobile-ip-dist; Fri, 30 Aug 2002 10:53: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UHrTwf014910 for ; Fri, 30 Aug 2002 10:53:30 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UHreuH014981 for ; Fri, 30 Aug 2002 10:53:40 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16813 for ; Fri, 30 Aug 2002 11:53:34 -0600 (MDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA21874; Fri, 30 Aug 2002 10:53:34 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7UHrXr18831; Fri, 30 Aug 2002 10:53:33 -0700 X-mProtect: <200208301753> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.52, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd4tZBQb; Fri, 30 Aug 2002 10:53:30 PDT Message-ID: <3D6FB114.8050806@iprg.nokia.com> Date: Fri, 30 Aug 2002 10:53:24 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: "Greg O'Shea" CC: mobile ip Subject: Re: [mobile-ip] Ordering of Mobility Header 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 as far as draft 18 is concerned, it is the final header (like ICMP). if http://www.ietf.org/internet-drafts/draft-ietf-mobileip-piggyback-00.txt goes through, MH would be the last extension header. Vijay Greg O'Shea wrote: > Is there a recommended ordering of MH with respect to other header types? > From owner-mobile-ip@sunroof.eng.sun.com Fri Aug 30 18:21: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 SAA07789 for ; Fri, 30 Aug 2002 18:21:54 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24584; Fri, 30 Aug 2002 16:19:27 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7UMJ0uN022359; Fri, 30 Aug 2002 15:19:25 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UMI2wf015475 for ; Fri, 30 Aug 2002 15:18:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7UMI2ZD015474 for mobile-ip-dist; Fri, 30 Aug 2002 15:18:02 -0700 (PDT) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-mobile-ip@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7UMHuwf015467 for ; Fri, 30 Aug 2002 15:17: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 PAA00715 for ; Fri, 30 Aug 2002 15:18:06 -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 QAA13271 for ; Fri, 30 Aug 2002 16:18:05 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 13E806A905; Sat, 31 Aug 2002 01:17:55 +0300 (EEST) Message-ID: <3D6FF046.2000900@kolumbus.fi> Date: Sat, 31 Aug 2002 01:23:02 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gregos@microsoft.com Cc: Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to handle RoutingHeader Type zero References: <697DAA22C5004B4596E033803A7CEF44013EF9BD@daebe007.americas.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 Greg! The intent has been to use RH2, and only RH2, for MIPv6 (perhaps we need to remove the text about "assuming ... if no other use..."). There's an open question, however. What does this mean for RH0. Possible interpretations: (a) Orthogonal. For some other purpose, RH0 may also be used. If so, we may need some rules on how RH0 and RH2 work if they are applied together, and perhaps also some rules on home addresses appeaering in RH0. (b) Not at the same time. Forbid RH0 if RH2 appears in the packet. If for some obscure reason someone wants to use RH0, then the use of RO is not possible at the same time. (c) Not by MIPv6 MNs and CNs. Devices supporting MIPv6 CN or MN functionality may no longer support RH0 at all. (d) Deprecate. Thou shall not use RH0 at all. Personally, I think the last one is the really right action but I realize this isn't going to be agreed upon now ;-) Perhaps the second option would be the way to go. Other opinions? Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 31 02:38: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 CAA24781 for ; Sat, 31 Aug 2002 02:38:16 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00922; Fri, 30 Aug 2002 23:28:37 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7V6SHuN012950; Fri, 30 Aug 2002 23:28:35 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7V6RQwf016108 for ; Fri, 30 Aug 2002 23:27:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7V6RQ2V016107 for mobile-ip-dist; Fri, 30 Aug 2002 23:27: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7V6RKwf016100 for ; Fri, 30 Aug 2002 23:27:21 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7V6RWPG004548 for ; Fri, 30 Aug 2002 23:27:32 -0700 (PDT) Received: from shaku.sfc.wide.ad.jp (shaku.sfc.wide.ad.jp [203.178.143.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05641 for ; Sat, 31 Aug 2002 00:27:26 -0600 (MDT) Received: from [192.168.0.2] (pd33267.tkyoac00.ap.so-net.ne.jp [61.211.50.103]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.0/8.12.0) with ESMTP id g7V6R8Mb004894; Sat, 31 Aug 2002 15:27:09 +0900 Date: Sat, 31 Aug 2002 15:27:08 +0900 From: Ryuji Wakikawa To: Vijay Devarapalli Subject: Re: [mobile-ip] Ordering of Mobility Header Cc: "Greg O'Shea" , mobile ip In-Reply-To: <3D6FB114.8050806@iprg.nokia.com> References: <3D6FB114.8050806@iprg.nokia.com> Message-Id: <20020831152457.0A56.RYUJI@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.05.04 Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Vijay. How about the ordering of Mobility options. Is there any recommended ordering for options? regards, ryuji > as far as draft 18 is concerned, it is the final header (like ICMP). > > if http://www.ietf.org/internet-drafts/draft-ietf-mobileip-piggyback-00.txt > goes through, MH would be the last extension header. > > Vijay > > Greg O'Shea wrote: > > > Is there a recommended ordering of MH with respect to other header types? > > -- Ryuji Wakikawa From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 31 04:29: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 EAA28437 for ; Sat, 31 Aug 2002 04:29:46 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24024; Sat, 31 Aug 2002 01:20:25 -0700 (PDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7V8KDuN001881; Sat, 31 Aug 2002 01:20:24 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7V8Ikwf016204 for ; Sat, 31 Aug 2002 01:18:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7V8IkK1016203 for mobile-ip-dist; Sat, 31 Aug 2002 01:18: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7V8Iewf016196 for ; Sat, 31 Aug 2002 01:18:40 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7V8IouH001720 for ; Sat, 31 Aug 2002 01:18:50 -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 CAA05816 for ; Sat, 31 Aug 2002 02:18:44 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3B2B06A905; Sat, 31 Aug 2002 11:18:43 +0300 (EEST) Message-ID: <3D707D17.9080600@kolumbus.fi> Date: Sat, 31 Aug 2002 11:23:51 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020516 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Cc: Vijay Devarapalli , "Greg O'Shea" , mobile ip Subject: Re: [mobile-ip] Ordering of Mobility Header References: <3D6FB114.8050806@iprg.nokia.com> <20020831152457.0A56.RYUJI@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > How about the ordering of Mobility options. > Is there any recommended ordering for options? I don't think we have said anything about the order, i.e., any order is legal. I don't think we should recommend anything unless it would also be a mandatory fixed order. But a free order seems like the approach taken in IPv6 protocols in general, so perhaps we should stick with it here as well. Jari From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 31 09:36: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 JAA02938 for ; Sat, 31 Aug 2002 09:36:29 -0400 (EDT) Received: from engmail1mpk.Eng.Sun.COM ([129.146.1.45]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00972; Sat, 31 Aug 2002 07:31:23 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7VDV6uN016420; Sat, 31 Aug 2002 06:31:21 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VDTGwf016674 for ; Sat, 31 Aug 2002 06:29:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7VDTF9S016673 for mobile-ip-dist; Sat, 31 Aug 2002 06:29: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 engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VDTAwf016666 for ; Sat, 31 Aug 2002 06:29:10 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7VDTLuH015778 for ; Sat, 31 Aug 2002 06:29: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 HAA15217 for ; Sat, 31 Aug 2002 07:29:15 -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 g7VDT9h10425; Sat, 31 Aug 2002 15:29:09 +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 PAA01859; Sat, 31 Aug 2002 15:29: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.12.3/8.12.3) with ESMTP id g7VDT86o044083; Sat, 31 Aug 2002 15:29:09 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208311329.g7VDT86o044083@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: gregos@microsoft.com, Basavaraj.Patil@nokia.com, mobile-ip@sunroof.eng.sun.com Subject: Re: [mobile-ip] How to handle RoutingHeader Type zero In-reply-to: Your message of Sat, 31 Aug 2002 01:23:02 +0300. <3D6FF046.2000900@kolumbus.fi> Date: Sat, 31 Aug 2002 15:29: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: There's an open question, however. => no, RFC 2460 stands (RHs are processed in order). What does this mean for RH0. Possible interpretations: (a) Orthogonal. For some other purpose, RH0 may also be used. If so, we may need some rules on how RH0 and RH2 work if they are applied together, and perhaps also some rules on home addresses appeaering in RH0. (b) Not at the same time. Forbid RH0 if RH2 appears in the packet. If for some obscure reason someone wants to use RH0, then the use of RO is not possible at the same time. (c) Not by MIPv6 MNs and CNs. Devices supporting MIPv6 CN or MN functionality may no longer support RH0 at all. (d) Deprecate. Thou shall not use RH0 at all. Personally, I think the last one is the really right action but => I strongly disagree because we can need RH0 one day. So the proper action is (a) and Mobile IPv6 has nothing to specify. I realize this isn't going to be agreed upon now ;-) Perhaps the second option would be the way to go. Other opinions? => I can't see a problem with multiple RHs even this case has no usage today. So let just apply RFC 2460 which gives (a). Regards Francis.Dupont@enst-bretagne.fr From owner-mobile-ip@sunroof.eng.sun.com Sat Aug 31 11:15: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 LAA04878 for ; Sat, 31 Aug 2002 11:14:59 -0400 (EDT) Received: from engmail2sun.Eng.Sun.COM ([129.144.134.19]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16118; Sat, 31 Aug 2002 09:11:39 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7VF9qPM009195; Sat, 31 Aug 2002 08:11:37 -0700 (PDT) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VF7pwf016829 for ; Sat, 31 Aug 2002 08:07:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6/Submit) id g7VF7peu016828 for mobile-ip-dist; Sat, 31 Aug 2002 08:07: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 engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.6+Sun/8.12.6) with ESMTP id g7VF7jwf016821; Sat, 31 Aug 2002 08:07:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.2+Sun/8.12.2/ENSMAIL,v2.2) with ESMTP id g7VF7pPG009070; Sat, 31 Aug 2002 08:07:51 -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 JAA23180; Sat, 31 Aug 2002 09:07:41 -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 g7VF7bh12743; Sat, 31 Aug 2002 17:07: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 RAA02224; Sat, 31 Aug 2002 17:07: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.12.3/8.12.3) with ESMTP id g7VF7X6o044997; Sat, 31 Aug 2002 17:07:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200208311507.g7VF7X6o044997@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: itojun@iijlab.net, mrw@windriver.com, Erik.Nordmark@sun.com, kre@munnari.OZ.AU, dthaler@windows.microsoft.com, charliep@iprg.nokia.com, mobile-ip@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: [mobile-ip] RE: RFC 2462 DAD optimization In-reply-to: Your message of Tue, 27 Aug 2002 12:33:34 +0300. <200208270933.MAA18566@burp.tkv.asdf.org> Date: Sat, 31 Aug 2002 17:07:33 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-mobile-ip@sunroof.eng.sun.com Precedence: bulk List-Archive: List-Owner: List-Subscribe: List-Unsubscribe: In your previous mail you wrote: > >I'm going to ingore RFC 2710 on this point. I do not send MLD for link > >local multicast groups. > > then your device will have trouble operating on coming switches > that support MLD snooping, and it will be very difficult to > track the issue down (extraordinary support load to your colleagues). > i suggest you to follow RFC2710. => I strongly support Itojun! Please don't ignore standards just because NIBY. Francis.Dupont@enst-bretagne.fr