From mip6-bounces@ietf.org Mon Nov 1 03:21:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01997 for ; Mon, 1 Nov 2004 03:21:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COXTb-0008VL-Ux for mip6-web-archive@ietf.org; Mon, 01 Nov 2004 03:23:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COXBb-0000uq-U1; Mon, 01 Nov 2004 03:05:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COX7d-0000bj-JT for mip6@megatron.ietf.org; Mon, 01 Nov 2004 03:01:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03468 for ; Mon, 1 Nov 2004 03:00:59 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COXMU-0008OT-3h for mip6@ietf.org; Mon, 01 Nov 2004 03:16:22 -0500 Received: from iseran.local (net56-dhcp-234.sfc.keio.ac.jp [133.27.57.234]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id C67584C069; Mon, 1 Nov 2004 17:00:28 +0900 (JST) Date: Mon, 1 Nov 2004 17:03:05 +0900 From: Thierry Ernst To: mip6@ietf.org Subject: Re: [Mip6] Draft agenda of MIP6 WG meeting at IETF61 Message-Id: <20041101170305.5737d2e4.ernst@sfc.wide.ad.jp> In-Reply-To: <418211A9.4070102@clarinet.u-strasbg.fr> References: <697DAA22C5004B4596E033803A7CEF4403B1C07E@daebe007.americas.nokia.com> <418211A9.4070102@clarinet.u-strasbg.fr> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Cc: koo@comnets.uni-bremen.de, Ryuji Wakikawa , Nicolas Montavont , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Dear all, Of course, I second this. I would like to add that the ability to manage multiple interfaces is very important, particularly for mobile nodes. Now that the important work on the MIPv6 spec is behind us, I think it's the right time to bring the "multiple interfaces management" issue back on the table, before people implement non-compatible solutions. Note that the ability to manage multiple interfaces is probably the feature that would motivate the need for MIP6 (I cannot see the need to perform MIP6 between 2 WIFI hot-spots since the opportunity seldomly appear; however, I would definitely use MIP6 on a daily-base if I could switch between WIFI and 3G|AirH|B-mobile|GPRS. So, it's a good timing to question if the MIP6 working group wants to add this as a WG item. If yes, we need more thought on the problem statement and to discuss the potential interactions with the NEMO WG (cf draft-ietf-nemo-multihoming-issues). If not, we may seriously think about setting up a new WG, but I would rather leave it as a second option if the conclusion of the meeting is that MIP6 is not the right WG for it. We probably need a 10mins discussion in order to reach a conclusion (I don't think we need to discuss the motivations, the existing drafts do it already). Thierry. On Fri, 29 Oct 2004 11:47:21 +0200 Nicolas Montavont wrote: > Dear Basavaraj and folks, > > We just published a new version of our draft on Multihoming analysis in > MIPv6. You can find the new version at > http://www.ietf.org/internet-drafts/draft-montavont-mobileip-multihoming-pb-statement-02.txt > > This draft analyses the MIP6 behavior when a MN is multihomed and > classifies the different cases when a MN is multihomed. It completes the > generic draft > (http://www.ietf.org/internet-drafts/draft-ernst-generic-goals-and-benefits-00.txt) > which explains the goals and benefits we can expect from the multihoming > of host. > > It would be good to have feedback from the working group on this work. > > We would like to request a short slot to discuss the interest of the > Working Group on the multihoming. It is a long time that several drafts > deal with MIPv6 and multihoming. Our two drafts could be the starting > point to add a new item to the WG charter. These two drafts may define > the problem statement of MN multhoming. > > Once more, please don't hesitate to comment both the drafts and the > proposition to add a new item in the WG charter. > > Regards, > > Nicolas > > Basavaraj.Patil@nokia.com wrote: > > > > > > >Time and Date of WG meeting at IETF61: TBD > >Duration: 2.5 hours > > > >Agenda > >====== > > > >1. Agenda, Bluesheets, Note-takers and Jabber scribes 5 Mins > > > >2. WG status update Chairs 10 Mins > > > >3. MIP6 Operation with IKEv2 and the revised IPsec Arch. 10 Mins > > I-D: draft-ietf-mip6-ikev2-ipsec-00.txt > > Vijay Devarapalli > > > > > >4. a. Using IPsec to protect signaling between MN and CN 5 Mins > > I-D: draft-dupont-mipv6-cn-ipsec-01.txt > > b. Care-of address test procedure using a state cookie 5 Mins > > I-D: Annex of draft-dupont-mipv6-cn-ipsec-01.txt > > Francis Dupont > > > >5. MIPv6 Authorization and Configuration based on EAP 10 Mins > > I-D: draft-giaretta-mip6-authorization-eap-02.txt > > Giaretta Gerardo > > > >6. Application Master Session Key (AMSK) for Mobile IPv6 5 Mins > > I-D: draft-giaretta-mip6-amsk-00.txt > > Giaretta Gerardo > > > >7. Goals for AAA-HA interface 10 Mins > > I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt > > Giaretta Gerardo > > > >8. AAA Mobile IPv6 Application Framework 10 Mins > > I-D: draft-yegin-mip6-aaa-fwk-00.txt > > Alper Yegin > > > >9. Diameter Mobile IPv6 Bootstrapping Application using PANA 10 Mins > > I-D: draft-jee-mip6-bootstrap-pana-00.txt > > Junghoon Jee > > > >10. Mobile IPv6 Bootstrapping Architecture Using DHCP 15 Mins > > I-D: draft-ohba-mip6-boot-arch-dhcp-00 > > Yoshihiro Ohba > > > >11. Precomputable Binding Management Key Kbm for Mobile IPv6 5 Mins > > I-D: draft-ietf-mip6-precfgkbm-01.txt > > Charles Perkins > > > >12. Improvement of Return Routability Protocol 10 Mins > > I-D: draft-qiu-mip6-rr-improvement-00.txt > > Jianying ZHOU > > > > > >13. Next steps Chairs 5 Mins > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www1.ietf.org/mailman/listinfo/mip6 > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mailman-bounces@ietf.org Mon Nov 1 06:44:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19996 for ; Mon, 1 Nov 2004 06:44:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COar2-00053T-0K for mip6-web-archive@ietf.org; Mon, 01 Nov 2004 07:00:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZRU-0001gV-RX for mip6-web-archive@ietf.org; Mon, 01 Nov 2004 05:29:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: mip6-web-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:11:04 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for mip6-web-archive@ietf.org: List Password // URL ---- -------- mip6@ietf.org motoka https://www1.ietf.org/mailman/options/mip6/mip6-web-archive%40ietf.org From mip6-bounces@ietf.org Mon Nov 1 11:13:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27042 for ; Mon, 1 Nov 2004 11:13:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COf38-0002Wp-RS for mip6-web-archive@ietf.org; Mon, 01 Nov 2004 11:28:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COe6s-0004C7-8G; Mon, 01 Nov 2004 10:28:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COblC-0005uz-PX for mip6@megatron.ietf.org; Mon, 01 Nov 2004 07:58:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27816 for ; Mon, 1 Nov 2004 07:58:08 -0500 (EST) Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COc03-0006aL-Fv for mip6@ietf.org; Mon, 01 Nov 2004 08:13:35 -0500 Received: from serpens (localhost [127.0.0.1]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id iA1Cvnx07815; Mon, 1 Nov 2004 13:57:49 +0100 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host localhost [127.0.0.1] claimed to be serpens From: "Koojana Kuladinithi" To: "'Thierry Ernst'" , Subject: RE: [Mip6] Draft agenda of MIP6 WG meeting at IETF61 Date: Mon, 1 Nov 2004 15:03:32 +0100 Organization: University of Bremen Message-ID: <000301c4c01b$92d3caa0$c39b6686@SWD> 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, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal In-Reply-To: <20041101170305.5737d2e4.ernst@sfc.wide.ad.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 Content-Transfer-Encoding: 7bit Cc: =?iso-8859-1?Q?Carmelita_G=F6rg?= , cabo@informatik.uni-bremen.de, "'Ryuji Wakikawa'" , "'Nicolas Montavont'" , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Content-Transfer-Encoding: 7bit Hi all, Just to remind you all about the history of this issue: We had several discussions in mip6 ML regarding multiple interface management based on several related drafts. Later, we agreed to address this issue with a PB draft to show the possibilities of using multiple interfaces in mip6, before going in to the details of how to do it. I too agree with this (well, I "third it"). We have a few public projects in which this capability is needed. So, I too agree that the WG should think about bringing this topic up. Kind regards Koojana >-----Original Message----- >From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On >Behalf Of Thierry Ernst >Sent: Monday, November 01, 2004 9:03 AM >To: mip6@ietf.org >Cc: koo@comnets.uni-bremen.de; Ryuji Wakikawa; Nicolas >Montavont; Basavaraj.Patil@nokia.com >Subject: Re: [Mip6] Draft agenda of MIP6 WG meeting at IETF61 > > > >Dear all, > >Of course, I second this. I would like to add that the ability >to manage multiple interfaces is very important, particularly >for mobile nodes. Now that the important work on the MIPv6 >spec is behind us, I think it's the right time to bring the >"multiple interfaces management" issue back on the table, >before people implement non-compatible solutions. > >Note that the ability to manage multiple interfaces is >probably the feature that would motivate the need for MIP6 (I >cannot see the need to perform MIP6 between 2 WIFI hot-spots >since the opportunity seldomly appear; however, I would >definitely use MIP6 on a daily-base if I could switch between >WIFI and 3G|AirH|B-mobile|GPRS. > >So, it's a good timing to question if the MIP6 working group >wants to add this as a WG item. If yes, we need more thought >on the problem statement and to discuss the potential >interactions with the NEMO WG (cf >draft-ietf-nemo-multihoming-issues). If not, we may seriously >think about setting up a new WG, but I would rather leave it >as a second option if the conclusion of the meeting is that >MIP6 is not the right WG for it. > >We probably need a 10mins discussion in order to reach a >conclusion (I don't think we need to discuss the motivations, >the existing drafts do it already). > >Thierry. > >On Fri, 29 Oct 2004 11:47:21 +0200 >Nicolas Montavont wrote: > >> Dear Basavaraj and folks, >> >> We just published a new version of our draft on Multihoming analysis >> in >> MIPv6. You can find the new version at >> >http://www.ietf.org/internet-drafts/draft-montavont-mobileip-mu >ltihoming-pb-statement-02.txt >> >> This draft analyses the MIP6 behavior when a MN is multihomed and >> classifies the different cases when a MN is multihomed. It >completes the >> generic draft >> >(http://www.ietf.org/internet-drafts/draft-ernst-generic-goals- >and-benefits-00.txt) >> which explains the goals and benefits we can expect from the >multihoming >> of host. >> >> It would be good to have feedback from the working group on >this work. >> >> We would like to request a short slot to discuss the interest of the >> Working Group on the multihoming. It is a long time that >several drafts >> deal with MIPv6 and multihoming. Our two drafts could be the >starting >> point to add a new item to the WG charter. These two drafts >may define >> the problem statement of MN multhoming. >> >> Once more, please don't hesitate to comment both the drafts and the >> proposition to add a new item in the WG charter. >> >> Regards, >> >> Nicolas >> >> Basavaraj.Patil@nokia.com wrote: >> >> > >> > >> >Time and Date of WG meeting at IETF61: TBD >> >Duration: 2.5 hours >> > >> >Agenda >> >====== >> > >> >1. Agenda, Bluesheets, Note-takers and Jabber scribes 5 Mins >> > >> >2. WG status update Chairs 10 Mins >> > >> >3. MIP6 Operation with IKEv2 and the revised IPsec Arch. 10 Mins >> > I-D: draft-ietf-mip6-ikev2-ipsec-00.txt >> > Vijay Devarapalli >> > >> > >> >4. a. Using IPsec to protect signaling between MN and CN 5 Mins >> > I-D: draft-dupont-mipv6-cn-ipsec-01.txt >> > b. Care-of address test procedure using a state cookie 5 Mins >> > I-D: Annex of draft-dupont-mipv6-cn-ipsec-01.txt >> > Francis Dupont >> > >> >5. MIPv6 Authorization and Configuration based on EAP 10 Mins >> > I-D: draft-giaretta-mip6-authorization-eap-02.txt >> > Giaretta Gerardo >> > >> >6. Application Master Session Key (AMSK) for Mobile IPv6 5 Mins >> > I-D: draft-giaretta-mip6-amsk-00.txt >> > Giaretta Gerardo >> > >> >7. Goals for AAA-HA interface > 10 Mins >> > I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt >> > Giaretta Gerardo >> > >> >8. AAA Mobile IPv6 Application Framework 10 Mins >> > I-D: draft-yegin-mip6-aaa-fwk-00.txt >> > Alper Yegin >> > >> >9. Diameter Mobile IPv6 Bootstrapping Application using >PANA 10 Mins >> > I-D: draft-jee-mip6-bootstrap-pana-00.txt >> > Junghoon Jee >> > >> >10. Mobile IPv6 Bootstrapping Architecture Using DHCP > 15 Mins >> > I-D: draft-ohba-mip6-boot-arch-dhcp-00 >> > Yoshihiro Ohba >> > >> >11. Precomputable Binding Management Key Kbm for Mobile IPv6 5 Mins >> > I-D: draft-ietf-mip6-precfgkbm-01.txt >> > Charles Perkins >> > >> >12. Improvement of Return Routability Protocol > 10 Mins >> > I-D: draft-qiu-mip6-rr-improvement-00.txt >> > Jianying ZHOU >> > >> > >> >13. Next steps Chairs > 5 Mins >> > >> >_______________________________________________ >> >Mip6 mailing list >> >Mip6@ietf.org >> >https://www1.ietf.org/mailman/listinfo/mip6 >> > >> > >> > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 1 13:44:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16831 for ; Mon, 1 Nov 2004 13:44:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COhOr-00080d-B8 for mip6-web-archive@ietf.org; Mon, 01 Nov 2004 13:59:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COgog-0007e2-14; Mon, 01 Nov 2004 13:22:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COgUg-0003oN-Am for mip6@megatron.ietf.org; Mon, 01 Nov 2004 13:01:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10365 for ; Mon, 1 Nov 2004 13:01:24 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COgjc-00061V-25 for mip6@ietf.org; Mon, 01 Nov 2004 13:16:53 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iA1I0RQ32620; Mon, 1 Nov 2004 19:00:27 +0100 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 iA1I0RSj053188; Mon, 1 Nov 2004 19:00:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411011800.iA1I0RSj053188@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" Subject: Re: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt In-reply-to: Your message of Mon, 25 Oct 2004 09:58:30 PDT. <012c01c4bab3$de4606a0$656115ac@dcml.docomolabsusa.com> Date: Mon, 01 Nov 2004 19:00:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Giaretta Gerardo , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 In your previous mail you wrote: >BTW, do you think we need in the MN-AAA interface a mechanism to >negotiate the IKE version to be used between MN and HA? Hmm, not sure. What does IKE itself provide? => the right thing! If there's adequate support in IKE for version handling, then I think it isn't necessary. On the other hand, the HA might support both and might want to control which one is used by specific kinds of MNs. BTW, I believe many IKEv1 implementations also provide address assignment, though it is not part of the base specification. => this is worse than not to be a part: the extension was explicitly rejected (not for itself but for its companion XAUTH). So just telling the MN to use IKE address assignment probably isn't enough to determine whether IKEv1 or IKEv2 is used. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 1 19:47:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27307 for ; Mon, 1 Nov 2004 19:47:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COn54-000294-7B for mip6-web-archive@ietf.org; Mon, 01 Nov 2004 20:03:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COmmi-0003Oa-Er; Mon, 01 Nov 2004 19:44:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COmYy-00084Z-8T for mip6@megatron.ietf.org; Mon, 01 Nov 2004 19:30:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26221 for ; Mon, 1 Nov 2004 19:30:13 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COmny-0001nh-1J for mip6@ietf.org; Mon, 01 Nov 2004 19:45:46 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6J00JX101IUH@mailout2.samsung.com> for mip6@ietf.org; Tue, 02 Nov 2004 09:29:42 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6I000X9ZZ08X@mailout2.samsung.com> for mip6@ietf.org; Tue, 02 Nov 2004 09:28:13 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6I008GEZYYDY@mmp2.samsung.com> for mip6@ietf.org; Tue, 02 Nov 2004 09:28:11 +0900 (KST) Date: Mon, 01 Nov 2004 16:28:09 -0800 From: Alper Yegin To: mip6@ietf.org Message-id: <00c301c4c072$d58a6c80$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7BIT Subject: [Mip6] Comments on ohba-mip6-boot-arch-dhcp X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7BIT Hello, I just read draft-ohba-mip6-boot-arch-dhcp-00.txt. Please see below for my comments and questions. - Is authenticated DHCP a necessary component of this solution, or another problem (bootstrapping RFC3118) solved by the overall solution? If it is the latter, separating the problems/solutions would simplify the reading, imo. - As I understand the functionality of AAA-MS is to bring in the HA/HoA information to the access network. What would be the drawback of performing that functionality via AAA-NA? I know this is mentioned once in the document, but can't we always do that? - The document is referring to an interface between the AAA-MS and HA: When the home agent receives an authentication request message (e.g., an IKE_SA_INIT request message in IKEv2) from the mobile node, it requests IKE credentials such as a symmetric key to the AAA server. Alternatively, the AAA server may send the IKE credentials to the home agent before the home agent receives the authentication request message. yegin-mip6-aaa-fwk aims at such an interface (though, only the "pull" variant). I was wondering what the authors were thinking for handling that interface. This has a different functionality than the AAA-MS protocol defined in this document. Thanks in advance. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 1 20:51:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02049 for ; Mon, 1 Nov 2004 20:51:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COo55-0003PT-K5 for mip6-web-archive@ietf.org; Mon, 01 Nov 2004 21:07:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnUX-000841-Jz; Mon, 01 Nov 2004 20:29:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnQM-000596-4H for mip6@megatron.ietf.org; Mon, 01 Nov 2004 20:25:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29819 for ; Mon, 1 Nov 2004 20:25:22 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COnfM-0002pU-4G for mip6@ietf.org; Mon, 01 Nov 2004 20:40:56 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6J0042H2LGIT@mailout3.samsung.com> for mip6@ietf.org; Tue, 02 Nov 2004 10:24:52 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6J00MU32HVFE@mailout3.samsung.com> for mip6@ietf.org; Tue, 02 Nov 2004 10:22:43 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6J0080U2HTMQ@mmp2.samsung.com> for mip6@ietf.org; Tue, 02 Nov 2004 10:22:43 +0900 (KST) Date: Mon, 01 Nov 2004 17:22:41 -0800 From: Alper Yegin To: mip6@ietf.org Message-id: <00d001c4c07a$73692430$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7BIT Subject: [Mip6] Comments on jee-mip6-bootstrap-pana X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7BIT Hello, Here are some comments and questions on the draft-jee-mip6-bootstrap-pana-00.txt. - I see the new Diameter application has two functionalities. Regarding the delivery of the bootstrapping information to the MN, I was wondering if we could get away with not defining new commands, but instead piggybacking on existing NAS application? The bootstrapping information could be delivered to the NAS as part of the mobile's profile. - The other functionality is the push of bootstrapping information from AAAh to HA. This is carried in serial with the (in fact, in the middle of) network access AAA. I think it could be done in parallel, or even after the network access AAA. If you use a pull model instead of the push, this part gets aligned with the yegin-mip6-aaa-fwk. - I didn't quite understand how the MN obtains/computes the MIPv6-AAA-Key. It is only provided with the MIPv6-AAA-Key-Id, and that's not sufficient to derive the key. Thanks in advance. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 1 21:49:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05876 for ; Mon, 1 Nov 2004 21:49:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COoyQ-0004aH-5L for mip6-web-archive@ietf.org; Mon, 01 Nov 2004 22:04:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COoSt-0002yq-GM; Mon, 01 Nov 2004 21:32:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COoG0-00063P-Ov for mip6@megatron.ietf.org; Mon, 01 Nov 2004 21:18:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04341 for ; Mon, 1 Nov 2004 21:18:45 -0500 (EST) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COoV1-00041e-GJ for mip6@ietf.org; Mon, 01 Nov 2004 21:34:20 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id iA22Icbv028257; Tue, 2 Nov 2004 11:18:38 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id iA22IcLu012930; Tue, 2 Nov 2004 11:18:38 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA12929 ; Tue, 2 Nov 2004 11:18:38 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id LAA03118; Tue, 2 Nov 2004 11:18:37 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id iA22Ibr7006370; Tue, 2 Nov 2004 11:18:37 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id iA22IauY022273; Tue, 2 Nov 2004 11:18:36 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0I6J002VQ52XQN@tsbpo1.po.toshiba.co.jp>; Tue, 2 Nov 2004 11:18:36 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1COkpC-0003Wz-00; Mon, 01 Nov 2004 14:38:54 -0800 Date: Mon, 01 Nov 2004 17:38:54 -0500 From: Yoshihiro Ohba Subject: Re: [Mip6] Comments on ohba-mip6-boot-arch-dhcp In-reply-to: <00c301c4c072$d58a6c80$291d9069@sisa.samsung.com> To: Alper Yegin Message-id: <20041101223854.GP2224@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: <00c301c4c072$d58a6c80$291d9069@sisa.samsung.com> X-Spam-Score: 0.7 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Hi Alper, Thank you for reading the draft and sending the comments. Please see my comments below. On Mon, Nov 01, 2004 at 04:28:09PM -0800, Alper Yegin wrote: > Hello, > > I just read draft-ohba-mip6-boot-arch-dhcp-00.txt. Please see below for > my comments and questions. > > - Is authenticated DHCP a necessary component of this solution, or > another problem (bootstrapping RFC3118) solved by the overall solution? > If it is the latter, separating the problems/solutions would simplify > the reading, imo. I think we could separate authenticated DHCP from this solution. Thank you very much for your insight. > > - As I understand the functionality of AAA-MS is to bring in the HA/HoA > information to the access network. What would be the drawback of > performing that functionality via AAA-NA? I know this is mentioned once > in the document, but can't we always do that? In some case, the home address may be updated to another one during the mobile node's authorization lifetime for network access. In such a case, it might be good if AAA-MS is not always performed via AAA-NA. If there is some need on such a scenario we would think more about it in the next revision. > > - The document is referring to an interface between the AAA-MS and HA: > > When the home agent receives an authentication request message > (e.g., an IKE_SA_INIT request message in IKEv2) from the mobile > node, it requests IKE credentials such as a symmetric key to the > AAA server. Alternatively, the AAA server may send the IKE > credentials to the home agent before the home agent receives the > authentication request message. > > yegin-mip6-aaa-fwk aims at such an interface (though, only the "pull" > variant). I was wondering what the authors were thinking for handling > that interface. This has a different functionality than the AAA-MS > protocol defined in this document. Good point. I agree with you that there is some difference between draft-ohba-mip6-boot-arch-dhcp and draft-yegin-mip6-aaa-fwk in the interface between HA and AAA-MS server. As far as I understand, the difference is as to when authentication to derive the IKE credentials occurs. In draft-yegin-mip6-aaa-fw, authentication to derive the IKE credentials occurs during AAA-MS procedure. In draft-ohba-mip6-boot-arch-dhcp, authentication to derive the IKE credentials occurs during AAA-NA procedure. > > Thanks in advance. Thank you, Yoshihiro Ohba > > Alper > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 1 23:00:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21824 for ; Mon, 1 Nov 2004 23:00:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COq58-00066R-Vj for mip6-web-archive@ietf.org; Mon, 01 Nov 2004 23:15:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COper-0002Fz-4a; Mon, 01 Nov 2004 22:48:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COpdL-0001PJ-Re for mip6@megatron.ietf.org; Mon, 01 Nov 2004 22:46:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21217 for ; Mon, 1 Nov 2004 22:46:58 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COpsM-0005sK-UR for mip6@ietf.org; Mon, 01 Nov 2004 23:02:32 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA23ktl10422 for ; Tue, 2 Nov 2004 05:46:55 +0200 (EET) X-Scanned: Tue, 2 Nov 2004 05:46:57 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA23kvb3032674 for ; Tue, 2 Nov 2004 05:46:57 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00oy91db; Tue, 02 Nov 2004 05:46:55 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA23kUS07935 for ; Tue, 2 Nov 2004 05:46:30 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 21:46:29 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Nov 2004 21:46:29 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C0B5@daebe007.americas.nokia.com> Thread-Topic: MIP6 meeting at IETF61: Update Thread-Index: AcTAjofpMsI9rCpNTzKdpo2ov/OkPw== To: X-OriginalArrivalTime: 02 Nov 2004 03:46:29.0921 (UTC) FILETIME=[8992E110:01C4C08E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Subject: [Mip6] MIP6 meeting at IETF61: Update X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Hello, As per the current agenda published at = http://ietf.org/meetings/agenda_61.html MIP6 is scheduled to meet on Friday (Nov 12th) from 9 to 1130 AM.=20 We have requested that the meeting be moved to an earlier day in the = week. It is likely that the MIP6 meeting will be moved to Monday, Nov 8th from 7.30 to 10 PM.=20 -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 1 23:10:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22458 for ; Mon, 1 Nov 2004 23:10:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COqF3-0006GK-GK for mip6-web-archive@ietf.org; Mon, 01 Nov 2004 23:25:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COpso-0005lU-Br; Mon, 01 Nov 2004 23:02:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COpfF-0002OS-PC for mip6@megatron.ietf.org; Mon, 01 Nov 2004 22:48:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21307 for ; Mon, 1 Nov 2004 22:48:56 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COpuH-0005ua-Oa for mip6@ietf.org; Mon, 01 Nov 2004 23:04:30 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA23mtl13818 for ; Tue, 2 Nov 2004 05:48:55 +0200 (EET) X-Scanned: Tue, 2 Nov 2004 05:48:44 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA23miix006468 for ; Tue, 2 Nov 2004 05:48:44 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 006xsK2m; Tue, 02 Nov 2004 05:48:44 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA23mJS08650 for ; Tue, 2 Nov 2004 05:48:20 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 1 Nov 2004 21:48:19 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 1 Nov 2004 21:48:18 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C0B6@daebe007.americas.nokia.com> Thread-Topic: MIP6 meeting at IETF61: Revised agenda Thread-Index: AcTAjsnSJr2rLRlcSouIc1LDeOKL6g== To: X-OriginalArrivalTime: 02 Nov 2004 03:48:19.0355 (UTC) FILETIME=[CACD2EB0:01C4C08E] X-Spam-Score: 0.3 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] MIP6 meeting at IETF61: Revised agenda X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Mobility for IPv6 (mip6) - Rev 1 =20 Time and Date of WG meeting at IETF61: Currently scheduled for Friday Nov 12th from 9 AM to 1130 AM. Likelihood of being moved to Monday, Nov 8th from 730 PM to 1000 PM. Duration: 2.5 hours Agenda =3D=3D=3D=3D=3D=3D 1. Agenda, Bluesheets, Note-takers and Jabber scribes 5 Mins 2. WG status update Chairs 10 Mins 3. MIP6 Operation with IKEv2 and the revised IPsec Arch. 20 Mins I-D: draft-ietf-mip6-ikev2-ipsec-00.txt Vijay Devarapalli 4. a. Using IPsec to protect signaling between MN and CN 5 Mins I-D: draft-dupont-mipv6-cn-ipsec-01.txt b. Care-of address test procedure using a state cookie 5 Mins I-D: Annex of draft-dupont-mipv6-cn-ipsec-01.txt Francis Dupont 5. AAA Mobile IPv6 Application Framework 10 Mins I-D: draft-yegin-mip6-aaa-fwk-00.txt Alper Yegin 6. Goals for AAA-HA interface 10 Mins I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt Giaretta Gerardo 7. MIPv6 Authorization and Configuration based on EAP 10 Mins I-D: draft-giaretta-mip6-authorization-eap-02.txt Giaretta Gerardo =20 8. Application Master Session Key (AMSK) for Mobile IPv6 5 Mins I-D: draft-giaretta-mip6-amsk-00.txt Giaretta Gerardo =20 9. Diameter Mobile IPv6 Bootstrapping Application using PANA 10 Mins I-D: draft-jee-mip6-bootstrap-pana-00.txt Junghoon Jee =20 10. Mobile IPv6 Bootstrapping Architecture Using DHCP 15 Mins I-D: draft-ohba-mip6-boot-arch-dhcp-00 Yoshihiro Ohba 11. Bootstrap Control Function mechanism for Mobile IPv6 Bootstrap 10 = Mins I-D: draft-deng-mip6-bootstrap-bcf-00.txt Hui Deng 12. Precomputable Binding Management Key Kbm for Mobile IPv6 5 Mins I-D: draft-ietf-mip6-precfgkbm-01.txt Charles Perkins 13. Improvement of Return Routability Protocol 10 Mins I-D: draft-qiu-mip6-rr-improvement-00.txt Jianying ZHOU 13. Next steps Chairs 5 Mins Time permitting, we will discuss these IDs and interest in this work: a. Multihoming in MIP6 I-Ds: draft-montavont-mobileip-multihoming-pb-statement-02.txt draft-ernst-generic-goals-and-benefits-00.txt Nicolas Montavont b. Load Balance for Distributed Home Agents in Mobile IPv6 I-D: draft-deng-mip6-ha-loadbalance-02.txt Hui Deng =20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 2 03:06:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24384 for ; Tue, 2 Nov 2004 03:06:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COtvk-0002u8-Er for mip6-web-archive@ietf.org; Tue, 02 Nov 2004 03:22:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COta2-0005yJ-G1; Tue, 02 Nov 2004 02:59:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COtVN-0003z6-7X for mip6@megatron.ietf.org; Tue, 02 Nov 2004 02:55:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23355 for ; Tue, 2 Nov 2004 02:55:00 -0500 (EST) Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27] helo=i2r.a-star.edu.sg) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COtkQ-0002fm-K2 for mip6@ietf.org; Tue, 02 Nov 2004 03:10:35 -0500 Received: from newmailhost (localhost [127.0.0.1]) by i2r.a-star.edu.sg (8.12.10/8.12.10) with ESMTP id iA27smCE011704 for ; Tue, 2 Nov 2004 15:54:48 +0800 (SGT) Received: from i2r.a-star.edu.sg ([192.168.137.229]) by mailhost.lit.org.sg (iPlanet Messaging Server 5.2 Patch 1 (built Aug 19 2002)) with ESMTP id <0I6J0084YKNJHF@mailhost.lit.org.sg> for mip6@ietf.org; Tue, 02 Nov 2004 15:54:55 +0800 (SGT) Date: Tue, 02 Nov 2004 15:56:22 +0800 From: Jianying Zhou Subject: Re: [Mip6] RR protocol To: Christian Vogt Message-id: <41873DA6.8030103@i2r.a-star.edu.sg> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 References: <4148080E.10009@i2r.a-star.edu.sg> <41481E0B.6000904@kolumbus.fi> <417FB0DA.80207@tm.uka.de> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7BIT Cc: Jari Arkko , qiuying@i2r.a-star.edu.sg, robertdeng@smu.edu.sg, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7BIT Hi, Christian, Thank you very much for your comments. Our feedback is as follows. > My first comment is on movement-halting attacks (section 3.2). I agree > that an attack like this is possible. Actually, this is what [2] calls > a "time-shift attack": get a token at one time and use it at another > time. Note that the movement-halting attack can be even simpler than > the one you describe in your draft. Since you assume that the MN moves > rapidly enough such that the previous Care-of Keygen Token is still > valid when the MN is at its new place, it wouldn't surprise if the > previous Home Keygen Token is still fresh as well. So, the attacker > could even use both tokens from the previous RR in order to redirect > the MN's packet back to the old CoA. Note that this attack is simpler > for the attacker to accomplish than the attack in your draft: Here, > the attacker does not need to follow the MN to the new location. In > your draft, it needs to. =========== It depends on how the attacker is positioned. If the attacker can intercept both HoT and CoT in a single RR session, your attack on the original RR protocol works. (However, based on the RR design assumption, it occurs less likely.) In our attacking scenario, the attacker could intercept HoT and CoT in different RR sessions. Our improvement prevents the attack in both your scenario and our our scenario. HoT and CoT are all linked to specific HoA and CoA, and they cannot be used to forge valid binding updates with other HoA and CoA. (Note CN will use HoA and CoA etc. to re-calculate KTh and KTc.) ========= > Second, traffic-permutation attacks. This kind of attack is > interesting. It's a variation of the attack where the perpetrator > redirects a MN's (or a stationary node's) packets to a random IP > address (section 3.1.5 of [2]). But note that it is well-known that RR > is vulnerable to an attacker inside the CN's network (more precisely: > somewhere on the intersection of all paths between the CN and one of > the victims). The attacker can impersonate any other node in this > position, and it can redirect other nodes' packets to any IP address. > One way of doing this is the method you describe in your draft. > (Although I don't quite understand why the CN would accept a spoofed > Binding Update only with probability 1/4. The probability should be > 1.0 unless you consider things like nonce-lifetime expiration...) ========= If an attacker uses CoA_i and CoA_j, or HoA_i and HoA_j, or HoA_i and CoA_j (in this order) to generate MACbu, the attack will fail. As the attacker will select them randomly, the probability of success to forge a valid binding update is 1/4, that is only using CoA_i and HoA_j. (CN will use this ordered information to re-calculate KTc and KTh in binding update verification.) With our improvement, the traffic-permutation attack could be prevented. ========= > Ok, my last comment is on your improvement proposal. Your > argumentation is interesting, but I am not sure about the benefit your > proposal has. Consider that, at some point, an attacker must do > something actively. There is no passive attack against the RR except > dropping messages. And we know that RR is vulnerable to an attacker on > the path between the CN and the MN's HA (section 3.1.1 of [2]). In > this position, the attacker can send its own HoTI with the victim's > HoA (and, if we apply your proposed improvement, with a CoA that the > attacker chooses). Due to its position, the attacker can intercept the > HoT. The attacker would then send a CoTI, again with the victim's HoA > (and, if we follow your proposal, the chosen CoA). The attacker must > send the CoTI from a place where it can intercept the CoT. This attack > is possible in the RR as defined in RFC 3775, and it is still possible > with your approach. ========= If MN has bound CoA in HoT, then even if the attacker is on the path between the CN and the MN's HA and intercepts HoT, and further intercepts CoT on the path between the CN and CoA path, the attack still does not work. The same reason as explained in response to your first comment. (Note again, HoT, CoT, HoA, CoA are all linked in our improvement, any change of them will invalidate the binding update verification process.) ========= > I might be missing something. If so, don't hesitate to tell me. ;-) > > Bye, see you in Washington D.C... Look forward to seeing you in Washington DC next week. Cheers. Jianying > - Christian > > > [1] Improvement of Return Routability Protocol > draft-qiu-mip6-rr-improvement-00.txt > > [2] Mobile IP version 6 Route Optimization Security Design Background > draft-ietf-mip6-ro-sec-02.txt > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 2 03:25:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25728 for ; Tue, 2 Nov 2004 03:25:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COuDi-0003H0-LR for mip6-web-archive@ietf.org; Tue, 02 Nov 2004 03:40:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COtw6-0006Rt-68; Tue, 02 Nov 2004 03:22:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COtkt-0002by-G7 for mip6@megatron.ietf.org; Tue, 02 Nov 2004 03:11:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24837 for ; Tue, 2 Nov 2004 03:11:02 -0500 (EST) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COtzx-0002zJ-H2 for mip6@ietf.org; Tue, 02 Nov 2004 03:26:38 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0I6J00E7UKYLD5@dns2.cselt.it> for mip6@ietf.org; Tue, 02 Nov 2004 09:01:33 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 02 Nov 2004 09:07:28 +0100 Date: Tue, 02 Nov 2004 09:09:30 +0100 From: Giaretta Gerardo Subject: RE: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt To: James Kempf Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt thread-index: AcS7gfWN94fxK+JbSYSUNWvb+iuK4QC2fGJw Content-Class: urn:content-classes:message X-OriginalArrivalTime: 02 Nov 2004 08:07:28.0718 (UTC) FILETIME=[FEF1AEE0:01C4C0B2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable Hi James, see below... >=20 > I think that this approach would be very useful if the IPsec SA can be > bootstrapped using certs (i.e. there is a certification path=20 > between the > MN and the HA of the foreign domain). In case pre-shared key > authentication is used, who is going to generate the PSK and=20 > deliver it > to MN and HA? >=20 > jak>>> Agree certs are the most likely candidate, but the=20 > AAA-H could push a > preshared key to the AAA-F. This is less secure than using certs w. DH > however, and probably to be discouraged. If it is used at=20 > all, the AAA-H > would probably derive a key from the preshared key and push=20 > that, and the MN > would probably use the same kind of derivation. The kind of=20 > situation I > would expect this to be used is when the network operator has=20 > a bunch of > subsidiaries that run their own AAA servers for distributed processing > rather than centralizing everything. I think it would be less=20 > useful between > operators, since there's more risk of compromise. > I agree it would be less useful in a scenario between operators. However, I don't clearly understand the scenario you described: do the subsidiaries' AAA servers authenticate the users or simply act as AAA proxies? In the former case, how can they authenticate them? Do they have a copy of users' credentials? Are the users' credentials distributed by the central AAA server to all subsidiaries' AAA servers?=20 =20 > > > > > Section 8.3: I would like a flag here indicating to the MN > > > that it should > > > derive its HoA from IKEv2. > > > > > > > >This could be an interesting extension. > > > > > >BTW, do you think we need in the MN-AAA interface a mechanism to > > >negotiate the IKE version to be used between MN and HA? > > > > Hmm, not sure. What does IKE itself provide? If there's > > adequate support in > > IKE for version handling, then I think it isn't necessary. On > > the other > > hand, the HA might support both and might want to control > > which one is used > > by specific kinds of MNs. > > > > BTW, I believe many IKEv1 implementations also provide > > address assignment, > > though it is not part of the base specification. So just > > telling the MN to > > use IKE address assignment probably isn't enough to determine > > whether IKEv1 > > or IKEv2 is used. > > >=20 > This is what I had in mind: does the AAAH need to know if a=20 > specific MN > supports IKEv1 or IKEv2 or both? > Consider a scenario where some HAs support only IKEv1 and some others > support IKEv2. In this situation, in order to allocate an appropriate > HA, the AAAH must know during the MIPv6 bootstrapping=20 > negotiation which > version of IKE the MN supports. Do you think this is a meaningful > scenario? >=20 > jak>>> Yes, it might occur. But if IKE provides adequate handling of > versions, I don't see that anything would be needed in the=20 > EAP exchange. For > the EAP exchange to indicate IKE address assignment if the HA supports > IKEv1, however, the AAA server has to know if the IKEv1 implementation > supports an unstandardized IKEv1 address assignment option. >=20 I agree: a negotiation about dyamic address assignment is needed even if IKEv1 is used. Moreover, I wonder whether the MN must declare its capabilities (i.e. which version of IKE it supports): what happens if the MN supports only IKEv1 and the HA only IKEv2? Or do you think this scenario is not feasible since the HA is expected to support both IKEv1 and IKEv2? >=20 > > >If the negotiation fails, there will not be the > > >Authorization-Lifetime-AVP. > > >So it may be better not to combine the two options. What do > > you think? > > > > If the negotiation fails, then presumably there will be a > > Status option > > indicating that, and the lifetime can be set to zero. > > Combining the two > > avoids the overhead of an additional type and length. > > >=20 > Ok, I get your point. Maybe the termination of the=20 > negotiation procedure > can be improved. >=20 > A possible change could be: > - leave the Negotiation-Result-TLV as is for the=20 > communication from the > MN to the AAAH. This TLV is used by the MN to tell the AAAH whether it > accepts or not the proposed configuration. > - change the format (and maybe also the name) of the > Authorization-Lifetime-TLV in a way that it includes a Status field. > This is used in the communication from the AAAH to the MN. >=20 > jak>>> OK, that would work. It was not clear to me from the=20 > document that > the Negotiation-Result-TLV also originated at the MN. Is=20 > there a need for > the MN to indicate a status? The protocol seems more like the=20 > AAA server > pushing stuff to the MN, so it's kind of take it or leave it=20 > from the MN's > view, unless I'm missing something. >=20 In the EAP negotiation phase the MN can ask for particular service options, for example the allocation of the HA in the foreign domain. If the AAAH cannot provide some options requested by the MN, it must be possibile for the MN to reject the MIPv6 parameters proposed by the AAAH (i.e. it is not interested in a HA in the home domain but only in a HA in the foreign domain) and not to activate MIPv6 service. This is the reason for the MN to send the Negotiation-Result-TLV. Maybe this could be better explained in the document. Regards, --Gerardo > jak >=20 >=20 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 2 10:47:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02764 for ; Tue, 2 Nov 2004 10:47:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP17Y-0004kz-H3 for mip6-web-archive@ietf.org; Tue, 02 Nov 2004 11:02:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0i0-00081B-2R; Tue, 02 Nov 2004 10:36:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP0Rz-0008A9-3y for mip6@megatron.ietf.org; Tue, 02 Nov 2004 10:19:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29848 for ; Tue, 2 Nov 2004 10:19:57 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP0h6-0003zg-Dt for mip6@ietf.org; Tue, 02 Nov 2004 10:35:37 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2FJte10464 for ; Tue, 2 Nov 2004 17:19:55 +0200 (EET) X-Scanned: Tue, 2 Nov 2004 17:19:38 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA2FJc4G021196 for ; Tue, 2 Nov 2004 17:19:38 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00c4qZOs; Tue, 02 Nov 2004 17:19:37 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2FJaa08591 for ; Tue, 2 Nov 2004 17:19:36 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 09:19:02 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Nov 2004 09:19:02 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C0C8@daebe007.americas.nokia.com> Thread-Topic: MIP6 meeting on Friday, Nov 12 at IETF61 Thread-Index: AcTA70gEor4MKbfrRumHw0tOVoT+qA== To: X-OriginalArrivalTime: 02 Nov 2004 15:19:03.0056 (UTC) FILETIME=[492C1900:01C4C0EF] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Subject: [Mip6] MIP6 meeting on Friday, Nov 12 at IETF61 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Hello, Just an update. The MIP6 meeting will be on Friday morning, Nov 12th as scheduled at IETF61. The plan to move it to Monday has been dropped. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 2 13:12:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23132 for ; Tue, 2 Nov 2004 13:12:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP3Nu-00011C-SI for mip6-web-archive@ietf.org; Tue, 02 Nov 2004 13:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2v9-0001x8-9M; Tue, 02 Nov 2004 12:58:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2iN-0003WH-6R for mip6@megatron.ietf.org; Tue, 02 Nov 2004 12:45:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16507 for ; Tue, 2 Nov 2004 12:45:00 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP2xV-0008Eo-Jo for mip6@ietf.org; Tue, 02 Nov 2004 13:00:43 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2Hix317216 for ; Tue, 2 Nov 2004 19:44:59 +0200 (EET) X-Scanned: Tue, 2 Nov 2004 19:44:40 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iA2HieF3007091 for ; Tue, 2 Nov 2004 19:44:40 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00sAWM44; Tue, 02 Nov 2004 19:44:39 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2HiXa15571 for ; Tue, 2 Nov 2004 19:44:33 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 11:43:58 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Nov 2004 11:43:58 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C0D0@daebe007.americas.nokia.com> Thread-Topic: Comments on I-D draft-yegin-mip6-aaa-fwk-00 Thread-Index: AcTBA4fnM/fvO0cTQJyXXTtRnsbF+A== To: X-OriginalArrivalTime: 02 Nov 2004 17:43:58.0813 (UTC) FILETIME=[883F50D0:01C4C103] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Comments on I-D draft-yegin-mip6-aaa-fwk-00 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable 1. "In the presence of multiple HAs on a home subnet, reliance on pre-configuration increases the network management overhead." Using IKE, you can establish an SA with any HA on the home subnet. The keys or cert used in IKE/IPsec can be on some LDAP server shared by the HAs. You dont really have to pre-configure every HA. It depends on your deployment. However I do agree that using AAA for authentication/authorization in MIP6 deployemnt scenarios is useful. 2.=20 " The current Mobile IPv6 design relies on use of IPsec for authentication of protocol signaling between the MN and the HA. The associated IPsec SA is created by running IKE [RFC3776] between the two. The initial authentication and authorization of MN and HA should be performed during the IKE execution. This is where HA must consult the AAA infrastructure. " With IKEv2, dont you think it is possible that there could be AAA interaction in the backend (HA-AAA). Hence MIP6/HA really does not have to do anything to enable the establishment of an IPsec SA. I dont know if the IKEv2 I-D (MIP6) covers this scenario. 3. W.r.t accounting, I dont think you can rely entirely on the HA. Of course it depends on whether your accounting is based on time vs amount of data. If the MN is capable of RO, then you cannot generate charging data based on data volumes.=20 4. After reading the I-D, I am not so sure that we are talking about a AAA framework here. The I-D proposes the need for an HA-AAA interface that enables an MN to be authenticated and aithorized for MIP6 service. Additionally this interface is also used for charging.=20 I think a AAA framework for MIP6 should also include the ability to bootstrap. You do mention it in the I-D, but this should be integral to the I-D as well.=20 >From the perspective of the MIP6 WG, I think we need to identify the AAA requirements and define a new AAA application, AVPs or extensions in the AAA and Radext WGs.=20 -Basavaraj =20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 2 13:26:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25071 for ; Tue, 2 Nov 2004 13:26:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP3c4-0001Ri-Nf for mip6-web-archive@ietf.org; Tue, 02 Nov 2004 13:42:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2zk-00051G-6D; Tue, 02 Nov 2004 13:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP2rb-0007wS-B8 for mip6@megatron.ietf.org; Tue, 02 Nov 2004 12:54:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17596 for ; Tue, 2 Nov 2004 12:54:32 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP36j-00004q-Nq for mip6@ietf.org; Tue, 02 Nov 2004 13:10:15 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2HsVe28936 for ; Tue, 2 Nov 2004 19:54:31 +0200 (EET) X-Scanned: Tue, 2 Nov 2004 19:54:16 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iA2HsGdZ016012 for ; Tue, 2 Nov 2004 19:54:16 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 005xcWvG; Tue, 02 Nov 2004 19:54:15 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA2HsES12440 for ; Tue, 2 Nov 2004 19:54:14 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 2 Nov 2004 11:54:12 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 Nov 2004 11:54:12 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C0D1@daebe007.americas.nokia.com> Thread-Topic: Comments on I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt Thread-Index: AcTBBPVfRGok2/CaSHSjfKZQtnXfng== To: X-OriginalArrivalTime: 02 Nov 2004 17:54:12.0918 (UTC) FILETIME=[F6484D60:01C4C104] X-Spam-Score: 0.3 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Comments on I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable The I-D captures quite well the reasons for an HA-AAA interface. I believe Alper's I-D draft-yegin-mip6-aaa-fwk-00 is essentially proposing the same.=20 This I-D can be used as the primary vehicle for communicating with the AAA WGs (AAA/Radext) in order to ensure that the requirements are met by either defining a new AAA application or defining new attributes as needed. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 2 15:08:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05012 for ; Tue, 2 Nov 2004 15:08:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5C9-0003vU-EO for mip6-web-archive@ietf.org; Tue, 02 Nov 2004 15:23:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4nt-0002MC-Jk; Tue, 02 Nov 2004 14:58:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4df-00069T-VR for mip6@megatron.ietf.org; Tue, 02 Nov 2004 14:48:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02930 for ; Tue, 2 Nov 2004 14:48:17 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP4sp-0003RK-Hl for mip6@ietf.org; Tue, 02 Nov 2004 15:04:00 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6K00D01HNMUQ@mailout2.samsung.com> for mip6@ietf.org; Wed, 03 Nov 2004 04:47:46 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6K00JGGHNLF0@mailout2.samsung.com> for mip6@ietf.org; Wed, 03 Nov 2004 04:47:45 +0900 (KST) Received: from Alperyegin ([105.253.155.20]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I6K00HGUHNI1Z@mmp1.samsung.com> for mip6@ietf.org; Wed, 03 Nov 2004 04:47:45 +0900 (KST) Date: Tue, 02 Nov 2004 11:47:41 -0800 From: Alper Yegin Subject: RE: [Mip6] Comments on I-D draft-yegin-mip6-aaa-fwk-00 In-reply-to: <697DAA22C5004B4596E033803A7CEF4403B1C0D0@daebe007.americas.nokia.com> To: Basavaraj.Patil@nokia.com, mip6@ietf.org Message-id: <000001c4c114$d22d3020$6901a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7BIT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7BIT Hi Raj, Thank you for reading the I-D and the feedback. > 1. > "In the presence of multiple HAs on a home subnet, reliance on > pre-configuration increases the network management overhead." > > Using IKE, you can establish an SA with any HA on the home subnet. The > keys or cert used in IKE/IPsec can be on some LDAP server shared by > the HAs. You dont really have to pre-configure every HA. It depends on > your deployment. Sure, LDAP can be used between the HA and a centralized server. Whether it is LDAP or a AAA protocol, we'd need to define what is carried, protocol flow, etc. So, yes, LDAP can be another way to achieve the same/similar effect. > However I do agree that using AAA for authentication/authorization in > MIP6 deployemnt scenarios is useful. > > 2. > " The current Mobile IPv6 design relies on use of IPsec for > authentication of protocol signaling between the MN and the HA. The > associated IPsec SA is created by running IKE [RFC3776] between the > two. The initial authentication and authorization of MN and HA > should be performed during the IKE execution. This is where HA must > consult the AAA infrastructure. > " > With IKEv2, dont you think it is possible that there could be AAA > interaction in the backend (HA-AAA). Hence MIP6/HA really does not > have to do anything to enable the establishment of an IPsec SA. I > dont know if the IKEv2 I-D (MIP6) covers this scenario. I described that in conjunction with the use of EAP/IKEv2 in the text. Yes, that's possible. We need to transport EAP/AAA between the HA and the AAA server. That specification already exists, but for the NAS application/service. We need one for the MIP6 application/service. Delta may be small. > > 3. W.r.t accounting, I dont think you can rely entirely on the > HA. Of course it depends on whether your accounting is based on > time vs amount of data. If the MN is capable of RO, then you cannot > generate charging data based on data volumes. Agreed. This is only for the accounting on the HA. > 4. After reading the I-D, I am not so sure that we are talking about a > AAA framework here. The I-D proposes the need for an HA-AAA > interface that enables an MN to be authenticated and aithorized for > MIP6 service. Additionally this interface is also used for > charging. > I think a AAA framework for MIP6 should also include the ability to > bootstrap. You do mention it in the I-D, but this should be > integral to the I-D as well. I tried to cover the relation between AAA for MIP6 and the bootstrapping in section 4. The framework I described does not allow HA discovery. HA discovery can be achieved by other means, such as described in draft-jang-dhc-haopt-00. (the HA information can be delivered to the DHCP server as part of the network access AAA) > >From the perspective of the MIP6 WG, I think we need to identify the > AAA requirements and define a new AAA application, AVPs or extensions > in the AAA and Radext WGs. There are many ways to use AAA in the context of MIP6, as the current array of proposals indicates. My recommendation is to agree on the framework(s) first before working out the requirements. Alper > > -Basavaraj > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 2 15:20:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06672 for ; Tue, 2 Nov 2004 15:20:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5O5-0004EW-43 for mip6-web-archive@ietf.org; Tue, 02 Nov 2004 15:36:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4se-0000fr-TI; Tue, 02 Nov 2004 15:03:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP4jw-0000Vr-Ad for mip6@megatron.ietf.org; Tue, 02 Nov 2004 14:54:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03594 for ; Tue, 2 Nov 2004 14:54:46 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP4z6-0003c5-Ix for mip6@ietf.org; Tue, 02 Nov 2004 15:10:29 -0500 Received: from jurassic.eng.sun.com ([129.146.85.105]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id iA2Jsk7q023600 for ; Tue, 2 Nov 2004 11:54:46 -0800 (PST) Received: from shubho (shubho.SFBay.Sun.COM [129.146.73.85]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with SMTP id iA2JsjHR457799; Tue, 2 Nov 2004 11:54:45 -0800 (PST) Message-Id: <200411021954.iA2JsjHR457799@jurassic.eng.sun.com> Date: Tue, 2 Nov 2004 11:54:18 -0800 (PST) From: Samita Chakrabarti To: mip6@ietf.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vF4f7ZCBlrvV5FS9EER8sA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_54 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: samita.chakrabarti@sun.com Subject: [Mip6] Comments on draft-chen-mip6-gprs-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c I understand from the authors that this document is targeting for individual RFC submission. I only have some editorial comments. minor nits: In my copy, I was getting blank pages off and on. Please check if it still happens in the latest version. General comment: Since this document describes issues with GPRS services and IMS services, it might be better to organize the issues under each of those services; for example: 3.1 GPRS Services 3.1.1 Mobile Terminal defined packet filtering 3.1.2 Network Service Defined packet filtering 3.2 IMS Services : : In section 3.1 "The TFT only applies...with it" is not very clear, please re-word the senstence. 4.1.1.2 "As a result, two possible decisions can be made by the GGSN... to B" Is this indicating possible solutions or today GGSN is capable of handling the Route optimization this way? section 4.2.1.2 "If tunnelled packets ....PDP Context to B" - may be this part of text is redundant since we are describing the issues. section 5. At the end of the page, it made reference to [14] which is non-existent. As discussed before on the private list that "home agent tunneling" is due to the issue of GGSN's handling of IP-in-IP tunnel - it is not a MIP6 specific issue - it should be mentioned in the document to clarify that. -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 2 15:48:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10161 for ; Tue, 2 Nov 2004 15:48:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5oj-0005IU-0c for mip6-web-archive@ietf.org; Tue, 02 Nov 2004 16:03:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5Lp-0000h1-E5; Tue, 02 Nov 2004 15:33:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP58v-0006NK-9i for mip6@megatron.ietf.org; Tue, 02 Nov 2004 15:20:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06671 for ; Tue, 2 Nov 2004 15:20:35 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5O5-0004Cj-Me for mip6@ietf.org; Tue, 02 Nov 2004 15:36:18 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6K00I01J5CZV@mailout3.samsung.com> for mip6@ietf.org; Wed, 03 Nov 2004 05:20:00 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6K00GS4J5B1B@mailout3.samsung.com> for mip6@ietf.org; Wed, 03 Nov 2004 05:19:59 +0900 (KST) Received: from Alperyegin ([105.253.155.20]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I6K00HMWJ551Z@mmp1.samsung.com> for mip6@ietf.org; Wed, 03 Nov 2004 05:19:56 +0900 (KST) Date: Tue, 02 Nov 2004 12:19:51 -0800 From: Alper Yegin Subject: RE: [Mip6] Comments on I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: <697DAA22C5004B4596E033803A7CEF4403B1C0D1@daebe007.americas.nokia.com> To: Basavaraj.Patil@nokia.com, mip6@ietf.org Message-id: <000001c4c119$5100b300$6901a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7BIT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7BIT > The I-D captures quite well the reasons for an HA-AAA > interface. I believe Alper's I-D draft-yegin-mip6-aaa-fwk-00 > is essentially proposing the same. Yes, there is quite a bit of alignment between the two I-Ds. Scenarios 1, 3, and 4 are common in both documents. I think these scenarios can be handled by one basic and relatively straight forward HA-AAA interface. I believe scenario 2 is different than the other scenarios. I perceive this as falling under another framework/architecture, as I mentioned in section 5 of yegin-mip6-aaa-fwk.txt. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 2 16:06:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11840 for ; Tue, 2 Nov 2004 16:06:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP66E-0005km-FM for mip6-web-archive@ietf.org; Tue, 02 Nov 2004 16:21:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5Yc-0002IY-9J; Tue, 02 Nov 2004 15:47:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5IH-0006Lb-Nc for mip6@megatron.ietf.org; Tue, 02 Nov 2004 15:30:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08306 for ; Tue, 2 Nov 2004 15:30:16 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5XS-0004cG-TS for mip6@ietf.org; Tue, 02 Nov 2004 15:45:59 -0500 Received: from jurassic.eng.sun.com ([129.146.83.36]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iA2KUENH012644; Tue, 2 Nov 2004 13:30:14 -0700 (MST) Received: from shubho (shubho.SFBay.Sun.COM [129.146.73.85]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with SMTP id iA2KUDCj478937; Tue, 2 Nov 2004 12:30:13 -0800 (PST) Message-Id: <200411022030.iA2KUDCj478937@jurassic.eng.sun.com> Date: Tue, 2 Nov 2004 12:29:46 -0800 (PST) From: Samita Chakrabarti To: mip6@ietf.org, mark@borst.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ETsTQCzLCf11qf7kmc8aMA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_54 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: samita.chakrabarti@sun.com Subject: [Mip6] Comments on draft-borst-mip6api-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 I assume this document is an effort to identify usage cases and basic API for MIP6 applications, which could be a feedback to another organization which actually will create application level API. I only had time to review the document in a haste, here are some general comments. - Please mention in the introduction and section 3 (goals and requirements) that the application level API should use "MIP6 Sockets API" to access low level data when applicable. - This document discusses movement detection for "localized service discovery", but I assume that a mobile device would implement a "DNA" solution to achieve movement detection at the system level. If it does not use RO, then MIP6 implementation takes care of updating HA with new COA. This should be transparent to the mobileip user applications. If using RO, the MN/CN takes care of RO signaling and BU/BACK after finding out the movement as per DNA or other method specified in FMIP6. Some system apps may need to be involved in that detection - I don't see why applications need to know the movement at that point. However, if the application wants to know when BUL or BCE gets updated, it can query the MIP6 system to find out its movement status given the current COA. An API may be needed at that level. - A few API seem to be important for user level mobile APPs ( they are addressed in the draft) : -- whether it is home -- whether it has moved ( given the COA that it knows and home-addr) -- Lookup of entry of binding given the home-addr/(and may be interface for multi-interfaced nodes) [ Providing an API to retrieve all the entries in the list may not be so useful, IMHO. Instead entry lookup is more useful for apps. But for performance reason, in some cases the whole list is useful than going in a loop - perhaps both options are needed] -- Finding out its home-agent on a particular interface might be useful as well. Finding domain name might be useful from the ip-address. Hope this helps. -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 2 20:34:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12430 for ; Tue, 2 Nov 2004 20:34:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPAHX-0004zG-BF for mip6-web-archive@ietf.org; Tue, 02 Nov 2004 20:49:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP9sD-0004Iw-6k; Tue, 02 Nov 2004 20:23:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP9n2-0001vp-CW for mip6@megatron.ietf.org; Tue, 02 Nov 2004 20:18:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10949 for ; Tue, 2 Nov 2004 20:18:19 -0500 (EST) Received: from cms5.etri.re.kr ([129.254.16.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPA2F-0004ad-VB for mip6@ietf.org; Tue, 02 Nov 2004 20:34:04 -0500 Received: from RESTART (jhjee.etri.re.kr [129.254.242.56]) by cms5.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VRGY9QXH; Wed, 3 Nov 2004 10:23:55 +0900 Message-ID: <002501c4c142$f7a737f0$38f2fe81@RESTART> From: "Junghoon Jee" To: "Alper Yegin" , References: <00d001c4c07a$73692430$291d9069@sisa.samsung.com> Subject: Re: [Mip6] Comments on jee-mip6-bootstrap-pana Date: Wed, 3 Nov 2004 10:18:03 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.2 (++) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1437099091==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab --===============1437099091== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVsbG8gQWxwZXIsIA0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgcmVhZGluZyB0aGUgSS1EIGFu ZCB0aGUgZmVlZGJhY2suDQoNCiA+IC0gSSBzZWUgdGhlIG5ldyBEaWFtZXRlciBhcHBsaWNhdGlv biBoYXMgdHdvIGZ1bmN0aW9uYWxpdGllcy4gUmVnYXJkaW5nDQo+IHRoZSBkZWxpdmVyeSBvZiB0 aGUgYm9vdHN0cmFwcGluZyBpbmZvcm1hdGlvbiB0byB0aGUgTU4sIEkgd2FzIHdvbmRlcmluZw0K PiBpZiB3ZSBjb3VsZCBnZXQgYXdheSB3aXRoIG5vdCBkZWZpbmluZyBuZXcgY29tbWFuZHMsIGJ1 dCBpbnN0ZWFkDQo+IHBpZ2d5YmFja2luZyBvbiBleGlzdGluZyBOQVMgYXBwbGljYXRpb24/IFRo ZSBib290c3RyYXBwaW5nIGluZm9ybWF0aW9uDQo+IGNvdWxkIGJlIGRlbGl2ZXJlZCB0byB0aGUg TkFTIGFzIHBhcnQgb2YgdGhlIG1vYmlsZSdzIHByb2ZpbGUuDQoNClRoZSBtb2JpbGUgbm9kZSdz IGJvb3RzdHJhcHBpbmcgaW5mb3JtYXRpb24gbWF5IGJlIHBpZ2d5YmFja2VkIHRvIHRoZQ0KcHJl dmlvdXMgTkFTIGFwcGxpY2F0aW9uLiBJbiB0aGF0IGNhc2UsIHdlIHN0aWxsIHNob3VsZCBkZWZp bmUgbmV3IGNvbW1hbmRzIA0KYmV0d2VlbiBBQUEgc2VydmVyIGFuZCBIQS4gTW9yZW92ZXIsIEkg dGhpbmsgd2Ugc2hvdWxkIHN1cHBvcnQgDQp0aGUgTW9iaWxlIElQdjYgYm9vdHN0cmFwcGluZyBp biB0aGUgdmlzaXRlZCBkb21haW4uDQpJdCBtZWFucyB0aGF0IG1vYmlsZSBub2RlcycgaG9tZSBh ZGRyZXNzIGFuZCBIQSBpcyBhc3NpZ25lZCBpbiB0aGUgdmlzaXRlZCBkb21haW4uDQpTaW1wbHkg cGlnZ3liYWNraW5nIHRvIHRoZSBleGlzdGluZyB0aGUgTkFTIGFwcGxpY2F0aW9uIGNhbiBub3Qg YmUgYSBzb2x1dGlvbiBpbiB0aGlzIGNhc2UuDQpUaGUgYm9vdHN0cmFwcGluZyBzdXBwb3J0IGlu IHRoZSB2aXNpdGVkIGRvbWFpbiBpcyBkZXNjcmliZWQgaW4gdGhlIHNlY3Rpb24gNC4zLjIgb2Yg ZHJhZnQtamVlLW1pcDYtYm9vdHN0cmFwLXBhbmEtMDAudHh0Lg0KSSB0aGluayBkZWZpbmluZyBh IG5ldyBhcHBsaWNhdGlvbiB3aXRoIG5ldyBjb21tYW5kIGNvZGVzIGFuZCBBVlBzIGlzIHRoZSBy aWdodCBjaG9pY2UuDQoNCj4gLSBUaGUgb3RoZXIgZnVuY3Rpb25hbGl0eSBpcyB0aGUgcHVzaCBv ZiBib290c3RyYXBwaW5nIGluZm9ybWF0aW9uIGZyb20NCj4gQUFBaCB0byBIQS4gVGhpcyBpcyBj YXJyaWVkIGluIHNlcmlhbCB3aXRoIHRoZSAoaW4gZmFjdCwgaW4gdGhlIG1pZGRsZQ0KPiBvZikg bmV0d29yayBhY2Nlc3MgQUFBLiBJIHRoaW5rIGl0IGNvdWxkIGJlIGRvbmUgaW4gcGFyYWxsZWws IG9yIGV2ZW4NCj4gYWZ0ZXIgdGhlIG5ldHdvcmsgYWNjZXNzIEFBQS4gSWYgeW91IHVzZSBhIHB1 bGwgbW9kZWwgaW5zdGVhZCBvZiB0aGUNCj4gcHVzaCwgdGhpcyBwYXJ0IGdldHMgYWxpZ25lZCB3 aXRoIHRoZSB5ZWdpbi1taXA2LWFhYS1md2suDQoNClJpZ2h0LCBJIGFncmVlIHdpdGggeW91Lg0K T25lIHF1ZXN0aW9uLCBJZiB3ZSB1c2UgYSBwdWxsIG1vZGVsLCBkb2VzIEhBIHJlcXVlc3QgdGhl IGJvb3RzdHJhcHBpbmcgaW5mb3JtYXRpb24gdG8gdGhlIEFBQSBzZXJ2ZXIgPw0KDQo+IC0gSSBk aWRuJ3QgcXVpdGUgdW5kZXJzdGFuZCBob3cgdGhlIE1OIG9idGFpbnMvY29tcHV0ZXMgdGhlDQo+ IE1JUHY2LUFBQS1LZXkuIEl0IGlzIG9ubHkgcHJvdmlkZWQgd2l0aCB0aGUgTUlQdjYtQUFBLUtl eS1JZCwgYW5kIHRoYXQncw0KPiBub3Qgc3VmZmljaWVudCB0byBkZXJpdmUgdGhlIGtleS4NCg0K UEFOQS1BQUEtS2V5LUlkIGlzIHVzZWQgdG8gaWRlbnRpZnkgdGhlIFBBTkEtQUFBLUtleSBhcyBz cGVjaWZpZWQgaW4gdGhlIGRyYWZ0LWlldGYtcGFuYS1wYW5hLTA2LnR4dC4NClNpbWlsYXJseSwg TUlQdjYtQUFBLUtleS1JZCBpcyB1c2VkIHRvIGlkZW50aWZ5IHRoZSBNSVB2Ni1BQUEtS2V5IGdp dmVuIHRoZSBQQU5BIGFuZCBBQUEgc2Vzc2lvbi4NCkFueSBtaXNzaW5nIHBvaW50ID8NCk1OIGNv bXB1dGVzIHRoZSBJS0UgUFNLIHVzaW5nIHRoZSBNSVB2Ni1BQUEtS2V5IGFzIHNwZWNpZmllZCBp biB0aGUgc2VjdGlvbiA0Ljkgb2YgZHJhZnQtamVlLW1pcDYtYm9vdHN0cmFwLXBhbmEtMDAudHh0 Lg0KDQpCZXN0IFJlZ2FyZHMsDQoNCkp1bmdob29u --===============1437099091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1437099091==-- From mip6-bounces@ietf.org Tue Nov 2 21:36:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16511 for ; Tue, 2 Nov 2004 21:36:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPBFu-0006Jh-Et for mip6-web-archive@ietf.org; Tue, 02 Nov 2004 21:52:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPAtq-0001Q5-W8; Tue, 02 Nov 2004 21:29:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPAs4-0008Qf-7E for mip6@megatron.ietf.org; Tue, 02 Nov 2004 21:27:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16076 for ; Tue, 2 Nov 2004 21:27:34 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPB77-00067k-SG for mip6@ietf.org; Tue, 02 Nov 2004 21:43:20 -0500 Message-ID: <00ed01c4c14c$b4029580$5b6015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Giaretta Gerardo" References: Subject: Re: [Mip6] Review of draft-giaretta-mip6-authorization-eap-02.txt Date: Tue, 2 Nov 2004 18:20:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit I agree it would be less useful in a scenario between operators. However, I don't clearly understand the scenario you described: do the subsidiaries' AAA servers authenticate the users or simply act as AAA proxies? In the former case, how can they authenticate them? Do they have a copy of users' credentials? Are the users' credentials distributed by the central AAA server to all subsidiaries' AAA servers? jak>> If they are not proxies, they would have to be caches. I don't think the key derivation suggestion I mentioned in the original email would work, though, unless the MN also can do it, and for that it would have to know that it was talking with the subsidiary's AAA server. I agree: a negotiation about dyamic address assignment is needed even if IKEv1 is used. Moreover, I wonder whether the MN must declare its capabilities (i.e. which version of IKE it supports): what happens if the MN supports only IKEv1 and the HA only IKEv2? Or do you think this scenario is not feasible since the HA is expected to support both IKEv1 and IKEv2? jak>> I think it unlikely that the HA will support v2 and not v1. I'm not so sure about the MN though, it might be possible there. It might be best to include the IKE version, even though IKE apparently does allow adequate version negotiation, especially if we include an indicator to get the home address through IKE. In the EAP negotiation phase the MN can ask for particular service options, for example the allocation of the HA in the foreign domain. If the AAAH cannot provide some options requested by the MN, it must be possibile for the MN to reject the MIPv6 parameters proposed by the AAAH (i.e. it is not interested in a HA in the home domain but only in a HA in the foreign domain) and not to activate MIPv6 service. This is the reason for the MN to send the Negotiation-Result-TLV. Maybe this could be better explained in the document. jak>> Yes it might be useful to explain that in the overview section. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 2 22:27:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21327 for ; Tue, 2 Nov 2004 22:27:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPC3I-0007aQ-DO for mip6-web-archive@ietf.org; Tue, 02 Nov 2004 22:43:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPBe9-0004u9-AG; Tue, 02 Nov 2004 22:17:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPBRd-0008TJ-8d for mip6@megatron.ietf.org; Tue, 02 Nov 2004 22:04:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19616 for ; Tue, 2 Nov 2004 22:04:18 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPBgq-00074q-U1 for mip6@ietf.org; Tue, 02 Nov 2004 22:20:05 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I6L001011UBON@mailout1.samsung.com> for mip6@ietf.org; Wed, 03 Nov 2004 12:03:47 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I6L004231UB0N@mailout1.samsung.com> for mip6@ietf.org; Wed, 03 Nov 2004 12:03:47 +0900 (KST) Received: from Alperyegin ([105.253.155.20]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6L0022M1U70Z@mmp2.samsung.com> for mip6@ietf.org; Wed, 03 Nov 2004 12:03:47 +0900 (KST) Date: Tue, 02 Nov 2004 19:03:40 -0800 From: Alper Yegin Subject: RE: [Mip6] Comments on jee-mip6-bootstrap-pana In-reply-to: <002501c4c142$f7a737f0$38f2fe81@RESTART> To: "'Junghoon Jee'" , mip6@ietf.org Message-id: <003001c4c151$ba7fb5a0$6901a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7BIT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7BIT Hi Junghoon, > > - The other functionality is the push of bootstrapping information from > > AAAh to HA. This is carried in serial with the (in fact, in the middle > > of) network access AAA. I think it could be done in parallel, or even > > after the network access AAA. If you use a pull model instead of the > > push, this part gets aligned with the yegin-mip6-aaa-fwk. > > Right, I agree with you. > One question, If we use a pull model, does HA request the bootstrapping > information to the AAA server ? Yes. > > - I didn't quite understand how the MN obtains/computes the > > MIPv6-AAA-Key. It is only provided with the MIPv6-AAA-Key-Id, and that's > > not sufficient to derive the key. > > PANA-AAA-Key-Id is used to identify the PANA-AAA-Key as specified in the > draft-ietf-pana-pana-06.txt. > Similarly, MIPv6-AAA-Key-Id is used to identify the MIPv6-AAA-Key given > the PANA and AAA session. > Any missing point ? Keys are independent of the Key-Ids. Unless you know the Key, you cannot compute it from the Key-Id. > MN computes the IKE PSK using the MIPv6-AAA-Key as specified in the > section 4.9 of draft-jee-mip6-bootstrap-pana-00.txt. Alper > > Best Regards, > > Junghoon _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 2 23:53:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26860 for ; Tue, 2 Nov 2004 23:53:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPDOw-000132-MC for mip6-web-archive@ietf.org; Wed, 03 Nov 2004 00:09:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPD3i-00028u-Rg; Tue, 02 Nov 2004 23:47:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPCzW-0005Yx-Ij for mip6@megatron.ietf.org; Tue, 02 Nov 2004 23:43:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26183 for ; Tue, 2 Nov 2004 23:43:24 -0500 (EST) Received: from cms5.etri.re.kr ([129.254.16.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPDEf-0000fu-09 for mip6@ietf.org; Tue, 02 Nov 2004 23:59:12 -0500 Received: from RESTART (jhjee.etri.re.kr [129.254.242.56]) by cms5.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VRGY9RS2; Wed, 3 Nov 2004 13:48:52 +0900 Message-ID: <00e901c4c15f$994ada50$38f2fe81@RESTART> From: "Junghoon Jee" To: "Alper Yegin" , References: <003001c4c151$ba7fb5a0$6901a8c0@sisa.samsung.com> Subject: Re: [Mip6] Comments on jee-mip6-bootstrap-pana Date: Wed, 3 Nov 2004 13:43:01 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.2 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1581544920==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f --===============1581544920== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgQWxwZXIsDQoNCiA+ID4gPiAtIFRoZSBvdGhlciBmdW5jdGlvbmFsaXR5IGlzIHRoZSBwdXNo IG9mIGJvb3RzdHJhcHBpbmcgaW5mb3JtYXRpb24NCj4gZnJvbQ0KPiA+ID4gQUFBaCB0byBIQS4g VGhpcyBpcyBjYXJyaWVkIGluIHNlcmlhbCB3aXRoIHRoZSAoaW4gZmFjdCwgaW4gdGhlDQo+IG1p ZGRsZQ0KPiA+ID4gb2YpIG5ldHdvcmsgYWNjZXNzIEFBQS4gSSB0aGluayBpdCBjb3VsZCBiZSBk b25lIGluIHBhcmFsbGVsLCBvcg0KPiBldmVuDQo+ID4gPiBhZnRlciB0aGUgbmV0d29yayBhY2Nl c3MgQUFBLiBJZiB5b3UgdXNlIGEgcHVsbCBtb2RlbCBpbnN0ZWFkIG9mIHRoZQ0KPiA+ID4gcHVz aCwgdGhpcyBwYXJ0IGdldHMgYWxpZ25lZCB3aXRoIHRoZSB5ZWdpbi1taXA2LWFhYS1md2suDQo+ ID4gDQo+ID4gUmlnaHQsIEkgYWdyZWUgd2l0aCB5b3UuDQo+ID4gT25lIHF1ZXN0aW9uLCBJZiB3 ZSB1c2UgYSBwdWxsIG1vZGVsLCBkb2VzIEhBIHJlcXVlc3QgdGhlDQo+IGJvb3RzdHJhcHBpbmcN Cj4gPiBpbmZvcm1hdGlvbiB0byB0aGUgQUFBIHNlcnZlciA/DQo+IA0KPiBZZXMuDQo+IA0KDQpJ ZiB0aGUgSEEgc2hvdWxkIHJlcXVlc3QgdG8gdGhlIEFBQSBzZXJ2ZXIgdG8gZ2V0IGEgYm9vdHN0 cmFwcGluZyBpbmZvcm1hdGlvbiwgSSB0aGluaw0KdGhlIEhBIHNob3VsZCBrbm93IHRoZSB0aW1l IHdoZW4gQUFBIHNlcnZlciBjb21wbGV0ZXMgdGhlIGNvbmZpZ3VyYXRpb24gb2YgYm9vdHN0cmFw cGluZyBpbmZvcm1hdGlvbi4NCkhvdyBjYW4gdGhlIEhBIGlkZW50aWZ5IHRoYXQgdGhlIGJvb3Rz dHJhcHBpbmcgaW5mb3JtYXRpb24gY29uZmlndXJhdGlvbiBpcyBjb21wbGV0ZWQgaW4gdGhlIEFB QSBzZXJ2ZXIgPw0KDQpKdW5naG9vbg== --===============1581544920== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1581544920==-- From mip6-bounces@ietf.org Wed Nov 3 00:56:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00176 for ; Wed, 3 Nov 2004 00:56:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPENI-0002Dl-C7 for mip6-web-archive@ietf.org; Wed, 03 Nov 2004 01:12:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPE68-0006Ob-00; Wed, 03 Nov 2004 00:54:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPDuE-0001H6-Fd for mip6@megatron.ietf.org; Wed, 03 Nov 2004 00:42:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29327 for ; Wed, 3 Nov 2004 00:41:59 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPE9T-0001ui-Ek for mip6@ietf.org; Wed, 03 Nov 2004 00:57:48 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6L00M8A953X9@mailout2.samsung.com> for mip6@ietf.org; Wed, 03 Nov 2004 14:41:27 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6L0043V93JJ9@mailout2.samsung.com> for mip6@ietf.org; Wed, 03 Nov 2004 14:40:31 +0900 (KST) Received: from Alperyegin ([105.253.155.20]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I6L004QW93GCW@mmp1.samsung.com> for mip6@ietf.org; Wed, 03 Nov 2004 14:40:31 +0900 (KST) Date: Tue, 02 Nov 2004 21:40:24 -0800 From: Alper Yegin Subject: RE: [Mip6] Comments on jee-mip6-bootstrap-pana In-reply-to: <00e901c4c15f$994ada50$38f2fe81@RESTART> To: "'Junghoon Jee'" , mip6@ietf.org Message-id: <004f01c4c167$9f65fcf0$6901a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7BIT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7BIT Junghoon, > > > > - The other functionality is the push of bootstrapping information > > from > > > > AAAh to HA. This is carried in serial with the (in fact, in the > > middle > > > > of) network access AAA. I think it could be done in parallel, or > > even > > > > after the network access AAA. If you use a pull model instead of the > > > > push, this part gets aligned with the yegin-mip6-aaa-fwk. > > > > > > Right, I agree with you. > > > One question, If we use a pull model, does HA request the > > bootstrapping > > > information to the AAA server ? > > > > Yes. > > > > If the HA should request to the AAA server to get a bootstrapping > information, I think > the HA should know the time when AAA server completes the configuration of > bootstrapping information. > How can the HA identify that the bootstrapping information configuration > is completed in the AAA server ? HA can contact the AAA server when the MN starts the IKE exchange. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 3 02:56:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08360 for ; Wed, 3 Nov 2004 02:56:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPGFD-0004vs-VQ for mip6-web-archive@ietf.org; Wed, 03 Nov 2004 03:11:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPFmk-0005Kj-2v; Wed, 03 Nov 2004 02:42:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPFie-0003ZE-Vs for mip6@megatron.ietf.org; Wed, 03 Nov 2004 02:38:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07098 for ; Wed, 3 Nov 2004 02:38:11 -0500 (EST) Received: from cms5.etri.re.kr ([129.254.16.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPFxu-0004YC-Ly for mip6@ietf.org; Wed, 03 Nov 2004 02:54:00 -0500 Received: from RESTART (jhjee.etri.re.kr [129.254.242.56]) by cms5.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VRGY9SHX; Wed, 3 Nov 2004 16:43:49 +0900 Message-ID: <011401c4c178$09609f60$38f2fe81@RESTART> From: "Junghoon Jee" To: "Alper Yegin" , References: <004f01c4c167$9f65fcf0$6901a8c0@sisa.samsung.com> Subject: Re: [Mip6] Comments on jee-mip6-bootstrap-pana Date: Wed, 3 Nov 2004 16:37:57 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.2 (++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1775872952==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 --===============1775872952== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 QWxwZXIsIA0KIA0KPiA+ICA+ID4gPiAtIFRoZSBvdGhlciBmdW5jdGlvbmFsaXR5IGlzIHRoZSBw dXNoIG9mIGJvb3RzdHJhcHBpbmcNCj4gaW5mb3JtYXRpb24NCj4gPiA+IGZyb20NCj4gPiA+ID4g PiBBQUFoIHRvIEhBLiBUaGlzIGlzIGNhcnJpZWQgaW4gc2VyaWFsIHdpdGggdGhlIChpbiBmYWN0 LCBpbiB0aGUNCj4gPiA+IG1pZGRsZQ0KPiA+ID4gPiA+IG9mKSBuZXR3b3JrIGFjY2VzcyBBQUEu IEkgdGhpbmsgaXQgY291bGQgYmUgZG9uZSBpbiBwYXJhbGxlbCwgb3INCj4gPiA+IGV2ZW4NCj4g PiA+ID4gPiBhZnRlciB0aGUgbmV0d29yayBhY2Nlc3MgQUFBLiBJZiB5b3UgdXNlIGEgcHVsbCBt b2RlbCBpbnN0ZWFkIG9mDQo+IHRoZQ0KPiA+ID4gPiA+IHB1c2gsIHRoaXMgcGFydCBnZXRzIGFs aWduZWQgd2l0aCB0aGUgeWVnaW4tbWlwNi1hYWEtZndrLg0KPiA+ID4gPg0KPiA+ID4gPiBSaWdo dCwgSSBhZ3JlZSB3aXRoIHlvdS4NCj4gPiA+ID4gT25lIHF1ZXN0aW9uLCBJZiB3ZSB1c2UgYSBw dWxsIG1vZGVsLCBkb2VzIEhBIHJlcXVlc3QgdGhlDQo+ID4gPiBib290c3RyYXBwaW5nDQo+ID4g PiA+IGluZm9ybWF0aW9uIHRvIHRoZSBBQUEgc2VydmVyID8NCj4gPiA+DQo+ID4gPiBZZXMuDQo+ ID4gPg0KPiA+IA0KPiA+IElmIHRoZSBIQSBzaG91bGQgcmVxdWVzdCB0byB0aGUgQUFBIHNlcnZl ciB0byBnZXQgYSBib290c3RyYXBwaW5nDQo+ID4gaW5mb3JtYXRpb24sIEkgdGhpbmsNCj4gPiB0 aGUgSEEgc2hvdWxkIGtub3cgdGhlIHRpbWUgd2hlbiBBQUEgc2VydmVyIGNvbXBsZXRlcyB0aGUN Cj4gY29uZmlndXJhdGlvbiBvZg0KPiA+IGJvb3RzdHJhcHBpbmcgaW5mb3JtYXRpb24uDQo+ID4g SG93IGNhbiB0aGUgSEEgaWRlbnRpZnkgdGhhdCB0aGUgYm9vdHN0cmFwcGluZyBpbmZvcm1hdGlv bg0KPiBjb25maWd1cmF0aW9uDQo+ID4gaXMgY29tcGxldGVkIGluIHRoZSBBQUEgc2VydmVyID8N Cj4gDQo+IEhBIGNhbiBjb250YWN0IHRoZSBBQUEgc2VydmVyIHdoZW4gdGhlIE1OIHN0YXJ0cyB0 aGUgSUtFIGV4Y2hhbmdlLg0KDQpZb3UgbWVhbiB0aGF0IHRoZSBIQSByZXF1ZXN0cyB0aGUgYm9v dHN0cmFwcGluZyBpbmZvcm1hdGlvbiB0byB0aGUgQUFBIHNlcnZlciANCmFmdGVyIHRoZSBIQSBy ZWNlaXZlcyB0aGUgSUtFIGluaXRpYXRpb24gbWVzc2FnZSBmcm9tIHRoZSBNTiA/DQpJZiBzbywg aXNuJ3QgdGhlcmUgYW55IG9wZW4gaXNzdWVzIGFib3V0IGluaXRpYXRpbmcgSUtFIGV4Y2hhbmdl IGJldHdlZW4gdGhlIE1OIGFuZCBIQQ0KYmVmb3JlIHRoZSBIQSBnZXRzIGJvb3RzdHJhcHBpbmcg aW5mb3JtYXRpb24gPw0KDQpKdW5naG9vbg0K --===============1775872952== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1775872952==-- From mip6-bounces@ietf.org Wed Nov 3 03:00:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08688 for ; Wed, 3 Nov 2004 03:00:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPGJV-00051z-Sx for mip6-web-archive@ietf.org; Wed, 03 Nov 2004 03:16:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPG0q-0003EI-0t; Wed, 03 Nov 2004 02:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPFtl-0007tW-5A for mip6@megatron.ietf.org; Wed, 03 Nov 2004 02:49:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08036 for ; Wed, 3 Nov 2004 02:49:39 -0500 (EST) Received: from cms5.etri.re.kr ([129.254.16.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPG91-0004o3-92 for mip6@ietf.org; Wed, 03 Nov 2004 03:05:28 -0500 Received: from RESTART (jhjee.etri.re.kr [129.254.242.56]) by cms5.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VRGY9S2S; Wed, 3 Nov 2004 16:55:17 +0900 Message-ID: <012201c4c179$a3f5b910$38f2fe81@RESTART> From: "Junghoon Jee" To: "Alper Yegin" , References: <003001c4c151$ba7fb5a0$6901a8c0@sisa.samsung.com> Subject: Re: [Mip6] Comments on jee-mip6-bootstrap-pana Date: Wed, 3 Nov 2004 16:49:25 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.2 (++) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0368169469==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 --===============0368169469== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 QWxwZXIsDQoNCj4gPiA+IC0gSSBkaWRuJ3QgcXVpdGUgdW5kZXJzdGFuZCBob3cgdGhlIE1OIG9i dGFpbnMvY29tcHV0ZXMgdGhlDQo+ID4gPiBNSVB2Ni1BQUEtS2V5LiBJdCBpcyBvbmx5IHByb3Zp ZGVkIHdpdGggdGhlIE1JUHY2LUFBQS1LZXktSWQsIGFuZA0KPiB0aGF0J3MNCj4gPiA+IG5vdCBz dWZmaWNpZW50IHRvIGRlcml2ZSB0aGUga2V5Lg0KPiA+IA0KPiA+IFBBTkEtQUFBLUtleS1JZCBp cyB1c2VkIHRvIGlkZW50aWZ5IHRoZSBQQU5BLUFBQS1LZXkgYXMgc3BlY2lmaWVkIGluDQo+IHRo ZQ0KPiA+IGRyYWZ0LWlldGYtcGFuYS1wYW5hLTA2LnR4dC4NCj4gPiBTaW1pbGFybHksIE1JUHY2 LUFBQS1LZXktSWQgaXMgdXNlZCB0byBpZGVudGlmeSB0aGUgTUlQdjYtQUFBLUtleQ0KPiBnaXZl bg0KPiA+IHRoZSBQQU5BIGFuZCBBQUEgc2Vzc2lvbi4NCj4gPiBBbnkgbWlzc2luZyBwb2ludCA/ DQo+IA0KPiBLZXlzIGFyZSBpbmRlcGVuZGVudCBvZiB0aGUgS2V5LUlkcy4gVW5sZXNzIHlvdSBr bm93IHRoZSBLZXksIHlvdSBjYW5ub3QNCj4gY29tcHV0ZSBpdCBmcm9tIHRoZSBLZXktSWQuIA0K PiANCj4gPiBNTiBjb21wdXRlcyB0aGUgSUtFIFBTSyB1c2luZyB0aGUgTUlQdjYtQUFBLUtleSBh cyBzcGVjaWZpZWQgaW4gdGhlDQo+ID4gc2VjdGlvbiA0Ljkgb2YgZHJhZnQtamVlLW1pcDYtYm9v dHN0cmFwLXBhbmEtMDAudHh0Lg0KDQpUaGUgQUFBIHNlcnZlciBhbmQgdGhlIE1OIG1haW50YWlu cyB0aGUga2V5IG1hcHBpbmcgdGFibGUsIE1JUHY2LUFBQS1LZXktSWQgdnMuIE1JUHY2LUFBQS1L ZXkuDQpXaGVuIEVBUCBhdXRoZW50aWNhdGlvbiBpcyBzdWNjZWVkZWQsIHRoZSBNSVB2Ni1BQUEt S2V5IGFuZCBpdHMgaWQuIGFyZSBzdG9yZWQgdG8gdGhlIGtleSBtYXBwaW5nIHRhYmxlLg0KVGhl IE1JUHY2LUFBQS1LZXkgY2FuIGJlIGFuIEFBQS1LZXkgb3IgY29uY2F0ZW5hdGlvbiBvZiB0aGUg QUFBLUtleScgd2l0aCBBQUEtS2V5JycgaWYgbXVsdGlwbGUNCnNlc3Npb24ga2V5cyBhcmUgZGVy aXZlZCBieSB0aGUgRUFQIGF1dGhlbnRpY2F0aW9uIHByb2Nlc3MuIFRoZSBjaG9pY2Ugb2Ygd2hp Y2gga2V5IHRvIHVzZSB0byBkZXJpdmUgTUlQdjYgSUtFIFBTSyBpcw0KZGV0ZXJtaW5lZCBieSB0 aGUgQUFBIGhvbWUgc2VydmVyLiBUaGUgQUFBIGhvbWUgc2VydmVyIG5vdGlmaWVzIHRoZSBNTiB3 aGljaCBrZXkgdG8gdXNlIGJ5IHNlbmRpbmcgdGhlIE1JUHY2LUFBQS1LZXktSWQuDQoNCkp1bmdo b29u --===============0368169469== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0368169469==-- From mip6-bounces@ietf.org Wed Nov 3 06:36:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26862 for ; Wed, 3 Nov 2004 06:36:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPJgb-0001iT-EQ for mip6-web-archive@ietf.org; Wed, 03 Nov 2004 06:52:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPJMV-0005Sq-Uk; Wed, 03 Nov 2004 06:31:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPJBf-0002BN-J5 for mip6@megatron.ietf.org; Wed, 03 Nov 2004 06:20:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24655 for ; Wed, 3 Nov 2004 06:20:19 -0500 (EST) Received: from mail32.messagelabs.com ([62.173.108.211]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CPJQm-00018Q-LK for mip6@ietf.org; Wed, 03 Nov 2004 06:36:11 -0500 X-VirusChecked: Checked X-Env-Sender: xiaobao.chen@orange.co.uk X-Msg-Ref: server-6.tower-32.messagelabs.com!1099480555!23426794!1 X-StarScan-Version: 5.4.2; banners=orange.co.uk,-,- X-Originating-IP: [193.35.135.133] Received: (qmail 11021 invoked from network); 3 Nov 2004 11:15:55 -0000 Received: from unknown (HELO hagrid.orange.co.uk) (193.35.135.133) by server-6.tower-32.messagelabs.com with SMTP; 3 Nov 2004 11:15:55 -0000 Received: from bit.orange.co.uk (bit.orange.co.uk) by hagrid.orange.co.uk (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Wed, 3 Nov 2004 11:14:55 +0000 Received: from ukexbrismtp02.uk.orangegad.com (ukexbrismtp02.orange.co.uk [172.16.131.106]) by bit.orange.co.uk with SMTP id iA3BEsD04557; Wed, 3 Nov 2004 11:14:54 GMT X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Comments on draft-chen-mip6-gprs-02.txt Date: Wed, 3 Nov 2004 11:14:53 -0000 Message-ID: <8C8F0E870815804FAC506E74B8A6F7B401C3AC0A@UKEXBRIMBX001.uk.orangegad.com> Thread-Topic: [Mip6] Comments on draft-chen-mip6-gprs-02.txt Thread-Index: AcTBGbU0IVZ6h74VRnqlqCxK4VMrCgAdcFdH From: "CHEN, Xiaobao" To: "Samita Chakrabarti" , X-OriginalArrivalTime: 03 Nov 2004 11:14:54.0193 (UTC) FILETIME=[582EBE10:01C4C196] X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: quoted-printable Cc: samita.chakrabarti@sun.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Content-Transfer-Encoding: quoted-printable Samita, =20 Many=20thanks=20for=20the=20=20comments.=20My=20response=20is=20in=20line.= =20 =20 Regards, =20 Xiaobao =09-----Original=20Message-----=20 =09From:=20mip6-bounces@ietf.org=20on=20behalf=20of=20Samita=20Chakrabarti= =20 =09Sent:=20Tue=2002/11/2004=2019:54=20 =09To:=20mip6@ietf.org=20 =09Cc:=20samita.chakrabarti@sun.com=20 =09Subject:=20[Mip6]=20Comments=20on=20draft-chen-mip6-gprs-02.txt =09 =09 =09I=20understand=20from=20the=20authors=20that=20this=20document=20is=20t= argeting=20for individual =09RFC=20submission.=20I=20only=20have=20some=20editorial=20comments. =09 =09minor=20nits: =09In=20my=20copy,=20I=20was=20getting=20blank=20pages=20off=20and=20on.=20= Please=20check=20if=20it still =09happens=20in=20the=20latest=20version. =09 =09[xc]=20Yes,=20will=20check=20it=20again=20and=20make=20sure=20it=20won'= t=20happen=20in=20the next=20revised=20version. =09 =09 =09General=20comment:=20Since=20this=20document=20describes=20issues=20wit= h=20GPRS services =09and=20IMS=20services,=20it=20might=20be=20better=20to=20organize=20the=20= issues=20under each=20of =09those=20services;=20for=20example: =09 =093.1=20GPRS=20Services =09=20=20=203.1.1=20Mobile=20Terminal=20defined=20packet=20filtering =09=20=20=203.1.2=20Network=20Service=20Defined=20packet=20filtering =09=20=20 =093.2=20=20IMS=20Services =09=20=20=20=20: =09=20=20=20=20: =09=20=20=20 =09[xc]=20Good=20point.=20This=20is=20certainly=20one=20of=20the=20ways=20= for=20organising=20the structure=20for=20the=20problems=20descriptions=20=20that=20we=20considere= d=20before.=20After comparing=20this=20with=20the=20current=20structure=20of=20the=20descripti= ons,=20i.e.=20the=20GPRS node=20being=20either=20the=20correspondent=20=20node=20or=20the=20mobile=20= node,=20=20we=20found=20it perhaps=20easier=20and=20clearer=20=20for=20some=20readers=20who=20may=20n= ot=20be=20very=20familiar with=20the=203GPP=20networks=20to=20understand=20the=20descriptions=20by=20= describing=20=20the problems=20in=20a=20style=20close=20to=20the=20way=20that=20Mobile=20IP=20= works. =09But=20I=20will=20discuss=20this=20again=20with=20other=20co-authors=20t= o=20see=20what=20is the=20best=20way=20for=20describing=20the=20problems=20clearly. =09 =09=20In=20section=203.1=20"The=20TFT=20only=20applies...with=20it"=20is=20= not=20very=20clear, please =09=20re-word=20the=20senstence. =09 =09[xc]=20Yes,=20will=20provide=20clarifications=20in=20the=20next=20revis= ed=20version.=20 =09 =09=204.1.1.2=20=20"As=20a=20result,=20two=20possible=20decisions=20can=20= be=20made=20by=20the GGSN...=20to=20B" =09 =09=20Is=20this=20indicating=20possible=20solutions=20or=20today=20GGSN=20= is=20capable=20of handling=20the =09=20Route=20optimization=20this=20way? =09 =09[xc]=20In=20current=203GPP=20standard=20specifications,=20the=20GGSN=20= =20allows=20one PDP=20without=20TFT=20at=20=20maximum.=20And=20it=20is=20also=20possible=20= that=20all=20PDP=20contexts have=20TFT's.=20=20The=20sentense=20you=20mentiond=20=20in=20the=20draft=20= indicates=20that=20the=20GGSN, when=20having=20a=20PDP=20without=20the=20TFT,=20may=20choose=20to=20use=20= this=20PDP=20to=20deliver=20=20the IP=20datagrams=20that=20fail=20to=20match=20any=20TFT's.=20=20But=20the=20= problem=20with=20this=20is=20that the=20IP=20datagrams=20will=20not=20receive=20the=20correct=20QoS.=20And=20= this=20won't=20work=20for the=20cases=20when=20all=20PDP's=20have=20TFT'. =09This=20sentense=20does=20not=20intend=20to=20indicate=20any=20solution=20= but=20further describe=20problems=20still=20exist=20even=20=20if=20one=20TFT-free=20PDP=20= =20is=20=20possible. =09 =09=20section=204.2.1.2 =09 =09=20"If=20tunnelled=20packets=20....PDP=20Context=20to=20B"=20-=20may=20= be=20this=20part=20of text=20is =09=20redundant=20since=20we=20are=20describing=20the=20issues. =09 =09[xc]=20We=20will=20consider=20to=20delete=20the=20sentence.=20 =09 =09=20section=205. =09=20At=20the=20end=20of=20the=20page,=20it=20made=20reference=20to=20[14= ]=20which=20is non-existent. =09 =09[xc]=20Yes,=20it=20will=20be=20corrected. =09 =09=20As=20discussed=20before=20on=20the=20private=20list=20that=20"home=20= agent=20tunneling" is=20due =09=20to=20the=20issue=20of=20GGSN's=20handling=20of=20IP-in-IP=20tunnel=20= -=20it=20is=20not=20a MIP6=20specific =09=20issue=20-=20it=20should=20be=20mentioned=20in=20=20the=20document=20= to=20clarify=20that. =09 =09[xc]=20Agreed. =09 =09 =09=20-Samita =09 =09 =09 =09_______________________________________________ =09Mip6=20mailing=20list =09Mip6@ietf.org =09https://www1.ietf.org/mailman/listinfo/mip6 =09 ******************************************************************** Important. Confidentiality:=20This=20communication=20is=20intended=20for=20the=20abov= e-named person=20and=20may=20be=20confidential=20and/or=20legally=20privileged. Any=20opinions=20expressed=20in=20this=20communication=20are=20not=20neces= sarily=20 those=20of=20the=20company.=20If=20it=20has=20come=20to=20you=20in=20error= =20you=20must=20 take=20no=20action=20based=20on=20it,=20nor=20must=20you=20copy=20or=20sho= w=20it=20to=20anyone;=20 please=20delete/destroy=20and=20inform=20the=20sender=20immediately. Monitoring/Viruses. Orange=20may=20monitor=20all=20incoming=20and=20outgoing=20emails=20in=20l= ine=20with=20 current=20legislation.=20=20Although=20we=20have=20taken=20steps=20to=20en= sure=20that=20 this=20email=20and=20attachments=20are=20free=20from=20any=20virus,=20we=20= advise=20that=20 in=20keeping=20with=20good=20computing=20practice=20the=20recipient=20shou= ld=20ensure=20 they=20are=20actually=20virus=20free. Orange=20PCS=20Limited=20is=20a=20subsidiary=20of=20Orange=20SA=20and=20is= =20registered=20 in=20England=20No=202178917,=20with=20its=20address=20at=20St=20James=20Co= urt,=20 Great=20Park=20Road,=20Almondsbury=20Park,=20Bradley=20Stoke,=20Bristol=20= BS32=204QJ. ******************************************************************** _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 3 07:36:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02454 for ; Wed, 3 Nov 2004 07:36:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPKcJ-000371-Bc for mip6-web-archive@ietf.org; Wed, 03 Nov 2004 07:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPKAl-0006WZ-My; Wed, 03 Nov 2004 07:23:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPK30-0005I9-M6 for mip6@megatron.ietf.org; Wed, 03 Nov 2004 07:15:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00504 for ; Wed, 3 Nov 2004 07:15:27 -0500 (EST) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPKI5-0002dd-UP for mip6@ietf.org; Wed, 03 Nov 2004 07:31:20 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0I6L00G2WR9A3S@dns1.cselt.it> for mip6@ietf.org; Wed, 03 Nov 2004 13:12:46 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Wed, 03 Nov 2004 13:16:42 +0100 Date: Wed, 03 Nov 2004 13:13:41 +0100 From: Giaretta Gerardo Subject: RE: [Mip6] Comments on I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt To: Alper Yegin , Basavaraj.Patil@nokia.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Comments on I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt thread-index: AcTBHWxkXn6sqXjfSfSjT/5TaABPgwAgTkRg Content-Class: urn:content-classes:message X-OriginalArrivalTime: 03 Nov 2004 12:16:42.0187 (UTC) FILETIME=[FA51B9B0:01C4C19E] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On=20 > Behalf Of Alper Yegin > Sent: Tuesday, November 02, 2004 9:20 PM > To: Basavaraj.Patil@nokia.com; mip6@ietf.org > Subject: RE: [Mip6] Comments on I-D:=20 > draft-giaretta-mip6-aaa-ha-goals-00.txt >=20 >=20 >=20 > > The I-D captures quite well the reasons for an HA-AAA > > interface. I believe Alper's I-D draft-yegin-mip6-aaa-fwk-00 > > is essentially proposing the same. >=20 > Yes, there is quite a bit of alignment between the two I-Ds. >=20 > Scenarios 1, 3, and 4 are common in both documents. I think these > scenarios can be handled by one basic and relatively straight forward > HA-AAA interface.=20 >=20 I think that also scenario 2 can be handled by the same HA-AAA interface, even if it might fall in another framework. In section 6 of draft-giaretta-mip6-aaa-ha-goals-00 we tried to map the goals with the scenarios: as you can see, the goals for a AAA-HA interface are quite similar in scearios 1 and 2. The main difference is the provisioning of configuration parameters (needed in scenario 2) that could be handled quite easily, imho (e.g. optional AVPs in a Diameter application). --Gerardo > I believe scenario 2 is different than the other scenarios. I perceive > this as falling under another framework/architecture, as I=20 > mentioned in > section 5 of yegin-mip6-aaa-fwk.txt.=20 >=20 > Alper >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 3 08:29:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07875 for ; Wed, 3 Nov 2004 08:29:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPLS9-0004p1-2J for mip6-web-archive@ietf.org; Wed, 03 Nov 2004 08:45:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPL8I-0004br-6K; Wed, 03 Nov 2004 08:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPKum-0000V3-Aw for mip6@megatron.ietf.org; Wed, 03 Nov 2004 08:11:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06287 for ; Wed, 3 Nov 2004 08:11:02 -0500 (EST) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPLA2-0004Mw-Mm for mip6@ietf.org; Wed, 03 Nov 2004 08:26:54 -0500 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by smtp2.int-evry.fr (Postfix) with ESMTP id 209192FE94; Wed, 3 Nov 2004 14:11:02 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1CPKsI-0001Tr-Oq; Wed, 03 Nov 2004 14:08:30 +0100 Date: Wed, 3 Nov 2004 14:08:30 +0100 From: Julien Bournelle To: Giaretta Gerardo Subject: Re: [Mip6] Comments on I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt Message-ID: <20041103130830.GK314@ipv6-5.int-evry.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-5.814, requis 4.5, autolearn=spam, ALL_TRUSTED -3.30, AWL 0.09, BAYES_00 -2.60) X-MailScanner-From: jb@ipv6-5.int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Alper Yegin , mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi all, comments inline, On Wed, Nov 03, 2004 at 01:13:41PM +0100, Giaretta Gerardo wrote: > > Yes, there is quite a bit of alignment between the two I-Ds. > > > > Scenarios 1, 3, and 4 are common in both documents. I think these > > scenarios can be handled by one basic and relatively straight forward > > HA-AAA interface. > > > > I think that also scenario 2 can be handled by the same HA-AAA > interface, even if it might fall in another framework. In section 6 of > draft-giaretta-mip6-aaa-ha-goals-00 we tried to map the goals with the > scenarios: as you can see, the goals for a AAA-HA interface are quite > similar in scearios 1 and 2. The main difference is the provisioning of > configuration parameters (needed in scenario 2) that could be handled > quite easily, imho (e.g. optional AVPs in a Diameter application). I tend to agree with alper. I don't think that we can define a unique solution for all scenarios. For scenario 1, 3 and 4 a AAA application should be defined but I don't think that we need a AAA protocol for scenario 2. -- julien.bournelle@int-evry.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 3 08:50:19 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09332 for ; Wed, 3 Nov 2004 08:50:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPLm6-0005IC-MI for mip6-web-archive@ietf.org; Wed, 03 Nov 2004 09:06:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPLP5-00009s-Js; Wed, 03 Nov 2004 08:42:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPLHG-0007Mg-KZ for mip6@megatron.ietf.org; Wed, 03 Nov 2004 08:34:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08259 for ; Wed, 3 Nov 2004 08:34:16 -0500 (EST) Received: from mn-2.atm.tut.fi ([130.230.52.147] helo=mn-2) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPLWa-0004u2-77 for mip6@ietf.org; Wed, 03 Nov 2004 08:50:08 -0500 Received: from mark by mn-2 with local (Exim 3.36 #1 (Debian)) id 1CPLEv-0003Zs-00; Wed, 03 Nov 2004 15:31:53 +0200 From: Mark Borst To: Samita Chakrabarti In-Reply-To: <200411022030.iA2KUDCj478937@jurassic.eng.sun.com> References: <200411022030.iA2KUDCj478937@jurassic.eng.sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Wed, 03 Nov 2004 15:31:53 +0200 Message-Id: <1099488713.13194.22.camel@mn-2> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, samita.chakrabarti@sun.com Subject: [Mip6] Re: Comments on draft-borst-mip6api-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Hello Thank you for your review. You will find my comments inline. On Tue, 2004-11-02 at 12:29 -0800, Samita Chakrabarti wrote: > I assume this document is an effort to identify usage cases and basic > API for MIP6 applications, which could be a feedback to another organization > which actually will create application level API. We are not completely sure on the path to take with this draft, but at least we have need for this API and are implementing it. > I only had time to review the document in a haste, here are some general > comments. > > - Please mention in the introduction and section 3 (goals and requirements) > that the application level API should use "MIP6 Sockets API" to access > low level data when applicable. This is actually an implementation requirement, which cannot be a 'requirement'. We have extensively thought about it, but it proves to be more a burden than a benefit to use the "MIP6 Sockets API" in this case. The thing is that you are then duplicating a lot of code that is already in the MIPv6 stack, for instance for the movement detection. This is at least valid for the MIPL platform. We could add it as a hint to implementers though. > - This document discusses movement detection for "localized service discovery", > but I assume that a mobile device would implement a "DNA" solution to > achieve movement detection at the system level. That is correct. The whole word 'detection' is not mentioned in the draft. We leave the movement detection part completely to other solutions, as are already implemented or otherwise available. We just want to extract this information from the MIPv6 stack and present it to applications. > If it does not use RO, > then MIP6 implementation takes care of updating HA with new COA. This > should be transparent to the mobileip user applications. > If using RO, the MN/CN takes care of RO signaling and BU/BACK after > finding out the movement as per DNA or other method specified in FMIP6. > Some system apps may need to be involved in that detection - I don't > see why applications need to know the movement at that point. The very point of this leads to the need for movement notification. Maybe the explanation in section 2.1 is not so clear, so let me try to give a very concrete example: A mobile node is in its home network. It uses SLP to find the closest printer, and uses that. Now the mobile node moves to another network. If SLP doesn't know about the movement, it would still use the printer in the home network. To solve this, one can enhance SLP for mobile environments so that it rediscovers the closest printer when it knows that the node has moved. SLP could for instance detect changes in application level (SLP) packets. Or, the way we are proposing, it requests movement notifications from this API that tell it that the node has moved. The latter solution is in our opinion preferable. It is all about telling applications that their environment has changed. MIPv6 goes a long way to hide that, but this is not always desired. > However, if the application wants to know when BUL or BCE gets updated, > it can query the MIP6 system to find out its movement status given the > current COA. An API may be needed at that level. We provide this. > - A few API seem to be important for user level mobile APPs ( they are > addressed in the draft) : > -- whether it is home Provided. > -- whether it has moved ( given the COA that it knows and home-addr) Provided. > -- Lookup of entry of binding given the home-addr/(and may be interface > for multi-interfaced nodes) > [ Providing an API to retrieve all the entries in the list may > not be so useful, IMHO. Instead entry lookup is more useful for > apps. But for performance reason, in some cases the whole list > is useful than going in a loop - perhaps both options are needed] We provide both single-entry lookup and whole-list lookup as we think they are both useful. However, we are open for other ideas. > -- Finding out its home-agent on a particular interface might be > useful as well. Finding domain name might be useful from the > ip-address. That's a good point. We will take it along in our considerations. > > Hope this helps. It does. Thanks. -- Mark Borst Researcher Network and Protocols Group Tampere University of Technology, Finland _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 3 10:27:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19260 for ; Wed, 3 Nov 2004 10:27:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPNIa-0007mB-Mx for mip6-web-archive@ietf.org; Wed, 03 Nov 2004 10:43:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPMt3-0006gW-Nj; Wed, 03 Nov 2004 10:17:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPMlf-0004DE-85 for mip6@megatron.ietf.org; Wed, 03 Nov 2004 10:09:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16820 for ; Wed, 3 Nov 2004 10:09:44 -0500 (EST) From: Franck.Le@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPN0z-0007HO-RH for mip6@ietf.org; Wed, 03 Nov 2004 10:25:38 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA3F9ge08964; Wed, 3 Nov 2004 17:09:42 +0200 (EET) X-Scanned: Wed, 3 Nov 2004 17:09:22 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iA3F9M6X011625; Wed, 3 Nov 2004 17:09:22 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00pM4s67; Wed, 03 Nov 2004 17:08:19 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA3F8Ba07812; Wed, 3 Nov 2004 17:08:11 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Nov 2004 09:08:03 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Last Call Comments: draft-ietf-mip6-firewalls-00.txt Date: Wed, 3 Nov 2004 09:08:03 -0600 Message-ID: <57A26D272F67A743952F6B4371B8F81103F299EA@daebe007.americas.nokia.com> Thread-Topic: [Mip6] Last Call Comments: draft-ietf-mip6-firewalls-00.txt Thread-Index: AcS+GLZRSVpOX176TGGUi+yUV+CRIwDndntA To: , X-OriginalArrivalTime: 03 Nov 2004 15:08:03.0911 (UTC) FILETIME=[EAB44D70:01C4C1B6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: quoted-printable Cc: samita.chakrabarti@sun.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Hello Samita, Thank you for all your comments and suggestions. I will report them on = the issue tracker and we will incorporate them in the next version of = the internet draft to clarify it. Thank you again, Franck > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On Behalf Of > ext Samita Chakrabarti > Sent: 29 October, 2004 07:17 PM > To: mip6@ietf.org > Cc: samita.chakrabarti@sun.com > Subject: [Mip6] Last Call Comments: draft-ietf-mip6-firewalls-00.txt >=20 >=20 > Here are some comments for the mip6-firewalls draft: >=20 > - RRT is mentioned several places in the document, please define this > term in the begining > =20 > - In the section 2.1 , it would be good to clarify the three areas of > firewall packet filtering this document is addressing - such as > addresses (src, dst), ports and protocols. > =20 > =20 > - Section 2.2 talks about packet filtering problem in 3G networks, but > I don't see much relevance of that in this document. This document > structure may be modeled after that- this paragraph may be moved to > appendix or to a different section toward the end ( to show=20 > that similar > deployment problem exists in 3G networks). > =20 > =20 > - section 3.1.1 "Return Routability Test sp" -- what is sp? typo? > This section could be shorter with some more editing. It might be > effective to point out the issue (COTI, but not HOTI) in=20 > the beginiing > of the paragraph. It seems fig 2. could be replaced by fig=20 > 3- thus fig2 > may be redundant. > =20 > - section 3.1.2 last paragraph " Requiring the stateful=20 > inspection ...network" > I am not sure if I understand the problem here. How does=20 > BU come into the > picture? Previously it talks about COTI. I assume, the=20 > same problem applies > to BU/BA between CN (within firewall) and MN (external)=20 > when RR is used. > Also, if the firewall checks for MIP6 nexthdr and type=20 > (COTI, BU, BA), then > it would not be a big issue- becuase the validity checks=20 > are supposed to > happen at CN anyway. For DOS attack, I agree it is easier than > sending packets for a particular port and upperlayer=20 > proto, but DOS attacks > are hard to prevent. I guess we are going into solution=20 > space here- let's > just state the issues.=20 > =20 > - section 3.2 Scenario when the inner node is a Mobile Node > I think this section needs to discuss the two cases: > 1) when MN moves within the same Firewalled network > 2) when MN moves into the firewalled network from=20 > external network > =20 > - section 3.2.1=20 > Issue with ESP and Firewall: > -- Firewall dropping ESP packets is a IPsec issue -=20 > which is not > MIP6 problem. It should be solved though for=20 > deployment for MIP6. > =20 > -- ESP protecting mobility header in transport mode or=20 > tunnel mode > could be a problem if we want to allow MIP6 BU/BA=20 > between MN-HA > in the firewall. > You may want to clarify these two cases.=20 > =20 > -- section 3.2.2 >=20 > This section discusses about state life time issue- but it is not > clear to me how CN-MN come into question given that we=20 > were talking > about MN-HA states. Is it talking about problem with IP-n_IP IPsec > tunnel where the ESP header sits above the internal IPv6 header ( > MN(HOA)-->HAA) ? This can be clarified by giving the=20 > packet sequence > as described in RFC3776. > =20 > =20 > -- section 3.2.3 > This section needs editing for concise description. Also=20 > it needs to > separate issues in subsections such as HOTI/HOT under ESP=20 > tunnel or > COTI/COT or BU to the CN. This section is again trying to=20 > indicate=20 > some solutions - it may be good idea not to suggest that=20 > in this doc. > =20 > -- section 3.2.4 =3D=3D> this really belongs to section 3.2 as one of = the > configurations. > =20 > -- section 3.2.5=20 > Please clarify two cases (without and with RR). > If RR is not used then it is no different (wrt the new FW and MN) > than external MN is moving into firewalled network as MN=20 > needs to rebuild a new tunnel to HA assuming its COA changes. > =20 > BTW, it is good to see this document which discusses the=20 > real-life issues. >=20 > Thanks, > -Samita > =20 > =20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 3 18:18:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02100 for ; Wed, 3 Nov 2004 18:18:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPUdp-0002OX-H2 for mip6-web-archive@ietf.org; Wed, 03 Nov 2004 18:34:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPUNT-000413-P0; Wed, 03 Nov 2004 18:17:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPUKD-0002Ey-Nk for mip6@megatron.ietf.org; Wed, 03 Nov 2004 18:13:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01534 for ; Wed, 3 Nov 2004 18:13:55 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPUZa-0002Hw-4W for mip6@ietf.org; Wed, 03 Nov 2004 18:29:53 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6M00K0OLU9S8@mailout2.samsung.com> for mip6@ietf.org; Thu, 04 Nov 2004 08:13:21 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6M002CBLU8E5@mailout2.samsung.com> for mip6@ietf.org; Thu, 04 Nov 2004 08:13:21 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6M00GS1LU6M3@mmp2.samsung.com> for mip6@ietf.org; Thu, 04 Nov 2004 08:13:20 +0900 (KST) Date: Wed, 03 Nov 2004 15:13:18 -0800 From: Alper Yegin Subject: RE: [Mip6] Comments on jee-mip6-bootstrap-pana In-reply-to: <011401c4c178$09609f60$38f2fe81@RESTART> To: "'Junghoon Jee'" , mip6@ietf.org Message-id: <00b101c4c1fa$b56a64d0$6901a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7BIT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7BIT JungHoon, > > HA can contact the AAA server when the MN starts the IKE exchange. > > You mean that the HA requests the bootstrapping information to the AAA > server > after the HA receives the IKE initiation message from the MN ? > If so, isn't there any open issues about initiating IKE exchange between > the MN and HA > before the HA gets bootstrapping information ? The flow in my mind is this: 1. MN engages in network access AAA. That sets up state on AAAh. 2. MN starts IKE with the HA. That triggers the HA contact with AAAh. So, it is the IKE exchange that prompts the HA to contact the AAAh. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 4 05:33:54 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06810 for ; Thu, 4 Nov 2004 05:33:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPfBl-000072-KJ for mip6-web-archive@ietf.org; Thu, 04 Nov 2004 05:49:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPeoJ-0000b8-5o; Thu, 04 Nov 2004 05:25:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPeaB-0007Ah-1F for mip6@megatron.ietf.org; Thu, 04 Nov 2004 05:11:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05234 for ; Thu, 4 Nov 2004 05:11:05 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPepf-00083q-8b for mip6@ietf.org; Thu, 04 Nov 2004 05:27:08 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iA4AB3BO023009; Thu, 4 Nov 2004 11:11:03 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iA4AB3BO016751; Thu, 4 Nov 2004 11:11:03 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR0LW1>; Thu, 4 Nov 2004 11:11:03 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F05319F6C@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Alper Yegin , mip6@ietf.org Subject: RE: [Mip6] Comments on jee-mip6-bootstrap-pana Date: Thu, 4 Nov 2004 11:11:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 hi alper, when i read the draft i came accross the same questions. i like your pull (instead of the push approach). this might also work nicely with . i wasn't sure how and when the MIPv6-AAA-Key is computed as well. a minor correction to your mail: the diameter application ships the parameters to the PAA (and not to the mobile node). this is the reason why a pana protocol is required which carries the parameters finally to the end host. this is probably the most important difference with regard to the draft. ciao hannes ps: it might be good to reference an old draft which proposed the same approach. i also remember that julien published a draft with a similar idea some time ago. > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@samsung.com] > Sent: Dienstag, 02. November 2004 02:23 > To: mip6@ietf.org > Subject: [Mip6] Comments on jee-mip6-bootstrap-pana > > Hello, > > Here are some comments and questions on the > draft-jee-mip6-bootstrap-pana-00.txt. > > - I see the new Diameter application has two functionalities. > Regarding the delivery of the bootstrapping information to > the MN, I was wondering if we could get away with not > defining new commands, but instead piggybacking on existing > NAS application? The bootstrapping information could be > delivered to the NAS as part of the mobile's profile. > > - The other functionality is the push of bootstrapping > information from AAAh to HA. This is carried in serial with > the (in fact, in the middle > of) network access AAA. I think it could be done in parallel, > or even after the network access AAA. If you use a pull model > instead of the push, this part gets aligned with the > yegin-mip6-aaa-fwk. > > - I didn't quite understand how the MN obtains/computes the > MIPv6-AAA-Key. It is only provided with the MIPv6-AAA-Key-Id, > and that's not sufficient to derive the key. > > Thanks in advance. > > Alper > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 4 07:57:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16030 for ; Thu, 4 Nov 2004 07:57:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPhQe-00038h-Tg for mip6-web-archive@ietf.org; Thu, 04 Nov 2004 08:13:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPh9A-0003Pv-TE; Thu, 04 Nov 2004 07:55:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPh7B-00033i-2Y for mip6@megatron.ietf.org; Thu, 04 Nov 2004 07:53:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15762 for ; Thu, 4 Nov 2004 07:53:20 -0500 (EST) Received: from cms1.etri.re.kr ([129.254.16.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPhMh-00032g-Ep for mip6@ietf.org; Thu, 04 Nov 2004 08:09:24 -0500 Received: from ETRIYSLEE (218.234.143.66 [218.234.143.66]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VRH24BWZ; Thu, 4 Nov 2004 21:52:43 +0900 Message-ID: <002b01c4c26d$2a6962f0$428feada@ETRIYSLEE> From: "Junghoon Jee" To: "Tschofenig Hannes" , "Alper Yegin" , References: <2A8DB02E3018D411901B009027FD3A3F05319F6C@mchp905a.mch.sbs.de> Subject: Re: [Mip6] Comments on jee-mip6-bootstrap-pana Date: Thu, 4 Nov 2004 21:52:00 +0900 Organization: CMS MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 1.1 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Junghoon Jee List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0435496586==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --===============0435496586== Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGFubmVzLA0KDQo+IA0KPiB3aGVuIGkgcmVhZCB0aGUgZHJhZnQgaSBjYW1lIGFjY3Jvc3MgdGhl IHNhbWUgcXVlc3Rpb25zLiANCj4gDQo+IGkgbGlrZSB5b3VyIHB1bGwgKGluc3RlYWQgb2YgdGhl IHB1c2ggYXBwcm9hY2gpLiB0aGlzIG1pZ2h0IGFsc28gd29yayBuaWNlbHkNCj4gd2l0aCA8ZHJh ZnQtaWV0Zi1taXA2LWF1dGgtcHJvdG9jb2wtMDAudHh0Pi4gDQoNCkNhbiB5b3UgZXhwbGFpbiB0 aGlzIHBvaW50IG1vcmUgY29uY3JldGVseSA/DQoNCj4gaSB3YXNuJ3Qgc3VyZSBob3cgYW5kIHdo ZW4gdGhlIE1JUHY2LUFBQS1LZXkgaXMgY29tcHV0ZWQgYXMgd2VsbC4gDQoNCkkgYW5zd2VyZWQg dGhhdCBxdWVzdGlvbiB0aHJvdWdoIG15IHByZXZpb3VzIG1haWwuDQpGb3IgY2xhcml0eSwgDQpU aGUgQUFBIHNlcnZlciBhbmQgdGhlIE1OIG1haW50YWlucyB0aGUga2V5IG1hcHBpbmcgdGFibGUs IE1JUHY2LUFBQS1LZXktSWQgdnMuIE1JUHY2LUFBQS1LZXkuDQpXaGVuIEVBUCBhdXRoZW50aWNh dGlvbiBpcyBzdWNjZWVkZWQsIHRoZSBNSVB2Ni1BQUEtS2V5IGFuZCBpdHMgaWQuIGFyZSBzdG9y ZWQgdG8gdGhlIGtleSBtYXBwaW5nIHRhYmxlLg0KVGhlIE1JUHY2LUFBQS1LZXkgY2FuIGJlIGFu IEFBQS1LZXkgb3IgY29uY2F0ZW5hdGlvbiBvZiB0aGUgQUFBLUtleScgd2l0aCBBQUEtS2V5Jycg aWYgbXVsdGlwbGUNCnNlc3Npb24ga2V5cyBhcmUgZGVyaXZlZCBieSB0aGUgRUFQIGF1dGhlbnRp Y2F0aW9uIHByb2Nlc3MuIA0KVGhlIGNob2ljZSBvZiB3aGljaCBrZXkgdG8gdXNlIHRvIGRlcml2 ZSBNSVB2NiBJS0UgUFNLIGlzIGRldGVybWluZWQgYnkgdGhlIEFBQSBob21lIHNlcnZlci4gDQpU aGUgQUFBIGhvbWUgc2VydmVyIG5vdGlmaWVzIHRoZSBNTiB3aGljaCBrZXkgdG8gdXNlIGJ5IHNl bmRpbmcgdGhlIE1JUHY2LUFBQS1LZXktSWQuDQoNCj4gYSBtaW5vciBjb3JyZWN0aW9uIHRvIHlv dXIgbWFpbDogdGhlIGRpYW1ldGVyIGFwcGxpY2F0aW9uIHNoaXBzIHRoZQ0KPiBwYXJhbWV0ZXJz IHRvIHRoZSBQQUEgKGFuZCBub3QgdG8gdGhlIG1vYmlsZSBub2RlKS4gdGhpcyBpcyB0aGUgcmVh c29uIHdoeSBhDQo+IHBhbmEgcHJvdG9jb2wgaXMgcmVxdWlyZWQgd2hpY2ggY2FycmllcyB0aGUg cGFyYW1ldGVycyBmaW5hbGx5IHRvIHRoZSBlbmQNCj4gaG9zdC4gdGhpcyBpcyBwcm9iYWJseSB0 aGUgbW9zdCBpbXBvcnRhbnQgZGlmZmVyZW5jZSB3aXRoIHJlZ2FyZCB0byB0aGUNCj4gPGRyYWZ0 LWdpYXJldHRhLW1pcDYtYXV0aG9yaXphdGlvbi1lYXA+IGRyYWZ0Lg0KDQpSaWdodCwgSSBhZ3Jl ZSB3aXRoIHlvdS4NCg0KPiAgIA0KPiBwczogaXQgbWlnaHQgYmUgZ29vZCB0byByZWZlcmVuY2Ug YW4gb2xkIGRyYWZ0DQo+IDxkcmFmdC1sZS1hYWEtZGlhbWV0ZXItbW9iaWxlaXB2Ni0wMi50eHQ+ IHdoaWNoIHByb3Bvc2VkIHRoZSBzYW1lIGFwcHJvYWNoLg0KPiBpIGFsc28gcmVtZW1iZXIgdGhh dCBqdWxpZW4gcHVibGlzaGVkIGEgZHJhZnQgd2l0aCBhIHNpbWlsYXIgaWRlYSBzb21lIHRpbWUN Cj4gYWdvLiANCg0KVGhlIHByZXZpb3VzIGRyYWZ0LWxlLWFhYS1kaWFtZXRlci1tb2JpbGVpcHY2 LTAzLnR4dCBpcyBhIGdvb2QgcmVmZXJlbmNlIGZvciBvdXIgd29yay4NCkluIHRoYXQgZHJhZnQs IEJVIG1lc3NhZ2UgaXMgcHJvY2Vzc2VkIGR1cmluZyB0aGUgQUFBIGF1dGguICYgYXV0aG9yaXph dGlvbiBwaGFzZS4NClRoZSBCVSBtZXNzYWdlIGNhbiBiZSBwaWdneWJhY2tlZCB0byB0aGUgQUFB IGF1dGggcmVxdWVzdCBtZXNzYWdlIA0Kb3IgaXQgY2FuIGJlIHByb2R1Y2VkIG9uIHRoZSBBQUEg c2VydmVyLiANCkluIHRoZSBkcmFmdC1qZWUtbWlwNi1ib290c3RyYXAtYWFhLTAwLCBCVSBpcyBw cm9jZXNzZWQgYWZ0ZXIgdGhlIEFBQSBhdXRoICYgYXV0aG9yaXphdGlvbiBwaGFzZS4NClRoaXMg aXMgYmVjYXVzZSB0aGUgQlUgTVVTVCBiZSBwcm90ZWN0ZWQgYnkgdGhlIElQc2VjIFNBIGFjY29y ZGluZyB0byB0aGUgUkZDIDM3NzUuDQpJZiB0aGUgIGRyYWZ0LWlldGYtbWlwNi1hdXRoLXByb3Rv Y29sLTAwLnR4dCBpcyB1c2VkLCANCkJVIG1heSBiZSBwaWdneWJhY2tlZCBkdXJpbmcgdGhlIEFB QSBhdXRoJiBhdXRob3JpemF0aW9uIHBoYXNlIGlmIHRoZSBNTidzIENvQSBpcyBjb25maWd1cmVk Lg0KDQoNCkp1bmdob29uDQoNCg0KDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g PiBGcm9tOiBBbHBlciBZZWdpbiBbbWFpbHRvOmFscGVyLnllZ2luQHNhbXN1bmcuY29tXSANCj4g PiBTZW50OiBEaWVuc3RhZywgMDIuIE5vdmVtYmVyIDIwMDQgMDI6MjMNCj4gPiBUbzogbWlwNkBp ZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFtNaXA2XSBDb21tZW50cyBvbiBqZWUtbWlwNi1ib290c3Ry YXAtcGFuYQ0KPiA+IA0KPiA+IEhlbGxvLA0KPiA+IA0KPiA+IEhlcmUgYXJlIHNvbWUgY29tbWVu dHMgYW5kIHF1ZXN0aW9ucyBvbiB0aGUgDQo+ID4gZHJhZnQtamVlLW1pcDYtYm9vdHN0cmFwLXBh bmEtMDAudHh0Lg0KPiA+IA0KPiA+IC0gSSBzZWUgdGhlIG5ldyBEaWFtZXRlciBhcHBsaWNhdGlv biBoYXMgdHdvIGZ1bmN0aW9uYWxpdGllcy4gDQo+ID4gUmVnYXJkaW5nIHRoZSBkZWxpdmVyeSBv ZiB0aGUgYm9vdHN0cmFwcGluZyBpbmZvcm1hdGlvbiB0byANCj4gPiB0aGUgTU4sIEkgd2FzIHdv bmRlcmluZyBpZiB3ZSBjb3VsZCBnZXQgYXdheSB3aXRoIG5vdCANCj4gPiBkZWZpbmluZyBuZXcg Y29tbWFuZHMsIGJ1dCBpbnN0ZWFkIHBpZ2d5YmFja2luZyBvbiBleGlzdGluZyANCj4gPiBOQVMg YXBwbGljYXRpb24/IFRoZSBib290c3RyYXBwaW5nIGluZm9ybWF0aW9uIGNvdWxkIGJlIA0KPiA+ IGRlbGl2ZXJlZCB0byB0aGUgTkFTIGFzIHBhcnQgb2YgdGhlIG1vYmlsZSdzIHByb2ZpbGUuDQo+ ID4gDQo+ID4gLSBUaGUgb3RoZXIgZnVuY3Rpb25hbGl0eSBpcyB0aGUgcHVzaCBvZiBib290c3Ry YXBwaW5nIA0KPiA+IGluZm9ybWF0aW9uIGZyb20gQUFBaCB0byBIQS4gVGhpcyBpcyBjYXJyaWVk IGluIHNlcmlhbCB3aXRoIA0KPiA+IHRoZSAoaW4gZmFjdCwgaW4gdGhlIG1pZGRsZQ0KPiA+IG9m KSBuZXR3b3JrIGFjY2VzcyBBQUEuIEkgdGhpbmsgaXQgY291bGQgYmUgZG9uZSBpbiBwYXJhbGxl bCwgDQo+ID4gb3IgZXZlbiBhZnRlciB0aGUgbmV0d29yayBhY2Nlc3MgQUFBLiBJZiB5b3UgdXNl IGEgcHVsbCBtb2RlbCANCj4gPiBpbnN0ZWFkIG9mIHRoZSBwdXNoLCB0aGlzIHBhcnQgZ2V0cyBh bGlnbmVkIHdpdGggdGhlIA0KPiA+IHllZ2luLW1pcDYtYWFhLWZ3ay4NCj4gPiANCj4gPiAtIEkg ZGlkbid0IHF1aXRlIHVuZGVyc3RhbmQgaG93IHRoZSBNTiBvYnRhaW5zL2NvbXB1dGVzIHRoZSAN Cj4gPiBNSVB2Ni1BQUEtS2V5LiBJdCBpcyBvbmx5IHByb3ZpZGVkIHdpdGggdGhlIE1JUHY2LUFB QS1LZXktSWQsIA0KPiA+IGFuZCB0aGF0J3Mgbm90IHN1ZmZpY2llbnQgdG8gZGVyaXZlIHRoZSBr ZXkuDQo+ID4gDQo+ID4gVGhhbmtzIGluIGFkdmFuY2UuDQo+ID4gDQo+ID4gQWxwZXINCj4gPiAN Cj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IE1pcDYgbWFpbGluZyBsaXN0DQo+ID4gTWlw NkBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21p cDYNCj4gPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IE1pcDYgbWFpbGluZyBsaXN0DQo+IE1pcDZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlwNg== --===============0435496586== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0435496586==-- From mip6-bounces@ietf.org Thu Nov 4 08:37:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19737 for ; Thu, 4 Nov 2004 08:37:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPi3O-00047b-EW for mip6-web-archive@ietf.org; Thu, 04 Nov 2004 08:53:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPhf1-0008PB-UH; Thu, 04 Nov 2004 08:28:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPhZC-0007JU-Hx for mip6@megatron.ietf.org; Thu, 04 Nov 2004 08:22:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18348 for ; Thu, 4 Nov 2004 08:22:17 -0500 (EST) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPhog-0003n2-12 for mip6@ietf.org; Thu, 04 Nov 2004 08:38:21 -0500 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by smtp2.int-evry.fr (Postfix) with ESMTP id C03722FEDA; Thu, 4 Nov 2004 14:22:29 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1CPhWv-0002zh-24; Thu, 04 Nov 2004 14:19:57 +0100 Date: Thu, 4 Nov 2004 14:19:57 +0100 From: Julien Bournelle To: Junghoon Jee Subject: Re: [Mip6] Comments on jee-mip6-bootstrap-pana Message-ID: <20041104131957.GL10930@ipv6-5.int-evry.fr> References: <2A8DB02E3018D411901B009027FD3A3F05319F6C@mchp905a.mch.sbs.de> <002b01c4c26d$2a6962f0$428feada@ETRIYSLEE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002b01c4c26d$2a6962f0$428feada@ETRIYSLEE> X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-5.817, requis 4.5, autolearn=not spam, ALL_TRUSTED -3.30, AWL 0.08, BAYES_00 -2.60) X-MailScanner-From: jb@ipv6-5.int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Alper Yegin , mip6@ietf.org, Tschofenig Hannes X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 hi, just a little comment inline, > > ps: it might be good to reference an old draft > > which proposed the same approach. > > i also remember that julien published a draft with a similar idea some time > > ago. > > The previous draft-le-aaa-diameter-mobileipv6-03.txt is a good reference for our work. > In that draft, BU message is processed during the AAA auth. & authorization phase. > The BU message can be piggybacked to the AAA auth request message > or it can be produced on the AAA server. > In the draft-jee-mip6-bootstrap-aaa-00, BU is processed after the AAA auth & authorization phase. > This is because the BU MUST be protected by the IPsec SA according to the RFC 3775. > If the draft-ietf-mip6-auth-protocol-00.txt is used, > BU may be piggybacked during the AAA auth& authorization phase if the MN's CoA is configured. I think that one of the major issue with this approach (defining a specific AAA application for Mobile IPv6) is that all visited network MUST use this specific AAA application if you want to bootstrapp Mobile IPv6. Thus, if the visited network uses Diameter-EAP or RADIUS-EAP, you can't bootstrapp Mobile IPv6. This imply that all operators should deploy this solution. With our approach (draft-giaretta), the visited network does not need to Mobile IPV6 aware. -- julien.bournelle@int-evry.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 4 08:52:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20860 for ; Thu, 4 Nov 2004 08:52:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPiHg-0004U0-Op for mip6-web-archive@ietf.org; Thu, 04 Nov 2004 09:08:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPhw7-0002wQ-7D; Thu, 04 Nov 2004 08:45:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPNcQ-0008B9-F4; Wed, 03 Nov 2004 11:04:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22029; Wed, 3 Nov 2004 11:04:16 -0500 (EST) Received: from mx1.iit.cnr.it ([146.48.98.40] helo=mx.iit.cnr.it) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPNrl-00007U-5b; Wed, 03 Nov 2004 11:20:10 -0500 Received: from localhost (mx.iit.cnr.it [127.0.0.1]) by mx.iit.cnr.it (Postfix) with ESMTP id C941E2EF4F; Wed, 3 Nov 2004 17:03:43 +0100 (CET) Received: from mx.iit.cnr.it ([127.0.0.1]) by localhost (mx.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17432-16; Wed, 3 Nov 2004 17:03:40 +0100 (CET) Received: from delmastro1 (delmastrof.iit.cnr.it [146.48.98.74]) by mx.iit.cnr.it (Postfix) with ESMTP id 053202EE1B; Wed, 3 Nov 2004 17:03:03 +0100 (CET) Message-ID: <002301c4c1be$9cb7e160$51d9fea9@delmastro1> From: "Franca Delmastro" To: "Franca Delmastro" Date: Wed, 3 Nov 2004 17:03:06 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by Content Checker at iit.cnr.it X-Spam-Score: 0.7 (/) X-Scan-Signature: 9724479da43a8325ad975c1a9b841870 X-Mailman-Approved-At: Thu, 04 Nov 2004 08:45:56 -0500 Subject: [Mip6] [WoWMoM 2005] Cfp: Submission Deadline EXTENDED to November 20 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1728766943==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 9361ae25efd9cff62e36f70ef966350e This is a multi-part message in MIME format. --===============1728766943== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C4C1C6.FCFC8730" This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C4C1C6.FCFC8730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= We apologize in advance if you receive multiple copies of this CFP. ************************************************************* CALL FOR PAPERS WoWMoM 2005 IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks http://cnd.iit.cnr.it/wowmom2005 Taormina, Italy, June 13-16, 2005 Sponsored by The IEEE Computer Society The University of Texas at Arlington Technical sponsored by IEEE TCCC **** Submission Deadline --- November 10, 2004 **** Extended to November 20, 2004 ************************************************************** Technology evolution is driving toward a world of wireless, mobile, and multimedia pervasive communications where users can seamlessly and ubiquitously accomplish their tasks, access information or communicate with other users all the anytime, everywhere, and from any device. Technologies include, among others, IEEE 802.11, 802.15, 802.16, Mobile IP, micro-mobility protocols, IP paging, wireless IP QOS, mobile ad hoc and sensor networks, and cellular networks. In addition to these, new and emerging technologies (e.g., UWB) need to be taken into account. The resulting networking environment will constitute the fourth generation wireless networks. 4G will integrate different types of wireless networks with wire-line backbone network seamlessly, and provide the convergence of voice, multimedia and data traffic over a single IP based core network. WoWMoM 2005 technical program committee is soliciting papers addressing the research challenges toward a world of wireless, mobile, and multimedia pervasive communications. Two types of contributions will be accepted: FULL PAPERS: Full Papers must present original, previously unpublished, complete works, validated by experimentation, simulation, or analysis. Practical experiences and experimental efforts are welcome. POSITION PAPERS: Papers in this category must be visionary, innovative and forward-looking. They must offer new perspectives opening future research directions, rather than by presenting mature work with quantitative results. Only a limited number of slots will be available for position papers that will be reviewed primarily for relevance and originality. Topics of interest for WOWMOM 2005 include, but are not limited to: - System prototypes and experiences - Software technologies and systems - QoS for real-time voice and video in wireless networks - Interactive broadband television, gaming, and video distribution - Middleware support for QoS provision - Caching and content management in WLANs and WMANs - Differentiated service in wireless multimedia networks - IP-based multimedia services over wireless networks - Networking services for ambient intelligent and pervasive environments - Multicasting and broadcasting problems and solutions - Handoff and mobility management - Seamless internetworking - IP-based mobile networks - Location mechanism and services - Wireless BAN, PAN, LAN, and MAN - Ad hoc and sensor networks - Vehicular wireless networks - Access technologies - Third and fourth generation systems - Energy-efficient protocols and power management - Wireless security and authentication - Pricing and billing - Modeling and Performance evaluation PAPER SUBMISSION AND PUBLICATION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Papers should neither have been published elsewhere nor currently under review by another conference or journal. Guidelines on paper submission and formatting will be provided on the website. Accepted papers will appear in the symposium proceedings published by IEEE. IMPORTANT DATES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Full papers due: November 10, 2004 Extended to: November 20, 2004 Notification: January 20, 2005 Camera Ready due: February 15, 2005 ORGANIZING COMMITTEE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D GENERAL Co-Chairs: Giuseppe Anastasi, University of Pisa, Italy Sajal K. Das, The University of Texas at Arlington, USA PROGRAM Co-Chairs: Marco Conti, IIT-CNR, Italy Dipankar Raychaudhuri WINLAB/Rutgers University, USA FINANCE & REGISTRATION Chair: Yonghe Liu, The University of Texas at Arlington, USA PUBLICITY Co-Chairs: Mainak Chatterjee, Univ. Central Florida, USA Sunghyun Choi, Seoul National University, Korea Franca Delmastro, IIT-CNR, Italy PUBLICATION Co-Chairs: Eleonora Borgia, IIT-CNR, Italy Luciana Pelusi, IIT-CNR, Italy SPONSORSHIP Chair Alessandro Genco, University of Palermo, Italy LOCAL ARRANGEMENTS Chair: Antonio Puliafito, University of Messina, Italy WEB DESIGNER & MANAGER: Patrizia Andronico, IIT-CNR, Italy STEERING COMMITTEE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Marco Conti, IIT-CNR, Italy Sajal K. Das, The University of Texas at Arlington, USA (chair) Dipankar Raychaudhuri WINLAB/Rutgers University, USA Satish K. Tripathi, SUNY Buffalo, USA PROGRAM COMMITTEE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Arup Acharya, IBM T.J. Watson Research, USA Dharma P. Agrawal, University of Cincinnati, USA Kevin C. Almeroth, University of California at Santa Barbara, USA Christian Becker, University of Stuttgart, Germany Giuseppe Bianchi, University of Rome "Tor Vergata", Italy Chris Blondia, University of Antwerp, Belgium Azzedine Boukerche, University of Ottawa, Canada Jiannong Cao, Hong Kong Polytechnic University, Hong Kong Chua Kee Chaing, National University of Singapore, Republic of Singapore Rajarathnam Chandramouili, Stevens Institute of Technology, USA Mainak Chatterjee, University of Central Florida, USA Carla-Fabiana Chiasserini, Polytechnic of Turin, Italy A. Chockalingam, Indian Institute of Science, Banglore, India Sunghyun Choi, Seoul National University, Korea Antonio Corradi, University of Bologna, Italy Antony Ephremides, University of Maryland, USA Gabor Fodor, Ericsson, Sweden Luigi Fratta, Polytechnic of Milan, Italy Marco Gruteser, Rutgers University, USA Paul J.M. Havinga, University of Twente, The Netherlands Kazuo Imai, NTT DoCoMo, Japan Holger Karl, Universtit=E4t Paderborn, Germany Anurag Kumar, Indian Inst of Science, Bangalore, India Mohan Kumar, The University of Texas at Arlington, USA P. R. Kumar, University of Illinois, USA Masahiro Kuroda, National Institute of Info. and Com. Tech., Japan Luciano Lenzini, University of Pisa, Italy K. Ben Letaief, Hong Kong Univ. Science & Technology, Hong Kong Victor Leung, The University of British Columbia, Canada Yonghe Liu, Univ. Texas at Arlington, USA Giri Mandyam, Nokia Research Center, USA Martin Mauve, University of Dusseldorf, Germany Archan Misra, IBM T.J. Watson Research, USA Refik Molva, Institut Eurecom, France Giacomo Morabito, University of Catania, Italy Hiroyuki Morikawa, , University of Tokyo, Japan Stephan Olariu, Old Dominion University, USA Maximilian Ott, Semandex Networks, USA Michael Paterakis, Technical University of Crete, Greece George C. Polyzos, Athens University of Economics and Business, Greece Antonio Puliafito, University of Messina, Italy Jochen H. Schiller, Freie Universit=E4t Berlin, Germany Henning Schulzrinne, Columbia University, USA Rajeev Shorey, IBM India Research Lab, India Ivan Stojmenovic, University of Ottawa, Canada Violet R. Syrotiuk, Arizona State University, USA Wade Trappe, Rutgers University, USA Ooi Wei Tsang, National University of Singapore, Singapore Christian Tschudin, Basel University, Switzerland Thierry Turletti, INRIA France Andras Valko, Ericsson, Hungary Bernard Walke, Aachen University of Technology, Germany Xingwei Wang, Northeastern Univ, China Jie Wu, Florida Atlantic University, USA Gergely Zaruba, The University of Texas at Arlington, USA Roger Zimmerman, University of Southern California, USA ************************************************************ Franca Delmastro Pervasive Computing & Networking Lab. (PerLab) IIT- National Research Council via G. Moruzzi,1 56124 Pisa, Italy ******************************************************** ------=_NextPart_000_0020_01C4C1C6.FCFC8730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
 
----------------------------------------------------------------= ---------

We apologize in advance if you = receive multiple=20 copies of this=20 CFP.
*************************************************************

          &nbs= p;         &nbs= p;  =20 CALL FOR PAPERS

          &nbs= p;         &nbs= p;    =20 WoWMoM 2005
         IEEE=20 International Symposium on a World of=20 Wireless,
          =        =20 Mobile and Multimedia=20 Networks

         &nb= sp;      =20 http://cnd.iit.cnr.it/wowmom2005
      &= nbsp;        =20 Taormina, Italy, June 13-16,=20 2005

          &= nbsp;         &= nbsp;    =20 Sponsored=20 by
           <= SPAN>       =20 The IEEE Computer=20 Society
          &n= bsp; =20 The University of Texas at=20 Arlington
          =    =20 Technical sponsored by IEEE=20 TCCC

        **** Submission = Deadline=20 --- November 10, 2004 ****
          &nbs= p;            = ; =20  Extended to November 20,=20 2004
**********************************************************= ****


Technology=20 evolution is driving toward a world of wireless,
mobile, and = multimedia=20 pervasive communications where users can
seamlessly and ubiquitously=20 accomplish their tasks, access information
or communicate with other = users=20 all the anytime, everywhere, and from
any device. Technologies = include, among=20 others, IEEE 802.11,
802.15, 802.16, Mobile IP, micro-mobility = protocols, IP=20 paging,
wireless IP QOS, mobile ad hoc and sensor networks, and=20 cellular
networks.
In addition to these, new and emerging = technologies=20 (e.g., UWB) need to
be taken into account.  The resulting = networking=20 environment will
constitute the fourth generation wireless networks. = 4G will=20 integrate
different types of wireless networks with wire-line = backbone=20 network
seamlessly, and provide the convergence of voice, multimedia=20 and
data traffic over a single IP based core network.  WoWMoM = 2005=20 technical
program committee is soliciting papers addressing the=20 research
challenges
toward a world of wireless, mobile, and = multimedia=20 pervasive
communications.
Two types of contributions will be=20 accepted:

FULL PAPERS: Full Papers must present original, = previously=20 unpublished,
complete works, validated by experimentation, = simulation, or=20 analysis.
Practical experiences and experimental efforts are=20 welcome.

POSITION PAPERS: Papers in this category must be = visionary,=20 innovative
and forward-looking. They must offer new perspectives = opening=20 future
research directions, rather than by presenting mature work=20 with
quantitative results. Only a limited number of slots will be=20 available
for
position papers that will be reviewed primarily for=20 relevance and
originality.

Topics of interest for WOWMOM 2005 = include,=20 but are not limited to:
- System prototypes and experiences
- = Software=20 technologies and systems
- QoS for real-time voice and video in = wireless=20 networks
- Interactive broadband television, gaming, and video=20 distribution
- Middleware support for QoS provision
- Caching and = content=20 management in WLANs and WMANs
- Differentiated service in wireless = multimedia=20 networks
- IP-based multimedia services over wireless networks
-=20 Networking services for ambient intelligent and pervasive = environments
-=20 Multicasting and broadcasting problems and solutions
- Handoff and = mobility=20 management
- Seamless internetworking
- IP-based mobile=20 networks
- Location mechanism and = services
- Wireless=20 BAN, PAN, LAN, and MAN
- Ad hoc and sensor networks
- Vehicular = wireless=20 networks
- Access technologies
- Third and fourth generation = systems
-=20 Energy-efficient protocols and power management
- Wireless security = and=20 authentication
- Pricing and billing
- Modeling and Performance=20 evaluation

PAPER SUBMISSION AND=20 PUBLICATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Papers should neither have been = published=20 elsewhere nor currently
under review by another conference or = journal. =20 Guidelines on paper
submission and formatting will be = provided on=20 the website.
Accepted papers will appear in the symposium proceedings = published by
IEEE.


IMPORTANT = DATES
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Full=20 papers due:        November 10,=20 2004
Extended to:     = November 20,=20 2004
Notification:        &nb= sp; =20 January 20, 2005
Camera Ready = due:      =20 February 15, 2005


ORGANIZING COMMITTEE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
GENERAL=20 Co-Chairs:
        Giuseppe = Anastasi,=20 University of Pisa, Italy
        = Sajal K.=20 Das, The University of Texas at Arlington, USA

PROGRAM=20 Co-Chairs:
        Marco Conti, = IIT-CNR,=20 Italy
        Dipankar = Raychaudhuri=20 WINLAB/Rutgers University, USA


FINANCE & REGISTRATION=20 Chair:
         Yonghe Liu, = The=20 University of Texas at Arlington, USA
PUBLICITY=20 Co-Chairs:
         Mainak=20 Chatterjee, Univ. Central Florida,=20 USA
         Sunghyun Choi, = Seoul=20 National University, Korea
        =20 Franca Delmastro, IIT-CNR, Italy


PUBLICATION Co-Chairs:
        =20 Eleonora Borgia, IIT-CNR, Italy
        =20 Luciana Pelusi, IIT-CNR, Italy


SPONSORSHIP Chair
        Alessandro = Genco,=20 University of Palermo, Italy


LOCAL ARRANGEMENTS=20 Chair:
        Antonio Puliafito,=20 University of Messina, Italy


WEB DESIGNER &=20 MANAGER:
        Patrizia = Andronico,=20 IIT-CNR, Italy



STEERING=20 COMMITTEE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ma= rco Conti, IIT-CNR, Italy
Sajal K. Das,=20 The University of Texas at Arlington, USA (chair)
Dipankar = Raychaudhuri=20 WINLAB/Rutgers University, USA
Satish K. Tripathi, SUNY Buffalo,=20 USA


PROGRAM = COMMITTEE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Arup = Acharya, IBM T.J.=20 Watson Research, USA
Dharma P. Agrawal, University of Cincinnati,=20 USA
Kevin C. Almeroth, University of California at Santa Barbara,=20 USA
Christian Becker, University of Stuttgart, Germany
Giuseppe = Bianchi,=20 University of Rome "Tor Vergata", Italy
Chris Blondia, University of = Antwerp,=20 Belgium
Azzedine  Boukerche, University of Ottawa, = Canada
Jiannong=20 Cao, Hong Kong Polytechnic University, Hong Kong
Chua Kee Chaing, = National=20 University of Singapore, Republic of Singapore
Rajarathnam = Chandramouili,=20 Stevens Institute of Technology, USA
Mainak Chatterjee, University of = Central=20 Florida, USA
Carla-Fabiana Chiasserini, Polytechnic of Turin, = Italy
A.=20 Chockalingam, Indian Institute of Science, Banglore, India
Sunghyun = Choi,=20 Seoul National University, Korea
Antonio Corradi, University of = Bologna,=20 Italy
Antony Ephremides, University of Maryland, USA
Gabor Fodor,=20 Ericsson, Sweden
Luigi Fratta, Polytechnic of Milan, Italy
Marco = Gruteser,=20 Rutgers University, USA
Paul J.M. Havinga, University of Twente, The=20 Netherlands
Kazuo Imai, NTT DoCoMo, Japan
Holger Karl, Universtit=E4t = Paderborn,=20 Germany
Anurag Kumar, Indian Inst of = Science, Bangalore,=20 India
Mohan Kumar, The University of Texas at Arlington, USA
P. R. = Kumar,=20 University of Illinois, USA
Masahiro Kuroda, National Institute of = Info. and=20 Com. Tech., Japan
Luciano Lenzini, University of Pisa, Italy
K. = Ben=20 Letaief, Hong Kong Univ. Science & Technology, Hong Kong
Victor = Leung,=20 The University of British Columbia, Canada
Yonghe Liu, Univ. Texas at = Arlington,=20 USA
Giri Mandyam, Nokia Research Center, = USA
Martin Mauve, University of Dusseldorf, Germany
Archan Misra, = IBM T.J.=20 Watson Research, USA
Refik Molva, Institut Eurecom, France
Giacomo = Morabito, University of Catania, Italy
Hiroyuki Morikawa, , = University of=20 Tokyo, Japan
Stephan Olariu, Old Dominion University, = USA
Maximilian Ott,=20 Semandex Networks, USA
Michael Paterakis, Technical University of = Crete,=20 Greece
George C. Polyzos, Athens University of Economics and = Business,=20 Greece
Antonio Puliafito, University of Messina, Italy
Jochen H. = Schiller,=20 Freie Universit=E4t Berlin, Germany
Henning Schulzrinne, Columbia = University,=20 USA
Rajeev Shorey, IBM India Research Lab, India
Ivan Stojmenovic, = University of Ottawa, Canada
Violet R. Syrotiuk, Arizona State = University,=20 USA
Wade Trappe, Rutgers University, USA
Ooi Wei Tsang, National=20 University of Singapore, Singapore
Christian Tschudin, Basel = University,=20 Switzerland
Thierry Turletti, INRIA France
Andras Valko, Ericsson, = Hungary
Bernard Walke, Aachen University of Technology, = Germany
Xingwei=20 Wang, Northeastern Univ, China
Jie Wu, Florida Atlantic University,=20 USA
Gergely Zaruba, The University of = Texas at=20 Arlington, USA
Roger Zimmerman, University of = Southern=20 California, USA
 
************************************************************
= Franca=20 Delmastro
Pervasive Computing & Networking Lab. = (PerLab)
 
IIT- National Research = Council
via G.=20 Moruzzi,1
56124 Pisa,=20 Italy
********************************************************<= /DIV> ------=_NextPart_000_0020_01C4C1C6.FCFC8730-- --===============1728766943== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1728766943==-- From mip6-bounces@ietf.org Thu Nov 4 09:50:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26150 for ; Thu, 4 Nov 2004 09:50:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjBv-00060n-0R for mip6-web-archive@ietf.org; Thu, 04 Nov 2004 10:06:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPioK-0006fo-O5; Thu, 04 Nov 2004 09:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPidK-0004dE-QJ for mip6@megatron.ietf.org; Thu, 04 Nov 2004 09:30:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24696 for ; Thu, 4 Nov 2004 09:30:37 -0500 (EST) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPiss-0005Wx-7i for mip6@ietf.org; Thu, 04 Nov 2004 09:46:42 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id iA4EUYP6015151; Thu, 4 Nov 2004 15:30:34 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iA4EUXBO011736; Thu, 4 Nov 2004 15:30:33 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR0R3W>; Thu, 4 Nov 2004 15:30:33 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F05319FD7@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Junghoon Jee , Alper Yegin , mip6@ietf.org Subject: RE: [Mip6] Comments on jee-mip6-bootstrap-pana Date: Thu, 4 Nov 2004 15:30:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d hi junghoon, > Hannes, > > > > > when i read the draft i came accross the same questions. > > > > i like your pull (instead of the push approach). this might > also work > > nicely with . > > Can you explain this point more concretely ? you can bootstrap a number of security associations using the same approach. hence, you might be able to bootstrap a security association which can be used for protecting mip6 binding updates as described in (instead of an ike/ipsec sa). i can draw a message flow if you want. > > > i wasn't sure how and when the MIPv6-AAA-Key is computed as well. > > I answered that question through my previous mail. > For clarity, > The AAA server and the MN maintains the key mapping table, > MIPv6-AAA-Key-Id vs. MIPv6-AAA-Key. > When EAP authentication is succeeded, the MIPv6-AAA-Key and > its id. are stored to the key mapping table. > The MIPv6-AAA-Key can be an AAA-Key or concatenation of the > AAA-Key' with AAA-Key'' if multiple session keys are derived > by the EAP authentication process. > The choice of which key to use to derive MIPv6 IKE PSK is > determined by the AAA home server. > The AAA home server notifies the MN which key to use by > sending the MIPv6-AAA-Key-Id. i see. > > > a minor correction to your mail: the diameter application ships the > > parameters to the PAA (and not to the mobile node). this is > the reason > > why a pana protocol is required which carries the > parameters finally > > to the end host. this is probably the most important > difference with > > regard to the draft. > > Right, I agree with you. > > > > > ps: it might be good to reference an old draft > > which proposed > the same approach. > > i also remember that julien published a draft with a > similar idea some > > time ago. > > The previous draft-le-aaa-diameter-mobileipv6-03.txt is a > good reference for our work. > In that draft, BU message is processed during the AAA auth. & > authorization phase. > The BU message can be piggybacked to the AAA auth request > message or it can be produced on the AAA server. > In the draft-jee-mip6-bootstrap-aaa-00, BU is processed after > the AAA auth & authorization phase. > This is because the BU MUST be protected by the IPsec SA > according to the RFC 3775. > If the draft-ietf-mip6-auth-protocol-00.txt is used, BU may > be piggybacked during the AAA auth& authorization phase if > the MN's CoA is configured. > there are certainly differences but the main idea goes in the same direction. ciao hannes > > Junghoon > > > > > > -----Original Message----- > > > From: Alper Yegin [mailto:alper.yegin@samsung.com] > > > Sent: Dienstag, 02. November 2004 02:23 > > > To: mip6@ietf.org > > > Subject: [Mip6] Comments on jee-mip6-bootstrap-pana > > > > > > Hello, > > > > > > Here are some comments and questions on the > > > draft-jee-mip6-bootstrap-pana-00.txt. > > > > > > - I see the new Diameter application has two functionalities. > > > Regarding the delivery of the bootstrapping information > to the MN, I > > > was wondering if we could get away with not defining new > commands, > > > but instead piggybacking on existing NAS application? The > > > bootstrapping information could be delivered to the NAS > as part of > > > the mobile's profile. > > > > > > - The other functionality is the push of bootstrapping > information > > > from AAAh to HA. This is carried in serial with the (in > fact, in the > > > middle > > > of) network access AAA. I think it could be done in parallel, or > > > even after the network access AAA. If you use a pull > model instead > > > of the push, this part gets aligned with the yegin-mip6-aaa-fwk. > > > > > > - I didn't quite understand how the MN obtains/computes the > > > MIPv6-AAA-Key. It is only provided with the MIPv6-AAA-Key-Id, and > > > that's not sufficient to derive the key. > > > > > > Thanks in advance. > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 4 10:21:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29962 for ; Thu, 4 Nov 2004 10:21:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjgM-0006mM-J3 for mip6-web-archive@ietf.org; Thu, 04 Nov 2004 10:37:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPjA1-00056G-0F; Thu, 04 Nov 2004 10:04:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPj5Q-0001Oz-77 for mip6@megatron.ietf.org; Thu, 04 Nov 2004 09:59:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26898 for ; Thu, 4 Nov 2004 09:59:38 -0500 (EST) Received: from david.siemens.de ([192.35.17.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjKw-0006D0-N3 for mip6@ietf.org; Thu, 04 Nov 2004 10:15:44 -0500 Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id iA4ExYBO008516; Thu, 4 Nov 2004 15:59:34 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id iA4ExPBO004980; Thu, 4 Nov 2004 15:59:29 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <4BVR0SDL>; Thu, 4 Nov 2004 15:59:25 +0100 Message-ID: <2A8DB02E3018D411901B009027FD3A3F05319FE8@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: Julien Bournelle , Junghoon Jee Subject: RE: [Mip6] Comments on jee-mip6-bootstrap-pana Date: Thu, 4 Nov 2004 15:59:23 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d hi julien, > I think that one of the major issue with this approach > (defining a specific AAA application for Mobile IPv6) is that > all visited network MUST use this specific AAA application if > you want to bootstrapp Mobile IPv6. Thus, if the visited > network uses Diameter-EAP or RADIUS-EAP, you can't bootstrapp > Mobile IPv6. This imply that all operators should deploy this > solution. > > With our approach (draft-giaretta), the visited network does > not need to Mobile IPV6 aware. thanks for pointing to this important issue. similarly, draft-tschofenig-mip6-bootstrapping-pana does not require the visited network to know anything about mobile ip. ciao hannes > > > -- > julien.bournelle@int-evry.fr > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 4 14:57:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27178 for ; Thu, 4 Nov 2004 14:57:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPnyz-0005J8-0y for mip6-web-archive@ietf.org; Thu, 04 Nov 2004 15:13:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPnfs-0007XT-7v; Thu, 04 Nov 2004 14:53:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPnWG-0006FW-H8 for mip6@megatron.ietf.org; Thu, 04 Nov 2004 14:43:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26377 for ; Thu, 4 Nov 2004 14:43:39 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPnlq-00051c-T3 for mip6@ietf.org; Thu, 04 Nov 2004 14:59:47 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA4Jhce25927 for ; Thu, 4 Nov 2004 21:43:38 +0200 (EET) X-Scanned: Thu, 4 Nov 2004 21:43:23 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iA4JhNrl005131 for ; Thu, 4 Nov 2004 21:43:23 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00sGlAn6; Thu, 04 Nov 2004 21:43:22 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA4JhGa08882 for ; Thu, 4 Nov 2004 21:43:16 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 4 Nov 2004 13:41:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Nov 2004 13:41:52 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> Thread-Topic: MIP6 agenda Thread-Index: AcTCpc6Fl4nb8h6kRfOxUUCHk3bOEgAAGRBw To: X-OriginalArrivalTime: 04 Nov 2004 19:41:52.0667 (UTC) FILETIME=[556B46B0:01C4C2A6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Subject: [Mip6] FW: MIP6 agenda (Final) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Patil Basavaraj=20 > Sent: Thursday, November 04, 2004 1:38 PM > To: 'agenda@ietf.org' > Subject: MIP6 agenda=20 >=20 >=20 >=20 > Hello, >=20 > The current MIP6 WG agenda posted on the IETF web site says=20 > the meeting is > scheduled for Friday, Nov 11th. It should be Nov 12th. >=20 > Please post the following agenda (Final) for the MIP6 WG. >=20 > Thanks, > -Basavaraj >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > Mobility for IPv6 (mip6) >=20 > Time and Date of WG meeting at IETF61: Friday, Nov 12 from 9 - 1130 AM > Duration: 2.5 hours >=20 > Agenda > =3D=3D=3D=3D=3D=3D >=20 > 1. Agenda, Bluesheets, Note-takers and Jabber scribes 5 Mins >=20 > 2. WG status update Chairs 10 Mins >=20 > 3. MIP6 Operation with IKEv2 and the revised IPsec Arch. 20 Mins > I-D: draft-ietf-mip6-ikev2-ipsec-00.txt > Vijay Devarapalli >=20 > 4. a. Using IPsec to protect signaling between MN and CN 5 Mins > I-D: draft-dupont-mipv6-cn-ipsec-01.txt > b. Care-of address test procedure using a state cookie 5 Mins > I-D: Annex of draft-dupont-mipv6-cn-ipsec-01.txt > Francis Dupont >=20 > 5. AAA and Mobile IPv6 =20 > 20 Mins > I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt > I-D: draft-yegin-mip6-aaa-fwk-00.txt > Giaretta Gerardo/Alper Yegin >=20 > 6. MIPv6 Authorization and Configuration based on EAP 10 Mins > I-D: draft-giaretta-mip6-authorization-eap-02.txt > Giaretta Gerardo > =20 > 7. Application Master Session Key (AMSK) for Mobile IPv6 5 Mins > I-D: draft-giaretta-mip6-amsk-00.txt > Giaretta Gerardo > =20 > 8. Diameter Mobile IPv6 Bootstrapping Application using PANA 15 Mins > I-D: draft-jee-mip6-bootstrap-pana-00.txt > I-D: draft-tschofenig-mip6-bootstrapping-pana-00.txt > Junghoon Jee, Hannes Tschofenig > =20 > 9. Mobile IPv6 Bootstrapping Architecture Using DHCP 15 Mins > I-D: draft-ohba-mip6-boot-arch-dhcp-00 > Yoshihiro Ohba >=20 > 10. Bootstrap Control Function mechanism for Mobile IPv6=20 > Bootstrap 10 Mins > I-D: draft-deng-mip6-bootstrap-bcf-00.txt > Hui Deng >=20 > 11. Precomputable Binding Management Key Kbm for Mobile IPv6 5 Mins > I-D: draft-ietf-mip6-precfgkbm-01.txt > Charles Perkins >=20 > 12. Improvement of Return Routability Protocol =09 > 10 Mins > I-D: draft-qiu-mip6-rr-improvement-00.txt > Jianying ZHOU >=20 >=20 > 13. Next steps Chairs =09 > 5 Mins >=20 > Time permitting, we will discuss these IDs and interest in this work: >=20 > a. Multihoming in MIP6 > I-Ds: draft-montavont-mobileip-multihoming-pb-statement-02.txt > draft-ernst-generic-goals-and-benefits-00.txt > Nicolas Montavont >=20 > b. Load Balance for Distributed Home Agents in Mobile IPv6 > I-D: draft-deng-mip6-ha-loadbalance-02.txt > Hui Deng > =20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 5 11:24:44 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25779 for ; Fri, 5 Nov 2004 11:24:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ794-0006lV-Nc for mip6-web-archive@ietf.org; Fri, 05 Nov 2004 11:41:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ6no-0004FC-Rf; Fri, 05 Nov 2004 11:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPj5F-0001Og-HT for mip6@megatron.ietf.org; Thu, 04 Nov 2004 09:59:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26874 for ; Thu, 4 Nov 2004 09:59:27 -0500 (EST) Received: from smtp1.clb.oleane.net ([213.56.31.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPjKn-0006By-8x for mip6@ietf.org; Thu, 04 Nov 2004 10:15:33 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp1.clb.oleane.net with ESMTP id iA4Ewv7K010743 for ; Thu, 4 Nov 2004 15:58:57 +0100 Message-Id: <200411041458.iA4Ewv7K010743@smtp1.clb.oleane.net> From: "Gunther Palmer" To: Date: Thu, 4 Nov 2004 15:58:54 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTCfs17hUXUf8t3SiazcG9MsdQevg== X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 X-Mailman-Approved-At: Fri, 05 Nov 2004 11:19:03 -0500 Subject: [Mip6] ZigBee Conference: Call for Proposals X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1831994183==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 This is a multi-part message in MIME format. --===============1831994183== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01CD_01C4C287.2FBEBF60" This is a multi-part message in MIME format. ------=_NextPart_000_01CD_01C4C287.2FBEBF60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Will wireless sensor networks be the next hot topic in the telecommunication industry? Analysts agree that the promise of wearable consumer goods, residential applications, and automotive network nodes is considerable. Enabling technologies must be developed further and standards must be agreed on in order to meet this demand. Will ZigBee play this role? The ZigBee Conference will be held in Paris on 10 to 13 May 2005. A call for papers is online at: http://www.upperside.fr/zigbee2005/zigbee2005intro.htm ------=_NextPart_000_01CD_01C4C287.2FBEBF60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Will wireless sensor = networks be the next hot topic in the telecommunication industry? Analysts agree that = the promise of wearable consumer goods, residential applications, and automotive = network nodes is considerable. Enabling technologies must be developed further = and standards must be agreed on in order to meet this demand. = Will ZigBee play this role?

The = ZigBee Conference will be held = in Paris on = 10 to 13 May 2005.

 

A call for papers is online = at:

 

http://www.upperside.fr/zigbee2005/zigbee2005intro.htm

 

------=_NextPart_000_01CD_01C4C287.2FBEBF60-- --===============1831994183== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1831994183==-- From mip6-bounces@ietf.org Fri Nov 5 11:28:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26091 for ; Fri, 5 Nov 2004 11:28:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ7D1-0006pz-KO for mip6-web-archive@ietf.org; Fri, 05 Nov 2004 11:45:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ6np-0004FX-Ja; Fri, 05 Nov 2004 11:19:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ0RL-0005f2-CV for mip6@megatron.ietf.org; Fri, 05 Nov 2004 04:31:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19873 for ; Fri, 5 Nov 2004 04:31:25 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ0h3-0005t0-3S for mip6@ietf.org; Fri, 05 Nov 2004 04:47:41 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) by smtp8.clb.oleane.net with ESMTP id iA59UnMo022241 for ; Fri, 5 Nov 2004 10:30:55 +0100 Message-Id: <200411050930.iA59UnMo022241@smtp8.clb.oleane.net> From: "Gunther Palmer" To: Date: Fri, 5 Nov 2004 10:30:52 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcTDGiSFKz+Z5ZcsSA+RCVFVlMaIUA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f X-Mailman-Approved-At: Fri, 05 Nov 2004 11:19:03 -0500 Subject: [Mip6] WiMAX Summit: Call for proposals X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0239137747==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 This is a multi-part message in MIME format. --===============0239137747== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FA_01C4C322.86A919B0" This is a multi-part message in MIME format. ------=_NextPart_000_00FA_01C4C322.86A919B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit . What is the business model for WiMAX? . What do we learn from earlier deployments? . What about the future extensions of the standard? . How is addressed the interoperability challenge? These questions, among others, will be addressed during the second edition of the WiMAX Summit, next April 5-8 2005, by distinguished experts and key players in the field. The call for proposal dead line has been extended to November 30. Details at: http://www.upperside.fr/wimax05/wimax2005intro.htm ------=_NextPart_000_00FA_01C4C322.86A919B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

• = What is the business model for WiMAX?
• = What do we learn from earlier deployments?
• = What about the future extensions of the standard?
• = How is addressed the interoperability challenge?

These questions, among others, will be addressed during the second = edition of the WiMAX Summit, next April 5-8 2005, by distinguished = experts and key players in the field.

 

The call for proposal dead line has been = extended to November 30.

 

Details at:

http://www.upperside.fr/wimax05/wimax2005intro.htm

 

------=_NextPart_000_00FA_01C4C322.86A919B0-- --===============0239137747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0239137747==-- From mip6-bounces@ietf.org Fri Nov 5 15:59:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16898 for ; Fri, 5 Nov 2004 15:59:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBQu-00046W-4W for mip6-web-archive@ietf.org; Fri, 05 Nov 2004 16:15:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQB5M-0003UJ-Rn; Fri, 05 Nov 2004 15:53:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQAxK-0007Q6-54 for mip6@megatron.ietf.org; Fri, 05 Nov 2004 15:45:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15761 for ; Fri, 5 Nov 2004 15:45:08 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQBD7-0003c9-LK for mip6@ietf.org; Fri, 05 Nov 2004 16:01:30 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I6Q009094ACFF@mailout1.samsung.com> for mip6@ietf.org; Sat, 06 Nov 2004 05:44:36 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I6Q001HD4A6D8@mailout1.samsung.com> for mip6@ietf.org; Sat, 06 Nov 2004 05:44:30 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I6Q008JJ4A42I@mmp1.samsung.com> for mip6@ietf.org; Sat, 06 Nov 2004 05:44:30 +0900 (KST) Date: Fri, 05 Nov 2004 12:44:28 -0800 From: Alper Yegin To: mip6@ietf.org Message-id: <000001c4c378$3f6f3100$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7BIT Subject: [Mip6] Comments on draft-deng-mip6-bootstrap-bcf-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7BIT Hello, Here are my comments on deng-mip6-bootstrap-bcf. As I understand, the essence of the proposal is to bootstrap MIP6 information from a centralized server (BCF). BCF is on-link with the potential HAs. I think Figure 2 is missing the step where the AAA (or, BCF?) and the selected HA signaling takes place. I think a AAA interface like the one proposed in yegin-mip6-aaa-fwk is needed here. I couldn't understand why steps 4 and 5 are separate. Why not combine them? I think the proposal/implementation would be simplified if BCF is co-located with each HA. That way, we can still have the load-balancing (HA redirects) but allocation of HoA is simpler. We wouldn't need a BCF-HA protocol anymore. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 7 04:54:14 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06975 for ; Sun, 7 Nov 2004 04:54:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQjkq-0007pe-5Z for mip6-web-archive@ietf.org; Sun, 07 Nov 2004 04:54:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQjjF-0008Pt-1G; Sun, 07 Nov 2004 04:52:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQjh2-00083T-T4 for mip6@megatron.ietf.org; Sun, 07 Nov 2004 04:50:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06885 for ; Sun, 7 Nov 2004 04:50:33 -0500 (EST) From: lynch@vmails.net Received: from [211.151.89.58] (helo=vmails.net) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CQjhB-0007lG-TV for mip6@ietf.org; Sun, 07 Nov 2004 04:50:55 -0500 Received: (eyou send program); Sun, 07 Nov 2004 17:49:37 +0800 Message-ID: <299820977.28512@vmails.net> X-EYOUMAIL-SMTPAUTH: lynch@vmails.net Received: from 211.71.8.37 (HELO clark) (211.71.8.37) by 166.111.3.243 with SMTP; Sun, 07 Nov 2004 17:49:37 +0800 Message-ID: <000c01c4c4b0$1c5f1ca0$2901a8c0@clark> To: Subject: RE: [Mip6] Comments on draft-deng-mip6-bootstrap-bcf-00.txt Date: Sun, 7 Nov 2004 17:56:53 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.181 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 X-Spam-Score: 1.0 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: hdeng@hitachi.cn X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.0 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Hi, Alper, Thank you for your comments. >Hello, > >Here are my comments on deng-mip6-bootstrap-bcf. > >As I understand, the essence of the proposal is to bootstrap MIP6 >information from a centralized server (BCF). BCF is on-link with the >potential HAs. Yes, BCF should be on-link with potential HAs. > >I think Figure 2 is missing the step where the AAA (or, BCF?) and the >selected HA signaling takes place. I think a AAA interface like the one >proposed in yegin-mip6-aaa-fwk is needed here. um...yes, currently we have not considered much about BCF HA signaling. We will consider in next version. > >I couldn't understand why steps 4 and 5 are separate. Why not combine them? I think we separate steps 4 and 5 for the following reason. We think BCF can co-located with one/each HA in some scenarios, and in such scenarios, step 5 (Handover message) may not be neccessary in bootstrap procedure, because BCF is HA itself. > >I think the proposal/implementation would be simplified if BCF is co-located >with each HA. That way, we can still have the load-balancing (HA redirects) >but allocation of HoA is simpler. We wouldn't need a BCF-HA protocol >anymore. In our draft, BCF is an abstract entity, and it can co-locate with HA in practice. Yes, bootstrap will be simplified with BCF co-locating with each HA/one HA. > > >Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 8 09:22:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11421 for ; Mon, 8 Nov 2004 09:22:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRAQQ-00026a-PD for mip6-web-archive@ietf.org; Mon, 08 Nov 2004 09:23:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRAHL-0001Rq-VS; Mon, 08 Nov 2004 09:13:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRA3J-0005y8-6a for mip6@megatron.ietf.org; Mon, 08 Nov 2004 08:59:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08986 for ; Mon, 8 Nov 2004 08:59:23 -0500 (EST) Received: from cms1.etri.re.kr ([129.254.16.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRA3n-0001NL-Ty for mip6@ietf.org; Mon, 08 Nov 2004 08:59:59 -0500 Received: from ETRIYSLEE (130.129.135.101 [130.129.135.101]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VRH2ZYGT; Mon, 8 Nov 2004 22:58:50 +0900 Message-ID: <001a01c4c59b$19b854d0$65878182@ETRIYSLEE> From: "Junghoon Jee" To: "Julien Bournelle" References: <2A8DB02E3018D411901B009027FD3A3F05319F6C@mchp905a.mch.sbs.de><002b01c4c26d$2a6962f0$428feada@ETRIYSLEE> <20041104131957.GL10930@ipv6-5.int-evry.fr> Subject: Re: [Mip6] Comments on jee-mip6-bootstrap-pana Date: Mon, 8 Nov 2004 08:58:54 -0500 Organization: CMS MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.2 (++) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Alper Yegin , mip6@ietf.org, Tschofenig Hannes X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Junghoon Jee List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1182622003==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a --===============1182622003== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVsbG8sIEp1bGllbi4NCg0KPiANCj4gaGksDQo+IA0KPiAganVzdCBhIGxpdHRsZSBjb21tZW50 IGlubGluZSwNCj4gDQo+ID4gPiBwczogaXQgbWlnaHQgYmUgZ29vZCB0byByZWZlcmVuY2UgYW4g b2xkIGRyYWZ0DQo+ID4gPiA8ZHJhZnQtbGUtYWFhLWRpYW1ldGVyLW1vYmlsZWlwdjYtMDIudHh0 PiB3aGljaCBwcm9wb3NlZCB0aGUgc2FtZSBhcHByb2FjaC4NCj4gPiA+IGkgYWxzbyByZW1lbWJl ciB0aGF0IGp1bGllbiBwdWJsaXNoZWQgYSBkcmFmdCB3aXRoIGEgc2ltaWxhciBpZGVhIHNvbWUg dGltZQ0KPiA+ID4gYWdvLiANCj4gPiANCj4gPiBUaGUgcHJldmlvdXMgZHJhZnQtbGUtYWFhLWRp YW1ldGVyLW1vYmlsZWlwdjYtMDMudHh0IGlzIGEgZ29vZCByZWZlcmVuY2UgZm9yIG91ciB3b3Jr Lg0KPiA+IEluIHRoYXQgZHJhZnQsIEJVIG1lc3NhZ2UgaXMgcHJvY2Vzc2VkIGR1cmluZyB0aGUg QUFBIGF1dGguICYgYXV0aG9yaXphdGlvbiBwaGFzZS4NCj4gPiBUaGUgQlUgbWVzc2FnZSBjYW4g YmUgcGlnZ3liYWNrZWQgdG8gdGhlIEFBQSBhdXRoIHJlcXVlc3QgbWVzc2FnZSANCj4gPiBvciBp dCBjYW4gYmUgcHJvZHVjZWQgb24gdGhlIEFBQSBzZXJ2ZXIuIA0KPiA+IEluIHRoZSBkcmFmdC1q ZWUtbWlwNi1ib290c3RyYXAtYWFhLTAwLCBCVSBpcyBwcm9jZXNzZWQgYWZ0ZXIgdGhlIEFBQSBh dXRoICYgYXV0aG9yaXphdGlvbiBwaGFzZS4NCj4gPiBUaGlzIGlzIGJlY2F1c2UgdGhlIEJVIE1V U1QgYmUgcHJvdGVjdGVkIGJ5IHRoZSBJUHNlYyBTQSBhY2NvcmRpbmcgdG8gdGhlIFJGQyAzNzc1 Lg0KPiA+IElmIHRoZSAgZHJhZnQtaWV0Zi1taXA2LWF1dGgtcHJvdG9jb2wtMDAudHh0IGlzIHVz ZWQsIA0KPiA+IEJVIG1heSBiZSBwaWdneWJhY2tlZCBkdXJpbmcgdGhlIEFBQSBhdXRoJiBhdXRo b3JpemF0aW9uIHBoYXNlIGlmIHRoZSBNTidzIENvQSBpcyBjb25maWd1cmVkLg0KPiANCj4gSSB0 aGluayB0aGF0IG9uZSBvZiB0aGUgbWFqb3IgaXNzdWUgd2l0aCB0aGlzIGFwcHJvYWNoIChkZWZp bmluZyBhDQo+IHNwZWNpZmljIEFBQSBhcHBsaWNhdGlvbiBmb3IgTW9iaWxlIElQdjYpIGlzIHRo YXQgYWxsIHZpc2l0ZWQgbmV0d29yaw0KPiBNVVNUIHVzZSB0aGlzIHNwZWNpZmljIEFBQSBhcHBs aWNhdGlvbiBpZiB5b3Ugd2FudCB0byBib290c3RyYXBwIE1vYmlsZQ0KPiBJUHY2LiAgVGh1cywg aWYgIHRoZSB2aXNpdGVkIG5ldHdvcmsgdXNlcw0KPiBEaWFtZXRlci1FQVAgb3IgUkFESVVTLUVB UCwgeW91IGNhbid0IGJvb3RzdHJhcHAgTW9iaWxlIElQdjYuIFRoaXMgaW1wbHkgdGhhdCBhbGwN Cj4gb3BlcmF0b3JzIHNob3VsZCBkZXBsb3kgdGhpcyBzb2x1dGlvbi4NCg0KPiBXaXRoIG91ciBh cHByb2FjaCAoZHJhZnQtZ2lhcmV0dGEpLCB0aGUgdmlzaXRlZCBuZXR3b3JrIGRvZXMgbm90IG5l ZWQgdG8NCj4gTW9iaWxlIElQVjYgYXdhcmUuDQo+IA0KPiBqdWxpZW4uYm91cm5lbGxlQGludC1l dnJ5LmZyDQo+IA0KDQpSaWdodC4gV2l0aCBteSBhcHByb2FjaChkcmFmdC1qZWUpLCBhIHNwZWNp ZmljIG5ldyBEaWFtZXRlciBBcHBsaWNhdGlvbiBpcyByZXF1aXJlZCB0byBib290c3RyYXANCm1v YmlsZSBub2Rlcy4gSW4gbXkgb3BpbmlvbiwgdGhlcmUgYXJlIHByb3MuICYgY29ucy4gaW4gdXNp bmcgYSBuZXcgRGlhbWV0ZXIgQXBwbGljYXRpb24gb3Igbm90Lg0KTmV3IERpYW1ldGVyIE1vYmls ZSBJUHY2IEJvb3RzdHJhcHBpbmcgQXBwbGljYXRpb24oZHJhZnQtamVlKSBzdXBwb3J0cyB0aGUg SEEgYXNzaWdubWVudCBpbiB0aGUNClZpc2l0ZWQgbmV0d29yay4gSWYgeW91IHVzZSBhIHByZXZp b3VzIERpYW1ldGVyIEVBUCBvciBSQURJVVMgRUFQLCB5b3UgY2Fubm5vdCBhc3NpZ24NCmEgSEEg aW4gdGhlIHZpc2l0ZWQgZG9tYWluLiBTb21lIG9mIG1vZGlmaWNhdGlvbiBvciBhZGRpbmcgYXJl IHJlcXVpcmVkLiAgICAgDQpUaGUgSEEgYXNzaWdubWVudCBpbiB0aGUgdmlzaXRlZCBkb21haW4g aXMgYSByZXF1aXJlbWVudCBpdGVtIGluIHRoZSBwcmV2aW91cyBJLUQoZHJhZnQtbGUtYWFhLW1p cHY2LXJlcXVpcmVtZW50cy0wMy50eHQpLiANClRoaXMgcG9pbnQgaXMgc3BlY2lmaWVkIGluIHRo ZSBzZWN0aW9uIDUuNSBvZiB0aGF0IEktRC4NCg0KaSB0aGluayB3ZSBzaG91bGQgY29uc2lkZXIg dGhlIEhBIGFzc2lnbm1lbnQgaW4gdGhlIHZpc2l0ZWQgZG9tYWluIG5vdCBvbmx5IGluIHRoZSBo b21lIGRvbWFpbi4NCg0KSnVuZ2hvb24NCg0KDQoNCiA= --===============1182622003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1182622003==-- From mip6-bounces@ietf.org Mon Nov 8 11:41:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28455 for ; Mon, 8 Nov 2004 11:41:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRCaZ-0006Nq-3A for mip6-web-archive@ietf.org; Mon, 08 Nov 2004 11:41:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRCRw-0004Dx-6u; Mon, 08 Nov 2004 11:33:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRC9n-0008Qt-No for mip6@megatron.ietf.org; Mon, 08 Nov 2004 11:14:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25652 for ; Mon, 8 Nov 2004 11:14:13 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRCAL-0005bB-Ut for mip6@ietf.org; Mon, 08 Nov 2004 11:14:51 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8GEAF09914; Mon, 8 Nov 2004 18:14:10 +0200 (EET) X-Scanned: Mon, 8 Nov 2004 18:13:37 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iA8GDbwQ010542; Mon, 8 Nov 2004 18:13:37 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00FWSBWU; Mon, 08 Nov 2004 18:11:23 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA8GBNS15418; Mon, 8 Nov 2004 18:11:23 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 10:10:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Nov 2004 10:10:40 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C132@daebe007.americas.nokia.com> Thread-Topic: Bar-Bof on Privacy scheduled for Monday, Nov 8th Thread-Index: AcTFrXwdaYVfmil4Q7O5EG9++BxWeg== To: X-OriginalArrivalTime: 08 Nov 2004 16:10:40.0455 (UTC) FILETIME=[7DD82D70:01C4C5AD] X-Spam-Score: 0.3 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Cc: multi6@ops.ietf.org Subject: [Mip6] Bar-Bof on Privacy scheduled for Monday, Nov 8th X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Hello, Note that the privacy Bar-Bof will be held in meeting room Lincoln at 10 PM on Monday, Nov 8th. Please join the discussion. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 8 20:16:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27241 for ; Mon, 8 Nov 2004 20:16:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRKcv-00041k-6P for mip6-web-archive@ietf.org; Mon, 08 Nov 2004 20:16:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRKa6-0006jg-Vn; Mon, 08 Nov 2004 20:13:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRKOl-0003xB-0t for mip6@megatron.ietf.org; Mon, 08 Nov 2004 20:02:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26134 for ; Mon, 8 Nov 2004 20:02:13 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRKPO-0003hl-5I for mip6@ietf.org; Mon, 08 Nov 2004 20:02:55 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA912BE08524 for ; Tue, 9 Nov 2004 03:02:12 +0200 (EET) X-Scanned: Tue, 9 Nov 2004 03:03:16 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iA913GFi031851 for ; Tue, 9 Nov 2004 03:03:16 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00P4GO7y; Tue, 09 Nov 2004 03:03:15 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iA90nfS21984 for ; Tue, 9 Nov 2004 02:49:41 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Nov 2004 18:49:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Nov 2004 18:49:40 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C137@daebe007.americas.nokia.com> Thread-Topic: Privacy related I-D Thread-Index: AcTF9f05aUPM/OQ+QDuJ/5twtNzlTg== To: X-OriginalArrivalTime: 09 Nov 2004 00:49:41.0017 (UTC) FILETIME=[FF10D890:01C4C5F5] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Privacy related I-D X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Greg Daley had mentioned about the ID below that may be useful to = consider as well within the scope of the privacy discussion at the Bar BoF. http://www.ctie.monash.edu.au/ipv6/draft-daley-mip6-locpriv-00.txt -BPa _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 8 20:52:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00923 for ; Mon, 8 Nov 2004 20:52:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRLC2-0004sm-0u for mip6-web-archive@ietf.org; Mon, 08 Nov 2004 20:53:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRL97-0000i5-Q8; Mon, 08 Nov 2004 20:50:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRL4u-00087W-Tx for mip6@megatron.ietf.org; Mon, 08 Nov 2004 20:45:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00078 for ; Mon, 8 Nov 2004 20:45:47 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRL5X-0004hL-HI for mip6@ietf.org; Mon, 08 Nov 2004 20:46:30 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iA91j9a19070; Tue, 9 Nov 2004 02:45:09 +0100 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 iA91jASj087037; Tue, 9 Nov 2004 02:45:10 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411090145.iA91jASj087037@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Privacy related I-D In-reply-to: Your message of Mon, 08 Nov 2004 18:49:40 CST. <697DAA22C5004B4596E033803A7CEF4403B1C137@daebe007.americas.nokia.com> Date: Tue, 09 Nov 2004 02:45:10 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 In your previous mail you wrote: Greg Daley had mentioned about the ID below that may be useful to consider as well within the scope of the privacy discussion at the Bar BoF. http://www.ctie.monash.edu.au/ipv6/draft-daley-mip6-locpriv-00.txt => there is the old draft-castelluccia-mobileip-privacy-00.txt In fact a paper based on the idea was presented at MWCN'04 two weeks ago (I have the presentation here for the BoF if needed) and an updated version of the I-D should be submitted... Regards Francis.Dupont@enst-bretagne.fr PS: here is a pointer for the impatient: http://www.watersprings.org/pub/id/draft-castelluccia-mobileip-privacy-00.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 10 10:22:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18916 for ; Wed, 10 Nov 2004 10:22:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuJQ-0004oX-Vs for mip6-web-archive@ietf.org; Wed, 10 Nov 2004 10:23:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuDd-0006bL-OU; Wed, 10 Nov 2004 10:17:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRtyL-0008KF-FE for mip6@megatron.ietf.org; Wed, 10 Nov 2004 10:01:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15331 for ; Wed, 10 Nov 2004 10:01:19 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRtzI-0004FT-Pr for mip6@ietf.org; Wed, 10 Nov 2004 10:02:22 -0500 Received: from jurassic.eng.sun.com ([129.146.85.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id iAAF1FNH015582; Wed, 10 Nov 2004 08:01:15 -0700 (MST) Received: from eng.sun.com (vpn-129-150-65-254.East.Sun.COM [129.150.65.254]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iAAF1EMD863867; Wed, 10 Nov 2004 07:01:14 -0800 (PST) Message-ID: <41922D34.70605@eng.sun.com> Date: Wed, 10 Nov 2004 07:01:08 -0800 From: Samita Chakrabarti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Borst References: <200411022030.iA2KUDCj478937@jurassic.eng.sun.com> <1099488713.13194.22.camel@mn-2> In-Reply-To: <1099488713.13194.22.camel@mn-2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, samita.chakrabarti@sun.com Subject: [Mip6] Re: Comments on draft-borst-mip6api-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Mark Borst wrote: >Hello > > > > > > > >> >>- Please mention in the introduction and section 3 (goals and requirements) >> that the application level API should use "MIP6 Sockets API" to access >> low level data when applicable. >> >> > >This is actually an implementation requirement, which cannot be a >'requirement'. We have extensively thought about it, but it proves to be >more a burden than a benefit to use the "MIP6 Sockets API" in this case. >The thing is that you are then duplicating a lot of code that is already >in the MIPv6 stack, for instance for the movement detection. This is at >least valid for the MIPL platform. We could add it as a hint to >implementers though. > > > > The API is a specification for implementation. My suggestion was to include "MIP6 Socket API" as one of the preferable options for underlying implementations. Thanks, -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 10 10:46:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22231 for ; Wed, 10 Nov 2004 10:46:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuga-0005OC-QT for mip6-web-archive@ietf.org; Wed, 10 Nov 2004 10:47:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRudB-0006qO-6u; Wed, 10 Nov 2004 10:43:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuQh-0004JQ-5k for mip6@megatron.ietf.org; Wed, 10 Nov 2004 10:30:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20338 for ; Wed, 10 Nov 2004 10:30:36 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuRf-00051M-5H for mip6@ietf.org; Wed, 10 Nov 2004 10:31:39 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAFUYv13004 for ; Wed, 10 Nov 2004 17:30:36 +0200 (EET) X-Scanned: Wed, 10 Nov 2004 17:30:08 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iAAFU8iY001753 for ; Wed, 10 Nov 2004 17:30:08 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00SltL9P; Wed, 10 Nov 2004 17:30:06 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAAFU5a15761 for ; Wed, 10 Nov 2004 17:30:05 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 10 Nov 2004 09:29:30 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Nov 2004 09:29:30 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C143@daebe007.americas.nokia.com> Thread-Topic: Minutes of Privacy Bar Bof held on Nov 8th, 2004 Thread-Index: AcTHOhHRVA5JjQD8QFyj0/t4uFrGRg== To: X-OriginalArrivalTime: 10 Nov 2004 15:29:30.0950 (UTC) FILETIME=[12BB1E60:01C4C73A] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Minutes of Privacy Bar Bof held on Nov 8th, 2004 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: quoted-printable Thanks to TJ for these notes. And corrections by Jari Arkko. ----------------------------------------------------------- Notes from IETF61 Privacy BAR BOF -- 35 attendees (names witheld for = privacy). 8 Nov 04 -- 10pm - 11:15pm Basavaraj P. leading. Notes by TJ Kniveton. James Kempf - Wrote an ISOC paper on the regulatory situation in US, Japan and Europe about IPv6 location..anyone deploying MIPv6 might want to look at it. In the US, not much regulation. But in Japan and Europe, users must be given a meaningful opportunity =20 Architectural considerations about privacy. Every protocol instantiates them differently.=20 Raj - privacy means different things to different people.. Wassim - focus on MAC and IP layers. Highlights the need to update them in a synchronized way, so that you don't change just one and leave the other unchanged.=20 Hesham - there are so many upper layer identifiers, such as cookies. Thinking we solve the problem of privacy at IP and it's done isn't true.=20 Jari Arkko - Privacy is not fully provided until you have solved it at the MAC layer, IP layer, authentication layer, mobility layer. On the other hand, things on those different layers have to be solved on their own.=20 Erik N. - Cases where you want to be reachable under a different identifier. But other cases you don't want to disclose on outbound communication, information that allows traceability.=20 Hesham - if you're making a call outbound and you try to hide your identity=20 TJ - Who are we trying to keep the privacy from? correspondent? routing infra? If I make a phone call, I can hide my caller ID info.. but the phone company still knows who I am, and if the police wants to know who I called, they can find out.=20 RFC 3041 thinks already about crossing boundaries. Shouldn't have a PTR record that points back to your permanent name. I might want to use different identities to hide things.=20 Raj - We want to talk about link layer identifier. Is that something the IETF should even be looking at?=20 Kempf - we might want to mention it, but don't dwell on it. Arkko - There's a difference between defining the problem and solving = it. Greg Daley - if we leave it there unresolved, it's an achilles heel. Because anyone can snoop mac addresses.=20 -some talk about cellular networks and whether you send an identifier to initiate calls. Sends identity in clear when you first buy the phone and turn it on, but not every time you turn it on.=20 Kempf - 3GPP2 is interested in what happens in IETF. We don't want to come up with a solution, and then a year later they come and say, sorry this doesn't work etc. We should engage them now to get a set of requirements.=20 Hesham - but we haven't even started a BOF yet. Kempf - 3GPP comes a lot, talks in SIP wgs, etc. 3GPP2 doesn't tend to do that.. How can we get them to talk to us?=20 Arkko - Works 2 ways. It might be useful to tell other bodies as well if they have something they need to fix.=20 Nordmark - does anyone know if IEEE 802.11 has looked at this? Kempf - They're not even close to this, they have been working on authentication.=20 Pasi Eronen - They looked at this a few times over the years. Now they're doing the opposite -- getting certificates based on MAC addresses.=20 TJ - Maybe this is a stupid question, but why do we really need to protect location privacy for IP addresses? I don't care if someone knows I'm in Washington DC because of the IP i'm using.=20 Hesham - Well there are some criminals who really care about that. Eronen - Well if you're in DC, that's fine. But if someone can tell where you are within 100m, they can come with an AK-47..=20 TJ - but can they really tell where I am within 100m?... .... discussion Kempf - well we need to satisfy regulators. Some fighting about what MIPv6 spec says for SPI selector, ESP header.... Can anyone on the home link tell where the MN is, or just the HA?=20 Erik: privacy aspects of multihoming=20 Erik - You have a HoA, CoA. might want to use multiple sets of those. When you switch, you want to switch both at the same time.=20 IKE - uses same SPI each time. Arkko - you always use the same IKE SPI, but you can renegotiate the IPsec SPI.=20 F Dupont - it's only useful if you are close to the security gateway. Raj - Questions we should ask here - Is this work even of interest in the IETF? - Privacy: is this something that should be dealt with on a mobility aspect, or should it be a broader question that is addressed with a new charter?=20 Hesham - This requires expertise from more than one WG. Location privacy for MNs can be tackled.=20 Arkko - HIP, MIPv6, etc. all have different privacy issues. Kempf - I would support updating the MIPv6 charter for that purpose. Arkko - But even beyond that, what about identity issues in MIP? More than just location privacy.=20 Hesham - make it so that location information and home address don't show up in the same packets.=20 Eronen- we need a threat description, because it's not a binary thing. If you can link things together, sooner or later you end up losing both location and identity information. You can solve against unbounded adversary capabilities.=20 Kempf - We need something realistic like what we did for binding = updates. nn - The endpoint has to be identified. You can't communicate without knowing the endpoints. So we want to protect the privacy as far as possible. You can't eliminate all possible cases where privacy can be breached.=20 Conclusion: Will suggest a change to the charter and contact. Jari: Conclusion was that the problem is interesting and that=20 we should attempt solving parts of the MIPv6 problem at the MIP6 WG, and amend the charter. In addition there seems to be a need for some general purpose architectural work around privacy, and James Kempf promised to start some paper around that. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 10 11:28:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27319 for ; Wed, 10 Nov 2004 11:28:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRvLU-0006b6-TS for mip6-web-archive@ietf.org; Wed, 10 Nov 2004 11:29:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvAh-00016R-7p; Wed, 10 Nov 2004 11:18:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRv6L-0008Uw-2I for mip6@megatron.ietf.org; Wed, 10 Nov 2004 11:13:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25419 for ; Wed, 10 Nov 2004 11:13:38 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRv7J-00069u-Nb for mip6@ietf.org; Wed, 10 Nov 2004 11:14:42 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iAAFjLB20794; Wed, 10 Nov 2004 07:45:21 -0800 X-mProtect: <200411101545> Nokia Silicon Valley Messaging Protection Received: from danira-pool05148.americas.nokia.com (10.241.51.48, claiming to be "[10.241.51.48]") by darkstar.iprg.nokia.com smtpd4JaLez; Wed, 10 Nov 2004 07:45:19 PST Message-ID: <41923E05.7090408@iprg.nokia.com> Date: Wed, 10 Nov 2004 08:12:53 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Minutes of Privacy Bar Bof held on Nov 8th, 2004 References: <697DAA22C5004B4596E033803A7CEF4403B1C143@daebe007.americas.nokia.com> In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1C143@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: 7bit hi Raj, I made a comment about how location privacy from the CN can be achieved by reverse tunneling everything (including the BU) through an IPsec protected tunnel between the MN and the HA. this is something we can do today without modifying any protocol. SPD entries can be easily setup for this. I mentioned we can use RFC 3041 generated home address (generated every few days) with an optional dynamic DNS update from the HA to provide the same level of privacy that is available in IPv6 today. I also said we must work on a solution that achieves location privacy from the visited network while still doing route optimization with the CN. all these comments are missing from the minutes. Vijay Basavaraj.Patil@nokia.com wrote: > Thanks to TJ for these notes. And corrections by Jari Arkko. > > ----------------------------------------------------------- > > > > Notes from IETF61 Privacy BAR BOF -- 35 attendees (names witheld for privacy). > 8 Nov 04 -- 10pm - 11:15pm > Basavaraj P. leading. Notes by TJ Kniveton. > > James Kempf - Wrote an ISOC paper on the regulatory situation in US, > Japan and Europe about IPv6 location..anyone deploying MIPv6 might > want to look at it. In the US, not much regulation. But in Japan and > Europe, users must be given a meaningful opportunity > Architectural considerations about privacy. Every protocol > instantiates them differently. > > Raj - privacy means different things to different people.. > > Wassim - focus on MAC and IP layers. Highlights the need to update > them in a synchronized way, so that you don't change just one and > leave the other unchanged. > > Hesham - there are so many upper layer identifiers, such as > cookies. Thinking we solve the problem of privacy at IP and it's done > isn't true. > > Jari Arkko - Privacy is not fully provided until you have solved it at > the MAC layer, IP layer, authentication layer, mobility > layer. On the other hand, things on those different layers have to be > solved on their own. > > Erik N. - Cases where you want to be reachable under a different > identifier. But other cases you don't want to disclose on outbound > communication, information that allows traceability. > > Hesham - if you're making a call outbound and you try to hide your > identity > > TJ - Who are we trying to keep the privacy from? correspondent? > routing infra? If I make a phone call, I can hide my caller ID > info.. but the phone company still knows who I am, and if the police > wants to know who I called, they can find out. > > RFC 3041 thinks already about crossing boundaries. Shouldn't have a > PTR record that points back to your permanent name. I might want to > use different identities to hide things. > > Raj - We want to talk about link layer identifier. Is that something > the IETF should even be looking at? > > Kempf - we might want to mention it, but don't dwell on it. > > Arkko - There's a difference between defining the problem and solving it. > > Greg Daley - if we leave it there unresolved, it's an achilles > heel. Because anyone can snoop mac addresses. > > -some talk about cellular networks and whether you send an identifier > to initiate calls. Sends identity in clear when you first buy the > phone and turn it on, but not every time you turn it on. > > Kempf - 3GPP2 is interested in what happens in IETF. We don't want to > come up with a solution, and then a year later they come and say, > sorry this doesn't work etc. We should engage them now to get a set of > requirements. > > Hesham - but we haven't even started a BOF yet. > > Kempf - 3GPP comes a lot, talks in SIP wgs, etc. 3GPP2 doesn't tend to > do that.. How can we get them to talk to us? > > Arkko - Works 2 ways. It might be useful to tell other bodies as well > if they have something they need to fix. > > Nordmark - does anyone know if IEEE 802.11 has looked at this? > > Kempf - They're not even close to this, they have been working on > authentication. > > Pasi Eronen - They looked at this a few times over the years. Now > they're doing the opposite -- getting certificates based on MAC > addresses. > > TJ - Maybe this is a stupid question, but why do we really need to > protect location privacy for IP addresses? I don't care if someone > knows I'm in Washington DC because of the IP i'm using. > > Hesham - Well there are some criminals who really care about that. > > Eronen - Well if you're in DC, that's fine. But if someone can tell > where you are within 100m, they can come with an AK-47.. > > TJ - but can they really tell where I am within 100m?... > > .... discussion > > Kempf - well we need to satisfy regulators. > > Some fighting about what MIPv6 spec says for SPI selector, ESP > header.... Can anyone on the home link tell where the MN is, or just > the HA? > > Erik: privacy aspects of multihoming > Erik - You have a HoA, CoA. might want to use multiple sets of > those. When you switch, you want to switch both at the same time. > > IKE - uses same SPI each time. > > Arkko - you always use the same IKE SPI, but you can renegotiate the > IPsec SPI. > > F Dupont - it's only useful if you are close to the security gateway. > > > Raj - Questions we should ask here > - Is this work even of interest in the IETF? > - Privacy: is this something that should be dealt with on a mobility > aspect, or should it be a broader question that is addressed with a > new charter? > > Hesham - This requires expertise from more than one WG. Location > privacy for MNs can be tackled. > > Arkko - HIP, MIPv6, etc. all have different privacy issues. > > Kempf - I would support updating the MIPv6 charter for that purpose. > > Arkko - But even beyond that, what about identity issues in MIP? More > than just location privacy. > > Hesham - make it so that location information and home address don't > show up in the same packets. > > Eronen- we need a threat description, because it's not a binary > thing. If you can link things together, sooner or later you end up > losing both location and identity information. You can solve against > unbounded adversary capabilities. > > Kempf - We need something realistic like what we did for binding updates. > > nn - The endpoint has to be identified. You can't communicate without > knowing the endpoints. So we want to protect the privacy as far as > possible. You can't eliminate all possible cases where privacy can be > breached. > > Conclusion: Will suggest a change to the charter and contact. > Jari: Conclusion was that the problem is interesting and that > we should attempt solving parts of the MIPv6 problem at the MIP6 WG, > and amend the charter. In addition there seems to be a need for > some general purpose architectural work around privacy, and James Kempf > promised to start some paper around that. > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 10 11:40:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28563 for ; Wed, 10 Nov 2004 11:40:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRvXK-0006vq-6N for mip6-web-archive@ietf.org; Wed, 10 Nov 2004 11:41:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvOC-0004RO-7t; Wed, 10 Nov 2004 11:32:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvF3-0001uu-VA for mip6@megatron.ietf.org; Wed, 10 Nov 2004 11:22:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26631 for ; Wed, 10 Nov 2004 11:22:39 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRvG2-0006Ri-5g for mip6@ietf.org; Wed, 10 Nov 2004 11:23:43 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iAAGLup20086; Wed, 10 Nov 2004 17:21:56 +0100 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 iAAGLvSj093395; Wed, 10 Nov 2004 17:21:57 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411101621.iAAGLvSj093395@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] Minutes of Privacy Bar Bof held on Nov 8th, 2004 In-reply-to: Your message of Wed, 10 Nov 2004 09:29:30 CST. <697DAA22C5004B4596E033803A7CEF4403B1C143@daebe007.americas.nokia.com> Date: Wed, 10 Nov 2004 17:21:57 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 In your previous mail you wrote: Conclusion: Will suggest a change to the charter and contact. Jari: Conclusion was that the problem is interesting and that we should attempt solving parts of the MIPv6 problem at the MIP6 WG, and amend the charter. In addition there seems to be a need for some general purpose architectural work around privacy, and James Kempf promised to start some paper around that. => we agree too to continue the problem statement effort, including not MIPv6 issue like the L2/L3 stuff. Regards Francis.Dupont@enst-bretagne.fr PS: how the charter will be updated? Will there be a point about this in the Friday session agenda? _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 10 13:09:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07389 for ; Wed, 10 Nov 2004 13:09:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRwvY-0000Vg-MI for mip6-web-archive@ietf.org; Wed, 10 Nov 2004 13:10:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRwt0-0005X9-4O; Wed, 10 Nov 2004 13:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRwpY-0004xQ-GU for mip6@megatron.ietf.org; Wed, 10 Nov 2004 13:04:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06987 for ; Wed, 10 Nov 2004 13:04:24 -0500 (EST) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRwqX-0000PS-Kk for mip6@ietf.org; Wed, 10 Nov 2004 13:05:30 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id A13DB8000A3; Wed, 10 Nov 2004 20:03:54 +0200 (EET) Date: Wed, 10 Nov 2004 20:03:54 +0200 (EET) From: Wassim Haddad To: Vijay Devarapalli Subject: Re: [Mip6] Minutes of Privacy Bar Bof held on Nov 8th, 2004 In-Reply-To: <41923E05.7090408@iprg.nokia.com> Message-ID: References: <697DAA22C5004B4596E033803A7CEF4403B1C143@daebe007.americas.nokia.com> <41923E05.7090408@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi all, There was also another comment about writing a threat model draft (to answer some comments/questions. I (and Raj) mentioned during the meeting that we are working on such draft but all what I've read in the minutes is about the famous architectural draft. Regards, Wassim H. On Wed, 10 Nov 2004, Vijay Devarapalli wrote: > hi Raj, > > I made a comment about how location privacy from the CN can > be achieved by reverse tunneling everything (including the BU) > through an IPsec protected tunnel between the MN and the HA. > this is something we can do today without modifying any > protocol. SPD entries can be easily setup for this. > > I mentioned we can use RFC 3041 generated home address > (generated every few days) with an optional dynamic DNS update > from the HA to provide the same level of privacy that is > available in IPv6 today. > > I also said we must work on a solution that achieves location > privacy from the visited network while still doing route > optimization with the CN. > > all these comments are missing from the minutes. > > Vijay > > Basavaraj.Patil@nokia.com wrote: > > > Thanks to TJ for these notes. And corrections by Jari Arkko. > > > > ----------------------------------------------------------- > > > > =C3> > > > Notes from IETF61 Privacy BAR BOF -- 35 attendees (names witheld for pr= ivacy). > > 8 Nov 04 -- 10pm - 11:15pm > > Basavaraj P. leading. Notes by TJ Kniveton. > > > > James Kempf - Wrote an ISOC paper on the regulatory situation in US, > > Japan and Europe about IPv6 location..anyone deploying MIPv6 might > > want to look at it. In the US, not much regulation. But in Japan and > > Europe, users must be given a meaningful opportunity > > Architectural considerations about privacy. Every protocol > > instantiates them differently. > > > > Raj - privacy means different things to different people.. > > > > Wassim - focus on MAC and IP layers. Highlights the need to update > > them in a synchronized way, so that you don't change just one and > > leave the other unchanged. > > > > Hesham - there are so many upper layer identifiers, such as > > cookies. Thinking we solve the problem of privacy at IP and it's done > > isn't true. > > > > Jari Arkko - Privacy is not fully provided until you have solved it at > > the MAC layer, IP layer, authentication layer, mobility > > layer. On the other hand, things on those different layers have to be > > solved on their own. > > > > Erik N. - Cases where you want to be reachable under a different > > identifier. But other cases you don't want to disclose on outbound > > communication, information that allows traceability. > > > > Hesham - if you're making a call outbound and you try to hide your > > identity > > > > TJ - Who are we trying to keep the privacy from? correspondent? > > routing infra? If I make a phone call, I can hide my caller ID > > info.. but the phone company still knows who I am, and if the police > > wants to know who I called, they can find out. > > > > RFC 3041 thinks already about crossing boundaries. Shouldn't have a > > PTR record that points back to your permanent name. I might want to > > use different identities to hide things. > > > > Raj - We want to talk about link layer identifier. Is that something > > the IETF should even be looking at? > > > > Kempf - we might want to mention it, but don't dwell on it. > > > > Arkko - There's a difference between defining the problem and solving i= t. =A9> > > > Greg Daley - if we leave it there unresolved, it's an achilles > > heel. Because anyone can snoop mac addresses. > > > > -some talk about cellular networks and whether you send an identifier > > to initiate calls. Sends identity in clear when you first buy the > > phone and turn it on, but not every time you turn it on. > > > > Kempf - 3GPP2 is interested in what happens in IETF. We don't want to > > come up with a solution, and then a year later they come and say, > > sorry this doesn't work etc. We should engage them now to get a set of > > requirements. > > > > Hesham - but we haven't even started a BOF yet. > > > > Kempf - 3GPP comes a lot, talks in SIP wgs, etc. 3GPP2 doesn't tend to > > do that.. How can we get them to talk to us? > > > > Arkko - Works 2 ways. It might be useful to tell other bodies as well > > if they have something they need to fix. > > > > Nordmark - does anyone know if IEEE 802.11 has looked at this? > > > > Kempf - They're not even close to this, they have been working on > > authentication. > > > > Pasi Eronen - They looked at this a few times over the years. Now > > they're doing the opposite -- getting certificates based on MAC > > addresses. > > > > TJ - Maybe this is a stupid question, but why do we really need to > > protect location privacy for IP addresses? I don't care if someone > > knows I'm in Washington DC because of the IP i'm using. > > > > Hesham - Well there are some criminals who really care about that. > > > > Eronen - Well if you're in DC, that's fine. But if someone can tell > > where you are within 100m, they can come with an AK-47.. > > > > TJ - but can they really tell where I am within 100m?... > > > > .... discussion > > > > Kempf - well we need to satisfy regulators. > > > > Some fighting about what MIPv6 spec says for SPI selector, ESP > > header.... Can anyone on the home link tell where the MN is, or just > > the HA? > > > > Erik: privacy aspects of multihoming > > Erik - You have a HoA, CoA. might want to use multiple sets of > > those. When you switch, you want to switch both at the same time. > > > > IKE - uses same SPI each time. > > > > Arkko - you always use the same IKE SPI, but you can renegotiate the > > IPsec SPI. > > > > F Dupont - it's only useful if you are close to the security gateway. > > > > > > Raj - Questions we should ask here > > - Is this work even of interest in the IETF? > > - Privacy: is this something that should be dealt with on a mobility > > aspect, or should it be a broader question that is addressed with a > > new charter? > > > > Hesham - This requires expertise from more than one WG. Location > > privacy for MNs can be tackled. > > > > Arkko - HIP, MIPv6, etc. all have different privacy issues. > > > > Kempf - I would support updating the MIPv6 charter for that purpose. > > > > Arkko - But even beyond that, what about identity issues in MIP? More > > than just location privacy. > > > > Hesham - make it so that location information and home address don't > > show up in the same packets. > > > > Eronen- we need a threat description, because it's not a binary > > thing. If you can link things together, sooner or later you end up > > losing both location and identity information. You can solve against > > unbounded adversary capabilities. > > > > Kempf - We need something realistic like what we did for binding update= s. > > > > nn - The endpoint has to be identified. You can't communicate without > > knowing the endpoints. So we want to protect the privacy as far as > > possible. You can't eliminate all possible cases where privacy can be > > breached. > > > > Conclusion: Will suggest a change to the charter and contact. > > Jari: Conclusion was that the problem is interesting and that > > we should attempt solving parts of the MIPv6 problem at the MIP6 WG, > > and amend the charter. In addition there seems to be a need for > > some general purpose architectural work around privacy, and James Kempf > > promised to start some paper around that. > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 10 13:16:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07982 for ; Wed, 10 Nov 2004 13:16:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRx2H-0000dH-3H for mip6-web-archive@ietf.org; Wed, 10 Nov 2004 13:17:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRwtw-0005fJ-U4; Wed, 10 Nov 2004 13:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRwrz-0005KM-4M for mip6@megatron.ietf.org; Wed, 10 Nov 2004 13:06:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07165 for ; Wed, 10 Nov 2004 13:06:55 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRwsw-0000SA-9S for mip6@ietf.org; Wed, 10 Nov 2004 13:08:01 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iAAI6HF29129; Wed, 10 Nov 2004 19:06:17 +0100 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 iAAI6HSj093741; Wed, 10 Nov 2004 19:06:17 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411101806.iAAI6HSj093741@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli Subject: Re: [Mip6] Minutes of Privacy Bar Bof held on Nov 8th, 2004 In-reply-to: Your message of Wed, 10 Nov 2004 08:12:53 PST. <41923E05.7090408@iprg.nokia.com> Date: Wed, 10 Nov 2004 19:06:17 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb In your previous mail you wrote: I made a comment about how location privacy from the CN can be achieved by reverse tunneling everything (including the BU) through an IPsec protected tunnel between the MN and the HA. this is something we can do today without modifying any protocol. SPD entries can be easily setup for this. => I don't believe it is a good idea (it is a part of what I call the VPN temptation) but I agree we talked about it! I mentioned we can use RFC 3041 generated home address (generated every few days) with an optional dynamic DNS update from the HA to provide the same level of privacy that is available in IPv6 today. => I don't know if registering addition home addresses is really supported but of course it is a way to hide actual home addresses (because the extra HR BUs will be protected using so will get the first home address). I also said we must work on a solution that achieves location privacy from the visited network while still doing route optimization with the CN. => as I have a concrete proposal to provide this I do support you all these comments are missing from the minutes. => it seems the minutes miss many details??? Thanks Francis.Dupont@enst-bretagne.fr PS: good minutes are critical: a common and stupid way to loose time is to fix the minutes of the previous meeting. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 10 22:43:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09256 for ; Wed, 10 Nov 2004 22:43:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS5si-0007Bo-7r for mip6-web-archive@ietf.org; Wed, 10 Nov 2004 22:44:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS5on-0008Ap-7Z; Wed, 10 Nov 2004 22:40:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS5j3-0007M8-Gj for mip6@megatron.ietf.org; Wed, 10 Nov 2004 22:34:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08536 for ; Wed, 10 Nov 2004 22:34:18 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS5k8-00070m-BK for mip6@ietf.org; Wed, 10 Nov 2004 22:35:28 -0500 Received: from iseran.local (unknown [130.129.132.200]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id D610F4C0A9 for ; Thu, 11 Nov 2004 12:33:48 +0900 (JST) Date: Thu, 11 Nov 2004 12:36:30 +0900 From: Thierry Ernst To: mip6@ietf.org Subject: Re: [Mip6] FW: MIP6 agenda (Final) Message-Id: <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Dear Basavaraj, > > Time permitting, we will discuss these IDs and interest in this work: > > > > a. Multihoming in MIP6 > > I-Ds: draft-montavont-mobileip-multihoming-pb-statement-02.txt > > draft-ernst-generic-goals-and-benefits-00.txt > > Nicolas Montavont Well, I hope that you will make it permitted, because this is a rather important issue on which we need feedback from the WG. We need some standardized mechanisms to handle multiple interfaces on the MN. The answer the MIP6 WG will give to this question will have an impact on how we are going to handle it in the NEMO WG. Note that I will make this presentation instead of Nicolas and that I do not intend to present the drafts (I will assume people have read it). I will rather have a couple of slides to motivate my question: can we include multiple interfaces support in MIP6 as a WG item ? If not, there are enough people willing to set up a BOF for discussing it at next IETF, but I would rather make sure we check this with the MIP6 WG first. Thierry (with no NEMO chair hat on) > > b. Load Balance for Distributed Home Agents in Mobile IPv6 > > I-D: draft-deng-mip6-ha-loadbalance-02.txt > > Hui Deng _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 10 22:49:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09920 for ; Wed, 10 Nov 2004 22:49:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS5yw-0007Jz-QG for mip6-web-archive@ietf.org; Wed, 10 Nov 2004 22:50:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS5pN-0008Kk-Qg; Wed, 10 Nov 2004 22:40:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS5mE-0007Zj-Ul for mip6@megatron.ietf.org; Wed, 10 Nov 2004 22:37:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08747 for ; Wed, 10 Nov 2004 22:37:36 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS5nJ-00074D-LZ for mip6@ietf.org; Wed, 10 Nov 2004 22:38:46 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iAB3ax106835; Thu, 11 Nov 2004 05:37:01 +0200 Date: Thu, 11 Nov 2004 05:36:59 +0200 (EET) From: Pekka Savola To: narten@us.ibm.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: mip6@ietf.org Subject: [Mip6] Appeal on MIP6 Consensus Call X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Thomas, This is an appeal to annull the interpretation on 13th Oct [1] of the consensus call on standardizing an authentication protocol. The result was 13 against, and 25 for (Actually, 24 for, because one was apparently counted twice.) The chairs judged this to be rough consensus. I consider this in itself a very rough consensus call, remembering that the IETF does vote. Further, examining those who voiced an opinion is revealing. Of those who responded "yes", apparently 10 had not written a single message on the Mobile IP mailing list during about a year (and possibly longer). Further two people had only responded to this consensus call, and the earlier consensus call on the justification for the authentication sub-option. The similar counts for those who responded "no" was zero. It seems likely that the IETF consensus process has been circumvented by "room packing" by a community to achieve a result against significant objection to the significant number of active WG participants. Therefore I request that the interpretation of the result of the consensus call be annulled; I do not believe there was sufficient rough consensus among WG participants to standardize the authentication protocol. (However, there may have been sufficient consensus on creating an experimental protocol.) [1] http://www1.ietf.org/mail-archive/web/mip6/current/msg01783.html Thanks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 11 05:24:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21929 for ; Thu, 11 Nov 2004 05:24:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSC8q-0006Ca-WE for mip6-web-archive@ietf.org; Thu, 11 Nov 2004 05:25:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSC2b-0007bd-KA; Thu, 11 Nov 2004 05:18:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSC0y-0007Hh-6J for mip6@megatron.ietf.org; Thu, 11 Nov 2004 05:17:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21278 for ; Thu, 11 Nov 2004 05:17:13 -0500 (EST) Received: from mn-2.atm.tut.fi ([130.230.52.147] helo=mn-2) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSC23-00061y-Co for mip6@ietf.org; Thu, 11 Nov 2004 05:18:26 -0500 Received: from mark by mn-2 with local (Exim 3.36 #1 (Debian)) id 1CSBze-0006Qe-00; Thu, 11 Nov 2004 12:15:54 +0200 From: Mark Borst To: Samita Chakrabarti In-Reply-To: <41922D34.70605@eng.sun.com> References: <200411022030.iA2KUDCj478937@jurassic.eng.sun.com> <1099488713.13194.22.camel@mn-2> <41922D34.70605@eng.sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 11 Nov 2004 12:15:53 +0200 Message-Id: <1100168153.24452.3.camel@mn-2> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, samita.chakrabarti@sun.com Subject: [Mip6] Re: Comments on draft-borst-mip6api-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit On Wed, 2004-11-10 at 07:01 -0800, Samita Chakrabarti wrote: > Mark Borst wrote: > > >Hello > >> > >>- Please mention in the introduction and section 3 (goals and requirements) > >> that the application level API should use "MIP6 Sockets API" to access > >> low level data when applicable. > >> > > > >This is actually an implementation requirement, which cannot be a > >'requirement'. We have extensively thought about it, but it proves to be > >more a burden than a benefit to use the "MIP6 Sockets API" in this case. > >The thing is that you are then duplicating a lot of code that is already > >in the MIPv6 stack, for instance for the movement detection. This is at > >least valid for the MIPL platform. We could add it as a hint to > >implementers though. > > > The API is a specification for implementation. I would rather say: The API is a specification of the external behaviour of its implementations. I would say that leaves the actual implementation up to the implementors. > My suggestion was to > include "MIP6 Socket API" as one of the preferable options for > underlying implementations. I still don't think that the option can be 'preferable', but it certainly can be an option and we can include a statement regarding this. -- Mark Borst Researcher Network and Protocols Group Tampere University of Technology, Finland _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 11 07:15:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01718 for ; Thu, 11 Nov 2004 07:15:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSDsF-0008Vk-M6 for mip6-web-archive@ietf.org; Thu, 11 Nov 2004 07:16:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSDp6-0007vG-TS; Thu, 11 Nov 2004 07:13:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSDjt-0006fc-9l for mip6@megatron.ietf.org; Thu, 11 Nov 2004 07:07:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01030 for ; Thu, 11 Nov 2004 07:07:42 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSDl2-0008JJ-QO for mip6@ietf.org; Thu, 11 Nov 2004 07:08:57 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iABC75r17019; Thu, 11 Nov 2004 14:07:07 +0200 Date: Thu, 11 Nov 2004 14:07:05 +0200 (EET) From: Pekka Savola To: narten@us.ibm.com Subject: Re: [Mip6] Appeal on MIP6 Consensus Call In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Thu, 11 Nov 2004, Pekka Savola wrote: > It seems likely that the IETF consensus process has been circumvented by > "room packing" by a community to achieve a result against significant > objection to the significant number of active WG participants. s/objection to/objection of/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 11 12:04:57 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02266 for ; Thu, 11 Nov 2004 12:04:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSIOj-0007DW-5V for mip6-web-archive@ietf.org; Thu, 11 Nov 2004 12:06:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSIGj-0001VT-Fl; Thu, 11 Nov 2004 11:57:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSIBB-00006w-3v for mip6@megatron.ietf.org; Thu, 11 Nov 2004 11:52:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00826 for ; Thu, 11 Nov 2004 11:52:10 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSICN-0006q3-Gn for mip6@ietf.org; Thu, 11 Nov 2004 11:53:27 -0500 Received: from jurassic.eng.sun.com ([129.146.88.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id iABGq9ui029626; Thu, 11 Nov 2004 09:52:09 -0700 (MST) Received: from eng.sun.com (vpn-129-150-66-16.East.Sun.COM [129.150.66.16]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iABGpxEu950612; Thu, 11 Nov 2004 08:52:04 -0800 (PST) Message-ID: <419398AA.2030002@eng.sun.com> Date: Thu, 11 Nov 2004 08:51:54 -0800 From: Samita Chakrabarti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Borst References: <200411022030.iA2KUDCj478937@jurassic.eng.sun.com> <1099488713.13194.22.camel@mn-2> <41922D34.70605@eng.sun.com> <1100168153.24452.3.camel@mn-2> In-Reply-To: <1100168153.24452.3.camel@mn-2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, samita.chakrabarti@sun.com Subject: [Mip6] Re: Comments on draft-borst-mip6api-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Mark Borst wrote: > >>> >>> >>> >>The API is a specification for implementation. >> >> > >I would rather say: The API is a specification of the external behaviour >of its implementations. I would say that leaves the actual >implementation up to the implementors. > > What is your definition of implementation? I was distinguishing between implementation and protocol specification. > > >>My suggestion was to >>include "MIP6 Socket API" as one of the preferable options for >>underlying implementations. >> >> > >I still don't think that the option can be 'preferable', but it >certainly can be an option and we can include a statement regarding >this. > > > > All the interfaces defined in the APPLICATION api do not need to use Socket APi extension for obvious reasons. But using socket API calls underneath this application api is preferable for portability wherever it is applicable. -Samita _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 11 12:30:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05238 for ; Thu, 11 Nov 2004 12:30:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSInD-0007yc-Sd for mip6-web-archive@ietf.org; Thu, 11 Nov 2004 12:31:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSIha-0001Eo-PI; Thu, 11 Nov 2004 12:25:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSIJI-00022j-Bl for mip6@megatron.ietf.org; Thu, 11 Nov 2004 12:00:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01727 for ; Thu, 11 Nov 2004 12:00:33 -0500 (EST) Received: from mn-2.atm.tut.fi ([130.230.52.147] helo=mn-2) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSIKT-00074Q-I9 for mip6@ietf.org; Thu, 11 Nov 2004 12:01:50 -0500 Received: from mark by mn-2 with local (Exim 3.36 #1 (Debian)) id 1CSIHv-0001PW-00; Thu, 11 Nov 2004 18:59:11 +0200 From: Mark Borst To: Samita Chakrabarti In-Reply-To: <419398AA.2030002@eng.sun.com> References: <200411022030.iA2KUDCj478937@jurassic.eng.sun.com> <1099488713.13194.22.camel@mn-2> <41922D34.70605@eng.sun.com> <1100168153.24452.3.camel@mn-2> <419398AA.2030002@eng.sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 11 Nov 2004 18:59:09 +0200 Message-Id: <1100192350.24452.18.camel@mn-2> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, samita.chakrabarti@sun.com Subject: [Mip6] Re: Comments on draft-borst-mip6api-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit On Thu, 2004-11-11 at 08:51 -0800, Samita Chakrabarti wrote: > Mark Borst wrote: > > >>> > >>The API is a specification for implementation. > > > >I would rather say: The API is a specification of the external behaviour > >of its implementations. I would say that leaves the actual > >implementation up to the implementors. > > > What is your definition of implementation? > I was distinguishing between implementation and protocol specification. I think I misinterpreted your comment then. Yes, we are specifying an implementation, not a protocol. I was meaning to say that we specify the outside behaviour of the black box, not how the black box is working. So I meant with implementation: the black box, ultimately object code, but originating from source code. But I think we mean the same, just are saying it a bit differently. > >>My suggestion was to > >>include "MIP6 Socket API" as one of the preferable options for > >>underlying implementations. > > > >I still don't think that the option can be 'preferable', but it > >certainly can be an option and we can include a statement regarding > >this. > > > All the interfaces defined in the APPLICATION api do not need to use > Socket APi extension for obvious reasons. But using socket API calls underneath this > application api is preferable for portability wherever it is applicable. Agreed. Regards, -- Mark Borst Researcher Network and Protocols Group Tampere University of Technology, Finland _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 11 15:51:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25951 for ; Thu, 11 Nov 2004 15:51:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSLwM-0004XB-8N for mip6-web-archive@ietf.org; Thu, 11 Nov 2004 15:53:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLpk-0004Ff-Fb; Thu, 11 Nov 2004 15:46:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSLh1-0007ft-2q for mip6@megatron.ietf.org; Thu, 11 Nov 2004 15:37:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23908 for ; Thu, 11 Nov 2004 15:37:17 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSLiE-00045L-0c for mip6@ietf.org; Thu, 11 Nov 2004 15:38:35 -0500 Received: from jurassic.eng.sun.com ([129.146.88.130]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id iABKbFs3014264; Thu, 11 Nov 2004 12:37:15 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.1+Sun/8.13.1) with ESMTP id iABKbA03226125; Thu, 11 Nov 2004 12:37:11 -0800 (PST) Message-ID: <4193C2B2.5050200@sun.com> Date: Thu, 11 Nov 2004 11:51:14 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [Mip6] FW: MIP6 agenda (Final) References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> In-Reply-To: <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > Dear Basavaraj, > > >>>Time permitting, we will discuss these IDs and interest in this work: >>> >>>a. Multihoming in MIP6 >>> I-Ds: draft-montavont-mobileip-multihoming-pb-statement-02.txt >>> draft-ernst-generic-goals-and-benefits-00.txt >>> Nicolas Montavont > > > Well, I hope that you will make it permitted, because this is a rather > important issue on which we need feedback from the WG. We need some > standardized mechanisms to handle multiple interfaces on the MN. The > answer the MIP6 WG will give to this question will have an impact on how > we are going to handle it in the NEMO WG. I'm concerned that the above draft just scratches the surface of the problem. Being able to tell the HA that the MR/MN has multiple CoAs doesn't provide a mechanism for them to determine which of the paths is working, and an interoperable mechanism for this would be needed. Furthermore, work on multihoming in the multi6 WG has wisely limited its scope to finding one working path, and in the MIP/Nemo context there has been discussion of QoS of the different paths being taken into account. While I understand the issue of wireless L2s with different bandwidth, that problem is present even without any mobility; it shows up with a laptop using WLAN and GPRS. Thus embarking on QoS sensitive, mobility specific multihoming support is both too open ended (on the QoS side) and too constraining (by only looking at cases when MIP/Nemo is used). So I think it would be useful for folks to try to think about and discuss the bigger picture. Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 11 16:30:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00400 for ; Thu, 11 Nov 2004 16:30:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMXR-0005ln-B5 for mip6-web-archive@ietf.org; Thu, 11 Nov 2004 16:31:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMN1-0008Ef-ED; Thu, 11 Nov 2004 16:20:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMGB-0003ov-Kp for mip6@megatron.ietf.org; Thu, 11 Nov 2004 16:13:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28775 for ; Thu, 11 Nov 2004 16:13:37 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMHP-0005Id-SO for mip6@ietf.org; Thu, 11 Nov 2004 16:14:56 -0500 Received: from iseran.local (unknown [130.129.132.200]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 5522A4C0B2 for ; Fri, 12 Nov 2004 06:13:00 +0900 (JST) Date: Fri, 12 Nov 2004 06:15:43 +0900 From: Thierry Ernst To: mip6@ietf.org Subject: Re: [Mip6] FW: MIP6 agenda (Final) Message-Id: <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> In-Reply-To: <4193C2B2.5050200@sun.com> References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Thanks Erik for your mail. Some comments below. > >>>Time permitting, we will discuss these IDs and interest in this work: > >>> > >>>a. Multihoming in MIP6 > >>> I-Ds: draft-montavont-mobileip-multihoming-pb-statement-02.txt > >>> draft-ernst-generic-goals-and-benefits-00.txt > >>> Nicolas Montavont > > > > > > Well, I hope that you will make it permitted, because this is a rather > > important issue on which we need feedback from the WG. We need some > > standardized mechanisms to handle multiple interfaces on the MN. The > > answer the MIP6 WG will give to this question will have an impact on how > > we are going to handle it in the NEMO WG. > > I'm concerned that the above draft just scratches the surface of the > problem. Being able to tell the HA that the MR/MN has multiple CoAs > doesn't provide a mechanism for them to determine which of the paths is > working, and an interoperable mechanism for this would be needed. > > Furthermore, work on multihoming in the multi6 WG has wisely limited its > scope to finding one working path, and in the MIP/Nemo context there has > been discussion of QoS of the different paths being taken into account. > While I understand the issue of wireless L2s with different bandwidth, > that problem is present even without any mobility; it shows up with a > laptop using WLAN and GPRS. Exactly, this is why we specified in draft-ernst-generic-goals-and-benefits-00.txt that motivations and benefits of multihoming apply to both fixed and mobile nodes and networks. At first, we wanted to look at the problem from a mobility perspective, which interests us at the first place, before we noticed that the problem scope is mostly the same as for fixed nodes. However, there is more motivations to have such features available for mobile nodes as they use wireless links (more proned to failures) and move (therefore attaching to heterogenous networks). > Thus embarking on QoS sensitive, mobility specific multihoming support > is both too open ended (on the QoS side) and too constraining (by only > looking at cases when MIP/Nemo is used). > > So I think it would be useful for folks to try to think about and > discuss the bigger picture. Agree. But then, where should this discussion take place ? MIP6 WG ? NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? This said, and given the fact the feature is more needed to mobile nodes, it may appropriate to limit the problem to mobile nodes only, and to address only a specified number of the issues, bringing limited, but useful benefits, in the short term. One starting point could be to allow multiple CoA registration in MIP6, which can be done in a very reasonable time-frame (solutions already exist). This is why I would vote to conduct the work in MIP6, but my intend is also to open the debate and not let him vanish as in the past. Thierry. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 11 16:49:21 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02351 for ; Thu, 11 Nov 2004 16:49:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMpz-0006Gn-S5 for mip6-web-archive@ietf.org; Thu, 11 Nov 2004 16:50:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMiK-0007ug-Hk; Thu, 11 Nov 2004 16:42:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMTf-0003WZ-4k for mip6@megatron.ietf.org; Thu, 11 Nov 2004 16:27:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00166 for ; Thu, 11 Nov 2004 16:27:33 -0500 (EST) Received: from cms1.etri.re.kr ([129.254.16.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMUs-0005g9-VZ for mip6@ietf.org; Thu, 11 Nov 2004 16:28:52 -0500 Received: from ETRIYSLEE (130.129.135.101 [130.129.135.101]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VRHJAPMG; Fri, 12 Nov 2004 06:26:41 +0900 Message-ID: <000b01c4c835$259489d0$65878182@ETRIYSLEE> From: "Junghoon Jee" To: , References: <697DAA22C5004B4596E033803A7CEF4403B1BFB5@daebe007.americas.nokia.com> Subject: Re: [Mip6] WGLC: I-D draft-ietf-mip6-bootstrap-ps-01.txt Date: Thu, 11 Nov 2004 16:26:38 -0500 Organization: CMS MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.2 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Junghoon Jee List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0178956667==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 --===============0178956667== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 VmVyeSBzb3JyeSBmb3IgbGF0ZSByZXZpZXcuDQoNCkFmdGVyIGkgcmV2aWV3ZWQgdGhpcyBJLUQs IGkgaGF2ZSBnb3Qgc29tZSBxdWVzdGlvbnMuDQoNClExLiBTaG91bGQgdGhlIG5ldHdvcmsgYWNj ZXNzIHNlcnZpY2UgYmUgYWx3YXlzIHBlcmZvcm1lZCB3aGVuIGEgTU4gYm9vdHN0cmFwcyA/IA0K DQpTZWN0aW9uIDYuICBOZXR3b3JrIEFjY2VzcyBhbmQgTW9iaWxpdHkgc2VydmljZXMNCltQYWdl IDE0XQ0KT25seSBoYXZpbmcgTW9iaWxlIElQdjYgc2VydmljZSBpcyBub3QgcG9zc2libGUsIHNp bmNlIHRoZSBNb2JpbGUgSVB2NiBwcm90b2NvbCByZXF1aXJlcw0KYWJpbGl0eSB0byBzZW5kIGFu ZCByZWNlaXZlIElQdjYgcGFja2V0cy4gIA0KPT4gSXQgc2VlbXMgdGhhdCBuZXR3b3JrIGF1dGhl bnRpY2F0aW9uIHNlcnZpY2Ugc2hvdWxkIGJlIGFsd2F5cyBwZXJmb3JtZWQuDQoNClNlY3Rpb24g Ny4xICBNb2JpbGl0eSBTZXJ2aWNlIFN1YnNjcmlwdGlvbiBTY2VuYXJpbw0KPT4gVGhlcmUgaXMg bm8gd29yZHMgYWJvdXQgbmV0d29yayBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlLg0KDQpRMi4gRG9l cyB3ZSBoYXZlIHRvIGNvbnNpZGVyIHRoZSBjYXNlIG9mICBpbmZyYXN0cnVjdHVyZS1sZXNzIHNj ZW5hcmlvIA0Kd2hlbiB3ZSBkZXZlbG9wIGEgYm9vdHN0cmFwcGluZyBzb2x1dGlvbiBvciBub3Qg Pw0KDQpTZWN0aW9uIDcuNCBJbmZyYXN0cnVjdHVyZS1sZXNzIHNjZW5hcmlvDQpbUGFnZSAxN10N ClRoaXMgc3BlY2lmaWMgc2NlbmFyaW8gaXMgbm90IHN1cHBvcnRlZCBpbiB0aGlzIGRvY3VtZW50 LiAgVGhlIHJlYXNvbg0KZm9yIHRoaXMgaXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gOS4NCg0KU2Vj dGlvbiA5LiBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KVGh1cywgdGhlIGNhc2Ugb2YgaW5mcmFz dHJ1Y3R1cmUtbGVzcyBuZXR3b3JrIHdoZXJlIHRoZXJlIGlzIGFic29sdXRlbHkgDQpubyBwcmUt bWVkaWF0ZWQgdHJ1c3QgaXMga2VwdCBvdXRzaWRlIG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQu DQoNCj0+IEl0IHNlZW1zIHRoYXQgd2UgZG9uJ3QgbmVlZCB0byBjb25zaWRlciB0aGUgaW5mcmFz dHJ1Y3R1cmUtbGVzcyBzY2VuYXJpbyANCiAgICAgd2hlbiB3ZSBjcmVhdGUgYSBib290c3RyYXBw aW5nIHNvbHV0aW9uLg0KDQpKdW5naG9vbg0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0t IA0KRnJvbTogPEJhc2F2YXJhai5QYXRpbEBub2tpYS5jb20+DQpUbzogPG1pcDZAaWV0Zi5vcmc+ DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMTUsIDIwMDQgNDo1NCBQTQ0KU3ViamVjdDogW01pcDZd IFdHTEM6IEktRCBkcmFmdC1pZXRmLW1pcDYtYm9vdHN0cmFwLXBzLTAxLnR4dA0KDQoNCg0KDQpI ZWxsbywNCg0KVGhpcyBpcyBhIFdvcmtpbmcgR3JvdXAgbGFzdCBjYWxsIGZvciB0aGUgZm9sbG93 aW5nIEktRDoNCkktRCA6ZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJhcC1wcy0wMS50eHQNClRpdGxl OiBQcm9ibGVtIFN0YXRlbWVudCBmb3IgYm9vdHN0cmFwcGluZyBNb2JpbGUgSVB2Ng0KDQpUaGUg c3RhdHVzIGFzc29jaWF0ZWQgd2l0aCB0aGlzIEktRCBpcyA6IEluZm9ybWF0aW9uYWwgYW5kIHdp bGwgYmUNCnByb2dyZXNzZWQgYXMgc3VjaC4NCg0KUGxlYXNlIHJldmlldyBhbmQgcG9zdCB5b3Vy IGNvbW1lbnRzIGJ5IE9jdG9iZXIgMzB0aCwgMjAwNC4NCg0KLUNoYWlycw0KDQpVUkwgdG8gSS1E Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1taXA2LWJv b3RzdHJhcC1wcy0wMS50eHQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCk1pcDYgbWFpbGluZyBsaXN0DQpNaXA2QGlldGYub3JnDQpodHRwczovL3d3 dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taXA2 --===============0178956667== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0178956667==-- From mip6-bounces@ietf.org Thu Nov 11 17:05:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03967 for ; Thu, 11 Nov 2004 17:05:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSN5u-0006en-6o for mip6-web-archive@ietf.org; Thu, 11 Nov 2004 17:07:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMpF-00023P-Ei; Thu, 11 Nov 2004 16:49:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSMmm-0000gn-76 for mip6@megatron.ietf.org; Thu, 11 Nov 2004 16:47:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02207 for ; Thu, 11 Nov 2004 16:47:18 -0500 (EST) Received: from cms1.etri.re.kr ([129.254.16.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSMo0-0006CT-4M for mip6@ietf.org; Thu, 11 Nov 2004 16:48:37 -0500 Received: from ETRIYSLEE (130.129.135.101 [130.129.135.101]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VRHJAQC8; Fri, 12 Nov 2004 06:46:10 +0900 Message-ID: <002001c4c837$de948b90$65878182@ETRIYSLEE> From: "Junghoon Jee" To: Date: Thu, 11 Nov 2004 16:44:27 -0500 Organization: CMS MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 1.1 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Mip6] Local HA Assignment issue X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Junghoon Jee List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0727316306==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 --===============0727316306== Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SSB3b3VsZCBsaWtlIHRvIGtub3cgd2hldGhlciB0aGUgbG9jYWwgSEEgYXNzaWdubWVudCBmdW5j dGlvbiBzaG91bGQgYmUNCmluY2x1ZGVkIHRvIHRoZSBNSVA2IFdHJ3MgYm9vdHN0cmFwcGluZyBz b2x1dGlvbiBvciBub3QuDQoNCmRyYWZ0LWlldGYtbWlwNi1ib290c3RyYXAtcHMtMDEudHh0DQpT ZWN0aW9uIDUuMS4yICBEeW5hbWljIEhvbWUgQWdlbnQgQXNzaWdubWVudA0KW1BhZ2UgMTBdDQpM b2NhbCBob21lIGFnZW50cw0KICAgICAgVGhlIG1vYmlsZSBub2RlJ3MgaG9tZSBBU1AgbWF5IHdh bnQgdG8gYWxsb3cgYSBsb2NhbCByb2FtaW5nDQogICAgICBwYXJ0bmVyIEFTUCB0byBhc3NpZ24g YSBsb2NhbCBob21lIGFnZW50IGZvciB0aGUgbW9iaWxlIG5vZGUuDQogICAgICBUaGlzIGlzIHVz ZWZ1bCBib3RoIGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgY29tbXVuaWNhdGlvbnMNCiAgICAg IGVmZmljaWVuY3ksIGFuZCBoYXMgYWxzbyBiZWVuIG1lbnRpb25lZCBhcyBvbmUgYXBwcm9hY2gg dG8gc3VwcG9ydA0KICAgICAgbG9jYXRpb24gcHJpdmFjeS4NCg0KPT4gV2hhdCBpcyB0aGUgZXhh Y3QgbWVhbmluZyBvZiB0aGUgJ3VzZWZ1bCcgYW5kICdhbHNvIGJlZW4gbWVudGlvbmVkJyA/DQog ICAgIElzIHRoZSBsb2NhbCBob21lIGFnZW50IGZ1bmN0aW9uIG9wdGlvbmFsW01BWV0gPw0KDQpk cmFmdC1sZS1hYWEtbWlwdjYtcmVxdWlyZW1lbnRzLTAzLnR4dA0KU2VjdGlvbiA1LjUuICBIb21l IGFnZW50IGFsbG9jYXRpb24NCiAgIFN1Y2ggZnVuY3Rpb25hbGl0eSBTSE9VTEQgYWxzbyBiZSBj b25zaWRlcmVkIHdoZW4gZGVzaWduaW5nIHRoZSBBQUENCiAgIHN1cHBvcnQgZm9yIE1JUHY2IHNv bHV0aW9uLg0KPT4gSXQgc2VlbXMgdGhhdCB3ZSBTSE9VTEQgc3VwcG9ydCB0aGUgbG9jYWwgSEEg YXNzaWdubWVudCBmdW5jdGlvbi4NCg0KSSBhbHJlYWR5IGtub3cgdGhhdCBkcmFmdC1pZXRmLW1p cDYtYm9vdHN0cmFwLXBzIGlzIG5vdCBhIEktRCB0aGF0IGRlc2NyaWJlIHRoZSByZXF1aXJlbWVu dCAmDQpkcmFmdC1sZS1hYWEtbWlwdjYtcmVxdWlyZW1lbnRzIHdhcyBleHBpcmVkLg0KDQpCdXQg aSB0aGluayB0aGF0IHdlIGhhdmUgdG8gZGVjaWRlIGFib3V0IHRoaXMgYmVjYXVzZSBtYW55IGRp ZmZlcmVudCBhcHByb2FjaGVzIGNhbiBiZSBjb21lIG91dA0KZGVwZW5kaW5nIG9uIG91ciBkZWNp c2lvbi4NCg0KSnVuZ2hvb24= --===============0727316306== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0727316306==-- From mip6-bounces@ietf.org Thu Nov 11 18:34:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14409 for ; Thu, 11 Nov 2004 18:34:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSOTc-0000hM-QT for mip6-web-archive@ietf.org; Thu, 11 Nov 2004 18:35:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSORB-0001WQ-0O; Thu, 11 Nov 2004 18:33:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSOOt-0000Vv-6A for mip6@megatron.ietf.org; Thu, 11 Nov 2004 18:30:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14106 for ; Thu, 11 Nov 2004 18:30:44 -0500 (EST) Received: from ztxmail03.ztx.compaq.com ([161.114.1.207]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSOQ7-0000bi-Sl for mip6@ietf.org; Thu, 11 Nov 2004 18:32:05 -0500 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail03.ztx.compaq.com (Postfix) with ESMTP id 1F049A992; Thu, 11 Nov 2004 17:30:08 -0600 (CST) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id A5A9E555A; Thu, 11 Nov 2004 17:30:07 -0600 (CST) Received: from [127.0.0.1] by kitche.zk3.dec.com (8.9.3/1.1.27.5/27Oct00-1235PM) id SAA0001818521; Thu, 11 Nov 2004 18:30:06 -0500 (EST) Message-ID: <4193F5D5.2050403@hp.com> Date: Thu, 11 Nov 2004 18:29:25 -0500 From: Brian Haley Organization: HP Linux and Open Source Lab User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Subject: Re: [Mip6] Appeal on MIP6 Consensus Call References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: narten@us.ibm.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit I would tend to agree with Pekka on this, there were enough problems raised during the discussion, and subsequently by the Security ADs, to raise doubt this should be on the standards track. I did my own counting, and if you divide it on company/organization lines it was 10 Yes and 9 No - that's not really a rough consensus of the entities that might implement the draft. -Brian Pekka Savola wrote: > Thomas, > > This is an appeal to annull the interpretation on 13th Oct [1] of the > consensus call on standardizing an authentication protocol. > > The result was 13 against, and 25 for (Actually, 24 for, because one was > apparently counted twice.) The chairs judged this to be rough consensus. > > I consider this in itself a very rough consensus call, remembering that > the IETF does vote. Further, examining those who voiced an opinion is > revealing. Of those who responded "yes", apparently 10 had not written > a single message on the Mobile IP mailing list during about a year (and > possibly longer). Further two people had only responded to this > consensus call, and the earlier consensus call on the justification for > the authentication sub-option. The similar counts for those who > responded "no" was zero. > > It seems likely that the IETF consensus process has been circumvented by > "room packing" by a community to achieve a result against significant > objection to the significant number of active WG participants. > > Therefore I request that the interpretation of the result of the > consensus call be annulled; I do not believe there was sufficient rough > consensus among WG participants to standardize the authentication > protocol. (However, there may have been sufficient consensus on > creating an experimental protocol.) > > [1] http://www1.ietf.org/mail-archive/web/mip6/current/msg01783.html > > Thanks. > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 12 01:07:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16414 for ; Fri, 12 Nov 2004 01:07:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSUca-0008JY-Op for mip6-web-archive@ietf.org; Fri, 12 Nov 2004 01:09:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSUVf-0004aA-LS; Fri, 12 Nov 2004 01:02:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSUSn-0003vX-GE for mip6@megatron.ietf.org; Fri, 12 Nov 2004 00:59:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15490 for ; Fri, 12 Nov 2004 00:59:10 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSUU5-00087D-Nm for mip6@ietf.org; Fri, 12 Nov 2004 01:00:35 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAC5x6F24836 for ; Fri, 12 Nov 2004 07:59:07 +0200 (EET) X-Scanned: Fri, 12 Nov 2004 07:58:55 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iAC5wtEw008861 for ; Fri, 12 Nov 2004 07:58:55 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00pPuxev; Fri, 12 Nov 2004 07:58:54 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAC5wsS24659 for ; Fri, 12 Nov 2004 07:58:54 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 11 Nov 2004 23:58:53 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2004 23:58:52 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4404A6CED1@daebe007.americas.nokia.com> Thread-Topic: Slides for WG meeting @ IETF61 Thread-Index: AcTIfG8K2bPz+dJATsCeBMfHppz3kg== To: X-OriginalArrivalTime: 12 Nov 2004 05:58:53.0384 (UTC) FILETIME=[B060A480:01C4C87C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Slides for WG meeting @ IETF61 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable Are at: http://people.nokia.net/~patil/MIP6-IETF61/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 12 09:29:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06163 for ; Fri, 12 Nov 2004 09:29:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CScSA-0001Fc-26 for mip6-web-archive@ietf.org; Fri, 12 Nov 2004 09:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CScI1-0005HY-35; Fri, 12 Nov 2004 09:20:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSc8D-0002pE-Bs for mip6@megatron.ietf.org; Fri, 12 Nov 2004 09:10:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04316 for ; Fri, 12 Nov 2004 09:10:27 -0500 (EST) Received: from cms1.etri.re.kr ([129.254.16.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSc9b-0000kx-5A for mip6@ietf.org; Fri, 12 Nov 2004 09:11:55 -0500 Received: from ETRIYSLEE (130.129.135.101 [130.129.135.101]) by cms1.etri.re.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id WYFL73G4; Fri, 12 Nov 2004 23:09:55 +0900 Message-ID: <001801c4c8c1$4dd5b130$65878182@ETRIYSLEE> From: "Junghoon Jee" To: "Junghoon Jee" , , References: <697DAA22C5004B4596E033803A7CEF4403B1BFB5@daebe007.americas.nokia.com> <000b01c4c835$259489d0$65878182@ETRIYSLEE> Subject: Re: [Mip6] WGLC: I-D draft-ietf-mip6-bootstrap-ps-01.txt Date: Fri, 12 Nov 2004 09:09:56 -0500 Organization: CMS MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 2.2 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Junghoon Jee List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0911527064==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 --===============0911527064== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SW4gbXkgY29tbWVudCwgSSB3b3VsZCBsaWtlIHRvIGNoYW5nZSB0aGUgcGhyYXNlLCAnbmV0d29y ayBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlJyB0byANCiduZXR3b3JrIGFjY2VzcyBzZXJ2aWNlJy4N Cg0KSnVuZ2hvb24NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206ICJKdW5n aG9vbiBKZWUiIDxqaGplZUBldHJpLnJlLmtyPg0KVG86IDxCYXNhdmFyYWouUGF0aWxAbm9raWEu Y29tPjsgPG1pcDZAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMTEsIDIwMDQg NDoyNiBQTQ0KU3ViamVjdDogUmU6IFtNaXA2XSBXR0xDOiBJLUQgZHJhZnQtaWV0Zi1taXA2LWJv b3RzdHJhcC1wcy0wMS50eHQNCg0KDQo+IFZlcnkgc29ycnkgZm9yIGxhdGUgcmV2aWV3Lg0KPiAN Cj4gQWZ0ZXIgaSByZXZpZXdlZCB0aGlzIEktRCwgaSBoYXZlIGdvdCBzb21lIHF1ZXN0aW9ucy4N Cj4gDQo+IFExLiBTaG91bGQgdGhlIG5ldHdvcmsgYWNjZXNzIHNlcnZpY2UgYmUgYWx3YXlzIHBl cmZvcm1lZCB3aGVuIGEgTU4gYm9vdHN0cmFwcyA/IA0KPiANCj4gU2VjdGlvbiA2LiAgTmV0d29y ayBBY2Nlc3MgYW5kIE1vYmlsaXR5IHNlcnZpY2VzDQo+IFtQYWdlIDE0XQ0KPiBPbmx5IGhhdmlu ZyBNb2JpbGUgSVB2NiBzZXJ2aWNlIGlzIG5vdCBwb3NzaWJsZSwgc2luY2UgdGhlIE1vYmlsZSBJ UHY2IHByb3RvY29sIHJlcXVpcmVzDQo+IGFiaWxpdHkgdG8gc2VuZCBhbmQgcmVjZWl2ZSBJUHY2 IHBhY2tldHMuICANCj4gPT4gSXQgc2VlbXMgdGhhdCBuZXR3b3JrIGF1dGhlbnRpY2F0aW9uIHNl cnZpY2Ugc2hvdWxkIGJlIGFsd2F5cyBwZXJmb3JtZWQuDQo+IA0KPiBTZWN0aW9uIDcuMSAgTW9i aWxpdHkgU2VydmljZSBTdWJzY3JpcHRpb24gU2NlbmFyaW8NCj4gPT4gVGhlcmUgaXMgbm8gd29y ZHMgYWJvdXQgbmV0d29yayBhdXRoZW50aWNhdGlvbiBzZXJ2aWNlLg0KPiANCj4gUTIuIERvZXMg d2UgaGF2ZSB0byBjb25zaWRlciB0aGUgY2FzZSBvZiAgaW5mcmFzdHJ1Y3R1cmUtbGVzcyBzY2Vu YXJpbyANCj4gd2hlbiB3ZSBkZXZlbG9wIGEgYm9vdHN0cmFwcGluZyBzb2x1dGlvbiBvciBub3Qg Pw0KPiANCj4gU2VjdGlvbiA3LjQgSW5mcmFzdHJ1Y3R1cmUtbGVzcyBzY2VuYXJpbw0KPiBbUGFn ZSAxN10NCj4gVGhpcyBzcGVjaWZpYyBzY2VuYXJpbyBpcyBub3Qgc3VwcG9ydGVkIGluIHRoaXMg ZG9jdW1lbnQuICBUaGUgcmVhc29uDQo+IGZvciB0aGlzIGlzIGRlc2NyaWJlZCBpbiBTZWN0aW9u IDkuDQo+IA0KPiBTZWN0aW9uIDkuIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQo+IFRodXMsIHRo ZSBjYXNlIG9mIGluZnJhc3RydWN0dXJlLWxlc3MgbmV0d29yayB3aGVyZSB0aGVyZSBpcyBhYnNv bHV0ZWx5IA0KPiBubyBwcmUtbWVkaWF0ZWQgdHJ1c3QgaXMga2VwdCBvdXRzaWRlIG9mIHNjb3Bl IG9mIHRoaXMgZG9jdW1lbnQuDQo+IA0KPiA9PiBJdCBzZWVtcyB0aGF0IHdlIGRvbid0IG5lZWQg dG8gY29uc2lkZXIgdGhlIGluZnJhc3RydWN0dXJlLWxlc3Mgc2NlbmFyaW8gDQo+ICAgICAgd2hl biB3ZSBjcmVhdGUgYSBib290c3RyYXBwaW5nIHNvbHV0aW9uLg0KPiANCj4gSnVuZ2hvb24NCj4g DQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+IEZyb206IDxCYXNhdmFyYWouUGF0 aWxAbm9raWEuY29tPg0KPiBUbzogPG1pcDZAaWV0Zi5vcmc+DQo+IFNlbnQ6IEZyaWRheSwgT2N0 b2JlciAxNSwgMjAwNCA0OjU0IFBNDQo+IFN1YmplY3Q6IFtNaXA2XSBXR0xDOiBJLUQgZHJhZnQt aWV0Zi1taXA2LWJvb3RzdHJhcC1wcy0wMS50eHQNCj4gDQo+IA0KPiANCj4gDQo+IEhlbGxvLA0K PiANCj4gVGhpcyBpcyBhIFdvcmtpbmcgR3JvdXAgbGFzdCBjYWxsIGZvciB0aGUgZm9sbG93aW5n IEktRDoNCj4gSS1EIDpkcmFmdC1pZXRmLW1pcDYtYm9vdHN0cmFwLXBzLTAxLnR4dA0KPiBUaXRs ZTogUHJvYmxlbSBTdGF0ZW1lbnQgZm9yIGJvb3RzdHJhcHBpbmcgTW9iaWxlIElQdjYNCj4gDQo+ IFRoZSBzdGF0dXMgYXNzb2NpYXRlZCB3aXRoIHRoaXMgSS1EIGlzIDogSW5mb3JtYXRpb25hbCBh bmQgd2lsbCBiZQ0KPiBwcm9ncmVzc2VkIGFzIHN1Y2guDQo+IA0KPiBQbGVhc2UgcmV2aWV3IGFu ZCBwb3N0IHlvdXIgY29tbWVudHMgYnkgT2N0b2JlciAzMHRoLCAyMDA0Lg0KPiANCj4gLUNoYWly cw0KPiANCj4gVVJMIHRvIEktRDoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJhcC1wcy0wMS50eHQNCj4gDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE1pcDYgbWFpbGluZyBsaXN0 DQo+IE1pcDZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbWlwNg0KPiANCj4gDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IE1pcDYgbWFpbGlu ZyBsaXN0DQo+IE1pcDZAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWlwNg0KPiA= --===============0911527064== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0911527064==-- From mip6-bounces@ietf.org Fri Nov 12 11:44:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18787 for ; Fri, 12 Nov 2004 11:44:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSeYR-0004PW-AS for mip6-web-archive@ietf.org; Fri, 12 Nov 2004 11:45:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSeNV-0001J9-Qg; Fri, 12 Nov 2004 11:34:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSeJy-0000Vo-Jg for mip6@megatron.ietf.org; Fri, 12 Nov 2004 11:30:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17916 for ; Fri, 12 Nov 2004 11:30:43 -0500 (EST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSeLN-00049L-5u for mip6@ietf.org; Fri, 12 Nov 2004 11:32:13 -0500 Received: from iraspam.ira.uni-karlsruhe.de ([141.3.10.6] helo=spamhost.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10) id 1CSeJu-000114-00; Fri, 12 Nov 2004 17:30:42 +0100 Received: from amavis by spamhost.ira.uka.de with scanned-ok (Exim 3.30 #3) id 1CSeJu-0000lq-00; Fri, 12 Nov 2004 17:30:42 +0100 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by spamhost.ira.uka.de with esmtp (Exim 3.30 #3) id 1CSeJZ-0000kE-00; Fri, 12 Nov 2004 17:30:21 +0100 Received: from [130.129.131.125] (helo=[130.129.131.125]) by iramx2.ira.uni-karlsruhe.de with asmtp (Exim 3.30 #10) id 1CSeJX-00010n-00; Fri, 12 Nov 2004 17:30:20 +0100 Message-ID: <4194E55C.6090903@tm.uka.de> Date: Fri, 12 Nov 2004 11:31:24 -0500 From: Christian Vogt User-Agent: Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: MIP6 Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id LAA17916 Cc: Francis Dupont Subject: [Mip6] Combining Pre-Configured KBMs w/ CoA Tests X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Hi MIP6 folks, even though Charlie cannot make it to today's MIP6 session, and there won't be a presentation of the latest version of the pre-configuration ID [1], I want to re-visit the possibility to combine pre-configuration with a CoA test. We had a thread on the MIP6 mailing list in March this year where some people, including me, argued that such a combination may be useful in scenarios where there is an opportunity to pre-configure MNs and CNs, but there still is no trust relationship btw. the MNs and CNs [2]. A 3G mobile operator is probably a good example for this. The idea back in March was to interpret the pre-configured key as a Home Keygen Token, and let the MN do the CoA test in order to gain a Care-of Address Token. The MN could then calculate a KBM just as in RFC 3775 [2]. Due to some changes Charlie meanwhile applied to the pre-configuration ID, this idea now requires slight revision. In the current ID, the MN is pre-configured with the Kcn, a home nonce, and a care-of nonce. Calculation of the KBM can so be achieved as defined in RFC 3775. Hence, in order to combine pre-configuration with a CoA test, one would simply have to omit pre-configuration of the care-of nonce. The MN would thus have to acuire the Care-of Keygen Token through a CoA test rather than calculating it from a pre-configured care-of nonce. (Note: One may prefer to use two Kcn's instead of a single one -- Kcn1 would be configured into the MN to calculate the Home Keygen Token, and Kcn2 would be used by the CN to come up with the Care-of Keygen Token during the CoA test. Of course, one could use the same Kcn in both the MN and the CN. But then it might be easier for a MN to spoof the Care-of Keygen Token.) The above proposal is IMO appealing because it re-uses the CoA-test technique from RFC 3775. - Christian [1] http://www.ietf.org/internet-drafts/draft-ietf-mip6-precfgkbm-01.txt [2] http://www1.ietf.org/mail-archive/web/mip6/current/msg00856.html, http://www1.ietf.org/mail-archive/web/mip6/current/msg00795.html --=20 Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/ "I love fools=92 experiments. I am always making them." (Charles Darwin) _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 15 20:55:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06686 for ; Mon, 15 Nov 2004 20:55:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTsbG-0008Nr-Cb for mip6-web-archive@ietf.org; Mon, 15 Nov 2004 20:57:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTsWh-0001yk-Jg; Mon, 15 Nov 2004 20:52:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTsWG-0001ta-Tf for mip6@megatron.ietf.org; Mon, 15 Nov 2004 20:52:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06474 for ; Mon, 15 Nov 2004 20:52:30 -0500 (EST) From: lmux801@cse.unsw.edu.au Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTsYJ-0008KZ-CM for mip6@ietf.org; Mon, 15 Nov 2004 20:54:43 -0500 Received: From webmail.cse.unsw.edu.au ([129.94.242.51] == albeniz.orchestra.cse.unsw.EDU.AU) (ident-user w3serv) By note With Smtp ; Tue, 16 Nov 2004 12:52:22 +1100 Received: from 129.94.208.239 (SquirrelMail authenticated user lmux801) by webmail.cse.unsw.edu.au with HTTP; Tue, 16 Nov 2004 12:52:21 +1100 (EST) To: mip6@ietf.org Date: Tue, 16 Nov 2004 12:52:21 +1100 (EST) Message-ID: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> Subject: [Mip6] New I-D: Security Issues in Dynamic Home Agent Address Discovery User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 2.0 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 8bit Cc: henrik.petander@hut.fi, mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 8bit Hello, ALL. Here is a new I-D, Security Issues in Dynamic Home Agent Address Discovery. Abstract: This document describes potential security issues relevant to the Dynamic Home Agent Address Discovery (DHAAD) procedure in Mobile IPv6. In particular, we illustrate a Denial of Service (DoS) attack scenario and propose three possible solutions to improve the security of DHAAD in MIPv6. URL to I-D: http://www.ietf.org/internet-drafts/draft-sun-mipv6-dhaadsecurity-00.txt Comments are welcome. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 16 09:16:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01478 for ; Tue, 16 Nov 2004 09:16:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4AY-0006OP-VP for mip6-web-archive@ietf.org; Tue, 16 Nov 2004 09:18:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU42Z-0000hb-F5; Tue, 16 Nov 2004 09:10:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU40q-0000Gb-4p for mip6@megatron.ietf.org; Tue, 16 Nov 2004 09:08:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00753 for ; Tue, 16 Nov 2004 09:08:51 -0500 (EST) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU433-0006EP-KB for mip6@ietf.org; Tue, 16 Nov 2004 09:11:09 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate.mot.com (Motorola/Motgate) with ESMTP id iAGE8gkO022749; Tue, 16 Nov 2004 07:08:43 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id iAGE8MDO022076; Tue, 16 Nov 2004 08:08:23 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A32F288CF71; Tue, 16 Nov 2004 15:08:39 +0100 (CET) Message-ID: <419A09E1.5040603@motorola.com> Date: Tue, 16 Nov 2004 15:08:33 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: lmux801@cse.unsw.edu.au Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent Address Discovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> In-Reply-To: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 1.1 (+) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: mip6@ietf.org, henrik.petander@hut.fi, mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1618808501==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1618808501== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4B371F912E2C9E3326EBB441" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4B371F912E2C9E3326EBB441 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit lmux801@cse.unsw.edu.au wrote: > Here is a new I-D, Security Issues in Dynamic Home Agent Address > Discovery. Thanks for this draft. It describes in detail a DoS attack on the MN, where the attacker denies the MN access to a HA, via fake DHAAD Replies; it mentions shortly the risk of disclosure of HA addresses to any remote party. It also proposes security solutions to this problem but I haven't read those parts. In addition to the HA-DoS threat, I think (let me know if I'm wrong) there are two others: (1) faking the HA List by attacker MN on home link and (2) attacks on the R-bit of a NEMO DHAAD Reply. For (1), DHAAD relies on building of a HA list by HAs on the home link, via the H-bit in their RAs. An attacker MN (one that is at home on the home link where the legitimate HAs are) can send fake HAs to pretend to be a HA, I think. Based on this fake RA, the legitimate HAs will build attacking HA lists, that contain the attacker MN as the highest priority HA (or pretending to support MRs while it doesn't). The end result of this attack is that MN uses the attacker HA as a HA. It is true that this attack is not exploiting the weaknesses of unprotected DHAAD Req/Rep, but building the HA list is an integral part of DHAAD operation, I think. For (2), NEMO Basic Support uses an R-bit in the DHAAD Req and Rep. The R-bit in the Req means MR is looking for an HA supporting MRs and an R-bit in the Rep means this HA does support MRs. An HA supporting MRs does support MHs too, so the only possible attack is a DoS on the "support MRs" part. In plain words, the risk is that MR requests an HA supporting MRs, gets fake reply back that has the R-bit 0, and thus all LFNs behind MR are denied HA service (but MR is not denied HA service). A similar threat analysis can be exercised on all fields in the DHAAD Req/Rep and on the HA Information Option within an RA (preference, lifetime). Whether this analysis is necessary or not - I don't know - but it usually gives exhaustive hints on what the solution would look like. Alex --------------enig4B371F912E2C9E3326EBB441 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBmgnnMmC0w56zj54RAqOaAJ0ZFIXkzogLDn9hcCNgutd4OnLuJwCgtU3q pKNJgiKVKrwyh6XPGuTqyjo= =UzeI -----END PGP SIGNATURE----- --------------enig4B371F912E2C9E3326EBB441-- --===============1618808501== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1618808501==-- From mip6-bounces@ietf.org Tue Nov 16 11:50:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18326 for ; Tue, 16 Nov 2004 11:50:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU6Ze-0001kw-SM for mip6-web-archive@ietf.org; Tue, 16 Nov 2004 11:53:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6UZ-0007TL-TX; Tue, 16 Nov 2004 11:47:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6Q1-0006ju-2Q for mip6@megatron.ietf.org; Tue, 16 Nov 2004 11:43:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17641 for ; Tue, 16 Nov 2004 11:42:59 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU6SE-0001aw-HA for mip6@ietf.org; Tue, 16 Nov 2004 11:45:20 -0500 Message-ID: <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" , References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery Date: Tue, 16 Nov 2004 08:43:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, henrik.petander@hut.fi, mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit The following seems problematic to me (Section 4.2): However, use of IPSec with IKE may introduce significant overhead on network transmission and host computation. To protect one message (i.e. DHAAD Reply), the home agent has to setup an IPSec Security Association (SA) with the mobile node. When using IPSec with Internet Key Exchange (IKE), IKE session involves at least six messages (three round trips) exchange to setup a SA between two nodes. It may also need a large number of computations. For small handheld devices, the use of IPSec may be too taxing on battery and processor performance [3]. Such overhead becomes particularly significant if this SA is used only once to protect DHAAD Reply message from the responding home agent and may not be used later for Binding Updates. A more serious problem of this mechanism is that it could introduce another kind of DoS attack. Home agent becomes vulnerable to DoS attacks, if it initiates IKE to protect DHAAD Reply with IPSec. An attacker could easily launch a DoS attack against all home agents on the home link by sending a large number of DHAAD Requests using different source addresses. Home agent(s) would create a new IKE session for each DHAAD Request, eventually running out of resources to serve valid mobile nodes. Note that there is no efficient mechanism to trace the attacker back to its real origin due to the DHAAD Requests are not authenticated. because: 1) I believe IKEv2 requires four messages, unless EAP is used, in which case it does require 6. 2) Both versions of IKE contain protection against DoS by requiring responder cookies and that the cookies be properly formulated. Naturally, this won't protect a flat out, no holds barred packet bombardment, but it does prevent a more subtle, state depletion attack. As a general point, with the exception of the MiTM DHAAD interception, how is a DoS attack on a known home agent address any different from an attack on any other server on the Internet, like, for example, cnn.com? jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 16 13:38:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28050 for ; Tue, 16 Nov 2004 13:38:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8G5-0004Qc-TH for mip6-web-archive@ietf.org; Tue, 16 Nov 2004 13:40:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU854-00037L-B4; Tue, 16 Nov 2004 13:29:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU7uM-0001LY-Bu for mip6@megatron.ietf.org; Tue, 16 Nov 2004 13:18:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26444 for ; Tue, 16 Nov 2004 13:18:24 -0500 (EST) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU7wY-000408-Nu for mip6@ietf.org; Tue, 16 Nov 2004 13:20:46 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id iAGILdYY002323; Tue, 16 Nov 2004 11:21:39 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id iAGI9vIM008088; Tue, 16 Nov 2004 12:09:58 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0216588CF71; Tue, 16 Nov 2004 19:18:01 +0100 (CET) Message-ID: <419A4458.1000009@motorola.com> Date: Tue, 16 Nov 2004 19:18:00 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> In-Reply-To: <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, henrik.petander@hut.fi, mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit James Kempf wrote: > As a general point, with the exception of the MiTM DHAAD > interception, how is a DoS attack on a known home agent address any > different from an attack on any other server on the Internet, like, > for example, cnn.com? Attacks are different in that attacking cnn.com is attacking a unique endpoint of many e2e edges, while attacking a Home Agent address is attacking the crux of many e2e edges. Enlarging the number of victims when attacking cnn.com can be achieved by getting closer to cnn.com, enlarging the number of victims when attacking MN can not by achieved by getting closer to HA (attacker does not need to, it already denies all victim CNs). Another comparison could be made with DHCP Discover (in my knowledge also insecure). Attacker DHCP Discovery may be avoided by simply moving to the other nearby DHCP "domain" once the attack is detected, while attacker DHAAD can not be avoided by moving to the next AR. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 16 15:04:38 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06229 for ; Tue, 16 Nov 2004 15:04:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9bQ-0006am-OA for mip6-web-archive@ietf.org; Tue, 16 Nov 2004 15:07:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9OO-0000dl-M1; Tue, 16 Nov 2004 14:53:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU9LF-0008Kf-8Q for mip6@megatron.ietf.org; Tue, 16 Nov 2004 14:50:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04966 for ; Tue, 16 Nov 2004 14:50:16 -0500 (EST) Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU9NV-0006Gx-TD for mip6@ietf.org; Tue, 16 Nov 2004 14:52:38 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 526B28983B; Tue, 16 Nov 2004 21:50:14 +0200 (EET) Message-ID: <419A5988.2010502@kolumbus.fi> Date: Tue, 16 Nov 2004 21:48:24 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> In-Reply-To: <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, henrik.petander@hut.fi, Alexandru Petrescu , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit > A more serious problem of this mechanism is that it could introduce > another kind of DoS attack. Home agent becomes vulnerable to DoS > attacks, if it initiates IKE to protect DHAAD Reply with IPSec. An I agree with James' observations about this paragraph. While I'm not a big fan of doing IKE everytime you send a packet somewhere, it seems that any cryptographic mechanism that protects DHAAD is bound to have some of the same DoS issues, and probably also some of the same solutions, such as cookie exchanges or rate limiting the processing of requests if you get too many of them. A meta-level issue with improvements to the DHAAD procedure is that there seems to be an interest in different kinds of provisioning schemes (including HA addresses) in the community, and I wonder how much effort we should put into improving DHAAD until we know what kind of provisioning is really going to be "the winner". --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 16 16:13:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14769 for ; Tue, 16 Nov 2004 16:13:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUAgV-0008IT-By for mip6-web-archive@ietf.org; Tue, 16 Nov 2004 16:16:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAZ7-0005Kv-TD; Tue, 16 Nov 2004 16:08:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUAVn-0003zO-Di for mip6@megatron.ietf.org; Tue, 16 Nov 2004 16:05:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13493 for ; Tue, 16 Nov 2004 16:05:13 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUAY1-00086P-DV for mip6@ietf.org; Tue, 16 Nov 2004 16:07:36 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAGL5k3B003499; Tue, 16 Nov 2004 14:05:46 -0700 (MST) Received: from [10.181.32.197] (mvp-10-181-32-197.ea.mot.com [10.181.32.197]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id iAGL2tMU011950; Tue, 16 Nov 2004 15:02:56 -0600 Message-ID: <419A6B4A.3030405@motorola.com> Date: Tue, 16 Nov 2004 22:04:10 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> <419A5988.2010502@kolumbus.fi> In-Reply-To: <419A5988.2010502@kolumbus.fi> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, James Kempf , henrik.petander@hut.fi, mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Excuse my interfering... Jari Arkko wrote: > somewhere, it seems that any cryptographic mechanism that protects > DHAAD is bound to have some of the same DoS issues, YEs, I agree, _some_. A secure DHAAD _will_ protect against the threat where MR is forced into being an MH (and thus denying service to LFNs behind it). If DHAAD were secure (even if not fully avoiding the HA DoS), this kind of MR DoS wouldn't happen. Also, if HAs on the same link send protected RAs then a certain number of attacks on DHAAD are eliminated (note: I don't know SEND). I think motivation for secure DHAAD should come from correctly formulating the threats of non-secure DHAAD and knowing what to expect from secure DHAAD. > and probably also some of the same solutions, such as cookie > exchanges or rate limiting the processing of requests if you get too > many of them. It is true that if a threat is formulated such as to say that because DHAAD is insecure then there is a HA DoS risk possible, then by this formulation it should mean that a secure DHAAD would eliminate entirely all the HA DoS risks. And this is barely feasible, as you mention. > A meta-level issue with improvements to the DHAAD procedure is that > there seems to be an interest in different kinds of provisioning > schemes (including HA addresses) in the community, and I wonder how > much effort we should put into improving DHAAD until we know what > kind of provisioning is really going to be "the winner". I am not aware of this proposal. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 16 17:51:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05224 for ; Tue, 16 Nov 2004 17:51:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUCCx-0005z9-VH for mip6-web-archive@ietf.org; Tue, 16 Nov 2004 17:53:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBwx-0005PJ-7A; Tue, 16 Nov 2004 17:37:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUBgs-0001un-HQ for mip6@megatron.ietf.org; Tue, 16 Nov 2004 17:20:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00235 for ; Tue, 16 Nov 2004 17:20:44 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUBj8-0004R3-SH for mip6@ietf.org; Tue, 16 Nov 2004 17:23:08 -0500 Message-ID: <01c301c4cc2a$a138e650$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" , "Jari Arkko" References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> <419A5988.2010502@kolumbus.fi> <419A6B4A.3030405@motorola.com> Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery Date: Tue, 16 Nov 2004 14:21:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, henrik.petander@hut.fi, mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit > > A meta-level issue with improvements to the DHAAD procedure is that > > there seems to be an interest in different kinds of provisioning > > schemes (including HA addresses) in the community, and I wonder how > > much effort we should put into improving DHAAD until we know what > > kind of provisioning is really going to be "the winner". > > I am not aware of this proposal. > Check: draft-giaretta-mip6-authorization-eap-02.txt draft-giaretta-mip6-aaa-ha-goals-00.txt draft-yegin-mip6-aaa-fwk-00.txt draft-jee-mip6-bootstrap-pana-00.txt draft-tschofenig-mip6-bootstrapping-pana-00.txt draft-ohba-mip6-boot-arch-dhcp-00 draft-deng-mip6-bootstrap-bcf-00.txt as well as: draft-ietf-mip6-bootstrap-ps-01.txt which explains the problem. In short, there are quite a few proposals for replacing DHAAD as part of the bootstrapping work. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 16 18:08:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07459 for ; Tue, 16 Nov 2004 18:08:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUCSv-0006bR-Sr for mip6-web-archive@ietf.org; Tue, 16 Nov 2004 18:10:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUCGh-0003eP-IZ; Tue, 16 Nov 2004 17:57:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUC5L-0000AI-I5 for mip6@megatron.ietf.org; Tue, 16 Nov 2004 17:46:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04612 for ; Tue, 16 Nov 2004 17:46:01 -0500 (EST) Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUC7c-0005oX-Ba for mip6@ietf.org; Tue, 16 Nov 2004 17:48:25 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id iAGMjlpH025847; Tue, 16 Nov 2004 15:45:47 -0700 (MST) Received: from [10.181.32.228] (mvp-10-181-32-228.ea.mot.com [10.181.32.228]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id iAGMh5i7024864; Tue, 16 Nov 2004 16:43:06 -0600 Message-ID: <419A8315.1030509@motorola.com> Date: Tue, 16 Nov 2004 23:45:41 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> <419A5988.2010502@kolumbus.fi> <419A6B4A.3030405@motorola.com> <01c301c4cc2a$a138e650$0f6115ac@dcml.docomolabsusa.com> In-Reply-To: <01c301c4cc2a$a138e650$0f6115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Jari Arkko , henrik.petander@hut.fi, mahbub@cse.unsw.edu.au, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit James Kempf wrote: >>>A meta-level issue with improvements to the DHAAD procedure is that >>>there seems to be an interest in different kinds of provisioning >>>schemes (including HA addresses) in the community, and I wonder how >>>much effort we should put into improving DHAAD until we know what >>>kind of provisioning is really going to be "the winner". >> >>I am not aware of this proposal. >> > > > Check: > > draft-giaretta-mip6-authorization-eap-02.txt > draft-giaretta-mip6-aaa-ha-goals-00.txt > draft-yegin-mip6-aaa-fwk-00.txt > draft-jee-mip6-bootstrap-pana-00.txt > draft-tschofenig-mip6-bootstrapping-pana-00.txt > draft-ohba-mip6-boot-arch-dhcp-00 > draft-deng-mip6-bootstrap-bcf-00.txt > > as well as: > > draft-ietf-mip6-bootstrap-ps-01.txt > > which explains the problem. > > In short, there are quite a few proposals for replacing DHAAD as part of the > bootstrapping work. Sorry to sound ignorant... The bootstrapping seemed to be an easy task, at least from an implementation perspective: discover your HA - DHAAD, get your prefix - MPD, configure a HoA, send a BU; that could have been all there was to it. The keys? Preconfigured. Ok, I'll have to get up to speed with the proposals, thanks. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 17 01:27:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16481 for ; Wed, 17 Nov 2004 01:27:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUJKL-00089B-GB for mip6-web-archive@ietf.org; Wed, 17 Nov 2004 01:30:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUJBn-0004Yh-MC; Wed, 17 Nov 2004 01:21:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUJB6-0004PX-Hs for mip6@megatron.ietf.org; Wed, 17 Nov 2004 01:20:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16123 for ; Wed, 17 Nov 2004 01:20:27 -0500 (EST) Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUJDS-00083E-LW for mip6@ietf.org; Wed, 17 Nov 2004 01:22:55 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 7370889877; Wed, 17 Nov 2004 08:20:25 +0200 (EET) Message-ID: <419AED3B.80907@kolumbus.fi> Date: Wed, 17 Nov 2004 08:18:35 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> <419A5988.2010502@kolumbus.fi> <419A6B4A.3030405@motorola.com> <01c301c4cc2a$a138e650$0f6115ac@dcml.docomolabsusa.com> <419A8315.1030509@motorola.com> In-Reply-To: <419A8315.1030509@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > The bootstrapping seemed to be an easy task, at least from an :-) > implementation perspective: discover your HA - DHAAD, get your prefix - > MPD, configure a HoA, send a BU; that could have been all there was to > it. The keys? Preconfigured. I think the "keys" part is the hard issue, people want to get away from having to have those preconfigured. But as a result it may also imply a different approach to discover the HA addresses, too. Or maybe not, but we don't know yet. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 17 10:45:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10395 for ; Wed, 17 Nov 2004 10:45:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUS2M-0003z4-B3 for mip6-web-archive@ietf.org; Wed, 17 Nov 2004 10:48:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CURnw-00043K-0u; Wed, 17 Nov 2004 10:33:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CURkQ-0002zH-VB for mip6@megatron.ietf.org; Wed, 17 Nov 2004 10:29:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08446 for ; Wed, 17 Nov 2004 10:29:28 -0500 (EST) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CURmr-0003Wi-SU for mip6@ietf.org; Wed, 17 Nov 2004 10:32:02 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id F096B8000B4; Wed, 17 Nov 2004 17:28:57 +0200 (EET) Date: Wed, 17 Nov 2004 17:28:57 +0200 (EET) From: Wassim Haddad To: mip6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: multi6@ops.ietf.org Subject: [Mip6] MoMiPriv Mailing List Announcement X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi all, A new mailing list dedicated to Privacy for mobility and multi-homing (MoMiPriv) discussions has been set up. To subscribe, please visit: http://lacnic.net/mailman/listinfo/momipriv Many Thanks to Marcelo for his help. Regards, Wassim H. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 08:38:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24329 for ; Thu, 18 Nov 2004 08:38:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUmX9-0001Nf-GP for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 08:41:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUmEy-0006ZO-4R; Thu, 18 Nov 2004 08:22:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU5lQ-0000Y1-My for mip6@megatron.ietf.org; Tue, 16 Nov 2004 11:01:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12884 for ; Tue, 16 Nov 2004 11:01:01 -0500 (EST) Received: from mail.dti.supsi.ch ([193.5.153.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU5nd-0000S3-73 for mip6@ietf.org; Tue, 16 Nov 2004 11:03:22 -0500 Received: from supsi.ch (pcm3134.dti.supsi.ch [193.5.153.134]) by mail.dti.supsi.ch (8.11.6/8.11.6) with ESMTP id iAGG0PK04868 for ; Tue, 16 Nov 2004 17:00:25 +0100 Message-ID: <419A2419.70009@supsi.ch> Date: Tue, 16 Nov 2004 17:00:25 +0100 From: Alessandro Puiatti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 18 Nov 2004 08:22:21 -0500 Subject: [Mip6] 1st IEEE WoWMoM Workshop on Autonomic Communications and Computing - Call for Papers X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit We apologize in advance if you receive multiple copies of this CFP. ---------------------------------------------------------------------- Call for Papers ACC 2005 1st IEEE WoWMoM Workshop on Autonomic Communications and Computing June 18, 2005 - Taormina, Italy in conjunction with IEEE WoWMoM 2005 http://www.autonomic-communication.org/acc/index.html Sponsored by IEEE WoWMoM Ubiquitous and self-organized Internet, ad hoc networks, wireless sensor networks are expected to be some of the basic building blocks of pervasive computing environments. However, the promise of pervasive computing environments will not be realized unless these systems can effectively "disappear". In order to do that they need to become autonomous by managing their own evolution and configuration changes without explicit user or administrator action. The goal of this workshop is to provide a forum to exchange ideas, discuss solutions, and share experiences among researchers, professionals, and application developers both from industry and academia. Original papers addressing both theoretical and practical aspects of autonomic communications and computing are solicited. Papers describing prototype implementations and deployment are particularly welcome. Topics of interest include but are not limited to: - Architecture and models for autonomic communication and computing systems - Tools and techniques for designing, analyzing and building autonomic systems and networks - Adaptive security for self protection of systems and networks - Economic, biological and social models used for autonomic communications - Novel management techniques for autonomic communication and computing systems - Sensing, monitoring and measurements for self-managing systems and networks - Languages, development and securely programmable environments for autonomic communications systems - Advanced technologies for enabling autonomic communication and computing systems - Autonomic communication and computing testbeds and measurements SUBMISSION INSTRUCTIONS Papers should contain original material and not be previously published, or currently submitted for consideration elsewhere. Manuscripts must be limited to 5 pages in IEEE 8.5x11 conference format, and formatted in strict accordance with the IEEE Computer Society author guidelines. All submissions will be handled electronically. Authors should prepare a PDF file and submit it to acc2005@autonomic-communication.org. Accepted papers will be published by the IEEE Computer Society Press in the combined WoWMoM 2005 workshop proceedings. IMPORTANT DATES: Papers due -------------------------- Dec. 20, 2004 Notification of acceptance ------------ Jan. 31, 2005 Camera-ready papers due --------------- Feb. 28, 2005 For more information, please contact the workshop co-organizers: Raouf Boutaba, Silvia Giordano and Michael Smirnov, or consult the workshop webpage. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 08:39:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24435 for ; Thu, 18 Nov 2004 08:39:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUmYS-0001PV-Bs for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 08:42:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUmEy-0006ZT-H0; Thu, 18 Nov 2004 08:22:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU6YW-00083G-PU; Tue, 16 Nov 2004 11:51:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18456; Tue, 16 Nov 2004 11:51:45 -0500 (EST) Received: from mx1.iit.cnr.it ([146.48.98.40] helo=mx.iit.cnr.it) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU6ah-0001lj-TA; Tue, 16 Nov 2004 11:54:07 -0500 Received: from localhost (mx.iit.cnr.it [127.0.0.1]) by mx.iit.cnr.it (Postfix) with ESMTP id 4CF902EF49; Tue, 16 Nov 2004 17:50:51 +0100 (CET) Received: from mx.iit.cnr.it ([127.0.0.1]) by localhost (mx.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03200-17; Tue, 16 Nov 2004 17:50:36 +0100 (CET) Received: from delmastro1 (delmastrof.iit.cnr.it [146.48.98.74]) by mx.iit.cnr.it (Postfix) with ESMTP id 995662EEE5; Tue, 16 Nov 2004 17:50:33 +0100 (CET) Message-ID: <027101c4cbfc$692d7380$4a623092@delmastro1> From: "Franca Delmastro" To: "Franca Delmastro" Date: Tue, 16 Nov 2004 17:50:40 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by Content Checker at iit.cnr.it X-Spam-Score: 0.7 (/) X-Scan-Signature: 4863a9796402a44fdb52482f353618fe X-Mailman-Approved-At: Thu, 18 Nov 2004 08:22:21 -0500 Subject: [Mip6] [WoWMoM 2005] Last Cfp: Submission Deadline November 20 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2023899268==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: 398dc098b38497efe55f044562a219e7 This is a multi-part message in MIME format. --===============2023899268== Content-Type: multipart/alternative; boundary="----=_NextPart_000_026E_01C4CC04.C9B98290" This is a multi-part message in MIME format. ------=_NextPart_000_026E_01C4CC04.C9B98290 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= We apologize in advance if you receive multiple copies of this CFP. ************************************************************* CALL FOR PAPERS WoWMoM 2005 IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks http://cnd.iit.cnr.it/wowmom2005 Taormina, Italy, June 13-16, 2005 Sponsored by The IEEE Computer Society The University of Texas at Arlington Technical sponsored by IEEE TCCC **** Submission Deadline --- November 10, 2004 **** Extended to November 20, 2004 ************************************************************** Technology evolution is driving toward a world of wireless, mobile, and multimedia pervasive communications where users can seamlessly and ubiquitously accomplish their tasks, access information or communicate with other users all the anytime, everywhere, and from any device. Technologies include, among others, IEEE 802.11, 802.15, 802.16, Mobile IP, micro-mobility protocols, IP paging, wireless IP QOS, mobile ad hoc and sensor networks, and cellular networks. In addition to these, new and emerging technologies (e.g., UWB) need to be taken into account. The resulting networking environment will constitute the fourth generation wireless networks. 4G will integrate different types of wireless networks with wire-line backbone network seamlessly, and provide the convergence of voice, multimedia and data traffic over a single IP based core network. WoWMoM 2005 technical program committee is soliciting papers addressing the research challenges toward a world of wireless, mobile, and multimedia pervasive communications. Two types of contributions will be accepted: FULL PAPERS: Full Papers must present original, previously unpublished, complete works, validated by experimentation, simulation, or analysis. Practical experiences and experimental efforts are welcome. POSITION PAPERS: Papers in this category must be visionary, innovative and forward-looking. They must offer new perspectives opening future research directions, rather than by presenting mature work with quantitative results. Only a limited number of slots will be available for position papers that will be reviewed primarily for relevance and originality. Topics of interest for WOWMOM 2005 include, but are not limited to: - System prototypes and experiences - Software technologies and systems - QoS for real-time voice and video in wireless networks - Interactive broadband television, gaming, and video distribution - Middleware support for QoS provision - Caching and content management in WLANs and WMANs - Differentiated service in wireless multimedia networks - IP-based multimedia services over wireless networks - Networking services for ambient intelligent and pervasive environments - Multicasting and broadcasting problems and solutions - Handoff and mobility management - Seamless internetworking - IP-based mobile networks - Location mechanism and services - Wireless BAN, PAN, LAN, and MAN - Ad hoc and sensor networks - Vehicular wireless networks - Access technologies - Third and fourth generation systems - Energy-efficient protocols and power management - Wireless security and authentication - Pricing and billing - Modeling and Performance evaluation PAPER SUBMISSION AND PUBLICATION =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Papers should neither have been published elsewhere nor currently under review by another conference or journal. Guidelines on paper submission and formatting will be provided on the website. Accepted papers will appear in the symposium proceedings published by IEEE. IMPORTANT DATES =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Full papers due: November 10, 2004 Extended to: November 20, 2004 Notification: January 20, 2005 Camera Ready due: February 15, 2005 ORGANIZING COMMITTEE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D GENERAL Co-Chairs: Giuseppe Anastasi, University of Pisa, Italy Sajal K. Das, The University of Texas at Arlington, USA PROGRAM Co-Chairs: Marco Conti, IIT-CNR, Italy Dipankar Raychaudhuri WINLAB/Rutgers University, USA FINANCE & REGISTRATION Chair: Yonghe Liu, The University of Texas at Arlington, USA PUBLICITY Co-Chairs: Mainak Chatterjee, Univ. Central Florida, USA Sunghyun Choi, Seoul National University, Korea Franca Delmastro, IIT-CNR, Italy PUBLICATION Co-Chairs: Eleonora Borgia, IIT-CNR, Italy Luciana Pelusi, IIT-CNR, Italy SPONSORSHIP Chair Alessandro Genco, University of Palermo, Italy LOCAL ARRANGEMENTS Chair: Antonio Puliafito, University of Messina, Italy WEB DESIGNER & MANAGER: Patrizia Andronico, IIT-CNR, Italy STEERING COMMITTEE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Marco Conti, IIT-CNR, Italy Sajal K. Das, The University of Texas at Arlington, USA (chair) Dipankar Raychaudhuri WINLAB/Rutgers University, USA Satish K. Tripathi, SUNY Buffalo, USA PROGRAM COMMITTEE =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Arup Acharya, IBM T.J. Watson Research, USA Dharma P. Agrawal, University of Cincinnati, USA Kevin C. Almeroth, University of California at Santa Barbara, USA Christian Becker, University of Stuttgart, Germany Giuseppe Bianchi, University of Rome "Tor Vergata", Italy Chris Blondia, University of Antwerp, Belgium Azzedine Boukerche, University of Ottawa, Canada Jiannong Cao, Hong Kong Polytechnic University, Hong Kong Chua Kee Chaing, National University of Singapore, Republic of Singapore Rajarathnam Chandramouili, Stevens Institute of Technology, USA Mainak Chatterjee, University of Central Florida, USA Carla-Fabiana Chiasserini, Polytechnic of Turin, Italy A. Chockalingam, Indian Institute of Science, Banglore, India Sunghyun Choi, Seoul National University, Korea Antonio Corradi, University of Bologna, Italy Antony Ephremides, University of Maryland, USA Gabor Fodor, Ericsson, Sweden Luigi Fratta, Polytechnic of Milan, Italy Marco Gruteser, Rutgers University, USA Paul J.M. Havinga, University of Twente, The Netherlands Kazuo Imai, NTT DoCoMo, Japan Holger Karl, Universtit=E4t Paderborn, Germany Anurag Kumar, Indian Inst of Science, Bangalore, India Mohan Kumar, The University of Texas at Arlington, USA P. R. Kumar, University of Illinois, USA Masahiro Kuroda, National Institute of Info. and Com. Tech., Japan Luciano Lenzini, University of Pisa, Italy K. Ben Letaief, Hong Kong Univ. Science & Technology, Hong Kong Victor Leung, The University of British Columbia, Canada Yonghe Liu, Univ. Texas at Arlington, USA Giri Mandyam, Nokia Research Center, USA Martin Mauve, University of Dusseldorf, Germany Archan Misra, IBM T.J. Watson Research, USA Refik Molva, Institut Eurecom, France Giacomo Morabito, University of Catania, Italy Hiroyuki Morikawa, , University of Tokyo, Japan Stephan Olariu, Old Dominion University, USA Maximilian Ott, Semandex Networks, USA Michael Paterakis, Technical University of Crete, Greece George C. Polyzos, Athens University of Economics and Business, Greece Antonio Puliafito, University of Messina, Italy Jochen H. Schiller, Freie Universit=E4t Berlin, Germany Henning Schulzrinne, Columbia University, USA Rajeev Shorey, IBM India Research Lab, India Ivan Stojmenovic, University of Ottawa, Canada Violet R. Syrotiuk, Arizona State University, USA Wade Trappe, Rutgers University, USA Ooi Wei Tsang, National University of Singapore, Singapore Christian Tschudin, Basel University, Switzerland Thierry Turletti, INRIA France Andras Valko, Ericsson, Hungary Bernard Walke, Aachen University of Technology, Germany Xingwei Wang, Northeastern Univ, China Jie Wu, Florida Atlantic University, USA Gergely Zaruba, The University of Texas at Arlington, USA Roger Zimmerman, University of Southern California, USA ************************************************************ Franca Delmastro Pervasive Computing & Networking Lab. (PerLab) IIT- National Research Council via G. Moruzzi,1 56124 Pisa, Italy ******************************************************** ------=_NextPart_000_026E_01C4CC04.C9B98290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----------------------------------------------------------------= ---------

We apologize in advance if you = receive multiple=20 copies of this=20 CFP.
*************************************************************

          &nbs= p;         &nbs= p;  =20 CALL FOR PAPERS

          &nbs= p;         &nbs= p;    =20 WoWMoM 2005
         IEEE=20 International Symposium on a World of=20 Wireless,
          =        =20 Mobile and Multimedia=20 Networks

         &nb= sp;      =20 http://cnd.iit.cnr.it/wowmom2005
      &= nbsp;        =20 Taormina, Italy, June 13-16,=20 2005

          &= nbsp;         &= nbsp;    =20 Sponsored=20 by
           <= SPAN>       =20 The IEEE Computer=20 Society
          &n= bsp; =20 The University of Texas at=20 Arlington
          =    =20 Technical sponsored by IEEE=20 TCCC

        **** Submission = Deadline=20 --- November 10, 2004 ****
          &nbs= p;            = ; =20  Extended to November 20,=20 2004
**********************************************************= ****


Technology=20 evolution is driving toward a world of wireless,
mobile, and = multimedia=20 pervasive communications where users can
seamlessly and ubiquitously=20 accomplish their tasks, access information
or communicate with other = users=20 all the anytime, everywhere, and from
any device. Technologies = include, among=20 others, IEEE 802.11,
802.15, 802.16, Mobile IP, micro-mobility = protocols, IP=20 paging,
wireless IP QOS, mobile ad hoc and sensor networks, and=20 cellular
networks.
In addition to these, new and emerging = technologies=20 (e.g., UWB) need to
be taken into account.  The resulting = networking=20 environment will
constitute the fourth generation wireless networks. = 4G will=20 integrate
different types of wireless networks with wire-line = backbone=20 network
seamlessly, and provide the convergence of voice, multimedia=20 and
data traffic over a single IP based core network.  WoWMoM = 2005=20 technical
program committee is soliciting papers addressing the=20 research
challenges
toward a world of wireless, mobile, and = multimedia=20 pervasive
communications.
Two types of contributions will be=20 accepted:

FULL PAPERS: Full Papers must present original, = previously=20 unpublished,
complete works, validated by experimentation, = simulation, or=20 analysis.
Practical experiences and experimental efforts are=20 welcome.

POSITION PAPERS: Papers in this category must be = visionary,=20 innovative
and forward-looking. They must offer new perspectives = opening=20 future
research directions, rather than by presenting mature work=20 with
quantitative results. Only a limited number of slots will be=20 available
for
position papers that will be reviewed primarily for=20 relevance and
originality.

Topics of interest for WOWMOM 2005 = include,=20 but are not limited to:
- System prototypes and experiences
- = Software=20 technologies and systems
- QoS for real-time voice and video in = wireless=20 networks
- Interactive broadband television, gaming, and video=20 distribution
- Middleware support for QoS provision
- Caching and = content=20 management in WLANs and WMANs
- Differentiated service in wireless = multimedia=20 networks
- IP-based multimedia services over wireless networks
-=20 Networking services for ambient intelligent and pervasive = environments
-=20 Multicasting and broadcasting problems and solutions
- Handoff and = mobility=20 management
- Seamless internetworking
- IP-based mobile=20 networks
- Location mechanism and = services
- Wireless=20 BAN, PAN, LAN, and MAN
- Ad hoc and sensor networks
- Vehicular = wireless=20 networks
- Access technologies
- Third and fourth generation = systems
-=20 Energy-efficient protocols and power management
- Wireless security = and=20 authentication
- Pricing and billing
- Modeling and Performance=20 evaluation

PAPER SUBMISSION AND=20 PUBLICATION
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Papers should neither have been = published=20 elsewhere nor currently
under review by another conference or = journal. =20 Guidelines on paper
submission and formatting will be = provided on=20 the website.
Accepted papers will appear in the symposium proceedings = published by
IEEE.


IMPORTANT = DATES
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Full=20 papers due:        November 10,=20 2004
Extended to:     = November 20,=20 2004
Notification:        &nb= sp; =20 January 20, 2005
Camera Ready = due:      =20 February 15, 2005


ORGANIZING COMMITTEE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
GENERAL=20 Co-Chairs:
        Giuseppe = Anastasi,=20 University of Pisa, Italy
        = Sajal K.=20 Das, The University of Texas at Arlington, USA

PROGRAM=20 Co-Chairs:
        Marco Conti, = IIT-CNR,=20 Italy
        Dipankar = Raychaudhuri=20 WINLAB/Rutgers University, USA


FINANCE & REGISTRATION=20 Chair:
         Yonghe Liu, = The=20 University of Texas at Arlington, USA
PUBLICITY=20 Co-Chairs:
         Mainak=20 Chatterjee, Univ. Central Florida,=20 USA
         Sunghyun Choi, = Seoul=20 National University, Korea
        =20 Franca Delmastro, IIT-CNR, Italy


PUBLICATION Co-Chairs:
        =20 Eleonora Borgia, IIT-CNR, Italy
        =20 Luciana Pelusi, IIT-CNR, Italy


SPONSORSHIP Chair
        Alessandro = Genco,=20 University of Palermo, Italy


LOCAL ARRANGEMENTS=20 Chair:
        Antonio Puliafito,=20 University of Messina, Italy


WEB DESIGNER &=20 MANAGER:
        Patrizia = Andronico,=20 IIT-CNR, Italy



STEERING=20 COMMITTEE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ma= rco Conti, IIT-CNR, Italy
Sajal K. Das,=20 The University of Texas at Arlington, USA (chair)
Dipankar = Raychaudhuri=20 WINLAB/Rutgers University, USA
Satish K. Tripathi, SUNY Buffalo,=20 USA


PROGRAM = COMMITTEE
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Arup = Acharya, IBM T.J.=20 Watson Research, USA
Dharma P. Agrawal, University of Cincinnati,=20 USA
Kevin C. Almeroth, University of California at Santa Barbara,=20 USA
Christian Becker, University of Stuttgart, Germany
Giuseppe = Bianchi,=20 University of Rome "Tor Vergata", Italy
Chris Blondia, University of = Antwerp,=20 Belgium
Azzedine  Boukerche, University of Ottawa, = Canada
Jiannong=20 Cao, Hong Kong Polytechnic University, Hong Kong
Chua Kee Chaing, = National=20 University of Singapore, Republic of Singapore
Rajarathnam = Chandramouili,=20 Stevens Institute of Technology, USA
Mainak Chatterjee, University of = Central=20 Florida, USA
Carla-Fabiana Chiasserini, Polytechnic of Turin, = Italy
A.=20 Chockalingam, Indian Institute of Science, Banglore, India
Sunghyun = Choi,=20 Seoul National University, Korea
Antonio Corradi, University of = Bologna,=20 Italy
Antony Ephremides, University of Maryland, USA
Gabor Fodor,=20 Ericsson, Sweden
Luigi Fratta, Polytechnic of Milan, Italy
Marco = Gruteser,=20 Rutgers University, USA
Paul J.M. Havinga, University of Twente, The=20 Netherlands
Kazuo Imai, NTT DoCoMo, Japan
Holger Karl, Universtit=E4t = Paderborn,=20 Germany
Anurag Kumar, Indian Inst of = Science, Bangalore,=20 India
Mohan Kumar, The University of Texas at Arlington, USA
P. R. = Kumar,=20 University of Illinois, USA
Masahiro Kuroda, National Institute of = Info. and=20 Com. Tech., Japan
Luciano Lenzini, University of Pisa, Italy
K. = Ben=20 Letaief, Hong Kong Univ. Science & Technology, Hong Kong
Victor = Leung,=20 The University of British Columbia, Canada
Yonghe Liu, Univ. Texas at = Arlington,=20 USA
Giri Mandyam, Nokia Research Center, = USA
Martin Mauve, University of Dusseldorf, Germany
Archan Misra, = IBM T.J.=20 Watson Research, USA
Refik Molva, Institut Eurecom, France
Giacomo = Morabito, University of Catania, Italy
Hiroyuki Morikawa, , = University of=20 Tokyo, Japan
Stephan Olariu, Old Dominion University, = USA
Maximilian Ott,=20 Semandex Networks, USA
Michael Paterakis, Technical University of = Crete,=20 Greece
George C. Polyzos, Athens University of Economics and = Business,=20 Greece
Antonio Puliafito, University of Messina, Italy
Jochen H. = Schiller,=20 Freie Universit=E4t Berlin, Germany
Henning Schulzrinne, Columbia = University,=20 USA
Rajeev Shorey, IBM India Research Lab, India
Ivan Stojmenovic, = University of Ottawa, Canada
Violet R. Syrotiuk, Arizona State = University,=20 USA
Wade Trappe, Rutgers University, USA
Ooi Wei Tsang, National=20 University of Singapore, Singapore
Christian Tschudin, Basel = University,=20 Switzerland
Thierry Turletti, INRIA France
Andras Valko, Ericsson, = Hungary
Bernard Walke, Aachen University of Technology, = Germany
Xingwei=20 Wang, Northeastern Univ, China
Jie Wu, Florida Atlantic University,=20 USA
Gergely Zaruba, The University of = Texas at=20 Arlington, USA
Roger Zimmerman, University of = Southern=20 California, USA
 
************************************************************
= Franca=20 Delmastro
Pervasive Computing & Networking Lab. = (PerLab)
 
IIT- National Research = Council
via G.=20 Moruzzi,1
56124 Pisa,=20 Italy
********************************************************<= /DIV> ------=_NextPart_000_026E_01C4CC04.C9B98290-- --===============2023899268== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2023899268==-- From mip6-bounces@ietf.org Thu Nov 18 08:40:35 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24508 for ; Thu, 18 Nov 2004 08:40:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUmZE-0001QX-4G for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 08:43:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUmEy-0006ZY-U3; Thu, 18 Nov 2004 08:22:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUh0D-0000M6-4l for mip6@megatron.ietf.org; Thu, 18 Nov 2004 02:46:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26001 for ; Thu, 18 Nov 2004 02:46:46 -0500 (EST) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUh2i-0002RT-7d for mip6@ietf.org; Thu, 18 Nov 2004 02:49:28 -0500 Received: from [127.0.0.1] (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id DBADF8001DD; Thu, 18 Nov 2004 09:46:08 +0200 (EET) Message-ID: <419C533E.7010702@rhea.tcs.hut.fi> Date: Thu, 18 Nov 2004 18:46:06 +1100 From: Henrik Petander User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> In-Reply-To: <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 18 Nov 2004 08:22:21 -0500 Cc: mip6@ietf.org, Alexandru Petrescu , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Hi Jak, Thanks for your comments on the draft. My replies are inline. James Kempf wrote: > The following seems problematic to me (Section 4.2): > > However, use of IPSec with IKE may introduce significant overhead on > network transmission and host computation. To protect one message > (i.e. DHAAD Reply), the home agent has to setup an IPSec Security > Association (SA) with the mobile node. When using IPSec with Internet > Key Exchange (IKE), IKE session involves at least six messages (three > round trips) exchange to setup a SA between two nodes. It may also > need a large number of computations. For small handheld devices, the > use of IPSec may be too taxing on battery and processor performance > [3]. Such overhead becomes particularly significant if this SA is > used only once to protect DHAAD Reply message from the responding > home agent and may not be used later for Binding Updates. > > A more serious problem of this mechanism is that it could introduce > another kind of DoS attack. Home agent becomes vulnerable to DoS > attacks, if it initiates IKE to protect DHAAD Reply with IPSec. An > attacker could easily launch a DoS attack against all home agents on > the home link by sending a large number of DHAAD Requests using > different source addresses. Home agent(s) would create a new IKE > session for each DHAAD Request, eventually running out of resources > to serve valid mobile nodes. Note that there is no efficient > mechanism to trace the attacker back to its real origin due to the > DHAAD Requests are not authenticated. > > because: > > 1) I believe IKEv2 requires four messages, unless EAP is used, in which case > it does require 6. Yes, you are correct about IKEv2. Still its use has a certain overhead, which may be considered large, if the IPSec SA is only used for protecting the DHAAD protocol at one CoA. Although this overhead may not happen very often, we thought that it was still relevant enough to be mentioned. IMO the second paragraph is a sufficient reason to not use IKE initiated by HA for creating IPSec SAs for protcting DHAAD reply. > 2) Both versions of IKE contain protection against DoS by requiring > responder cookies and that the cookies be properly formulated. Naturally, > this won't protect a flat out, no holds barred packet bombardment, but it > does prevent a more subtle, state depletion attack. The cookies protect the responder in IKE, who does not create state without the correct cookies. I am not an expert on the inner workings of IKE, but the initiator surely creates state to handle resending, in case it does not get a reply from the responder, or am I mistaken? > > As a general point, with the exception of the MiTM DHAAD interception, how > is a DoS attack on a known home agent address any different from an attack > on any other server on the Internet, like, for example, cnn.com? Normally AFAIK, if IPSec with IKE is used to protect a protocol, IKE is initiated by the initiator of the protocol to be protected. If IPSec was used to protect only the unicast DHAAD reply, HA would be the initiator of IKE and would create a new IKE session for each incoming DHAAD request. Then a malicious attacker could send masses of DHAAD requests with different source addresses, thus triggering new IKE sessions in HA until some limit would be reached after which HA could not serve valid MNs (at least with IKE). Does this clarify our point of the DoS attack against HA? Thanks, Henrik > > jak > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 08:41:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24581 for ; Thu, 18 Nov 2004 08:41:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUmZx-0001Rh-OP for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 08:44:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUmEz-0006Zd-9i; Thu, 18 Nov 2004 08:22:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUhHq-0005JT-OL for mip6@megatron.ietf.org; Thu, 18 Nov 2004 03:05:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28069 for ; Thu, 18 Nov 2004 03:05:00 -0500 (EST) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUhKQ-0002vb-A7 for mip6@ietf.org; Thu, 18 Nov 2004 03:07:42 -0500 Received: from [127.0.0.1] (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 8085C8000B4; Thu, 18 Nov 2004 10:04:28 +0200 (EET) Message-ID: <419C5789.7040102@hut.fi> Date: Thu, 18 Nov 2004 19:04:25 +1100 From: Henrik Petander User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent Address Discovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> In-Reply-To: <419A09E1.5040603@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 18 Nov 2004 08:22:21 -0500 Cc: mip6@ietf.org, mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Hi Alex, Thanks for reading the security analysis of DHAAD part of the draft and commenting it. Alexandru Petrescu wrote: > lmux801@cse.unsw.edu.au wrote: > >> Here is a new I-D, Security Issues in Dynamic Home Agent Address >> Discovery. > > > In addition to the HA-DoS threat, I think (let me know if I'm wrong) > there are two others: (1) faking the HA List by attacker MN on home link > and (2) attacks on the R-bit of a NEMO DHAAD Reply. > > For (1), DHAAD relies on building of a HA list by HAs on the home link, > via the H-bit in their RAs. An attacker MN (one that is at home on the > home link where the legitimate HAs are) can send fake HAs to pretend to > be a HA, I think. Based on this fake RA, the legitimate HAs will build > attacking HA lists, that contain the attacker MN as the highest priority > HA (or pretending to support MRs while it doesn't). The end result of > this attack is that MN uses the attacker HA as a HA. Yes, if home link is also an access network, then this is a very relevant vulnerability, since an attacker only needs to be able to send packets on the home link. We focused on the MN-HA part of the protocol, but this could be added to the draft, since building of HA list can also be seen to be a part of the DHAAD protocol. Alex, would you be interested in adding a subsection to the protocol vulnerabilities part about this? If SEND is used on the home link then this vulnerability can be fixed, provided that the HAs only add HAs to their list RAs which are authenticated as coming from authorized routers. I am not sure about the relevance of the R-bit attack, but it could possibly be used to attack MR more subtly han sending just an empty list or a list with fake addresses, which depending on the implementation might be more effective. Thanks, Henrik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 10:01:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00442 for ; Thu, 18 Nov 2004 10:01:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUnpS-0003Cx-VY for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 10:04:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUniY-0006Ma-30; Thu, 18 Nov 2004 09:57:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUnc6-0004Xj-5z for mip6@megatron.ietf.org; Thu, 18 Nov 2004 09:50:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29733 for ; Thu, 18 Nov 2004 09:50:19 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUnej-0002z7-O9 for mip6@ietf.org; Thu, 18 Nov 2004 09:53:06 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id iAIEpb1N012175; Thu, 18 Nov 2004 07:51:37 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id iAIElQi7024518; Thu, 18 Nov 2004 08:47:27 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 419D385C461; Thu, 18 Nov 2004 15:50:04 +0100 (CET) Message-ID: <419CB69B.90809@motorola.com> Date: Thu, 18 Nov 2004 15:50:03 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Petander Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent Address Discovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> <419C5789.7040102@hut.fi> In-Reply-To: <419C5789.7040102@hut.fi> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Henrik Petander wrote: >> For (1), DHAAD relies on building of a HA list by HAs on the home >> link, via the H-bit in their RAs. An attacker MN (one that is at >> home on the home link where the legitimate HAs are) can send fake >> HAs to pretend to be a HA, I think. Based on this fake RA, the >> legitimate HAs will build attacking HA lists, that contain the >> attacker MN as the highest priority HA (or pretending to support >> MRs while it doesn't). The end result of this attack is that MN >> uses the attacker HA as a HA. > > > Yes, if home link is also an access network, then this is a very > relevant vulnerability, since an attacker only needs to be able to > send packets on the home link. We focused on the MN-HA part of the > protocol, but this could be added to the draft, since building of HA > list can also be seen to be a part of the DHAAD protocol. Alex, would > you be interested in adding a subsection to the protocol > vulnerabilities part about this? Sure, you need a paragraph, a two-three paragraphs? How would you title it? > If SEND is used on the home link then this vulnerability can be > fixed, provided that the HAs only add HAs to their list RAs which are > authenticated as coming from authorized routers. I went back to read SEND. It somehow relies on routers (those who send RAs) be leading to "Trust Anchors" i.e. use Certificates; this implies to me that if we want to prevent MN from sending fake RAs on the home link then MN should use certs, or at least HAs use certs before building the HA lists. Also, I think that using SEND to protect DHAAD's RAs also involves using CGAs as options, but it is not clear to me whether RAs are an exception to this. Finally, outside SEND, the MN and the HA do share a key, and it would be risky for HA to rely on that key when receiving RAs from MN at home. > I am not sure about the relevance of the R-bit attack, but it could > possibly be used to attack MR more subtly han sending just an empty > list or a list with fake addresses, which depending on the > implementation might be more effective. The attack on R-bit looks to me like an exemplification of more than just denying HA service to a MH. An attacker could just zero the bit once and thus deny all service to LFNs but not to MR itself, there is no need to fake other addresses in the DHAAD Reply or to block all packets from HA to MR. And yes, depends on the implementation a lot. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 11:15:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07118 for ; Thu, 18 Nov 2004 11:15:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUoz3-0004oR-MG for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 11:18:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUosP-00061d-Jv; Thu, 18 Nov 2004 11:11:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUogh-0003NT-Dx for mip6@megatron.ietf.org; Thu, 18 Nov 2004 10:59:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06146 for ; Thu, 18 Nov 2004 10:59:08 -0500 (EST) From: qsun300@cse.unsw.edu.au Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUojK-0004Vp-Dx for mip6@ietf.org; Thu, 18 Nov 2004 11:01:56 -0500 Received: From webmail.cse.unsw.edu.au ([129.94.242.51] == albeniz.orchestra.cse.unsw.EDU.AU) (ident-user w3serv) By note With Smtp ; Fri, 19 Nov 2004 02:58:52 +1100 Received: from 220.237.11.186 (SquirrelMail authenticated user qsun300) by webmail.cse.unsw.edu.au with HTTP; Fri, 19 Nov 2004 02:58:52 +1100 (EST) To: "Henrik Petander" Date: Fri, 19 Nov 2004 02:58:52 +1100 (EST) Message-ID: <61299.220.237.11.186.1100793532.squirrel@webmail.cse.unsw.edu.au> In-Reply-To: <419C5789.7040102@hut.fi> References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au><419A09E1.5040603@motorola.com> <419C5789.7040102@hut.fi> Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 3.0 (+++) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 8bit Cc: mip6@ietf.org, mahbub@cse.unsw.edu.au, Alexandru Petrescu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 8bit > Hi Alex, > > Thanks for reading the security analysis of DHAAD part of the draft and > commenting it. > > Alexandru Petrescu wrote: >> lmux801@cse.unsw.edu.au wrote: >> >>> Here is a new I-D, Security Issues in Dynamic Home Agent Address >>> Discovery. >> >> >> In addition to the HA-DoS threat, I think (let me know if I'm wrong) >> there are two others: (1) faking the HA List by attacker MN on home link >> and (2) attacks on the R-bit of a NEMO DHAAD Reply. >> Yes, R-bit attack is another DoS attack scenario. Since this draft only focus on security issues in MIPv6, we don't mention R-bit attack scenarion in this draft. Actually, I think, in order to prevent R-bit attack, we should protect both DHAAD Request and DHAAD Reply. Solution 2 in the draft can be easily extended to protect R-bit attack. In my understanding, R-bit attack can be performed in two means: (let me know if I am not correct.thanks) (1) Attacker spoofing DHAAD Reply When attacker sniffs a mobile router sending a DHAAD Request(R-bit set 1), it replies a DHAAD Reply with R-bit set 0. The mobile router would register with home agent as a mobile node, so that it cannot serve all mobile nodes attach to it. (2) Attacker spoofing DHAAD Request When attacker sniffs a mobile router sending a DHAAD Request(R-bit set 1), it replicate the message, change R-bit to 0 and send it to home agent. Then home agent would reply mobile node with two DHAAD Reply(one R-bit set 0, and the other R-bit set 1). If the Reply with R-bit 1 arrives the mobile node first, then everything is ok. But if the DHAAD Reply with R-bit 0 arrives first, then the mobile router has two choice: (a) Discard it. The problem is: when the only home agent that supports mobile router crashes, the mobile router cannot register with other home agent as a mobile node, or it takes long time to do this(the mobile router retry DHAAD unitl it achieves maximum attempts, then register as a mobile node.) (b)Register as a mobile node. It cannot serve the mobile nodes attach to it. Based on above analysis, I think we should protect both DHAAD Request and Reply to prevent R-bit attack. Thanks for your comments. >> For (1), DHAAD relies on building of a HA list by HAs on the home link, >> via the H-bit in their RAs. An attacker MN (one that is at home on the >> home link where the legitimate HAs are) can send fake HAs to pretend to >> be a HA, I think. Based on this fake RA, the legitimate HAs will build >> attacking HA lists, that contain the attacker MN as the highest priority >> HA (or pretending to support MRs while it doesn't). The end result of >> this attack is that MN uses the attacker HA as a HA. > > Yes, if home link is also an access network, then this is a very > relevant vulnerability, since an attacker only needs to be able to send > packets on the home link. We focused on the MN-HA part of the protocol, > but this could be added to the draft, since building of HA list can also > be seen to be a part of the DHAAD protocol. Alex, would you be > interested in adding a subsection to the protocol vulnerabilities part > about this? > > If SEND is used on the home link then this vulnerability can be fixed, > provided that the HAs only add HAs to their list RAs which are > authenticated as coming from authorized routers. > > I am not sure about the relevance of the R-bit attack, but it could > possibly be used to attack MR more subtly han sending just an empty list > or a list with fake addresses, which depending on the implementation > might be more effective. > > Thanks, > > Henrik > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 12:34:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14516 for ; Thu, 18 Nov 2004 12:34:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUqDZ-0006pc-J4 for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 12:37:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUq25-000453-SP; Thu, 18 Nov 2004 12:25:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUplX-0005D1-Qw for mip6@megatron.ietf.org; Thu, 18 Nov 2004 12:08:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12255 for ; Thu, 18 Nov 2004 12:08:13 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUpoC-0006Ag-8b for mip6@ietf.org; Thu, 18 Nov 2004 12:11:01 -0500 Message-ID: <00f501c4cd91$4fc8d3d0$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Henrik Petander" References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> <419C533E.7010702@rhea.tcs.hut.fi> Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery Date: Thu, 18 Nov 2004 09:09:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Alexandru Petrescu , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Henrik, > > 2) Both versions of IKE contain protection against DoS by requiring > > responder cookies and that the cookies be properly formulated. Naturally, > > this won't protect a flat out, no holds barred packet bombardment, but it > > does prevent a more subtle, state depletion attack. > > The cookies protect the responder in IKE, who does not create state > without the correct cookies. I am not an expert on the inner workings of > IKE, but the initiator surely creates state to handle resending, in case > it does not get a reply from the responder, or am I mistaken? > It is not clear to me why the HA needs necessarily to be the initiator. The HA can discard the DHAAD Request unless the MN initiates the IKE SA. Anyway, I think we are mostly arguing about how many angels can dance on the head of a pin, since DHAAD does not seem to be a likely candidate for deployment at this point. The current bootstrapping work in mip6 is intended to replace DHAAD and HoAD with something that the WG deems is more deployable. > > > > As a general point, with the exception of the MiTM DHAAD interception, how > > is a DoS attack on a known home agent address any different from an attack > > on any other server on the Internet, like, for example, cnn.com? > > Normally AFAIK, if IPSec with IKE is used to protect a protocol, IKE is > initiated by the initiator of the protocol to be protected. If IPSec was > used to protect only the unicast DHAAD reply, HA would be the initiator > of IKE and would create a new IKE session for each incoming DHAAD > request. Then a malicious attacker could send masses of DHAAD requests > with different source addresses, thus triggering new IKE sessions in HA > until some limit would be reached after which HA could not serve valid > MNs (at least with IKE). Does this clarify our point of the DoS attack > against HA? > I think your point is an argument against this particular design, I don't think it addresses my general point. Alex's point, which ran towards "the difference is that the HA is more like a router rather than a server" was more what I was looking for. I don't see this point as necessarily being decisively differentating, however, since it addresses the quality of the impact for the attack rather than the mechanisms attackers use and therefore the possible effective countermeasures, which is what I was looking for. Based on impact, one could argue that an attack on a medical server used by people daily with some chronic disease that denied them access necessary for their health would have even more impact, though the mechanism might be the same as used on cnn.com or an HA. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 12:54:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16374 for ; Thu, 18 Nov 2004 12:54:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUqWq-0007Nx-2T for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 12:57:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUqPa-0002we-UB; Thu, 18 Nov 2004 12:49:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUq90-0005gx-Hy for mip6@megatron.ietf.org; Thu, 18 Nov 2004 12:32:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14427 for ; Thu, 18 Nov 2004 12:32:27 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUqBf-0006nC-DQ for mip6@ietf.org; Thu, 18 Nov 2004 12:35:15 -0500 Message-ID: <012001c4cd94$b44c9c30$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" , "Henrik Petander" References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au><419A09E1.5040603@motorola.com> <419C5789.7040102@hut.fi> <419CB69B.90809@motorola.com> Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery Date: Thu, 18 Nov 2004 09:33:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Alex, > > If SEND is used on the home link then this vulnerability can be > > fixed, provided that the HAs only add HAs to their list RAs which are > > authenticated as coming from authorized routers. > > I went back to read SEND. It somehow relies on routers (those who send > RAs) be leading to "Trust Anchors" i.e. use Certificates; this implies > to me that if we want to prevent MN from sending fake RAs on the home > link then MN should use certs, or at least HAs use certs before building > the HA lists. > The MN doesn't need a cert, only the routers on the home link, including the HA if it sends RAs, do. The MN uses the CPS/CPA to obtain the cert chain from the router, and the public key from the router's cert to validate the signature on the RA. > Also, I think that using SEND to protect DHAAD's RAs also involves using > CGAs as options, but it is not clear to me whether RAs are an exception > to this. > I don't know that SEND could be used to protect DHAAD since the CPS/CPA is sent over ICMP and therefore subject to problems with fragmentation if send over more than one link, since certs can be large. CGAs don't help here because the security issue is not authorization to do something with an address (which is what CGAs provide) but rather whether the router is authenticatable as certified by a trusted root (and, additionally if deployed, whether the router is authorized to route the subnet prefixes it is advertising). SEND might be used to protect RAs sent from the HA over the MN-HA tunnel when the HA has the MN's CoA binding, but, again, provided the MN already had the cert paths for the routers on the home link, due to the issue with CPS/CPA fragmentation. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 14:03:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22230 for ; Thu, 18 Nov 2004 14:03:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUrbw-0000fG-96 for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 14:06:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUrIG-0000kr-Gr; Thu, 18 Nov 2004 13:46:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUrDH-00070g-P9 for mip6@megatron.ietf.org; Thu, 18 Nov 2004 13:41:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20080 for ; Thu, 18 Nov 2004 13:40:58 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUrFx-0008VE-49 for mip6@ietf.org; Thu, 18 Nov 2004 13:43:45 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iAIICMB03031; Thu, 18 Nov 2004 10:12:22 -0800 X-mProtect: <200411181812> Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90) by darkstar.iprg.nokia.com smtpdMd8Gnm; Thu, 18 Nov 2004 10:12:21 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by rajeev.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id KAA63109; Thu, 18 Nov 2004 10:40:15 -0800 (PST) Message-ID: <419CEC8F.F29126E0@iprg.nokia.com> Date: Thu, 18 Nov 2004 10:40:15 -0800 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: Thierry Ernst Subject: Re: [Mip6] FW: MIP6 agenda (Final) References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajeev@iprg.nokia.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > > Thus embarking on QoS sensitive, mobility specific multihoming support > > is both too open ended (on the QoS side) and too constraining (by only > > looking at cases when MIP/Nemo is used). > > > > So I think it would be useful for folks to try to think about and > > discuss the bigger picture. > > Agree. But then, where should this discussion take place ? MIP6 WG ? > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > I would add to Erik's observation that we need to be able to assess a topic to see the maturity of the problem and the state of solutions, as well as what could be standardized in IETF. The IETF should work on well-defined _and_ well-agreed problems for which protocol specification could be accomplished in a timely manner. Topics where the problem needs to be crystalized, and solution space needs "thinking" require a forum for discussion. And, MobOpts could be such a place. We (mip*, MobOpts co-chairs) are in the process of working out a model to facilitate closer co-operation between mip* groups and MobOpts. The outcome should be focussed discussion on topics of mutual interest that lead to documents which can be a) taken up in mip* groups for standardization, b) MobOpts RG RFCs. MobOpts would run milestones and try to produce documents within a timeframe of interest to mip* groups. Regards, -Rajeev _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 16:36:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18394 for ; Thu, 18 Nov 2004 16:36:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUtzW-0007VE-Fy for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 16:38:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUte5-0003l9-LL; Thu, 18 Nov 2004 16:16:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUspS-00050s-Cd for mip6@megatron.ietf.org; Thu, 18 Nov 2004 15:24:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03057 for ; Thu, 18 Nov 2004 15:24:27 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUss8-0002oy-C2 for mip6@ietf.org; Thu, 18 Nov 2004 15:27:16 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAIKODF19566; Thu, 18 Nov 2004 22:24:14 +0200 (EET) X-Scanned: Thu, 18 Nov 2004 22:24:08 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iAIKO8a0028936; Thu, 18 Nov 2004 22:24:08 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00QButIz; Thu, 18 Nov 2004 22:24:07 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAIKO6S29525; Thu, 18 Nov 2004 22:24:06 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Nov 2004 14:23:40 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: MIP6 agenda (Final) Date: Thu, 18 Nov 2004 14:23:39 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C1AB@daebe007.americas.nokia.com> Thread-Topic: [Mip6] FW: MIP6 agenda (Final) Thread-Index: AcTNoXGdVKI/HG0pTPOfU1Samrqo7QACwIww To: , X-OriginalArrivalTime: 18 Nov 2004 20:23:40.0184 (UTC) FILETIME=[7DCC8180:01C4CDAC] X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: quoted-printable >> > Thus embarking on QoS sensitive, mobility specific multihoming = support >> > is both too open ended (on the QoS side) and too constraining (by = only >> > looking at cases when MIP/Nemo is used). >> > >> > So I think it would be useful for folks to try to think about and >> > discuss the bigger picture. >> >> Agree. But then, where should this discussion take place ? MIP6 WG ? >> NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? >> > >I would add to Erik's observation that we need to be able to assess a = topic to >see >the maturity of the problem and the state of solutions, as well as what = could >be standardized in IETF. The IETF should work on well-defined _and_ >well-agreed problems for which protocol specification could be = accomplished >in a timely manner. Topics where the problem needs to be crystalized, = and >solution space needs "thinking" require a forum for discussion. And, > MobOpts could be such a place. I agree with this approach. There are quite a large number of topics that are of interest. However given the current limitations of the charter and focus of the working group on specific topics, it is not possible to discuss interesting ideas. Mobopts could act as the place where such ideas dealing with mobility are discussed and the results of such discussions can then be then bought back to the IETF WGs for standardization if that is deemed so. > >We (mip*, MobOpts co-chairs) are in the process of working out a model = to >facilitate closer co-operation between mip* groups and MobOpts. The = outcome >should be focussed discussion on topics of mutual interest that lead to >documents >which can be a) taken up in mip* groups for standardization, b) MobOpts = RG >RFCs. MobOpts would run milestones and try to produce documents within = a >timeframe of interest to mip* groups. I agree. I think having the Mobopts RG do some of the ground work on ideas that have merit but do not necessarily receive the attention in the IETF WGs (mip*) makes sense. Most people tend to think that moving work to the IRTF RG is basically a means of killing it. I hope we can change this perception by having work from the Mobopts RG bought back to the MIP/6/4/shop WGs for standardization. Additionally it should be noted that the RG efforts should not be on infinite timelines. Having milestones for the RG to study topics and provide feedback to the IETF WGs would make this more practical. >-Rajeev -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 16:39:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18927 for ; Thu, 18 Nov 2004 16:39:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUu2U-0007bx-QJ for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 16:42:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUtfY-0005DI-VA; Thu, 18 Nov 2004 16:18:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUt6u-0007Cc-VJ for mip6@megatron.ietf.org; Thu, 18 Nov 2004 15:42:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05824 for ; Thu, 18 Nov 2004 15:42:30 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUt9b-0003bk-Mj for mip6@ietf.org; Thu, 18 Nov 2004 15:45:20 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAIKhoNu005163; Thu, 18 Nov 2004 13:43:50 -0700 (MST) Received: from [10.181.32.180] (mvp-10-181-32-180.ea.mot.com [10.181.32.180]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id iAIKewMU020330; Thu, 18 Nov 2004 14:40:59 -0600 Message-ID: <419D0925.5060807@motorola.com> Date: Thu, 18 Nov 2004 21:42:13 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> <419C533E.7010702@rhea.tcs.hut.fi> <00f501c4cd91$4fc8d3d0$0f6115ac@dcml.docomolabsusa.com> In-Reply-To: <00f501c4cd91$4fc8d3d0$0f6115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit James Kempf wrote: [angels on a pin's top...] > Anyway, I think we are mostly arguing about how many angels can dance > on the head of a pin, since DHAAD does not seem to be a likely > candidate for deployment at this point. Do you know why is DHAAD not a candidate for deployment at this point? Is it because it is insecure? Should we secure it such as to be a candidate for deployment? Is it impossible to secure because of the difficulties IPsec/anycast? Maybe it is not needed to use IPsec/anycast in order to have it a little more secure, a little more deployable. Or has DHAAD been simply overlooked by people in need of urgent deployment? > The current bootstrapping work in mip6 is intended to replace DHAAD > and HoAD with something that the WG deems is more deployable. I don't think there is anything simpler and thus more deployable than: discover HA - get MPD - configure HoA. The keys? Pre-shared. I still have to figure out why people don't like them pre-shared here. I bet that other methods to do HA Discovery and HoA configuration will render not only DHAAD useless but also MPD. And, being new methods, they'll surely have their own new security risks. That said, it still makes sense to me to recognize in a written document that a certain procedure (DHAAD) in a Standards Track RFC is insecure. Somehow for completeness. Somehow as advice "don't do so". Whether it is worth the effort to secure it or not - is another question. A question which could be raised to the WG. > Alex's point, which ran towards "the difference is that the HA is > more like a router rather than a server" was more what I was looking > for. I don't see this point as necessarily being decisively > differentating, however, since it addresses the quality of the impact > for the attack rather than the mechanisms attackers use and > therefore the possible effective countermeasures, which is what I was > looking for. Based on impact, one could argue that an attack on a > medical server used by people daily with some chronic disease that > denied them access necessary for their health would have even more > impact, though the mechanism might be the same as used on cnn.com or > an HA. This sounds logic, all layer-3 mechanisms used for attack being equal the impact on layer-7 is also equal (be it health data or video entertainment). I could only argue that impact is also a sort of assessment of the size of the risk, and impact of a risky local DHCP is obviously lower than impact of a risky Internet-wide Mobile IPv6. I am not arguing the impact of a risky HL7, a protocol for the kind of health data you mention (IIRC). Note I still have to read the drafts you mentioned. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 16:40:16 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19391 for ; Thu, 18 Nov 2004 16:40:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUu3W-0007hp-NS for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 16:43:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUtnT-0003e4-R4; Thu, 18 Nov 2004 16:26:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUtQ7-0003wW-VH for mip6@megatron.ietf.org; Thu, 18 Nov 2004 16:02:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11927 for ; Thu, 18 Nov 2004 16:02:21 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUtSl-0005ZR-OH for mip6@ietf.org; Thu, 18 Nov 2004 16:05:11 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAIL2Eb15968 for ; Thu, 18 Nov 2004 23:02:18 +0200 (EET) X-Scanned: Thu, 18 Nov 2004 23:01:37 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id iAIL1bAp015463 for ; Thu, 18 Nov 2004 23:01:37 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00A41YKi; Thu, 18 Nov 2004 23:01:31 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAIL1Ua29217 for ; Thu, 18 Nov 2004 23:01:30 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 18 Nov 2004 15:00:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Nov 2004 15:00:19 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF4403B1C1AF@daebe007.americas.nokia.com> Thread-Topic: I-D: draft-ietf-mip6-auth-protocol to progress on Informational track Thread-Index: AcTNsZwNn+kawg8sQOG7tmkX+n2OJg== To: X-OriginalArrivalTime: 18 Nov 2004 21:00:20.0020 (UTC) FILETIME=[9D00D740:01C4CDB1] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] I-D: draft-ietf-mip6-auth-protocol to progress on Informational track X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Hello, There was an appeal to the consensus call made by the chairs w.r.t the status of progressing the Auth I-D [draft-ietf-mip6-auth-protocol-00] on standards track. The appeal details are at: http://www1.ietf.org/mail-archive/web/mip6/current/msg01937.html The MIP6 Working group discussed this issue at the WG meeting at IETF61. There were plenty of arguments about the pros and cons of standardizing an alternate mechanism for securing the BU/BAck between the MN and HA. At the end of the discussion, the room was queried on how to proceed with this I-D. The options for progress were: 1. Not publish this I-D at all No hands raised to support this option. 2. Progress the I-D on standards track Several hands supporting this option (about 9) 3. Progress the I-D on Informational track Many more hands (about 30) The conclusion drawn from the discussion is that the consensus in the WG is to progress the I-D on an Informational track.=20 Consequently, the Auth-ID will now proceed in the WG towards publication as an Informational RFC. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 16:54:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21690 for ; Thu, 18 Nov 2004 16:54:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUuGu-0008MG-OI for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 16:56:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUu0V-00059A-O2; Thu, 18 Nov 2004 16:39:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUtjh-0000CE-C5 for mip6@megatron.ietf.org; Thu, 18 Nov 2004 16:22:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16161 for ; Thu, 18 Nov 2004 16:22:34 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUtmN-0006tB-R1 for mip6@ietf.org; Thu, 18 Nov 2004 16:25:24 -0500 Message-ID: <020901c4cdb4$d91bc660$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> <419C533E.7010702@rhea.tcs.hut.fi> <00f501c4cd91$4fc8d3d0$0f6115ac@dcml.docomolabsusa.com> <419D0925.5060807@motorola.com> Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery Date: Thu, 18 Nov 2004 13:23:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Alex, Many ISPs block ICMP except on the local link, since it can be used for ping attacks and also tends to cause increased traffic from backscatter during worm scanning. Also, as the draft points out, there are security problems with DHAAD, in addition to the issues with anycast that you point out below. The basic architectural thinking that went into DHAAD seems to have been that home agent discovery on the Internet is analgous to router discovery on the local link. I believe this thinking is not accurate, as services are discovered in the Internet in ways that are much different than locally in enterprise networks. Personally, I think the WG will come up with a couple (but probably not just one) techniques that are a better fit with the way wireless ISPs currently operate, and therefore are more deployable. We've got a some good drafts in this area, and the technical discussion seems to be progressing along well. jak ----- Original Message ----- From: "Alexandru Petrescu" To: "James Kempf" Cc: "Henrik Petander" ; ; ; Sent: Thursday, November 18, 2004 12:42 PM Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery > James Kempf wrote: > [angels on a pin's top...] > > Anyway, I think we are mostly arguing about how many angels can dance > > on the head of a pin, since DHAAD does not seem to be a likely > > candidate for deployment at this point. > > Do you know why is DHAAD not a candidate for deployment at this point? > Is it because it is insecure? Should we secure it such as to be a > candidate for deployment? Is it impossible to secure because of the > difficulties IPsec/anycast? Maybe it is not needed to use IPsec/anycast > in order to have it a little more secure, a little more deployable. Or > has DHAAD been simply overlooked by people in need of urgent deployment? > > > The current bootstrapping work in mip6 is intended to replace DHAAD > > and HoAD with something that the WG deems is more deployable. > > I don't think there is anything simpler and thus more deployable than: > discover HA - get MPD - configure HoA. The keys? Pre-shared. I still > have to figure out why people don't like them pre-shared here. > > I bet that other methods to do HA Discovery and HoA configuration will > render not only DHAAD useless but also MPD. And, being new methods, > they'll surely have their own new security risks. > > That said, it still makes sense to me to recognize in a written document > that a certain procedure (DHAAD) in a Standards Track RFC is insecure. > Somehow for completeness. Somehow as advice "don't do so". Whether it > is worth the effort to secure it or not - is another question. A > question which could be raised to the WG. > > > Alex's point, which ran towards "the difference is that the HA is > > more like a router rather than a server" was more what I was looking > > for. I don't see this point as necessarily being decisively > > differentating, however, since it addresses the quality of the impact > > for the attack rather than the mechanisms attackers use and > > therefore the possible effective countermeasures, which is what I was > > looking for. Based on impact, one could argue that an attack on a > > medical server used by people daily with some chronic disease that > > denied them access necessary for their health would have even more > > impact, though the mechanism might be the same as used on cnn.com or > > an HA. > > This sounds logic, all layer-3 mechanisms used for attack being equal > the impact on layer-7 is also equal (be it health data or video > entertainment). I could only argue that impact is also a sort of > assessment of the size of the risk, and impact of a risky local DHCP is > obviously lower than impact of a risky Internet-wide Mobile IPv6. I am > not arguing the impact of a risky HL7, a protocol for the kind of health > data you mention (IIRC). > > Note I still have to read the drafts you mentioned. > > Alex > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 17:14:58 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24418 for ; Thu, 18 Nov 2004 17:14:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUub6-0000Zw-JF for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 17:17:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuQD-0006dz-Fj; Thu, 18 Nov 2004 17:06:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuAq-0001c2-2l for mip6@megatron.ietf.org; Thu, 18 Nov 2004 16:50:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20928 for ; Thu, 18 Nov 2004 16:50:37 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUuDW-00087M-DV for mip6@ietf.org; Thu, 18 Nov 2004 16:53:27 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAILq0Nu010473; Thu, 18 Nov 2004 14:52:00 -0700 (MST) Received: from [10.181.32.180] (mvp-10-181-32-180.ea.mot.com [10.181.32.180]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id iAILn8MU025398; Thu, 18 Nov 2004 15:49:09 -0600 Message-ID: <419D191F.7020009@motorola.com> Date: Thu, 18 Nov 2004 22:50:23 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> <419C533E.7010702@rhea.tcs.hut.fi> <00f501c4cd91$4fc8d3d0$0f6115ac@dcml.docomolabsusa.com> <419D0925.5060807@motorola.com> <020901c4cdb4$d91bc660$0f6115ac@dcml.docomolabsusa.com> In-Reply-To: <020901c4cdb4$d91bc660$0f6115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit James Kempf wrote: > Alex, > > Many ISPs block ICMP James, as far as I can remember, one cellular ISP doesn't block ICMPv4 although NAT is in place and there is at least one other cellular ISP that does not do NAT. I will not dare however to make definitive statements about ISPs, cellular or otherwise. > below. The basic architectural thinking that went into DHAAD seems to > have been that home agent discovery on the Internet is analgous to > router discovery on the local link. I believe this thinking is not > accurate, as services are discovered in the Internet in ways that are > much different than locally in enterprise networks. If this thinking is not accurate, then MPD qualifies to same thinking: MPD is devised after router discovery on the local link too. > Personally, I think the WG will come up with a couple (but probably > not just one) It's good when there is choice. > techniques that are a better fit with the way wireless ISPs currently > operate, and therefore are more deployable. We've got a some good > drafts in this area, and the technical discussion seems to be > progressing along well. Again, I'll have to look at these. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 17:21:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25207 for ; Thu, 18 Nov 2004 17:21:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUuhI-0000kH-C3 for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 17:24:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuW0-0001KV-Hs; Thu, 18 Nov 2004 17:12:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuM3-00055T-Ap for mip6@megatron.ietf.org; Thu, 18 Nov 2004 17:02:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22654 for ; Thu, 18 Nov 2004 17:02:12 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUuOk-0000AG-VY for mip6@ietf.org; Thu, 18 Nov 2004 17:05:03 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAIM3fNu022043; Thu, 18 Nov 2004 15:03:41 -0700 (MST) Received: from [10.181.32.180] (mvp-10-181-32-180.ea.mot.com [10.181.32.180]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id iAIM0oMU004336; Thu, 18 Nov 2004 16:00:51 -0600 Message-ID: <419D1BDD.4040404@motorola.com> Date: Thu, 18 Nov 2004 23:02:05 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au> <419A09E1.5040603@motorola.com> <009301c4cbfb$73228b10$0f6115ac@dcml.docomolabsusa.com> <419C533E.7010702@rhea.tcs.hut.fi> <00f501c4cd91$4fc8d3d0$0f6115ac@dcml.docomolabsusa.com> <419D0925.5060807@motorola.com> <020901c4cdb4$d91bc660$0f6115ac@dcml.docomolabsusa.com> In-Reply-To: <020901c4cdb4$d91bc660$0f6115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Does this somehow mean that probably the DHAAD part of the NEMO BAsic Support suddenly becomes superfluous? This should be known... Alex James Kempf wrote: > Alex, > > Many ISPs block ICMP except on the local link, since it can be used for ping > attacks and also tends to cause increased traffic from backscatter during > worm scanning. Also, as the draft points out, there are security problems > with DHAAD, in addition to the issues with anycast that you point out below. > The basic architectural thinking that went into DHAAD seems to have been > that home agent discovery on the Internet is analgous to router discovery on > the local link. I believe this thinking is not accurate, as services are > discovered in the Internet in ways that are much different than locally in > enterprise networks. > > Personally, I think the WG will come up with a couple (but probably not just > one) techniques that are a better fit with the way wireless ISPs currently > operate, and therefore are more deployable. We've got a some good drafts in > this area, and the technical discussion seems to be progressing along well. > > jak > > > ----- Original Message ----- > From: "Alexandru Petrescu" > To: "James Kempf" > Cc: "Henrik Petander" ; ; > ; > Sent: Thursday, November 18, 2004 12:42 PM > Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent > AddressDiscovery > > > >>James Kempf wrote: >>[angels on a pin's top...] >> >>>Anyway, I think we are mostly arguing about how many angels can dance >>> on the head of a pin, since DHAAD does not seem to be a likely >>>candidate for deployment at this point. >> >>Do you know why is DHAAD not a candidate for deployment at this point? >>Is it because it is insecure? Should we secure it such as to be a >>candidate for deployment? Is it impossible to secure because of the >>difficulties IPsec/anycast? Maybe it is not needed to use IPsec/anycast >>in order to have it a little more secure, a little more deployable. Or >>has DHAAD been simply overlooked by people in need of urgent deployment? >> >> >>>The current bootstrapping work in mip6 is intended to replace DHAAD >>>and HoAD with something that the WG deems is more deployable. >> >>I don't think there is anything simpler and thus more deployable than: >>discover HA - get MPD - configure HoA. The keys? Pre-shared. I still >>have to figure out why people don't like them pre-shared here. >> >>I bet that other methods to do HA Discovery and HoA configuration will >>render not only DHAAD useless but also MPD. And, being new methods, >>they'll surely have their own new security risks. >> >>That said, it still makes sense to me to recognize in a written document >>that a certain procedure (DHAAD) in a Standards Track RFC is insecure. >>Somehow for completeness. Somehow as advice "don't do so". Whether it >>is worth the effort to secure it or not - is another question. A >>question which could be raised to the WG. >> >> >>>Alex's point, which ran towards "the difference is that the HA is >>>more like a router rather than a server" was more what I was looking >>>for. I don't see this point as necessarily being decisively >>>differentating, however, since it addresses the quality of the impact >>> for the attack rather than the mechanisms attackers use and >>>therefore the possible effective countermeasures, which is what I was >>>looking for. Based on impact, one could argue that an attack on a >>>medical server used by people daily with some chronic disease that >>>denied them access necessary for their health would have even more >>>impact, though the mechanism might be the same as used on cnn.com or >>>an HA. >> >>This sounds logic, all layer-3 mechanisms used for attack being equal >>the impact on layer-7 is also equal (be it health data or video >>entertainment). I could only argue that impact is also a sort of >>assessment of the size of the risk, and impact of a risky local DHCP is >>obviously lower than impact of a risky Internet-wide Mobile IPv6. I am >>not arguing the impact of a risky HL7, a protocol for the kind of health >>data you mention (IIRC). >> >>Note I still have to read the drafts you mentioned. >> >>Alex >> > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 17:24:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25582 for ; Thu, 18 Nov 2004 17:24:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUuk1-0000p6-M0 for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 17:27:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuXu-0001yq-2R; Thu, 18 Nov 2004 17:14:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUuPr-0006Ic-Jq for mip6@megatron.ietf.org; Thu, 18 Nov 2004 17:06:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23353 for ; Thu, 18 Nov 2004 17:06:08 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUuSZ-0000Go-BJ for mip6@ietf.org; Thu, 18 Nov 2004 17:08:59 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAIM7dNu026019; Thu, 18 Nov 2004 15:07:39 -0700 (MST) Received: from [10.181.32.180] (mvp-10-181-32-180.ea.mot.com [10.181.32.180]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id iAILvw4V005692; Thu, 18 Nov 2004 15:57:59 -0600 Message-ID: <419D1CC9.9010006@motorola.com> Date: Thu, 18 Nov 2004 23:06:01 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: qsun300@cse.unsw.edu.au Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au><419A09E1.5040603@motorola.com> <419C5789.7040102@hut.fi> <61299.220.237.11.186.1100793532.squirrel@webmail.cse.unsw.edu.au> In-Reply-To: <61299.220.237.11.186.1100793532.squirrel@webmail.cse.unsw.edu.au> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit qsun the 300th. Thanks for your reply. Could you please reveal your name so I can address you, thanks. Chairs, if I'm dancing on a pinus :-) please let me know if this effort is out of focus here, thanks. qsun300@cse.unsw.edu.au wrote: > Yes, R-bit attack is another DoS attack scenario. Since this draft > only focus on security issues in MIPv6, we don't mention R-bit attack > scenarion in this draft. Actually, I think, in order to prevent > R-bit attack, we should protect both DHAAD Request and DHAAD Reply. Yes, that's what I thought too, it's not enough to protect only the Reply. > In my understanding, R-bit attack can be performed in two means: (let > me know if I am not correct.thanks) (1) Attacker spoofing DHAAD > Reply When attacker sniffs a mobile router sending a DHAAD > Request(R-bit set 1), it replies a DHAAD Reply with R-bit set 0. The > mobile router would register with home agent as a mobile node, so > that it cannot serve all mobile nodes attach to it. YEs, but it may be not necessary for attacker to create a Reply faking the HA Reply, it is sufficient to forward a fake Request to HA and drop the valid Request. > (2) Attacker spoofing DHAAD Request When attacker sniffs a mobile > router sending a DHAAD Request(R-bit set 1), it replicate the > message, change R-bit to 0 and send it to home agent. Then home agent > would reply mobile node with two DHAAD Reply(one R-bit set 0, and > the other R-bit set 1). Actually, I was seeing a more powerful attacker that would create a brand new fake request (R-bit 0) and discard the valid Request (R-bit 1), so only the fake Request hits the HA, so only the fake Reply hits the MR. > If the Reply with R-bit 1 arrives the mobile node first, then > everything is ok. But if the DHAAD Reply with R-bit 0 arrives first, > then the mobile router has two choice: (a) Discard it. Yep, that's what the MR could do to realize there's error possible attack. > The problem is: when the only home agent that supports mobile router > crashes, the mobile router cannot register with other home agent as a > mobile node, or it takes long time to do this(the mobile router retry > DHAAD unitl it achieves maximum attempts, then register as a mobile > node.) That is a possibliity, I didn't think that far. > (b)Register as a mobile node. It cannot serve the mobile nodes attach > to it. > > Based on above analysis, I think we should protect both DHAAD Request > and Reply to prevent R-bit attack. Yes, I guess both should be protected somehow to protect against these attacks. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 17:57:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28980 for ; Thu, 18 Nov 2004 17:57:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUvGA-0001eU-Fj for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 18:00:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUv5R-0004Yi-LH; Thu, 18 Nov 2004 17:49:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUv3F-0003bq-En for mip6@megatron.ietf.org; Thu, 18 Nov 2004 17:46:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28074 for ; Thu, 18 Nov 2004 17:46:50 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUv5x-0001Q7-7j for mip6@ietf.org; Thu, 18 Nov 2004 17:49:41 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAIMmGNu002990; Thu, 18 Nov 2004 15:48:16 -0700 (MST) Received: from [10.181.32.235] (mvp-10-181-32-235.ea.mot.com [10.181.32.235]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id iAIMjMMU015840; Thu, 18 Nov 2004 16:45:24 -0600 Message-ID: <419D264D.8070006@motorola.com> Date: Thu, 18 Nov 2004 23:46:37 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au><419A09E1.5040603@motorola.com> <419C5789.7040102@hut.fi> <419CB69B.90809@motorola.com> <012001c4cd94$b44c9c30$0f6115ac@dcml.docomolabsusa.com> In-Reply-To: <012001c4cd94$b44c9c30$0f6115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit James Kempf wrote: > The MN doesn't need a cert, only the routers on the home link, > including the HA if it sends RAs, do. The MN uses the CPS/CPA to > obtain the cert chain from the router, and the public key from the > router's cert to validate the signature on the RA. The attack was something like where the MN at home sends the fake RA to HAs, so the receiving HAs on the home link needed to make sure the content of that RA is valid such as _not_ to build fake HA lists. So if SEND were to help with this, would MN need a cert? So this is like true simple SEND on a simple unique link, not across tunnels. >> Also, I think that using SEND to protect DHAAD's RAs also involves >> using CGAs as options, but it is not clear to me whether RAs are >> an exception to this. >> > > > I don't know that SEND could be used to protect DHAAD since the > CPS/CPA is sent over ICMP and therefore subject to problems with > fragmentation if send over more than one link, since certs can be > large. Fragmentation is done by end nodes so more than one intermediary links is not an issue. The first link may be an issue, because the links following usually have larger MTUs (unless successive HAs get in the way, a la nested NEMO). But there's also reassembly, hopefully. > CGAs don't help here because the security issue is not authorization > to do something with an address (which is what CGAs provide) but > rather whether the router is authenticatable as certified by a > trusted root (and, additionally if deployed, whether the router is > authorized to route the subnet prefixes it is advertising). Ok, I understand that. What I was wondering was whether a MH on the home link can be recognized as sending fake RAs with the tool SEND that may use certs or CGA, and if yes, are both certs and CGAs needed? Would this involve that HoA must be a CGA. I hope not. > SEND might be used to protect RAs sent from the HA over the MN-HA > tunnel when the HA has the MN's CoA binding, but, again, provided the > MN already had the cert paths for the routers on the home link, due > to the issue with CPS/CPA fragmentation. I don't think fragmentation on such long paths is an issue because reassembly. I didn't think to send DHAAD messages (Req/Rep) through the tunnel. I wondered whether SEND can protect when a legitimate-and-attacker MN is at home. (legitimate: because it shares keys with HA but attacker because it attacks another MN, attack by forcing HA to send fake DHAAD Replies to MN). Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 18:16:45 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01708 for ; Thu, 18 Nov 2004 18:16:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUvYk-00026h-TL for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 18:19:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUvNN-0003Zh-SH; Thu, 18 Nov 2004 18:07:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUvKh-00027T-69 for mip6@megatron.ietf.org; Thu, 18 Nov 2004 18:04:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29638 for ; Thu, 18 Nov 2004 18:04:51 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUvNO-0001pm-0t for mip6@ietf.org; Thu, 18 Nov 2004 18:07:43 -0500 Message-ID: <029001c4cdc3$236820c0$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alexandru Petrescu" References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au><419A09E1.5040603@motorola.com> <419C5789.7040102@hut.fi> <419CB69B.90809@motorola.com> <012001c4cd94$b44c9c30$0f6115ac@dcml.docomolabsusa.com> <419D264D.8070006@motorola.com> Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery Date: Thu, 18 Nov 2004 15:05:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit > The attack was something like where the MN at home sends the fake RA to > HAs, so the receiving HAs on the home link needed to make sure the > content of that RA is valid such as _not_ to build fake HA lists. So if > SEND were to help with this, would MN need a cert? If the MN doesn't have a certified asymmetric key pair, it can't generate a signature on the RA, thus the HAs would not accept the RA. > What I was wondering was whether a MH on the home link can be recognized > as sending fake RAs with the tool SEND that may use certs or CGA, and if > yes, are both certs and CGAs needed? Would this involve that HoA must > be a CGA. I hope not. > No, only certified asymmetric key pairs are needed and only on the HA. The HAs can recognize the fake RA, as can any other node on the home link. > I didn't think to send DHAAD messages (Req/Rep) through the tunnel. I > wondered whether SEND can protect when a legitimate-and-attacker MN is > at home. (legitimate: because it shares keys with HA but attacker > because it attacks another MN, attack by forcing HA to send fake DHAAD > Replies to MN). > I suppose one could put a SEND signature on the DHAAD message using the key pair certified by the router certificate. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 19:29:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08923 for ; Thu, 18 Nov 2004 19:29:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUwh1-0003y0-CY for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 19:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUwa2-0004OK-EX; Thu, 18 Nov 2004 19:24:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUwUR-0002lW-I0 for mip6@megatron.ietf.org; Thu, 18 Nov 2004 19:19:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08138 for ; Thu, 18 Nov 2004 19:18:59 -0500 (EST) Message-Id: <200411190018.TAA08138@ietf.org> Received: from mail1.lge.co.kr ([156.147.1.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUwX8-0003jo-Ms for mip6@ietf.org; Thu, 18 Nov 2004 19:21:51 -0500 Received: from [150.150.67.234] (eypark@lge.com) by mail1.lge.co.kr (Terrace MailWatcher) with ESMTP id 2004111909:14:45:987031.275.105 for ; Fri, 19 Nov 2004 09:14:45 +0900 (KST) From: =?ks_c_5601-1987?B?udrAur+1?= To: Date: Fri, 19 Nov 2004 09:18:19 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcTNk2kTivEmSXXSSQyc9vpaRR4BLAAOdC+A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-TERRACE-SPAMRATE: Spacelee says NOT YET spam-rated. X-Spam-Score: 1.1 (+) X-Scan-Signature: 83e9494d829b08cc3f644ef6ac1b9bd4 Content-Transfer-Encoding: 7bit Subject: [Mip6] RE: Mip6 Digest, Vol 7, Issue 21 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.8 (+) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Content-Transfer-Encoding: 7bit -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] Sent: Friday, November 19, 2004 2:23 AM To: mip6@ietf.org Subject: Mip6 Digest, Vol 7, Issue 21 Send Mip6 mailing list submissions to mip6@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/mip6 or, via email, send a message with subject or body 'help' to mip6-request@ietf.org You can reach the person managing the list at mip6-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Mip6 digest..." Today's Topics: 1. Re: New I-D: Security Issues in Dynamic Home Agent Address Discovery (Henrik Petander) 2. Re: New I-D: Security Issues in Dynamic Home Agent Address Discovery (Alexandru Petrescu) 3. Re: New I-D: Security Issues in Dynamic Home Agent AddressDiscovery (qsun300@cse.unsw.edu.au) ---------------------------------------------------------------------- Message: 1 Date: Thu, 18 Nov 2004 19:04:25 +1100 From: Henrik Petander Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent Address Discovery To: Alexandru Petrescu Cc: mip6@ietf.org, mahbub@cse.unsw.edu.au Message-ID: <419C5789.7040102@hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Alex, Thanks for reading the security analysis of DHAAD part of the draft and commenting it. Alexandru Petrescu wrote: > lmux801@cse.unsw.edu.au wrote: > >> Here is a new I-D, Security Issues in Dynamic Home Agent Address >> Discovery. > > > In addition to the HA-DoS threat, I think (let me know if I'm wrong) > there are two others: (1) faking the HA List by attacker MN on home link > and (2) attacks on the R-bit of a NEMO DHAAD Reply. > > For (1), DHAAD relies on building of a HA list by HAs on the home link, > via the H-bit in their RAs. An attacker MN (one that is at home on the > home link where the legitimate HAs are) can send fake HAs to pretend to > be a HA, I think. Based on this fake RA, the legitimate HAs will build > attacking HA lists, that contain the attacker MN as the highest priority > HA (or pretending to support MRs while it doesn't). The end result of > this attack is that MN uses the attacker HA as a HA. Yes, if home link is also an access network, then this is a very relevant vulnerability, since an attacker only needs to be able to send packets on the home link. We focused on the MN-HA part of the protocol, but this could be added to the draft, since building of HA list can also be seen to be a part of the DHAAD protocol. Alex, would you be interested in adding a subsection to the protocol vulnerabilities part about this? If SEND is used on the home link then this vulnerability can be fixed, provided that the HAs only add HAs to their list RAs which are authenticated as coming from authorized routers. I am not sure about the relevance of the R-bit attack, but it could possibly be used to attack MR more subtly han sending just an empty list or a list with fake addresses, which depending on the implementation might be more effective. Thanks, Henrik ------------------------------ Message: 2 Date: Thu, 18 Nov 2004 15:50:03 +0100 From: Alexandru Petrescu Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent Address Discovery To: Henrik Petander Cc: mip6@ietf.org, mahbub@cse.unsw.edu.au Message-ID: <419CB69B.90809@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Henrik Petander wrote: >> For (1), DHAAD relies on building of a HA list by HAs on the home >> link, via the H-bit in their RAs. An attacker MN (one that is at >> home on the home link where the legitimate HAs are) can send fake >> HAs to pretend to be a HA, I think. Based on this fake RA, the >> legitimate HAs will build attacking HA lists, that contain the >> attacker MN as the highest priority HA (or pretending to support >> MRs while it doesn't). The end result of this attack is that MN >> uses the attacker HA as a HA. > > > Yes, if home link is also an access network, then this is a very > relevant vulnerability, since an attacker only needs to be able to > send packets on the home link. We focused on the MN-HA part of the > protocol, but this could be added to the draft, since building of HA > list can also be seen to be a part of the DHAAD protocol. Alex, would > you be interested in adding a subsection to the protocol > vulnerabilities part about this? Sure, you need a paragraph, a two-three paragraphs? How would you title it? > If SEND is used on the home link then this vulnerability can be > fixed, provided that the HAs only add HAs to their list RAs which are > authenticated as coming from authorized routers. I went back to read SEND. It somehow relies on routers (those who send RAs) be leading to "Trust Anchors" i.e. use Certificates; this implies to me that if we want to prevent MN from sending fake RAs on the home link then MN should use certs, or at least HAs use certs before building the HA lists. Also, I think that using SEND to protect DHAAD's RAs also involves using CGAs as options, but it is not clear to me whether RAs are an exception to this. Finally, outside SEND, the MN and the HA do share a key, and it would be risky for HA to rely on that key when receiving RAs from MN at home. > I am not sure about the relevance of the R-bit attack, but it could > possibly be used to attack MR more subtly han sending just an empty > list or a list with fake addresses, which depending on the > implementation might be more effective. The attack on R-bit looks to me like an exemplification of more than just denying HA service to a MH. An attacker could just zero the bit once and thus deny all service to LFNs but not to MR itself, there is no need to fake other addresses in the DHAAD Reply or to block all packets from HA to MR. And yes, depends on the implementation a lot. Alex ------------------------------ Message: 3 Date: Fri, 19 Nov 2004 02:58:52 +1100 (EST) From: qsun300@cse.unsw.edu.au Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery To: "Henrik Petander" Cc: mip6@ietf.org, mahbub@cse.unsw.edu.au, Alexandru Petrescu Message-ID: <61299.220.237.11.186.1100793532.squirrel@webmail.cse.unsw.edu.au> Content-Type: text/plain;charset=iso-8859-1 > Hi Alex, > > Thanks for reading the security analysis of DHAAD part of the draft and > commenting it. > > Alexandru Petrescu wrote: >> lmux801@cse.unsw.edu.au wrote: >> >>> Here is a new I-D, Security Issues in Dynamic Home Agent Address >>> Discovery. >> >> >> In addition to the HA-DoS threat, I think (let me know if I'm wrong) >> there are two others: (1) faking the HA List by attacker MN on home link >> and (2) attacks on the R-bit of a NEMO DHAAD Reply. >> Yes, R-bit attack is another DoS attack scenario. Since this draft only focus on security issues in MIPv6, we don't mention R-bit attack scenarion in this draft. Actually, I think, in order to prevent R-bit attack, we should protect both DHAAD Request and DHAAD Reply. Solution 2 in the draft can be easily extended to protect R-bit attack. In my understanding, R-bit attack can be performed in two means: (let me know if I am not correct.thanks) (1) Attacker spoofing DHAAD Reply When attacker sniffs a mobile router sending a DHAAD Request(R-bit set 1), it replies a DHAAD Reply with R-bit set 0. The mobile router would register with home agent as a mobile node, so that it cannot serve all mobile nodes attach to it. (2) Attacker spoofing DHAAD Request When attacker sniffs a mobile router sending a DHAAD Request(R-bit set 1), it replicate the message, change R-bit to 0 and send it to home agent. Then home agent would reply mobile node with two DHAAD Reply(one R-bit set 0, and the other R-bit set 1). If the Reply with R-bit 1 arrives the mobile node first, then everything is ok. But if the DHAAD Reply with R-bit 0 arrives first, then the mobile router has two choice: (a) Discard it. The problem is: when the only home agent that supports mobile router crashes, the mobile router cannot register with other home agent as a mobile node, or it takes long time to do this(the mobile router retry DHAAD unitl it achieves maximum attempts, then register as a mobile node.) (b)Register as a mobile node. It cannot serve the mobile nodes attach to it. Based on above analysis, I think we should protect both DHAAD Request and Reply to prevent R-bit attack. Thanks for your comments. >> For (1), DHAAD relies on building of a HA list by HAs on the home link, >> via the H-bit in their RAs. An attacker MN (one that is at home on the >> home link where the legitimate HAs are) can send fake HAs to pretend to >> be a HA, I think. Based on this fake RA, the legitimate HAs will build >> attacking HA lists, that contain the attacker MN as the highest priority >> HA (or pretending to support MRs while it doesn't). The end result of >> this attack is that MN uses the attacker HA as a HA. > > Yes, if home link is also an access network, then this is a very > relevant vulnerability, since an attacker only needs to be able to send > packets on the home link. We focused on the MN-HA part of the protocol, > but this could be added to the draft, since building of HA list can also > be seen to be a part of the DHAAD protocol. Alex, would you be > interested in adding a subsection to the protocol vulnerabilities part > about this? > > If SEND is used on the home link then this vulnerability can be fixed, > provided that the HAs only add HAs to their list RAs which are > authenticated as coming from authorized routers. > > I am not sure about the relevance of the R-bit attack, but it could > possibly be used to attack MR more subtly han sending just an empty list > or a list with fake addresses, which depending on the implementation > might be more effective. > > Thanks, > > Henrik > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > ------------------------------ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 End of Mip6 Digest, Vol 7, Issue 21 *********************************** _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 19:32:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09340 for ; Thu, 18 Nov 2004 19:32:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUwju-00042x-Ed for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 19:35:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUwa3-0004Pi-RU; Thu, 18 Nov 2004 19:24:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUwW4-0002pe-L8 for mip6@megatron.ietf.org; Thu, 18 Nov 2004 19:20:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08243 for ; Thu, 18 Nov 2004 19:20:41 -0500 (EST) From: qsun300@cse.unsw.edu.au Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUwYm-0003mI-BI for mip6@ietf.org; Thu, 18 Nov 2004 19:23:33 -0500 Received: From webmail.cse.unsw.edu.au ([129.94.242.51] == albeniz.orchestra.cse.unsw.EDU.AU) (ident-user w3serv) By note With Smtp ; Fri, 19 Nov 2004 11:20:31 +1100 Received: from 220.237.11.186 (SquirrelMail authenticated user qsun300) by webmail.cse.unsw.edu.au with HTTP; Fri, 19 Nov 2004 11:20:31 +1100 (EST) To: "Alexandru Petrescu" Date: Fri, 19 Nov 2004 11:20:31 +1100 (EST) Message-ID: <61369.220.237.11.186.1100823631.squirrel@webmail.cse.unsw.edu.au> In-Reply-To: <419D1CC9.9010006@motorola.com> References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au><419A09E1.5040603@motorola.com> <419C5789.7040102@hut.fi> <61299.220.237.11.186.1100793532.squirrel@webmail.cse.unsw.edu.au> <419D1CC9.9010006@motorola.com> Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 4.2 (++++) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 8bit Cc: Henrik Petander , mahbub@cse.unsw.edu.au, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 4.2 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 8bit Thanks for your comments. You mentioned "drop the valid Request", however I think it requires the attacker sit in the middle of mobile router and home agent. I think it would be difficult to do this. On the other hand, if the attacker sits in the middle between the mobile router and home agent, it can definitly perform DoS attack no matter what kind protection is adopted(even you use IPSec, the attacker can drop IKE messages, SA cannot setup). So the attack scenarios I mentioned assumes the attacker is in the same foreign link with mobile router. That would be very easy. And the attack is still quite significant. > qsun the 300th. Thanks for your reply. Could you please reveal your > name so I can address you, thanks. > > Chairs, if I'm dancing on a pinus :-) please let me know if this effort > is out of focus here, thanks. > > qsun300@cse.unsw.edu.au wrote: >> Yes, R-bit attack is another DoS attack scenario. Since this draft >> only focus on security issues in MIPv6, we don't mention R-bit attack >> scenarion in this draft. Actually, I think, in order to prevent >> R-bit attack, we should protect both DHAAD Request and DHAAD Reply. > > Yes, that's what I thought too, it's not enough to protect only the Reply. > >> In my understanding, R-bit attack can be performed in two means: (let >> me know if I am not correct.thanks) (1) Attacker spoofing DHAAD >> Reply When attacker sniffs a mobile router sending a DHAAD >> Request(R-bit set 1), it replies a DHAAD Reply with R-bit set 0. The >> mobile router would register with home agent as a mobile node, so >> that it cannot serve all mobile nodes attach to it. > > YEs, but it may be not necessary for attacker to create a Reply faking > the HA Reply, it is sufficient to forward a fake Request to HA and drop > the valid Request. > >> (2) Attacker spoofing DHAAD Request When attacker sniffs a mobile >> router sending a DHAAD Request(R-bit set 1), it replicate the >> message, change R-bit to 0 and send it to home agent. Then home agent >> would reply mobile node with two DHAAD Reply(one R-bit set 0, and >> the other R-bit set 1). > > Actually, I was seeing a more powerful attacker that would create a > brand new fake request (R-bit 0) and discard the valid Request (R-bit > 1), so only the fake Request hits the HA, so only the fake Reply hits > the MR. > >> If the Reply with R-bit 1 arrives the mobile node first, then >> everything is ok. But if the DHAAD Reply with R-bit 0 arrives first, >> then the mobile router has two choice: (a) Discard it. > > Yep, that's what the MR could do to realize there's error possible attack. > >> The problem is: when the only home agent that supports mobile router >> crashes, the mobile router cannot register with other home agent as a >> mobile node, or it takes long time to do this(the mobile router retry >> DHAAD unitl it achieves maximum attempts, then register as a mobile >> node.) > > That is a possibliity, I didn't think that far. > >> (b)Register as a mobile node. It cannot serve the mobile nodes attach >> to it. >> >> Based on above analysis, I think we should protect both DHAAD Request >> and Reply to prevent R-bit attack. > > Yes, I guess both should be protected somehow to protect against these > attacks. > > Alex > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 19:45:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10717 for ; Thu, 18 Nov 2004 19:45:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUwwN-0004N3-Cj for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 19:47:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUwmw-0000Xr-3g; Thu, 18 Nov 2004 19:38:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUwlJ-00008L-It for mip6@megatron.ietf.org; Thu, 18 Nov 2004 19:36:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09834 for ; Thu, 18 Nov 2004 19:36:24 -0500 (EST) Message-Id: <200411190036.TAA09834@ietf.org> Received: from mail1.lge.co.kr ([156.147.1.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUwo0-00049q-0u for mip6@ietf.org; Thu, 18 Nov 2004 19:39:17 -0500 Received: from [150.150.67.234] (eypark@lge.com) by mail1.lge.co.kr (Terrace MailWatcher) with ESMTP id 2004111909:32:09:517473.275.157 for ; Fri, 19 Nov 2004 09:32:09 +0900 (KST) From: =?ks_c_5601-1987?B?udrAur+1?= To: Date: Fri, 19 Nov 2004 09:35:42 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcTNz7wLH8NIYOrMTpSgFRaP0cY72wAACrhQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2742.200 X-TERRACE-SPAMRATE: Spacelee says NOT YET spam-rated. X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b55e50be03ae25e9a8d86e86275fb10 Content-Transfer-Encoding: 7bit Subject: [Mip6] RE: Mip6 Digest, Vol 7, Issue 23 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.8 (+) X-Scan-Signature: d115f8e98afb84ba4860c5c6ee611921 Content-Transfer-Encoding: 7bit -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] Sent: Friday, November 19, 2004 9:35 AM To: mip6@ietf.org Subject: Mip6 Digest, Vol 7, Issue 23 Send Mip6 mailing list submissions to mip6@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/mip6 or, via email, send a message with subject or body 'help' to mip6-request@ietf.org You can reach the person managing the list at mip6-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Mip6 digest..." Today's Topics: 1. Re: New I-D: Security Issues in Dynamic Home Agent AddressDiscovery (Alexandru Petrescu) 2. Re: New I-D: Security Issues in Dynamic Home Agent AddressDiscovery (Alexandru Petrescu) 3. Re: New I-D: Security Issues in Dynamic Home Agent AddressDiscovery (Alexandru Petrescu) 4. Re: New I-D: Security Issues in Dynamic Home Agent AddressDiscovery (Alexandru Petrescu) 5. Re: New I-D: Security Issues in Dynamic Home Agent AddressDiscovery (James Kempf) 6. RE: Mip6 Digest, Vol 7, Issue 21 (???) ---------------------------------------------------------------------- Message: 1 Date: Thu, 18 Nov 2004 22:50:23 +0100 From: Alexandru Petrescu Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery To: James Kempf Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au Message-ID: <419D191F.7020009@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed James Kempf wrote: > Alex, > > Many ISPs block ICMP James, as far as I can remember, one cellular ISP doesn't block ICMPv4 although NAT is in place and there is at least one other cellular ISP that does not do NAT. I will not dare however to make definitive statements about ISPs, cellular or otherwise. > below. The basic architectural thinking that went into DHAAD seems to > have been that home agent discovery on the Internet is analgous to > router discovery on the local link. I believe this thinking is not > accurate, as services are discovered in the Internet in ways that are > much different than locally in enterprise networks. If this thinking is not accurate, then MPD qualifies to same thinking: MPD is devised after router discovery on the local link too. > Personally, I think the WG will come up with a couple (but probably > not just one) It's good when there is choice. > techniques that are a better fit with the way wireless ISPs currently > operate, and therefore are more deployable. We've got a some good > drafts in this area, and the technical discussion seems to be > progressing along well. Again, I'll have to look at these. Alex ------------------------------ Message: 2 Date: Thu, 18 Nov 2004 23:02:05 +0100 From: Alexandru Petrescu Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery To: James Kempf Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au Message-ID: <419D1BDD.4040404@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Does this somehow mean that probably the DHAAD part of the NEMO BAsic Support suddenly becomes superfluous? This should be known... Alex James Kempf wrote: > Alex, > > Many ISPs block ICMP except on the local link, since it can be used for ping > attacks and also tends to cause increased traffic from backscatter during > worm scanning. Also, as the draft points out, there are security problems > with DHAAD, in addition to the issues with anycast that you point out below. > The basic architectural thinking that went into DHAAD seems to have been > that home agent discovery on the Internet is analgous to router discovery on > the local link. I believe this thinking is not accurate, as services are > discovered in the Internet in ways that are much different than locally in > enterprise networks. > > Personally, I think the WG will come up with a couple (but probably not just > one) techniques that are a better fit with the way wireless ISPs currently > operate, and therefore are more deployable. We've got a some good drafts in > this area, and the technical discussion seems to be progressing along well. > > jak > > > ----- Original Message ----- > From: "Alexandru Petrescu" > To: "James Kempf" > Cc: "Henrik Petander" ; ; > ; > Sent: Thursday, November 18, 2004 12:42 PM > Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent > AddressDiscovery > > > >>James Kempf wrote: >>[angels on a pin's top...] >> >>>Anyway, I think we are mostly arguing about how many angels can dance >>> on the head of a pin, since DHAAD does not seem to be a likely >>>candidate for deployment at this point. >> >>Do you know why is DHAAD not a candidate for deployment at this point? >>Is it because it is insecure? Should we secure it such as to be a >>candidate for deployment? Is it impossible to secure because of the >>difficulties IPsec/anycast? Maybe it is not needed to use IPsec/anycast >>in order to have it a little more secure, a little more deployable. Or >>has DHAAD been simply overlooked by people in need of urgent deployment? >> >> >>>The current bootstrapping work in mip6 is intended to replace DHAAD >>>and HoAD with something that the WG deems is more deployable. >> >>I don't think there is anything simpler and thus more deployable than: >>discover HA - get MPD - configure HoA. The keys? Pre-shared. I still >>have to figure out why people don't like them pre-shared here. >> >>I bet that other methods to do HA Discovery and HoA configuration will >>render not only DHAAD useless but also MPD. And, being new methods, >>they'll surely have their own new security risks. >> >>That said, it still makes sense to me to recognize in a written document >>that a certain procedure (DHAAD) in a Standards Track RFC is insecure. >>Somehow for completeness. Somehow as advice "don't do so". Whether it >>is worth the effort to secure it or not - is another question. A >>question which could be raised to the WG. >> >> >>>Alex's point, which ran towards "the difference is that the HA is >>>more like a router rather than a server" was more what I was looking >>>for. I don't see this point as necessarily being decisively >>>differentating, however, since it addresses the quality of the impact >>> for the attack rather than the mechanisms attackers use and >>>therefore the possible effective countermeasures, which is what I was >>>looking for. Based on impact, one could argue that an attack on a >>>medical server used by people daily with some chronic disease that >>>denied them access necessary for their health would have even more >>>impact, though the mechanism might be the same as used on cnn.com or >>>an HA. >> >>This sounds logic, all layer-3 mechanisms used for attack being equal >>the impact on layer-7 is also equal (be it health data or video >>entertainment). I could only argue that impact is also a sort of >>assessment of the size of the risk, and impact of a risky local DHCP is >>obviously lower than impact of a risky Internet-wide Mobile IPv6. I am >>not arguing the impact of a risky HL7, a protocol for the kind of health >>data you mention (IIRC). >> >>Note I still have to read the drafts you mentioned. >> >>Alex >> > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 ------------------------------ Message: 3 Date: Thu, 18 Nov 2004 23:06:01 +0100 From: Alexandru Petrescu Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery To: qsun300@cse.unsw.edu.au Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au Message-ID: <419D1CC9.9010006@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed qsun the 300th. Thanks for your reply. Could you please reveal your name so I can address you, thanks. Chairs, if I'm dancing on a pinus :-) please let me know if this effort is out of focus here, thanks. qsun300@cse.unsw.edu.au wrote: > Yes, R-bit attack is another DoS attack scenario. Since this draft > only focus on security issues in MIPv6, we don't mention R-bit attack > scenarion in this draft. Actually, I think, in order to prevent > R-bit attack, we should protect both DHAAD Request and DHAAD Reply. Yes, that's what I thought too, it's not enough to protect only the Reply. > In my understanding, R-bit attack can be performed in two means: (let > me know if I am not correct.thanks) (1) Attacker spoofing DHAAD > Reply When attacker sniffs a mobile router sending a DHAAD > Request(R-bit set 1), it replies a DHAAD Reply with R-bit set 0. The > mobile router would register with home agent as a mobile node, so > that it cannot serve all mobile nodes attach to it. YEs, but it may be not necessary for attacker to create a Reply faking the HA Reply, it is sufficient to forward a fake Request to HA and drop the valid Request. > (2) Attacker spoofing DHAAD Request When attacker sniffs a mobile > router sending a DHAAD Request(R-bit set 1), it replicate the > message, change R-bit to 0 and send it to home agent. Then home agent > would reply mobile node with two DHAAD Reply(one R-bit set 0, and > the other R-bit set 1). Actually, I was seeing a more powerful attacker that would create a brand new fake request (R-bit 0) and discard the valid Request (R-bit 1), so only the fake Request hits the HA, so only the fake Reply hits the MR. > If the Reply with R-bit 1 arrives the mobile node first, then > everything is ok. But if the DHAAD Reply with R-bit 0 arrives first, > then the mobile router has two choice: (a) Discard it. Yep, that's what the MR could do to realize there's error possible attack. > The problem is: when the only home agent that supports mobile router > crashes, the mobile router cannot register with other home agent as a > mobile node, or it takes long time to do this(the mobile router retry > DHAAD unitl it achieves maximum attempts, then register as a mobile > node.) That is a possibliity, I didn't think that far. > (b)Register as a mobile node. It cannot serve the mobile nodes attach > to it. > > Based on above analysis, I think we should protect both DHAAD Request > and Reply to prevent R-bit attack. Yes, I guess both should be protected somehow to protect against these attacks. Alex ------------------------------ Message: 4 Date: Thu, 18 Nov 2004 23:46:37 +0100 From: Alexandru Petrescu Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery To: James Kempf Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au Message-ID: <419D264D.8070006@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed James Kempf wrote: > The MN doesn't need a cert, only the routers on the home link, > including the HA if it sends RAs, do. The MN uses the CPS/CPA to > obtain the cert chain from the router, and the public key from the > router's cert to validate the signature on the RA. The attack was something like where the MN at home sends the fake RA to HAs, so the receiving HAs on the home link needed to make sure the content of that RA is valid such as _not_ to build fake HA lists. So if SEND were to help with this, would MN need a cert? So this is like true simple SEND on a simple unique link, not across tunnels. >> Also, I think that using SEND to protect DHAAD's RAs also involves >> using CGAs as options, but it is not clear to me whether RAs are >> an exception to this. >> > > > I don't know that SEND could be used to protect DHAAD since the > CPS/CPA is sent over ICMP and therefore subject to problems with > fragmentation if send over more than one link, since certs can be > large. Fragmentation is done by end nodes so more than one intermediary links is not an issue. The first link may be an issue, because the links following usually have larger MTUs (unless successive HAs get in the way, a la nested NEMO). But there's also reassembly, hopefully. > CGAs don't help here because the security issue is not authorization > to do something with an address (which is what CGAs provide) but > rather whether the router is authenticatable as certified by a > trusted root (and, additionally if deployed, whether the router is > authorized to route the subnet prefixes it is advertising). Ok, I understand that. What I was wondering was whether a MH on the home link can be recognized as sending fake RAs with the tool SEND that may use certs or CGA, and if yes, are both certs and CGAs needed? Would this involve that HoA must be a CGA. I hope not. > SEND might be used to protect RAs sent from the HA over the MN-HA > tunnel when the HA has the MN's CoA binding, but, again, provided the > MN already had the cert paths for the routers on the home link, due > to the issue with CPS/CPA fragmentation. I don't think fragmentation on such long paths is an issue because reassembly. I didn't think to send DHAAD messages (Req/Rep) through the tunnel. I wondered whether SEND can protect when a legitimate-and-attacker MN is at home. (legitimate: because it shares keys with HA but attacker because it attacks another MN, attack by forcing HA to send fake DHAAD Replies to MN). Alex ------------------------------ Message: 5 Date: Thu, 18 Nov 2004 15:05:40 -0800 From: "James Kempf" Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery To: "Alexandru Petrescu" Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au Message-ID: <029001c4cdc3$236820c0$0f6115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset="iso-8859-1" > The attack was something like where the MN at home sends the fake RA to > HAs, so the receiving HAs on the home link needed to make sure the > content of that RA is valid such as _not_ to build fake HA lists. So if > SEND were to help with this, would MN need a cert? If the MN doesn't have a certified asymmetric key pair, it can't generate a signature on the RA, thus the HAs would not accept the RA. > What I was wondering was whether a MH on the home link can be recognized > as sending fake RAs with the tool SEND that may use certs or CGA, and if > yes, are both certs and CGAs needed? Would this involve that HoA must > be a CGA. I hope not. > No, only certified asymmetric key pairs are needed and only on the HA. The HAs can recognize the fake RA, as can any other node on the home link. > I didn't think to send DHAAD messages (Req/Rep) through the tunnel. I > wondered whether SEND can protect when a legitimate-and-attacker MN is > at home. (legitimate: because it shares keys with HA but attacker > because it attacks another MN, attack by forcing HA to send fake DHAAD > Replies to MN). > I suppose one could put a SEND signature on the DHAAD message using the key pair certified by the router certificate. jak ------------------------------ Message: 6 Date: Fri, 19 Nov 2004 09:18:19 +0900 From: ??? Subject: [Mip6] RE: Mip6 Digest, Vol 7, Issue 21 To: Message-ID: <200411190018.TAA08138@ietf.org> Content-Type: text/plain; charset="ks_c_5601-1987" -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] Sent: Friday, November 19, 2004 2:23 AM To: mip6@ietf.org Subject: Mip6 Digest, Vol 7, Issue 21 Send Mip6 mailing list submissions to mip6@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/mip6 or, via email, send a message with subject or body 'help' to mip6-request@ietf.org You can reach the person managing the list at mip6-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Mip6 digest..." Today's Topics: 1. Re: New I-D: Security Issues in Dynamic Home Agent Address Discovery (Henrik Petander) 2. Re: New I-D: Security Issues in Dynamic Home Agent Address Discovery (Alexandru Petrescu) 3. Re: New I-D: Security Issues in Dynamic Home Agent AddressDiscovery (qsun300@cse.unsw.edu.au) ---------------------------------------------------------------------- Message: 1 Date: Thu, 18 Nov 2004 19:04:25 +1100 From: Henrik Petander Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent Address Discovery To: Alexandru Petrescu Cc: mip6@ietf.org, mahbub@cse.unsw.edu.au Message-ID: <419C5789.7040102@hut.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi Alex, Thanks for reading the security analysis of DHAAD part of the draft and commenting it. Alexandru Petrescu wrote: > lmux801@cse.unsw.edu.au wrote: > >> Here is a new I-D, Security Issues in Dynamic Home Agent Address >> Discovery. > > > In addition to the HA-DoS threat, I think (let me know if I'm wrong) > there are two others: (1) faking the HA List by attacker MN on home link > and (2) attacks on the R-bit of a NEMO DHAAD Reply. > > For (1), DHAAD relies on building of a HA list by HAs on the home link, > via the H-bit in their RAs. An attacker MN (one that is at home on the > home link where the legitimate HAs are) can send fake HAs to pretend to > be a HA, I think. Based on this fake RA, the legitimate HAs will build > attacking HA lists, that contain the attacker MN as the highest priority > HA (or pretending to support MRs while it doesn't). The end result of > this attack is that MN uses the attacker HA as a HA. Yes, if home link is also an access network, then this is a very relevant vulnerability, since an attacker only needs to be able to send packets on the home link. We focused on the MN-HA part of the protocol, but this could be added to the draft, since building of HA list can also be seen to be a part of the DHAAD protocol. Alex, would you be interested in adding a subsection to the protocol vulnerabilities part about this? If SEND is used on the home link then this vulnerability can be fixed, provided that the HAs only add HAs to their list RAs which are authenticated as coming from authorized routers. I am not sure about the relevance of the R-bit attack, but it could possibly be used to attack MR more subtly han sending just an empty list or a list with fake addresses, which depending on the implementation might be more effective. Thanks, Henrik ------------------------------ Message: 2 Date: Thu, 18 Nov 2004 15:50:03 +0100 From: Alexandru Petrescu Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent Address Discovery To: Henrik Petander Cc: mip6@ietf.org, mahbub@cse.unsw.edu.au Message-ID: <419CB69B.90809@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Henrik Petander wrote: >> For (1), DHAAD relies on building of a HA list by HAs on the home >> link, via the H-bit in their RAs. An attacker MN (one that is at >> home on the home link where the legitimate HAs are) can send fake >> HAs to pretend to be a HA, I think. Based on this fake RA, the >> legitimate HAs will build attacking HA lists, that contain the >> attacker MN as the highest priority HA (or pretending to support >> MRs while it doesn't). The end result of this attack is that MN >> uses the attacker HA as a HA. > > > Yes, if home link is also an access network, then this is a very > relevant vulnerability, since an attacker only needs to be able to > send packets on the home link. We focused on the MN-HA part of the > protocol, but this could be added to the draft, since building of HA > list can also be seen to be a part of the DHAAD protocol. Alex, would > you be interested in adding a subsection to the protocol > vulnerabilities part about this? Sure, you need a paragraph, a two-three paragraphs? How would you title it? > If SEND is used on the home link then this vulnerability can be > fixed, provided that the HAs only add HAs to their list RAs which are > authenticated as coming from authorized routers. I went back to read SEND. It somehow relies on routers (those who send RAs) be leading to "Trust Anchors" i.e. use Certificates; this implies to me that if we want to prevent MN from sending fake RAs on the home link then MN should use certs, or at least HAs use certs before building the HA lists. Also, I think that using SEND to protect DHAAD's RAs also involves using CGAs as options, but it is not clear to me whether RAs are an exception to this. Finally, outside SEND, the MN and the HA do share a key, and it would be risky for HA to rely on that key when receiving RAs from MN at home. > I am not sure about the relevance of the R-bit attack, but it could > possibly be used to attack MR more subtly han sending just an empty > list or a list with fake addresses, which depending on the > implementation might be more effective. The attack on R-bit looks to me like an exemplification of more than just denying HA service to a MH. An attacker could just zero the bit once and thus deny all service to LFNs but not to MR itself, there is no need to fake other addresses in the DHAAD Reply or to block all packets from HA to MR. And yes, depends on the implementation a lot. Alex ------------------------------ Message: 3 Date: Fri, 19 Nov 2004 02:58:52 +1100 (EST) From: qsun300@cse.unsw.edu.au Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery To: "Henrik Petander" Cc: mip6@ietf.org, mahbub@cse.unsw.edu.au, Alexandru Petrescu Message-ID: <61299.220.237.11.186.1100793532.squirrel@webmail.cse.unsw.edu.au> Content-Type: text/plain;charset=iso-8859-1 > Hi Alex, > > Thanks for reading the security analysis of DHAAD part of the draft and > commenting it. > > Alexandru Petrescu wrote: >> lmux801@cse.unsw.edu.au wrote: >> >>> Here is a new I-D, Security Issues in Dynamic Home Agent Address >>> Discovery. >> >> >> In addition to the HA-DoS threat, I think (let me know if I'm wrong) >> there are two others: (1) faking the HA List by attacker MN on home link >> and (2) attacks on the R-bit of a NEMO DHAAD Reply. >> Yes, R-bit attack is another DoS attack scenario. Since this draft only focus on security issues in MIPv6, we don't mention R-bit attack scenarion in this draft. Actually, I think, in order to prevent R-bit attack, we should protect both DHAAD Request and DHAAD Reply. Solution 2 in the draft can be easily extended to protect R-bit attack. In my understanding, R-bit attack can be performed in two means: (let me know if I am not correct.thanks) (1) Attacker spoofing DHAAD Reply When attacker sniffs a mobile router sending a DHAAD Request(R-bit set 1), it replies a DHAAD Reply with R-bit set 0. The mobile router would register with home agent as a mobile node, so that it cannot serve all mobile nodes attach to it. (2) Attacker spoofing DHAAD Request When attacker sniffs a mobile router sending a DHAAD Request(R-bit set 1), it replicate the message, change R-bit to 0 and send it to home agent. Then home agent would reply mobile node with two DHAAD Reply(one R-bit set 0, and the other R-bit set 1). If the Reply with R-bit 1 arrives the mobile node first, then everything is ok. But if the DHAAD Reply with R-bit 0 arrives first, then the mobile router has two choice: (a) Discard it. The problem is: when the only home agent that supports mobile router crashes, the mobile router cannot register with other home agent as a mobile node, or it takes long time to do this(the mobile router retry DHAAD unitl it achieves maximum attempts, then register as a mobile node.) (b)Register as a mobile node. It cannot serve the mobile nodes attach to it. Based on above analysis, I think we should protect both DHAAD Request and Reply to prevent R-bit attack. Thanks for your comments. >> For (1), DHAAD relies on building of a HA list by HAs on the home link, >> via the H-bit in their RAs. An attacker MN (one that is at home on the >> home link where the legitimate HAs are) can send fake HAs to pretend to >> be a HA, I think. Based on this fake RA, the legitimate HAs will build >> attacking HA lists, that contain the attacker MN as the highest priority >> HA (or pretending to support MRs while it doesn't). The end result of >> this attack is that MN uses the attacker HA as a HA. > > Yes, if home link is also an access network, then this is a very > relevant vulnerability, since an attacker only needs to be able to send > packets on the home link. We focused on the MN-HA part of the protocol, > but this could be added to the draft, since building of HA list can also > be seen to be a part of the DHAAD protocol. Alex, would you be > interested in adding a subsection to the protocol vulnerabilities part > about this? > > If SEND is used on the home link then this vulnerability can be fixed, > provided that the HAs only add HAs to their list RAs which are > authenticated as coming from authorized routers. > > I am not sure about the relevance of the R-bit attack, but it could > possibly be used to attack MR more subtly han sending just an empty list > or a list with fake addresses, which depending on the implementation > might be more effective. > > Thanks, > > Henrik > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > ------------------------------ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 End of Mip6 Digest, Vol 7, Issue 21 *********************************** ------------------------------ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 End of Mip6 Digest, Vol 7, Issue 23 *********************************** _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 20:16:28 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13073 for ; Thu, 18 Nov 2004 20:16:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUxQl-0004y3-9j for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 20:19:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUxLm-0001iQ-K0; Thu, 18 Nov 2004 20:14:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUxGZ-0008Fo-Ob for mip6@megatron.ietf.org; Thu, 18 Nov 2004 20:08:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12514 for ; Thu, 18 Nov 2004 20:08:45 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUxJI-0004of-Qn for mip6@ietf.org; Thu, 18 Nov 2004 20:11:37 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Nov 2004 20:08:15 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] New I-D: Security Issues in Dynamic Home AgentAddressDiscovery Date: Thu, 18 Nov 2004 20:08:14 -0500 Message-ID: Thread-Topic: [Mip6] New I-D: Security Issues in Dynamic Home AgentAddressDiscovery Thread-Index: AcTNtxLIFYQP/R0jTaOjkKe9B48dEgAHPj0Q From: "Soliman, Hesham" To: "Alexandru Petrescu" , "James Kempf" X-OriginalArrivalTime: 19 Nov 2004 01:08:15.0117 (UTC) FILETIME=[3F4083D0:01C4CDD4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable I'm trying to follow this discussion to understand what=20 the threats are. Apart from a DoS attack on the mobile, is=20 there anything we need to worry about here? I really don't see a reason for securing DHAAD. The same type of active attacks can be applied on authentic messages to DoS the MN.. Hesham > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On=20 > Behalf Of > Alexandru Petrescu > Sent: Thursday, November 18, 2004 3:42 PM > To: James Kempf > Cc: mip6@ietf.org; Henrik Petander; mahbub@cse.unsw.edu.au > Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home > AgentAddressDiscovery >=20 >=20 > James Kempf wrote: > [angels on a pin's top...] > > Anyway, I think we are mostly arguing about how many=20 > angels can dance > > on the head of a pin, since DHAAD does not seem to be a likely=20 > > candidate for deployment at this point. >=20 > Do you know why is DHAAD not a candidate for deployment at=20 > this point? > Is it because it is insecure? Should we secure it such as to be a > candidate for deployment? Is it impossible to secure because of the=20 > difficulties IPsec/anycast? Maybe it is not needed to use=20 > IPsec/anycast=20 > in order to have it a little more secure, a little more=20 > deployable. Or=20 > has DHAAD been simply overlooked by people in need of urgent=20 > deployment? >=20 > > The current bootstrapping work in mip6 is intended to=20 > replace DHAAD > > and HoAD with something that the WG deems is more deployable. >=20 > I don't think there is anything simpler and thus more=20 > deployable than:=20 > discover HA - get MPD - configure HoA. The keys? =20 > Pre-shared. I still=20 > have to figure out why people don't like them pre-shared here. >=20 > I bet that other methods to do HA Discovery and HoA=20 > configuration will=20 > render not only DHAAD useless but also MPD. And, being new methods,=20 > they'll surely have their own new security risks. >=20 > That said, it still makes sense to me to recognize in a=20 > written document > that a certain procedure (DHAAD) in a Standards Track RFC is=20 > insecure. > Somehow for completeness. Somehow as advice "don't do so". =20 > Whether it > is worth the effort to secure it or not - is another question. A > question which could be raised to the WG. >=20 > > Alex's point, which ran towards "the difference is that the HA is=20 > > more like a router rather than a server" was more what I=20 > was looking=20 > > for. I don't see this point as necessarily being decisively=20 > > differentating, however, since it addresses the quality of=20 > the impact > > for the attack rather than the mechanisms attackers use and > > therefore the possible effective countermeasures, which is=20 > what I was > > looking for. Based on impact, one could argue that an attack on a > > medical server used by people daily with some chronic disease that > > denied them access necessary for their health would have even more > > impact, though the mechanism might be the same as used on=20 > cnn.com or > > an HA. >=20 > This sounds logic, all layer-3 mechanisms used for attack=20 > being equal=20 > the impact on layer-7 is also equal (be it health data or video > entertainment). I could only argue that impact is also a sort of > assessment of the size of the risk, and impact of a risky=20 > local DHCP is > obviously lower than impact of a risky Internet-wide Mobile=20 > IPv6. I am > not arguing the impact of a risky HL7, a protocol for the=20 > kind of health > data you mention (IIRC). >=20 > Note I still have to read the drafts you mentioned. >=20 > Alex >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 18 22:03:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22022 for ; Thu, 18 Nov 2004 22:03:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUz6I-0007PP-Pg for mip6-web-archive@ietf.org; Thu, 18 Nov 2004 22:06:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUyxJ-0000O2-9T; Thu, 18 Nov 2004 21:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUytP-0007bk-Vb for mip6@megatron.ietf.org; Thu, 18 Nov 2004 21:53:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21092 for ; Thu, 18 Nov 2004 21:52:57 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUyw8-00078B-6X for mip6@ietf.org; Thu, 18 Nov 2004 21:55:49 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 47C474C0BA; Fri, 19 Nov 2004 11:52:11 +0900 (JST) Date: Fri, 19 Nov 2004 11:55:03 +0900 From: Thierry Ernst To: mip6@ietf.org Subject: Re: [Mip6] FW: MIP6 agenda (Final) Message-Id: <20041119115503.4978b37f.ernst@sfc.wide.ad.jp> In-Reply-To: <419CEC8F.F29126E0@iprg.nokia.com> References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> <419CEC8F.F29126E0@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: rajeev@iprg.nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Dear Rajeev, Mobopts is a reseach group (IRTF), the problem that we want to solve is much more clarified clarified than that, and solutions could be brought in a timely manner if we restrict ourselves to part of the exisiting problems and extensions to MIP6 and NEMO. Of course, taking a look at the whole picture would require much more consideration, and for the whole picture Mobopts could be the right place. But, my intention, right now, is not to open the pendora box; it's rather about bringing a solution to an immediate concern, in a timely manner: how can I make use of my MIP6/NEMO function when I have multiple interfaces on my MH/MR ? I can't do it right now, and not because it's np complex, but because there is no agreed solution between the parties involved. Regarding what has been said at the MIP6 meeting, taking into account the feedback from Erik, Thomas, and all the other, I would go for a BOF at next IETF, but not with the objective to set up a new WG, but just a one-time BOF to discuss the problem thoroughly. But, prior to doing that, the other people involved with me on the problem statement drafts, we should improve/clarify/extend our drafts. The target would be end of this year; based on new drafts we would consider setting up a BOF or not. (OK, guys, now we have pressure on our shoulders ;-) Thierry On Thu, 18 Nov 2004 10:40:15 -0800 Rajeev Koodli wrote: > Thierry Ernst wrote: > > > > Thus embarking on QoS sensitive, mobility specific multihoming support > > > is both too open ended (on the QoS side) and too constraining (by only > > > looking at cases when MIP/Nemo is used). > > > > > > So I think it would be useful for folks to try to think about and > > > discuss the bigger picture. > > > > Agree. But then, where should this discussion take place ? MIP6 WG ? > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > I would add to Erik's observation that we need to be able to assess a topic to > see > the maturity of the problem and the state of solutions, as well as what could > be standardized in IETF. The IETF should work on well-defined _and_ > well-agreed problems for which protocol specification could be accomplished > in a timely manner. Topics where the problem needs to be crystalized, and > solution > space needs "thinking" require a forum for discussion. And, MobOpts could > be such a place. > > We (mip*, MobOpts co-chairs) are in the process of working out a model to > facilitate closer co-operation between mip* groups and MobOpts. The outcome > should be focussed discussion on topics of mutual interest that lead to > documents > which can be a) taken up in mip* groups for standardization, b) MobOpts RG > RFCs. MobOpts would run milestones and try to produce documents within a > timeframe of interest to mip* groups. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 19 01:52:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11425 for ; Fri, 19 Nov 2004 01:52:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV2ft-0003tW-Q9 for mip6-web-archive@ietf.org; Fri, 19 Nov 2004 01:55:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV2a1-00060L-8a; Fri, 19 Nov 2004 01:49:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV2YH-0005cO-Ta for mip6@megatron.ietf.org; Fri, 19 Nov 2004 01:47:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11139 for ; Fri, 19 Nov 2004 01:47:24 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV2b3-0003nE-Km for mip6@ietf.org; Fri, 19 Nov 2004 01:50:18 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iAJ6kmx06299; Fri, 19 Nov 2004 08:46:49 +0200 Date: Fri, 19 Nov 2004 08:46:48 +0200 (EET) From: Pekka Savola To: mip6@ietf.org Subject: Re: [Mip6] I-D: draft-ietf-mip6-auth-protocol to progress on Informational track In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1C1AF@daebe007.americas.nokia.com> Message-ID: References: <697DAA22C5004B4596E033803A7CEF4403B1C1AF@daebe007.americas.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: narten@us.ibm.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Hi, On Thu, 18 Nov 2004 Basavaraj.Patil@nokia.com wrote: > There was an appeal to the consensus call made by the chairs w.r.t the > status of progressing the Auth I-D [draft-ietf-mip6-auth-protocol-00] > on standards track. The appeal details are at: > http://www1.ietf.org/mail-archive/web/mip6/current/msg01937.html [...] > The conclusion drawn from the discussion is that the consensus in the > WG is to progress the I-D on an Informational track. > > Consequently, the Auth-ID will now proceed in the WG towards > publication as an Informational RFC. I am happy with this resolution, and I withdraw my appeal. Thanks! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 19 06:13:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17048 for ; Fri, 19 Nov 2004 06:13:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV6kp-000160-Um for mip6-web-archive@ietf.org; Fri, 19 Nov 2004 06:16:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV6gc-0005T8-7o; Fri, 19 Nov 2004 06:12:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV6e0-0004V4-GU for mip6@megatron.ietf.org; Fri, 19 Nov 2004 06:09:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16686 for ; Fri, 19 Nov 2004 06:09:34 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV6go-000113-4M for mip6@ietf.org; Fri, 19 Nov 2004 06:12:31 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAJBB0Nu023383; Fri, 19 Nov 2004 04:11:01 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id iAJB9QGa021320; Fri, 19 Nov 2004 05:09:27 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 65FE88A3C6C; Fri, 19 Nov 2004 12:09:26 +0100 (CET) Message-ID: <419DD464.8050406@motorola.com> Date: Fri, 19 Nov 2004 12:09:24 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: qsun300@cse.unsw.edu.au Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home Agent AddressDiscovery References: <50213.129.94.208.239.1100569941.squirrel@webmail.cse.unsw.edu.au><419A09E1.5040603@motorola.com> <419C5789.7040102@hut.fi> <61299.220.237.11.186.1100793532.squirrel@webmail.cse.unsw.edu.au> <419D1CC9.9010006@motorola.com> <61369.220.237.11.186.1100823631.squirrel@webmail.cse.unsw.edu.au> In-Reply-To: <61369.220.237.11.186.1100823631.squirrel@webmail.cse.unsw.edu.au> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit qsun300@cse.unsw.edu.au wrote: > Thanks for your comments. > > You mentioned "drop the valid Request", however I think it requires the > attacker sit in the middle of mobile router and home agent. I think it > would be difficult to do this. On the other hand, if the attacker sits in > the middle between the mobile router and home agent, it can definitly > perform DoS attack no matter what kind protection is adopted(even you use > IPSec, the attacker can drop IKE messages, SA cannot setup). So the attack > scenarios I mentioned assumes the attacker is in the same foreign link > with mobile router. That would be very easy. And the attack is still quite > significant. I agree. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 19 06:47:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20045 for ; Fri, 19 Nov 2004 06:47:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV7HJ-0001nc-8t for mip6-web-archive@ietf.org; Fri, 19 Nov 2004 06:50:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV74j-00037y-Og; Fri, 19 Nov 2004 06:37:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV70n-0002UT-FA for mip6@megatron.ietf.org; Fri, 19 Nov 2004 06:33:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18694 for ; Fri, 19 Nov 2004 06:33:06 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV73c-0001Vo-4k for mip6@ietf.org; Fri, 19 Nov 2004 06:36:04 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAJBYTNu011843; Fri, 19 Nov 2004 04:34:30 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id iAJBVdMU014606; Fri, 19 Nov 2004 05:31:39 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 54DE38A3C70; Fri, 19 Nov 2004 12:32:55 +0100 (CET) Message-ID: <419DD9E6.8020702@motorola.com> Date: Fri, 19 Nov 2004 12:32:54 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home AgentAddressDiscovery References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, James Kempf , Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Soliman, Hesham wrote: > I'm trying to follow this discussion to understand what the threats > are. Apart from a DoS attack on the mobile, is there anything we need > to worry about here? The "DoS attack on the mobile" that you mention has been dissected into: denying HA service to the MN, building fake HA lists in the home link by a legitimate-attacker MN, denying processing power capabilities on the HA (if Requests were protected, HA would not process fake Requests), denying HA service to LFN-behind-MR (but not to MR itself). The attacks do depend a lot on the capabilities of the attacker. Also, a packet that is dropped by a machine because it fails authentication takes much less processing power on that machine than if it were processed by the upper layer of the stack eventually followed by generating new packets and sent on the wire. So, authentication still helps a lot to protect against DoS. Except DoS should be better defined when we talk about it :-) There is DoS that nobody and nothing can protect against when one unplugs a level 9 cable. > I really don't see a reason for securing DHAAD. The reason would be to enable a simple Home Address autoconfiguration mechanism, whose components are already defined in RFC 3775 (DHAAD+MPD). > The same type of active attacks can be applied on authentic messages > to DoS the MN.. A certain attack on the home link by legitimate-attacker MN (the one that contributes building fake HA lists, "legitimate" because holds IPsec keys with HA but simultaneously "attacker" because sends fake RAs on the home link) can not be applied on authentic messages. If the messages were authentic (HA verifies the authenticity) then the legitimate MN (the remote one) would not be denied HA service. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 19 08:44:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01587 for ; Fri, 19 Nov 2004 08:44:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV96L-0004fU-2m for mip6-web-archive@ietf.org; Fri, 19 Nov 2004 08:47:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV8v5-00038N-8H; Fri, 19 Nov 2004 08:35:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CV8mW-0001OD-Tc for mip6@megatron.ietf.org; Fri, 19 Nov 2004 08:26:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29748 for ; Fri, 19 Nov 2004 08:26:31 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CV8pL-0004Gi-KO for mip6@ietf.org; Fri, 19 Nov 2004 08:29:29 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 19 Nov 2004 06:30:54 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAJDPt3O006387; Fri, 19 Nov 2004 05:25:55 -0800 (PST) Received: from [10.10.10.17] (sjc-vpn1-197.cisco.com [10.21.96.197]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id AZD41711; Fri, 19 Nov 2004 05:31:36 -0800 (PST) Message-ID: <419DF463.1080304@cisco.com> Date: Fri, 19 Nov 2004 05:25:55 -0800 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Subject: Re: [Mip6] I-D: draft-ietf-mip6-auth-protocol to progress on Informational track References: <697DAA22C5004B4596E033803A7CEF4403B1C1AF@daebe007.americas.nokia.com> In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1C1AF@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Raj - So, just to clarify, the Mobile Node Identifier (NAI/IMSI etc) draft is still standards track? Rgds -a Basavaraj.Patil@nokia.com wrote: >Hello, > >There was an appeal to the consensus call made by the chairs w.r.t the >status of progressing the Auth I-D [draft-ietf-mip6-auth-protocol-00] >on standards track. The appeal details are at: >http://www1.ietf.org/mail-archive/web/mip6/current/msg01937.html > >The MIP6 Working group discussed this issue at the WG meeting at >IETF61. There were plenty of arguments about the pros and cons of >standardizing an alternate mechanism for securing the BU/BAck between >the MN and HA. At the end of the discussion, the room was queried on >how to proceed with this I-D. >The options for progress were: >1. Not publish this I-D at all > No hands raised to support this option. >2. Progress the I-D on standards track > Several hands supporting this option (about 9) >3. Progress the I-D on Informational track > Many more hands (about 30) > >The conclusion drawn from the discussion is that the consensus in the >WG is to progress the I-D on an Informational track. > >Consequently, the Auth-ID will now proceed in the WG towards >publication as an Informational RFC. > >-Basavaraj > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 19 11:43:50 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19733 for ; Fri, 19 Nov 2004 11:43:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVBuM-0000Xk-Mx for mip6-web-archive@ietf.org; Fri, 19 Nov 2004 11:46:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVBoC-0003IG-Rf; Fri, 19 Nov 2004 11:40:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVBgc-0000vX-7y for mip6@megatron.ietf.org; Fri, 19 Nov 2004 11:32:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18368 for ; Fri, 19 Nov 2004 11:32:35 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVBjT-0000BN-8V for mip6@ietf.org; Fri, 19 Nov 2004 11:35:35 -0500 Message-ID: <02f901c4ce55$810afee0$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Thierry Ernst" , References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com><20041111123630.1be973c6.ernst@sfc.wide.ad.jp><4193C2B2.5050200@sun.com><20041112061543.0a263a00.ernst@sfc.wide.ad.jp><419CEC8F.F29126E0@iprg.nokia.com> <20041119115503.4978b37f.ernst@sfc.wide.ad.jp> Subject: Re: [Mip6] FW: MIP6 agenda (Final) Date: Fri, 19 Nov 2004 08:33:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: rajeev@iprg.nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Thierry, Are there any vendors interested in implementing this solution and/or network operators interested in deploying it (note: I'm not asking for detailed product plans, just the kind of committment that was given in, say, the chartering discussion of the Mobike WG several IETFs ago)? Or other standardization bodies (such as our good friends at 3GPP2) who are interested in incorporating it into their standards? jak PS: BTW, if you haven't seen it, you should check out the literature on Boeing's Connexion system. It uses BGP to manage routes to a mobile 802.11 network in an airplane on a transcontinental flight. Lufthasa has deployed it on their new A333-600's. ----- Original Message ----- From: "Thierry Ernst" To: Cc: Sent: Thursday, November 18, 2004 6:55 PM Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > Dear Rajeev, > > Mobopts is a reseach group (IRTF), the problem that we want to solve is > much more clarified clarified than that, and solutions could be brought > in a timely manner if we restrict ourselves to part of the exisiting > problems and extensions to MIP6 and NEMO. > > Of course, taking a look at the whole picture would require much more > consideration, and for the whole picture Mobopts could be the right > place. But, my intention, right now, is not to open the pendora box; > it's rather about bringing a solution to an immediate concern, in a > timely manner: how can I make use of my MIP6/NEMO function when I have > multiple interfaces on my MH/MR ? I can't do it right now, and not > because it's np complex, but because there is no agreed solution between > the parties involved. > > Regarding what has been said at the MIP6 meeting, taking into account > the feedback from Erik, Thomas, and all the other, I would go for a BOF > at next IETF, but not with the objective to set up a new WG, but just a > one-time BOF to discuss the problem thoroughly. > > But, prior to doing that, the other people involved with me on the > problem statement drafts, we should improve/clarify/extend our drafts. > The target would be end of this year; based on new drafts we would > consider setting up a BOF or not. (OK, guys, now we have pressure on our > shoulders ;-) > > Thierry > > > > On Thu, 18 Nov 2004 10:40:15 -0800 > Rajeev Koodli wrote: > > > Thierry Ernst wrote: > > > > > > Thus embarking on QoS sensitive, mobility specific multihoming support > > > > is both too open ended (on the QoS side) and too constraining (by only > > > > looking at cases when MIP/Nemo is used). > > > > > > > > So I think it would be useful for folks to try to think about and > > > > discuss the bigger picture. > > > > > > Agree. But then, where should this discussion take place ? MIP6 WG ? > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > I would add to Erik's observation that we need to be able to assess a topic to > > see > > the maturity of the problem and the state of solutions, as well as what could > > be standardized in IETF. The IETF should work on well-defined _and_ > > well-agreed problems for which protocol specification could be accomplished > > in a timely manner. Topics where the problem needs to be crystalized, and > > solution > > space needs "thinking" require a forum for discussion. And, MobOpts could > > be such a place. > > > > We (mip*, MobOpts co-chairs) are in the process of working out a model to > > facilitate closer co-operation between mip* groups and MobOpts. The outcome > > should be focussed discussion on topics of mutual interest that lead to > > documents > > which can be a) taken up in mip* groups for standardization, b) MobOpts RG > > RFCs. MobOpts would run milestones and try to produce documents within a > > timeframe of interest to mip* groups. > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 19 11:48:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20137 for ; Fri, 19 Nov 2004 11:48:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVByY-0000eM-Ea for mip6-web-archive@ietf.org; Fri, 19 Nov 2004 11:51:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVBuR-0004tO-OR; Fri, 19 Nov 2004 11:46:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVBpu-0003sa-2u for mip6@megatron.ietf.org; Fri, 19 Nov 2004 11:42:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19455 for ; Fri, 19 Nov 2004 11:42:11 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVBsk-0000So-TG for mip6@ietf.org; Fri, 19 Nov 2004 11:45:11 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Nov 2004 11:41:36 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] New I-D: Security Issues in Dynamic Home AgentAddressDiscovery Date: Fri, 19 Nov 2004 11:41:36 -0500 Message-ID: Thread-Topic: [Mip6] New I-D: Security Issues in Dynamic Home AgentAddressDiscovery Thread-Index: AcTOK4ov1tQjnpj2TFS5TMBr5yNM6AAKrBmA From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 19 Nov 2004 16:41:36.0757 (UTC) FILETIME=[A2D4A250:01C4CE56] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, James Kempf , Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable > > I'm trying to follow this discussion to understand what=20 > the threats=20 > > are. Apart from a DoS attack on the mobile, is there=20 > anything we need > > to worry about here? >=20 > The "DoS attack on the mobile" that you mention has been=20 > dissected into: > denying HA service to the MN, building fake HA lists in=20 > the home link > by a legitimate-attacker MN, denying processing power capabilities on > the HA (if Requests were protected, HA would not process=20 > fake Requests), > denying HA service to LFN-behind-MR (but not to MR itself). >=20 > The attacks do depend a lot on the capabilities of the attacker. >=20 > Also, a packet that is dropped by a machine because it fails > authentication takes much less processing power on that=20 > machine than if > it were processed by the upper layer of the stack eventually=20 > followed by > generating new packets and sent on the wire. =20 =3D> We're talking about communication between the MN and HA. What upper layers are involved here? If something modifies the BU on the way it will not affect upper layers. So,=20 > authentication still > helps a lot to protect against DoS. =20 =3D> Not the kind of DoS (actively modifying a packet) being discussed here. > > I really don't see a reason for securing DHAAD. >=20 > The reason would be to enable a simple Home Address autoconfiguration > mechanism, whose components are already defined in RFC 3775=20 > (DHAAD+MPD). =3D> Please separate DHAAD from MPD. MPD can be protected today. DHAAD is not and need not IMO. Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 19 13:11:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27903 for ; Fri, 19 Nov 2004 13:11:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVDGs-0002lE-1d for mip6-web-archive@ietf.org; Fri, 19 Nov 2004 13:14:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVDBL-0002iQ-Qi; Fri, 19 Nov 2004 13:08:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVD9E-0001XV-Cf for mip6@megatron.ietf.org; Fri, 19 Nov 2004 13:06:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27340 for ; Fri, 19 Nov 2004 13:06:13 -0500 (EST) Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVDC3-0002cP-99 for mip6@ietf.org; Fri, 19 Nov 2004 13:09:14 -0500 Received: from az33exr04.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (Motorola/Motgate) with ESMTP id iAJI5qtQ016702; Fri, 19 Nov 2004 11:05:53 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (Motorola/az33exr04) with ESMTP id iAJG5LTp026990; Fri, 19 Nov 2004 10:05:21 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id DA42E8A3C6C; Fri, 19 Nov 2004 19:05:49 +0100 (CET) Message-ID: <419E35FD.8050403@motorola.com> Date: Fri, 19 Nov 2004 19:05:49 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home AgentAddressDiscovery References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, James Kempf , Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Soliman, Hesham wrote: >> Also, a packet that is dropped by a machine because it fails >> authentication takes much less processing power on that machine >> than if it were processed by the upper layer of the stack >> eventually followed by generating new packets and sent on the wire. >> >> >> > => We're talking about communication between the MN and HA. What > upper layers are involved here? If something modifies the BU on the > way it will not affect upper layers. I meant "upper" not "uppermost". An IPv6 stack does some IPsec checks when receiving a packet. It drops them if checks fail, thus upper-above-ipsec layers (not necessarily L7, but still above) are not submitted, thus less processing. An attacker sending fake DHAAD Requests to HA provokes that HA to process the Request a bit upper than IPsec, but still below L7, and even generate replies back and overload o wire. If the DHAAD Req were protected somehow then no fake Rep generated, less load on the network. Some people call these aspects "bombing" or "reflection" or DDoS or similar. > So, >> authentication still helps a lot to protect against DoS. > > => Not the kind of DoS (actively modifying a packet) being discussed > here. I think that here we discuss both actively in-path intercepting, modifying and dropping packets, and also an attacker that can send any packet and not be subject to ingress filtering rules. It is true that DHAAD is subject to a range of DoS attacks to which no security mechanism can provide total protection (active on-path), but it is also true that DHAAD opens up new risks ("HA reflection" if you wish) to which protection _is_ possible, with known methods. And it is also true that _without_ DHAAD the network is more secure, as it is true that a network without _any_ protocol is more secure. >>> I really don't see a reason for securing DHAAD. >> >> The reason would be to enable a simple Home Address >> autoconfiguration mechanism, whose components are already defined >> in RFC 3775 (DHAAD+MPD). > > => Please separate DHAAD from MPD. MPD can be protected today. DHAAD > is not and need not IMO. Yes, I agree to keep them separated. DHAAD serves mostly to discover the HA, maybe when MN powers up while MPD serves mostly to get its address remade up when the prefixes on the home link change, every three months or so. They're separated now, ok? (they're still both ICMP :-) MPD can be protected today and should be; actually the spec it says it is. DHAAD can also be protected. If you think it needs not to be protected, then fine, I'm ok to know. If both DHAAD and MPD are protected and if MN uses the prefix in the MPD to initially configure its Home Address then we can say that DHAAD+MPD is a method to remotely and securely autoconfigure a HA address and a Home Address. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 19 14:18:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03696 for ; Fri, 19 Nov 2004 14:18:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVEK2-0004J2-3L for mip6-web-archive@ietf.org; Fri, 19 Nov 2004 14:21:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVE3e-0007li-SY; Fri, 19 Nov 2004 14:04:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVDxh-0005tQ-4S for mip6@megatron.ietf.org; Fri, 19 Nov 2004 13:58:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01870 for ; Fri, 19 Nov 2004 13:58:24 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVE0Z-0003mB-Td for mip6@ietf.org; Fri, 19 Nov 2004 14:01:24 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iAJITdG03377; Fri, 19 Nov 2004 10:29:39 -0800 X-mProtect: <200411191829> Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90) by darkstar.iprg.nokia.com smtpd1p3dZC; Fri, 19 Nov 2004 10:29:36 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by rajeev.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id KAA64646; Fri, 19 Nov 2004 10:57:33 -0800 (PST) Message-ID: <419E421D.BF063AA2@iprg.nokia.com> Date: Fri, 19 Nov 2004 10:57:33 -0800 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: Thierry Ernst Subject: Re: [Mip6] FW: MIP6 agenda (Final) References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> <419CEC8F.F29126E0@iprg.nokia.com> <20041119115503.4978b37f.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajeev@iprg.nokia.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Hi Thierry, Thierry Ernst wrote: > Dear Rajeev, > > Mobopts is a reseach group (IRTF), the problem that we want to solve is > much more clarified clarified than that, and solutions could be brought > in a timely manner if we restrict ourselves to part of the exisiting > problems and extensions to MIP6 and NEMO. > This seems to imply that Mobopts cannot produce documents in a timely manner. If so, I would like to encourage you to think otherwise. We would be enforcing milestones and deadlines, and produce documents which the IETF working groups find useful. Sorry I left out NEMO in my previous message. > > Of course, taking a look at the whole picture would require much more > consideration, and for the whole picture Mobopts could be the right > place. But, my intention, right now, is not to open the pendora box; > What is the pandora's box? I think understanding the host multi-homing and mobility is an important area before we can standardize things. -Rajeev > it's rather about bringing a solution to an immediate concern, in a > timely manner: how can I make use of my MIP6/NEMO function when I have > multiple interfaces on my MH/MR ? I can't do it right now, and not > because it's np complex, but because there is no agreed solution between > the parties involved. > > Regarding what has been said at the MIP6 meeting, taking into account > the feedback from Erik, Thomas, and all the other, I would go for a BOF > at next IETF, but not with the objective to set up a new WG, but just a > one-time BOF to discuss the problem thoroughly. > > But, prior to doing that, the other people involved with me on the > problem statement drafts, we should improve/clarify/extend our drafts. > The target would be end of this year; based on new drafts we would > consider setting up a BOF or not. (OK, guys, now we have pressure on our > shoulders ;-) > > Thierry > > On Thu, 18 Nov 2004 10:40:15 -0800 > Rajeev Koodli wrote: > > > Thierry Ernst wrote: > > > > > > Thus embarking on QoS sensitive, mobility specific multihoming support > > > > is both too open ended (on the QoS side) and too constraining (by only > > > > looking at cases when MIP/Nemo is used). > > > > > > > > So I think it would be useful for folks to try to think about and > > > > discuss the bigger picture. > > > > > > Agree. But then, where should this discussion take place ? MIP6 WG ? > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > I would add to Erik's observation that we need to be able to assess a topic to > > see > > the maturity of the problem and the state of solutions, as well as what could > > be standardized in IETF. The IETF should work on well-defined _and_ > > well-agreed problems for which protocol specification could be accomplished > > in a timely manner. Topics where the problem needs to be crystalized, and > > solution > > space needs "thinking" require a forum for discussion. And, MobOpts could > > be such a place. > > > > We (mip*, MobOpts co-chairs) are in the process of working out a model to > > facilitate closer co-operation between mip* groups and MobOpts. The outcome > > should be focussed discussion on topics of mutual interest that lead to > > documents > > which can be a) taken up in mip* groups for standardization, b) MobOpts RG > > RFCs. MobOpts would run milestones and try to produce documents within a > > timeframe of interest to mip* groups. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 19 23:26:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28976 for ; Fri, 19 Nov 2004 23:26:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVMrz-0002kf-JM for mip6-web-archive@ietf.org; Fri, 19 Nov 2004 23:29:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVMUp-0005rm-Oa; Fri, 19 Nov 2004 23:05:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVMQc-00050v-Up for mip6@megatron.ietf.org; Fri, 19 Nov 2004 23:00:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27150 for ; Fri, 19 Nov 2004 23:00:47 -0500 (EST) From: qsun300@cse.unsw.edu.au Received: from note.orchestra.cse.unsw.edu.au ([129.94.242.24] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVMTY-0002I5-Us for mip6@ietf.org; Fri, 19 Nov 2004 23:03:54 -0500 Received: From webmail.cse.unsw.edu.au ([129.94.242.51] == albeniz.orchestra.cse.unsw.EDU.AU) (ident-user w3serv) By note With Smtp ; Sat, 20 Nov 2004 15:00:37 +1100 Received: from 220.237.11.186 (SquirrelMail authenticated user qsun300) by webmail.cse.unsw.edu.au with HTTP; Sat, 20 Nov 2004 15:00:37 +1100 (EST) To: "Alexandru Petrescu" Date: Sat, 20 Nov 2004 15:00:37 +1100 (EST) Message-ID: <62542.220.237.11.186.1100923237.squirrel@webmail.cse.unsw.edu.au> In-Reply-To: <419DD9E6.8020702@motorola.com> References: <419DD9E6.8020702@motorola.com> Subject: Re: [Mip6] New I-D: Security Issues in Dynamic HomeAgentAddressDiscovery User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 2.0 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 8bit Cc: "Soliman, Hesham" , mip6@ietf.org, James Kempf , Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 8bit Alex wrote: > A certain attack on the home link by legitimate-attacker MN (the one > that contributes building fake HA lists, "legitimate" because holds > IPsec keys with HA but simultaneously "attacker" because sends fake RAs > on the home link) can not be applied on authentic messages. Should we make the following assumption? Once the MN holds IPsec keys, it is a legimate node and would not send malicious message (i.e. fake RAs) to HA. If the legimate nodes DO send malicious message, it's easy to trace the origin. So we don't need to worry about a legimate MN attack HA. Am I right? Thanks. Qian Sun > Soliman, Hesham wrote: >> I'm trying to follow this discussion to understand what the threats >> are. Apart from a DoS attack on the mobile, is there anything we need >> to worry about here? > > The "DoS attack on the mobile" that you mention has been dissected into: > denying HA service to the MN, building fake HA lists in the home link > by a legitimate-attacker MN, denying processing power capabilities on > the HA (if Requests were protected, HA would not process fake Requests), > denying HA service to LFN-behind-MR (but not to MR itself). > > The attacks do depend a lot on the capabilities of the attacker. > > Also, a packet that is dropped by a machine because it fails > authentication takes much less processing power on that machine than if > it were processed by the upper layer of the stack eventually followed by > generating new packets and sent on the wire. So, authentication still > helps a lot to protect against DoS. Except DoS should be better defined > when we talk about it :-) There is DoS that nobody and nothing can > protect against when one unplugs a level 9 cable. > >> I really don't see a reason for securing DHAAD. > > The reason would be to enable a simple Home Address autoconfiguration > mechanism, whose components are already defined in RFC 3775 (DHAAD+MPD). > >> The same type of active attacks can be applied on authentic messages >> to DoS the MN.. > > A certain attack on the home link by legitimate-attacker MN (the one > that contributes building fake HA lists, "legitimate" because holds > IPsec keys with HA but simultaneously "attacker" because sends fake RAs > on the home link) can not be applied on authentic messages. If the > messages were authentic (HA verifies the authenticity) then the > legitimate MN (the remote one) would not be denied HA service. > > Alex > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 20 06:25:13 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13873 for ; Sat, 20 Nov 2004 06:25:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVTPk-0002Zr-Ca for mip6-web-archive@ietf.org; Sat, 20 Nov 2004 06:28:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVTLq-00072m-38; Sat, 20 Nov 2004 06:24:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVTDv-0005BK-G0 for mip6@megatron.ietf.org; Sat, 20 Nov 2004 06:16:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13287 for ; Sat, 20 Nov 2004 06:16:07 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVTGw-0002Oj-AM for mip6@ietf.org; Sat, 20 Nov 2004 06:19:18 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAKBHXNi010484; Sat, 20 Nov 2004 04:17:34 -0700 (MST) Received: from [10.181.32.46] (mvp-10-181-32-46.ea.mot.com [10.181.32.46]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id iAKBEgSO031357; Sat, 20 Nov 2004 05:14:43 -0600 Message-ID: <419F276C.3030708@motorola.com> Date: Sat, 20 Nov 2004 12:15:56 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: qsun300@cse.unsw.edu.au Subject: Re: [Mip6] New I-D: Security Issues in Dynamic HomeAgentAddressDiscovery References: <419DD9E6.8020702@motorola.com> <62542.220.237.11.186.1100923237.squirrel@webmail.cse.unsw.edu.au> In-Reply-To: <62542.220.237.11.186.1100923237.squirrel@webmail.cse.unsw.edu.au> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: "Soliman, Hesham" , mip6@ietf.org, James Kempf , Henrik Petander , mahbub@cse.unsw.edu.au X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit qsun300@cse.unsw.edu.au wrote: > Alex wrote: > >>A certain attack on the home link by legitimate-attacker MN (the one >>that contributes building fake HA lists, "legitimate" because holds >>IPsec keys with HA but simultaneously "attacker" because sends fake RAs >>on the home link) can not be applied on authentic messages. > > > Should we make the following assumption? > Once the MN holds IPsec keys, it is a legimate node and would not send > malicious message (i.e. fake RAs) to HA. If the legimate nodes DO send > malicious message, it's easy to trace the origin. > > So we don't need to worry about a legimate MN attack HA. Am I right? Yes, this is right. I guess what I was trying to say was that even if MNs and HA hold current rfc3776 keys, an insecure current DHAAD allows MNs to attack each other and the HA. The target of the attack is both HA and MN. HA is a victim overloading the network unknowingly while the remote MN is a victim attacked apparently by HA, but in reality by another MN at home. These attacks are indeed traceable, but because there are three parties (MN, HA, victim MN) then the traceability is a bit more difficult. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 20 14:38:37 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20384 for ; Sat, 20 Nov 2004 14:38:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVb7H-0004HU-DN for mip6-web-archive@ietf.org; Sat, 20 Nov 2004 14:41:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVb1n-0005ej-96; Sat, 20 Nov 2004 14:36:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVaxI-0004oA-DG for mip6@megatron.ietf.org; Sat, 20 Nov 2004 14:31:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19895 for ; Sat, 20 Nov 2004 14:31:30 -0500 (EST) Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVb0O-00048P-36 for mip6@ietf.org; Sat, 20 Nov 2004 14:34:44 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 0D4E3898A1; Sat, 20 Nov 2004 21:31:27 +0200 (EET) Message-ID: <419F9B1C.4060904@kolumbus.fi> Date: Sat, 20 Nov 2004 21:29:32 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home AgentAddressDiscovery References: <419E35FD.8050403@motorola.com> In-Reply-To: <419E35FD.8050403@motorola.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Hesham Soliman , mip6@ietf.org, James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > I meant "upper" not "uppermost". An IPv6 stack does some IPsec checks > when receiving a packet. It drops them if checks fail, thus > upper-above-ipsec layers (not necessarily L7, but still above) are not > submitted, thus less processing. > > An attacker sending fake DHAAD Requests to HA provokes that HA to > process the Request a bit upper than IPsec, but still below L7, and even > generate replies back and overload o wire. > > If the DHAAD Req were protected somehow then no fake Rep generated, less > load on the network. It is true that additional security mechanisms on DHAAD would be able to prevent some vulnerabilities. I guess my question and Hesham's question are about what the most urgent things are the IETF should deal with in this space. In terms of MIP6, my personal top three list is: - deployment/bootstrapping improvements - making it possible to use operator AAA for home authentication - some improvements to movement latencies There's a bunch of other medium priority things following this (maybe privacy, home agent redundancy, etc). And then some low-priority items which we should forget for now. The question is, where is the DHAAD security improvement in this classification? Are there requirements from PP2 or someone else who intends to deploy that this particular issue is a problem? > Some people call these aspects "bombing" or "reflection" or DDoS or > similar. In the design of various protocols, we have looked into the economic aspects of vulnerabilities, similar vulnerabilities that exists elsewhere in the Internet already, and the cost of defenses. While its true that you can use DHAAD for bombing, its important to see that its still just 1:1 cost-benefit factor for the attacker; one packet causes another packet to be sent. Generally speaking, the Internet is full of attacks of similar severity. This does not seem like a major reason to start up some work. (Of course, there may be other issues, such the ability of operators to hide their infrastructure from each other.) --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 20 18:32:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08582 for ; Sat, 20 Nov 2004 18:32:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVela-0000Z2-K1 for mip6-web-archive@ietf.org; Sat, 20 Nov 2004 18:35:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVeeL-00031k-OA; Sat, 20 Nov 2004 18:28:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVeS3-0006ot-Oe for mip6@megatron.ietf.org; Sat, 20 Nov 2004 18:15:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07106 for ; Sat, 20 Nov 2004 18:15:28 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVeVB-0000EM-Jo for mip6@ietf.org; Sat, 20 Nov 2004 18:18:45 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAKNGpNi002996; Sat, 20 Nov 2004 16:16:51 -0700 (MST) Received: from [10.181.32.69] (mvp-10-181-32-69.ea.mot.com [10.181.32.69]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id iAKN794V030773; Sat, 20 Nov 2004 17:07:10 -0600 Message-ID: <419FD000.7080908@motorola.com> Date: Sun, 21 Nov 2004 00:15:12 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home AgentAddressDiscovery References: <419E35FD.8050403@motorola.com> <419F9B1C.4060904@kolumbus.fi> In-Reply-To: <419F9B1C.4060904@kolumbus.fi> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: Hesham Soliman , mip6@ietf.org, James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Jari, thanks for the message. Jari Arkko wrote: > It is true that additional security mechanisms on DHAAD would be able > to prevent some vulnerabilities. I guess my question and Hesham's > question are about what the most urgent things are the IETF should > deal with in this space. In terms of MIP6, my personal top three list > is: > > - deployment/bootstrapping improvements > > - making it possible to use operator AAA for home authentication > > - some improvements to movement latencies It looks to me that these three items have a strong deployment push, which is very important for the protocol itself, if it needs to live. I do not currently have such an ordered list of priorities for MIP6. > There's a bunch of other medium priority things following this (maybe > privacy, home agent redundancy, etc). And then some low-priority > items which we should forget for now. The question is, where is the > DHAAD security improvement in this classification? I may link "securing DHAAD" to "easy HoA configuration", and thus finally to "deployment/bootstrapping improvements" (your first item) but it seems that's a too contortious link, supposedly because secure DHAAD+MPD does not involve AAA (your second item). Thus, do you have a rough idea whether secure DHAAD would somehow fall within the "low-priority items" that we may forget for now? > Are there requirements from PP2 or someone else who intends to deploy > that this particular issue is a problem? Not as far as I know. I am not aware of 3GPP2 needing DHAAD secured, nor of 3GPP2 not needing DHAAD at all. I am just aware of a deployer mentiong something like "I don't deploy DHAAD because insecure". Which does not necessarily mean that particular deployer needs secure DHAAD, and I didn't ask. Absence of a protocol is more secure than that same protocol secured, I agree. > its true that you can use DHAAD for bombing, its important to see > that its still just 1:1 cost-benefit factor for the attacker; That's true and well said. Attackers may be indeed more tempted by "explosion"-like attacks like 1:n. I could build an "explosion"-like attack 1:n involving one attacker MN, one HA and several attacked MNs, triggered by only one fake RA on the home link, but I am not sure that me describing such an attack is of any use if there is no deployment push. I mean if nobody deploys DHAAD then there is no need to talk about it and its risks at all. > packet causes another packet to be sent. Generally speaking, the > Internet is full of attacks of similar severity. This does not seem > like a major reason to start up some work. (Of course, there may be > other issues, such the ability of operators to hide their > infrastructure from each other.) I agree. It is good to know this. I do not know whether this particular draft's authors also see secure DHAAD+MPD as a HoA bootstrapping mechanism, or whether secure DHAAD only is the only motivation. Thanks, Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 21 01:10:49 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29970 for ; Sun, 21 Nov 2004 01:10:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVkz9-0007KU-TP for mip6-web-archive@ietf.org; Sun, 21 Nov 2004 01:14:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVkuM-0000T4-Dy; Sun, 21 Nov 2004 01:09:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CVkst-0008UY-DH for mip6@megatron.ietf.org; Sun, 21 Nov 2004 01:07:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29765 for ; Sun, 21 Nov 2004 01:07:39 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CVkw1-0007HM-S5 for mip6@ietf.org; Sun, 21 Nov 2004 01:10:57 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAL67WF10031; Sun, 21 Nov 2004 08:07:33 +0200 (EET) X-Scanned: Sun, 21 Nov 2004 08:06:55 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iAL66tHj023724; Sun, 21 Nov 2004 08:06:55 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00vxnCm2; Sun, 21 Nov 2004 08:06:37 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAL66Za17886; Sun, 21 Nov 2004 08:06:35 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 21 Nov 2004 08:06:18 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sun, 21 Nov 2004 08:06:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Priorities RE: [Mip6] New I-D: Security Issues inDynamic Home AgentAddressDiscovery Date: Sun, 21 Nov 2004 08:06:17 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D432133@esebe056.ntc.nokia.com> Thread-Topic: [Mip6] New I-D: Security Issues inDynamic Home AgentAddressDiscovery Thread-Index: AcTPOR1KbpahFPdNQ7mFUHhGDM3j4QAVthzA To: X-OriginalArrivalTime: 21 Nov 2004 06:06:18.0093 (UTC) FILETIME=[372999D0:01C4CF90] X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Jari, > It is true that additional security mechanisms on DHAAD would > be able to prevent some vulnerabilities. I guess my question > and Hesham's question are about what the most urgent things > are the IETF should deal with in this space. In terms of MIP6, > my personal top three list is: >=20 > - deployment/bootstrapping improvements > - making it possible to use operator AAA for home authentication > - some improvements to movement latencies I agree with the above points. I'd prefer it we would focus on the issues needed to get MIPv6 deployed, while working on some of the other mechanisms done in the background. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 21 23:15:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28478 for ; Sun, 21 Nov 2004 23:15:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW5f1-000380-NB for mip6-web-archive@ietf.org; Sun, 21 Nov 2004 23:18:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW5ZR-00073C-Um; Sun, 21 Nov 2004 23:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW5Rm-0006UX-00 for mip6@megatron.ietf.org; Sun, 21 Nov 2004 23:05:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27942 for ; Sun, 21 Nov 2004 23:04:58 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW5V3-0002yf-5t for mip6@ietf.org; Sun, 21 Nov 2004 23:08:29 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id B325F4C0B4 for ; Mon, 22 Nov 2004 13:04:12 +0900 (JST) Date: Mon, 22 Nov 2004 13:07:06 +0900 From: Thierry Ernst To: mip6@ietf.org Subject: Re: [Mip6] FW: MIP6 agenda (Final) Message-Id: <20041122130706.3949bf2b.ernst@sfc.wide.ad.jp> In-Reply-To: <02f901c4ce55$810afee0$0f6115ac@dcml.docomolabsusa.com> References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> <419CEC8F.F29126E0@iprg.nokia.com> <20041119115503.4978b37f.ernst@sfc.wide.ad.jp> <02f901c4ce55$810afee0$0f6115ac@dcml.docomolabsusa.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: 7bit Hi James, > Are there any vendors interested in implementing this solution and/or > network operators interested in deploying it (note: I'm not asking for > detailed product plans, just the kind of committment that was given in, say, > the chartering discussion of the Mobike WG several IETFs ago)? Or other > standardization bodies (such as our good friends at 3GPP2) who are > interested in incorporating it into their standards? Peole from various companies have told me so and I would rather let them express their opinions directly to demonstrate their true interest. But many of them may not be on the list. Also, there are proprietary solutions and these manufacturers may not be eager to standardize their solutions (unless some raise the topic at the IETF, in which case they would have to). For instance, mobile phone company A may want terminals allowing their users to switch between 3G/GPRS and 802.11. In their scenario, both access networks would belong to the same operator, so a proprietary solution is fine. But from a user perspective, I and other people think standardization is important, and there is an important need. There are for instance the car manufacturers or those making products for them (unfortunately, they don't speak up at the IETF because it's not in their culture) who need to manage multiple interfaces on their MIP6/NEMO MN/MR. The ISO TC204 WG16 is one of those efforts where such feature is needed (in their CALM architecture). About implementation, there is an effort ongoing in a branch of the KAME ipv6 stack (don't look for it on the KAME page, you won't find it now) and people willing to do the same in USAGI. I don't want to speak up for USAGI and KAME people, but as far as reference implementations are concerned, we better implement standards rather than proprietary solutions, I think you would agree on this. Thierry. > jak > > PS: BTW, if you haven't seen it, you should check out the literature on > Boeing's Connexion system. It uses BGP to manage routes to a mobile 802.11 > network in an airplane on a transcontinental flight. Lufthasa has deployed > it on their new A333-600's. > > > ----- Original Message ----- > From: "Thierry Ernst" > To: > Cc: > Sent: Thursday, November 18, 2004 6:55 PM > Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > > > > > Dear Rajeev, > > > > Mobopts is a reseach group (IRTF), the problem that we want to solve is > > much more clarified clarified than that, and solutions could be brought > > in a timely manner if we restrict ourselves to part of the exisiting > > problems and extensions to MIP6 and NEMO. > > > > Of course, taking a look at the whole picture would require much more > > consideration, and for the whole picture Mobopts could be the right > > place. But, my intention, right now, is not to open the pendora box; > > it's rather about bringing a solution to an immediate concern, in a > > timely manner: how can I make use of my MIP6/NEMO function when I have > > multiple interfaces on my MH/MR ? I can't do it right now, and not > > because it's np complex, but because there is no agreed solution between > > the parties involved. > > > > Regarding what has been said at the MIP6 meeting, taking into account > > the feedback from Erik, Thomas, and all the other, I would go for a BOF > > at next IETF, but not with the objective to set up a new WG, but just a > > one-time BOF to discuss the problem thoroughly. > > > > But, prior to doing that, the other people involved with me on the > > problem statement drafts, we should improve/clarify/extend our drafts. > > The target would be end of this year; based on new drafts we would > > consider setting up a BOF or not. (OK, guys, now we have pressure on our > > shoulders ;-) > > > > Thierry > > > > > > > > On Thu, 18 Nov 2004 10:40:15 -0800 > > Rajeev Koodli wrote: > > > > > Thierry Ernst wrote: > > > > > > > > Thus embarking on QoS sensitive, mobility specific multihoming > support > > > > > is both too open ended (on the QoS side) and too constraining (by > only > > > > > looking at cases when MIP/Nemo is used). > > > > > > > > > > So I think it would be useful for folks to try to think about and > > > > > discuss the bigger picture. > > > > > > > > Agree. But then, where should this discussion take place ? MIP6 WG ? > > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > > > > I would add to Erik's observation that we need to be able to assess a > topic to > > > see > > > the maturity of the problem and the state of solutions, as well as what > could > > > be standardized in IETF. The IETF should work on well-defined _and_ > > > well-agreed problems for which protocol specification could be > accomplished > > > in a timely manner. Topics where the problem needs to be crystalized, > and > > > solution > > > space needs "thinking" require a forum for discussion. And, MobOpts > could > > > be such a place. > > > > > > We (mip*, MobOpts co-chairs) are in the process of working out a model > to > > > facilitate closer co-operation between mip* groups and MobOpts. The > outcome > > > should be focussed discussion on topics of mutual interest that lead to > > > documents > > > which can be a) taken up in mip* groups for standardization, b) MobOpts > RG > > > RFCs. MobOpts would run milestones and try to produce documents within a > > > timeframe of interest to mip* groups. > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 22 00:27:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03740 for ; Mon, 22 Nov 2004 00:27:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW6nA-0004Ww-Sx for mip6-web-archive@ietf.org; Mon, 22 Nov 2004 00:31:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW6iG-0000mv-T7; Mon, 22 Nov 2004 00:26:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW6hj-0000hj-PA for mip6@megatron.ietf.org; Mon, 22 Nov 2004 00:25:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03586 for ; Mon, 22 Nov 2004 00:25:33 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW6l6-0004TL-Ne for mip6@ietf.org; Mon, 22 Nov 2004 00:29:06 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id A5C114C0B7 for ; Mon, 22 Nov 2004 14:25:00 +0900 (JST) Date: Mon, 22 Nov 2004 14:27:54 +0900 From: Thierry Ernst To: mip6@ietf.org Subject: Re: [Mip6] FW: MIP6 agenda (Final) Message-Id: <20041122142754.791c1558.ernst@sfc.wide.ad.jp> In-Reply-To: <419E421D.BF063AA2@iprg.nokia.com> References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> <419CEC8F.F29126E0@iprg.nokia.com> <20041119115503.4978b37f.ernst@sfc.wide.ad.jp> <419E421D.BF063AA2@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Dear Rajeev, > > Mobopts is a reseach group (IRTF), the problem that we want to solve is > > much more clarified clarified than that, and solutions could be brought > > in a timely manner if we restrict ourselves to part of the exisiting > > problems and extensions to MIP6 and NEMO. > > > > This seems to imply that Mobopts cannot produce documents in a timely > manner. If so, I would like to encourage you to think otherwise. We would > be enforcing milestones and deadlines, and produce documents which > the IETF working groups find useful. Sorry I left out NEMO in my > previous message. > > Of course, taking a look at the whole picture would require much more > > consideration, and for the whole picture Mobopts could be the right > > place. But, my intention, right now, is not to open the pendora box; > > > > What is the pandora's box? I think understanding the host multi-homing > and mobility is an important area before we can standardize things. By pandora box, I mean opening the debate from scratch like shall we do that kind of stuffs at the application, transport or ip layer ? As I said, my indend is to do it for mobile nodes, so something combine to MIP6 and NEMO would bring the necessary benefits in not so long. From the various drafts submitted to the Mobile IP/MIP6 WG over the past years, it's quite obvious that we understand the problem. But solutions solve different part of the problem, so it is time to come up with a single solutions responding to the problem that can be solved reasonably easily with MIP and NEMO. On the other hand, investigating all the story with no specific protocol or layerin mind is something that is very much research and may lead to conclusions such as separating locator from identifier, etc. This, of course, should not be happening at the IETF as it would need some understanding. About Mobopts, it depends what we want to do (enhancements to MIP6/NEMO specifically vs covering the entire topic). Also, IRTF cannot produce anything in the standard track. Thierry > -Rajeev > > > > it's rather about bringing a solution to an immediate concern, in a > > timely manner: how can I make use of my MIP6/NEMO function when I have > > multiple interfaces on my MH/MR ? I can't do it right now, and not > > because it's np complex, but because there is no agreed solution between > > the parties involved. > > > > Regarding what has been said at the MIP6 meeting, taking into account > > the feedback from Erik, Thomas, and all the other, I would go for a BOF > > at next IETF, but not with the objective to set up a new WG, but just a > > one-time BOF to discuss the problem thoroughly. > > > > But, prior to doing that, the other people involved with me on the > > problem statement drafts, we should improve/clarify/extend our drafts. > > The target would be end of this year; based on new drafts we would > > consider setting up a BOF or not. (OK, guys, now we have pressure on our > > shoulders ;-) > > > > Thierry > > > > On Thu, 18 Nov 2004 10:40:15 -0800 > > Rajeev Koodli wrote: > > > > > Thierry Ernst wrote: > > > > > > > > Thus embarking on QoS sensitive, mobility specific multihoming support > > > > > is both too open ended (on the QoS side) and too constraining (by only > > > > > looking at cases when MIP/Nemo is used). > > > > > > > > > > So I think it would be useful for folks to try to think about and > > > > > discuss the bigger picture. > > > > > > > > Agree. But then, where should this discussion take place ? MIP6 WG ? > > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > > > > I would add to Erik's observation that we need to be able to assess a topic to > > > see > > > the maturity of the problem and the state of solutions, as well as what could > > > be standardized in IETF. The IETF should work on well-defined _and_ > > > well-agreed problems for which protocol specification could be accomplished > > > in a timely manner. Topics where the problem needs to be crystalized, and > > > solution > > > space needs "thinking" require a forum for discussion. And, MobOpts could > > > be such a place. > > > > > > We (mip*, MobOpts co-chairs) are in the process of working out a model to > > > facilitate closer co-operation between mip* groups and MobOpts. The outcome > > > should be focussed discussion on topics of mutual interest that lead to > > > documents > > > which can be a) taken up in mip* groups for standardization, b) MobOpts RG > > > RFCs. MobOpts would run milestones and try to produce documents within a > > > timeframe of interest to mip* groups. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 22 03:20:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00361 for ; Mon, 22 Nov 2004 03:20:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW9Uh-0007hY-Vk for mip6-web-archive@ietf.org; Mon, 22 Nov 2004 03:24:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW9Pt-0002O7-2U; Mon, 22 Nov 2004 03:19:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CW9LT-0001hs-Ty for mip6@megatron.ietf.org; Mon, 22 Nov 2004 03:14:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29981 for ; Mon, 22 Nov 2004 03:14:46 -0500 (EST) Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CW9Ot-0007aN-Af for mip6@ietf.org; Mon, 22 Nov 2004 03:18:19 -0500 Received: from [130.79.44.193] (dpt-info.u-strasbg.fr [130.79.44.193]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id iAM8Fxif024799; Mon, 22 Nov 2004 09:16:00 +0100 (CET) (envelope-from montavont@clarinet.u-strasbg.fr) Message-ID: <41A1A03F.8070809@clarinet.u-strasbg.fr> Date: Mon, 22 Nov 2004 09:15:59 +0100 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rajeev@iprg.nokia.com Subject: Re: [Mip6] FW: MIP6 agenda (Final) References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> <419CEC8F.F29126E0@iprg.nokia.com> <20041119115503.4978b37f.ernst@sfc.wide.ad.jp> <419E421D.BF063AA2@iprg.nokia.com> In-Reply-To: <419E421D.BF063AA2@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Thierry Ernst X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Hi Rajeev, Rajeev Koodli wrote: > Hi Thierry, > > Thierry Ernst wrote: > > >>Dear Rajeev, >> >>Mobopts is a reseach group (IRTF), the problem that we want to solve is >>much more clarified clarified than that, and solutions could be brought >>in a timely manner if we restrict ourselves to part of the exisiting >>problems and extensions to MIP6 and NEMO. >> > > > This seems to imply that Mobopts cannot produce documents in a timely > manner. If so, I would like to encourage you to think otherwise. We would > be enforcing milestones and deadlines, and produce documents which > the IETF working groups find useful. Sorry I left out NEMO in my > previous message. > > >>Of course, taking a look at the whole picture would require much more >>consideration, and for the whole picture Mobopts could be the right >>place. But, my intention, right now, is not to open the pendora box; >> > > > What is the pandora's box? I think understanding the host multi-homing > and mobility is an important area before we can standardize things. I just wanted to come up on this point. Our intend is not to provide any solution at that time. As you say, and we totally agree on this point, what is important now is to gather our experience and ideas on "host" multihoming and discuss this. If we are able to identify clear needs and/or problem statement, we should investigate the solution space. From our recent work on this topic, we believe that host multihoming should be considered at the IETF (in any Working Group), at least to provide a problem statement on which people can decide if this work is relevant or not. We just need a place to discuss this officially, not just 5 minutes at the end of a meeting or something like that. Nicolas > > -Rajeev > > > >>it's rather about bringing a solution to an immediate concern, in a >>timely manner: how can I make use of my MIP6/NEMO function when I have >>multiple interfaces on my MH/MR ? I can't do it right now, and not >>because it's np complex, but because there is no agreed solution between >>the parties involved. >> >>Regarding what has been said at the MIP6 meeting, taking into account >>the feedback from Erik, Thomas, and all the other, I would go for a BOF >>at next IETF, but not with the objective to set up a new WG, but just a >>one-time BOF to discuss the problem thoroughly. >> >>But, prior to doing that, the other people involved with me on the >>problem statement drafts, we should improve/clarify/extend our drafts. >>The target would be end of this year; based on new drafts we would >>consider setting up a BOF or not. (OK, guys, now we have pressure on our >>shoulders ;-) >> >>Thierry >> >>On Thu, 18 Nov 2004 10:40:15 -0800 >>Rajeev Koodli wrote: >> >> >>>Thierry Ernst wrote: >>> >>> >>>>>Thus embarking on QoS sensitive, mobility specific multihoming support >>>>>is both too open ended (on the QoS side) and too constraining (by only >>>>>looking at cases when MIP/Nemo is used). >>>>> >>>>>So I think it would be useful for folks to try to think about and >>>>>discuss the bigger picture. >>>> >>>>Agree. But then, where should this discussion take place ? MIP6 WG ? >>>>NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? >>>> >>> >>>I would add to Erik's observation that we need to be able to assess a topic to >>>see >>>the maturity of the problem and the state of solutions, as well as what could >>>be standardized in IETF. The IETF should work on well-defined _and_ >>>well-agreed problems for which protocol specification could be accomplished >>>in a timely manner. Topics where the problem needs to be crystalized, and >>>solution >>>space needs "thinking" require a forum for discussion. And, MobOpts could >>>be such a place. >>> >>>We (mip*, MobOpts co-chairs) are in the process of working out a model to >>>facilitate closer co-operation between mip* groups and MobOpts. The outcome >>>should be focussed discussion on topics of mutual interest that lead to >>>documents >>>which can be a) taken up in mip* groups for standardization, b) MobOpts RG >>>RFCs. MobOpts would run milestones and try to produce documents within a >>>timeframe of interest to mip* groups. > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 22 12:52:42 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26726 for ; Mon, 22 Nov 2004 12:52:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIQH-00056g-FH for mip6-web-archive@ietf.org; Mon, 22 Nov 2004 12:56:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIDH-0001St-7b; Mon, 22 Nov 2004 12:42:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIBv-0001GD-H6 for mip6@megatron.ietf.org; Mon, 22 Nov 2004 12:41:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25520 for ; Mon, 22 Nov 2004 12:41:27 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWI5y-000303-5d for mip6@ietf.org; Mon, 22 Nov 2004 12:35:33 -0500 Message-ID: <00d601c4d0b9$432ce780$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Nicolas Montavont" , References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> <419CEC8F.F29126E0@iprg.nokia.com> <20041119115503.4978b37f.ernst@sfc.wide.ad.jp><419E421D.BF063AA2@iprg.nokia.com> <41A1A03F.8070809@clarinet.u-strasbg.fr> Subject: Re: [Mip6] FW: MIP6 agenda (Final) Date: Mon, 22 Nov 2004 09:32:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Thierry Ernst X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Nicolas, > I just wanted to come up on this point. Our intend is not to provide any > solution at that time. As you say, and we totally agree on this point, > what is important now is to gather our experience and ideas on "host" > multihoming and discuss this. If we are able to identify clear needs > and/or problem statement, we should investigate the solution space. > This convinces me even more that this work should be done in MobOpts, as Raj has requested. IETF is not a good place to do work where there is not a general agreement on the architecture and basic design. Collecting data and achieving consensus on the basic design and architecture based on the data are research tasks, even though it may not be the kind of research that lands one a prized spot on next year's MobiCom agenda. Therefore, I think if there is not a solution that is well understood at hand, Mobopts is the perfect place to do the work. Rajeev and Bill are making a strong effort to have Mobopts be a place to mature good ideas rather than a graveyard for bad ideas as some have accused the IRTF of being; in fact, from our last meeting in Washington, Rajeev and Bill are planning to approve a couple drafts as Research Group drafts, for eventual movement into IETF. > From our recent work on this topic, we believe that host multihoming > should be considered at the IETF (in any Working Group), at least to > provide a problem statement on which people can decide if this work is > relevant or not. We just need a place to discuss this officially, not > just 5 minutes at the end of a meeting or something like that. > What about v6ops? Erik Nordmark gave a talk at the ipv6 WG meeting in Washington that the design team came up with. I believe they have been stovepiped for quite a while in order to be able to make progress, but the time may have come for someone with Mobile IP expertiese to take a look at their solution and see how mobility and Mobile IP fits in. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 22 12:54:46 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26853 for ; Mon, 22 Nov 2004 12:54:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWISH-0005U2-O5 for mip6-web-archive@ietf.org; Mon, 22 Nov 2004 12:58:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIDS-0001Ze-Ek; Mon, 22 Nov 2004 12:43:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWICO-0001In-FP for mip6@megatron.ietf.org; Mon, 22 Nov 2004 12:42:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25822 for ; Mon, 22 Nov 2004 12:41:57 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIFs-00046u-O2 for mip6@ietf.org; Mon, 22 Nov 2004 12:45:37 -0500 Message-ID: <00df01c4d0ba$b1ecff10$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Thierry Ernst" , References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com><20041111123630.1be973c6.ernst@sfc.wide.ad.jp><4193C2B2.5050200@sun.com><20041112061543.0a263a00.ernst@sfc.wide.ad.jp><419CEC8F.F29126E0@iprg.nokia.com><20041119115503.4978b37f.ernst@sfc.wide.ad.jp><02f901c4ce55$810afee0$0f6115ac@dcml.docomolabsusa.com> <20041122130706.3949bf2b.ernst@sfc.wide.ad.jp> Subject: Re: [Mip6] FW: MIP6 agenda (Final) Date: Mon, 22 Nov 2004 09:42:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Content-Transfer-Encoding: 7bit Hi Thierry, Please don't feel offended, but I tend to discount attestations from researchers that there is product and deployment interest. For 4 years, we had researchers saying that there was product and deployment interest in Seamoby, yet prior to switching the drafts to experimental, we had not a single vendor or operator willing to say that they were interested in developing and deploying the protocols. That's why they were switched to experimental. If there are not vendors and operators willing to come on the list and participate in the process so their customers can enjoy the benefits of interoperability, then I don't think this is an appropriate topic for the mip6 WG, since mip6 isn't chartered to do experimental work. Regarding ISO, if there's another standardization body that needs the work, then a liason letter to the IETF via the IAB requesting an Internet standard might be in order. However, I believe a more productive track would be to take the work to Mobopts as Raj and Rajeev have requested, possibly in conjunction with examining the multihoming work that v6ops is doing for mobility implications. Rajeev and Bill are working hard to make Mobopts a venue for maturing good ideas, and I think that this work may now be showing results, since we now have two drafts there that they are interested in making research group drafts, for eventual re-introduction into IETF. jak ----- Original Message ----- From: "Thierry Ernst" To: Sent: Sunday, November 21, 2004 8:07 PM Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > Hi James, > > > Are there any vendors interested in implementing this solution and/or > > network operators interested in deploying it (note: I'm not asking for > > detailed product plans, just the kind of committment that was given in, say, > > the chartering discussion of the Mobike WG several IETFs ago)? Or other > > standardization bodies (such as our good friends at 3GPP2) who are > > interested in incorporating it into their standards? > > Peole from various companies have told me so and I would rather let them > express their opinions directly to demonstrate their true interest. But > many of them may not be on the list. > > Also, there are proprietary solutions and these manufacturers may not be > eager to standardize their solutions (unless some raise the topic at the > IETF, in which case they would have to). > > For instance, mobile phone company A may want terminals allowing their > users to switch between 3G/GPRS and 802.11. In their scenario, both > access networks would belong to the same operator, so a proprietary > solution is fine. > > But from a user perspective, I and other people think standardization is > important, and there is an important need. > > There are for instance the car manufacturers or those making products > for them (unfortunately, they don't speak up at the IETF because it's > not in their culture) who need to manage multiple interfaces on their > MIP6/NEMO MN/MR. The ISO TC204 WG16 is one of those efforts where such > feature is needed (in their CALM architecture). > > About implementation, there is an effort ongoing in a branch of the KAME > ipv6 stack (don't look for it on the KAME page, you won't find it now) > and people willing to do the same in USAGI. I don't want to speak up for > USAGI and KAME people, but as far as reference implementations are > concerned, we better implement standards rather than proprietary > solutions, I think you would agree on this. > > Thierry. > > > > > jak > > > > PS: BTW, if you haven't seen it, you should check out the literature on > > Boeing's Connexion system. It uses BGP to manage routes to a mobile 802.11 > > network in an airplane on a transcontinental flight. Lufthasa has deployed > > it on their new A333-600's. > > > > > > ----- Original Message ----- > > From: "Thierry Ernst" > > To: > > Cc: > > Sent: Thursday, November 18, 2004 6:55 PM > > Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > > > > > > > > > Dear Rajeev, > > > > > > Mobopts is a reseach group (IRTF), the problem that we want to solve is > > > much more clarified clarified than that, and solutions could be brought > > > in a timely manner if we restrict ourselves to part of the exisiting > > > problems and extensions to MIP6 and NEMO. > > > > > > Of course, taking a look at the whole picture would require much more > > > consideration, and for the whole picture Mobopts could be the right > > > place. But, my intention, right now, is not to open the pendora box; > > > it's rather about bringing a solution to an immediate concern, in a > > > timely manner: how can I make use of my MIP6/NEMO function when I have > > > multiple interfaces on my MH/MR ? I can't do it right now, and not > > > because it's np complex, but because there is no agreed solution between > > > the parties involved. > > > > > > Regarding what has been said at the MIP6 meeting, taking into account > > > the feedback from Erik, Thomas, and all the other, I would go for a BOF > > > at next IETF, but not with the objective to set up a new WG, but just a > > > one-time BOF to discuss the problem thoroughly. > > > > > > But, prior to doing that, the other people involved with me on the > > > problem statement drafts, we should improve/clarify/extend our drafts. > > > The target would be end of this year; based on new drafts we would > > > consider setting up a BOF or not. (OK, guys, now we have pressure on our > > > shoulders ;-) > > > > > > Thierry > > > > > > > > > > > > On Thu, 18 Nov 2004 10:40:15 -0800 > > > Rajeev Koodli wrote: > > > > > > > Thierry Ernst wrote: > > > > > > > > > > Thus embarking on QoS sensitive, mobility specific multihoming > > support > > > > > > is both too open ended (on the QoS side) and too constraining (by > > only > > > > > > looking at cases when MIP/Nemo is used). > > > > > > > > > > > > So I think it would be useful for folks to try to think about and > > > > > > discuss the bigger picture. > > > > > > > > > > Agree. But then, where should this discussion take place ? MIP6 WG ? > > > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > > > > > > > I would add to Erik's observation that we need to be able to assess a > > topic to > > > > see > > > > the maturity of the problem and the state of solutions, as well as what > > could > > > > be standardized in IETF. The IETF should work on well-defined _and_ > > > > well-agreed problems for which protocol specification could be > > accomplished > > > > in a timely manner. Topics where the problem needs to be crystalized, > > and > > > > solution > > > > space needs "thinking" require a forum for discussion. And, MobOpts > > could > > > > be such a place. > > > > > > > > We (mip*, MobOpts co-chairs) are in the process of working out a model > > to > > > > facilitate closer co-operation between mip* groups and MobOpts. The > > outcome > > > > should be focussed discussion on topics of mutual interest that lead to > > > > documents > > > > which can be a) taken up in mip* groups for standardization, b) MobOpts > > RG > > > > RFCs. MobOpts would run milestones and try to produce documents within a > > > > timeframe of interest to mip* groups. > > > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 22 13:05:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27617 for ; Mon, 22 Nov 2004 13:05:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIcQ-0006MU-Ug for mip6-web-archive@ietf.org; Mon, 22 Nov 2004 13:08:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIQL-00042o-8w; Mon, 22 Nov 2004 12:56:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWIIp-0002Hi-Cf for mip6@megatron.ietf.org; Mon, 22 Nov 2004 12:48:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26299 for ; Mon, 22 Nov 2004 12:48:36 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWIMJ-0004dT-0P for mip6@ietf.org; Mon, 22 Nov 2004 12:52:16 -0500 Message-ID: <00e801c4d0bb$9f243af0$0f6115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" , "Alexandru Petrescu" References: <419E35FD.8050403@motorola.com> <419F9B1C.4060904@kolumbus.fi> Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home AgentAddressDiscovery Date: Mon, 22 Nov 2004 09:49:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Hesham Soliman , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit > It is true that additional security mechanisms on DHAAD would > be able to prevent some vulnerabilities. I guess my question > and Hesham's question are about what the most urgent things > are the IETF should deal with in this space. In terms of MIP6, > my personal top three list is: > > - deployment/bootstrapping improvements > - making it possible to use operator AAA for home authentication > - some improvements to movement latencies > > There's a bunch of other medium priority things following > this (maybe privacy, home agent redundancy, etc). And then > some low-priority items which we should forget for now. > The question is, where is the DHAAD security improvement > in this classification? Are there requirements from PP2 > or someone else who intends to deploy that this particular > issue is a problem? > I have to second Jari's note. As I mentioned in my original response, I don't see DHAAD being deployed. I believe that the mip6 group needs to stay closely focussed on those issues that have arisen as a result of implelmentation and deployment considerations. The issue of security for DHAAD falls way below the line, in my opinion. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 22 13:51:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02036 for ; Mon, 22 Nov 2004 13:51:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWJLZ-00032k-VA for mip6-web-archive@ietf.org; Mon, 22 Nov 2004 13:55:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWJC1-0004oj-9Z; Mon, 22 Nov 2004 13:45:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWJ2X-0003Sz-5V for mip6@megatron.ietf.org; Mon, 22 Nov 2004 13:35:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00829 for ; Mon, 22 Nov 2004 13:35:52 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWJ61-0001PS-Hw for mip6@ietf.org; Mon, 22 Nov 2004 13:39:30 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iAMI74F20923; Mon, 22 Nov 2004 10:07:04 -0800 X-mProtect: <200411221807> Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90) by darkstar.iprg.nokia.com smtpdEBMJt0; Mon, 22 Nov 2004 10:07:03 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by rajeev.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id KAA71268; Mon, 22 Nov 2004 10:35:07 -0800 (PST) Message-ID: <41A2315B.B4B95003@iprg.nokia.com> Date: Mon, 22 Nov 2004 10:35:07 -0800 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: Thierry Ernst Subject: Re: [Mip6] FW: MIP6 agenda (Final) References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> <419CEC8F.F29126E0@iprg.nokia.com> <20041119115503.4978b37f.ernst@sfc.wide.ad.jp> <419E421D.BF063AA2@iprg.nokia.com> <20041122142754.791c1558.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajeev@iprg.nokia.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > On the other hand, investigating all the story with no specific protocol > or layerin mind is something that is very much research and may lead to > conclusions such as separating locator from identifier, etc. This, of > course, should not be happening at the IETF as it would need some > understanding. > Well, MobOpts for sure is not going to be as open-ended as you might be imagining above. > > About Mobopts, it depends what we want to do (enhancements to MIP6/NEMO > specifically vs covering the entire topic). Also, IRTF cannot > produce anything in the standard track. > Right, IRTF does not produce PS documents. I am questioning the need for PS documents in IETF groups. If the "market out there" is happy with existing solutions, why are we trying to invent PS documents? Who needs them? Are we making judgement calls for the market? -Rajeev > > Thierry > > > -Rajeev > > > > > > > it's rather about bringing a solution to an immediate concern, in a > > > timely manner: how can I make use of my MIP6/NEMO function when I have > > > multiple interfaces on my MH/MR ? I can't do it right now, and not > > > because it's np complex, but because there is no agreed solution between > > > the parties involved. > > > > > > Regarding what has been said at the MIP6 meeting, taking into account > > > the feedback from Erik, Thomas, and all the other, I would go for a BOF > > > at next IETF, but not with the objective to set up a new WG, but just a > > > one-time BOF to discuss the problem thoroughly. > > > > > > But, prior to doing that, the other people involved with me on the > > > problem statement drafts, we should improve/clarify/extend our drafts. > > > The target would be end of this year; based on new drafts we would > > > consider setting up a BOF or not. (OK, guys, now we have pressure on our > > > shoulders ;-) > > > > > > Thierry > > > > > > On Thu, 18 Nov 2004 10:40:15 -0800 > > > Rajeev Koodli wrote: > > > > > > > Thierry Ernst wrote: > > > > > > > > > > Thus embarking on QoS sensitive, mobility specific multihoming support > > > > > > is both too open ended (on the QoS side) and too constraining (by only > > > > > > looking at cases when MIP/Nemo is used). > > > > > > > > > > > > So I think it would be useful for folks to try to think about and > > > > > > discuss the bigger picture. > > > > > > > > > > Agree. But then, where should this discussion take place ? MIP6 WG ? > > > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > > > > > > > I would add to Erik's observation that we need to be able to assess a topic to > > > > see > > > > the maturity of the problem and the state of solutions, as well as what could > > > > be standardized in IETF. The IETF should work on well-defined _and_ > > > > well-agreed problems for which protocol specification could be accomplished > > > > in a timely manner. Topics where the problem needs to be crystalized, and > > > > solution > > > > space needs "thinking" require a forum for discussion. And, MobOpts could > > > > be such a place. > > > > > > > > We (mip*, MobOpts co-chairs) are in the process of working out a model to > > > > facilitate closer co-operation between mip* groups and MobOpts. The outcome > > > > should be focussed discussion on topics of mutual interest that lead to > > > > documents > > > > which can be a) taken up in mip* groups for standardization, b) MobOpts RG > > > > RFCs. MobOpts would run milestones and try to produce documents within a > > > > timeframe of interest to mip* groups. > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 22 17:39:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29953 for ; Mon, 22 Nov 2004 17:39:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMto-0000qd-6d for mip6-web-archive@ietf.org; Mon, 22 Nov 2004 17:43:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMcR-0000cE-Ac; Mon, 22 Nov 2004 17:25:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWMXs-0007XF-Ii for mip6@megatron.ietf.org; Mon, 22 Nov 2004 17:20:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28312 for ; Mon, 22 Nov 2004 17:20:26 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWMbO-0006ms-Vv for mip6@ietf.org; Mon, 22 Nov 2004 17:24:08 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAMMLsNi001980; Mon, 22 Nov 2004 15:21:55 -0700 (MST) Received: from [192.172.33.112] (mvp-192-172-33-112.corp.mot.com [192.172.33.112]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id iAMMJ3kM032346; Mon, 22 Nov 2004 16:19:03 -0600 Message-ID: <41A26623.5070200@motorola.com> Date: Mon, 22 Nov 2004 23:20:19 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] New I-D: Security Issues in Dynamic Home AgentAddressDiscovery References: <419E35FD.8050403@motorola.com> <419F9B1C.4060904@kolumbus.fi> <00e801c4d0bb$9f243af0$0f6115ac@dcml.docomolabsusa.com> In-Reply-To: <00e801c4d0bb$9f243af0$0f6115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: Hesham Soliman , Jari Arkko , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit James Kempf wrote: > I don't see DHAAD being deployed. [...] focussed on those issues > [...] implementation and deployment considerations. Ok, I got the idea; I'm not insisting on this. Thanks, Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 23 04:32:26 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20428 for ; Tue, 23 Nov 2004 04:32:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWX5q-0002pV-6e for mip6-web-archive@ietf.org; Tue, 23 Nov 2004 04:36:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWWz1-00085i-Ni; Tue, 23 Nov 2004 04:29:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWWxb-0007gi-1J for mip6@megatron.ietf.org; Tue, 23 Nov 2004 04:27:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20150 for ; Tue, 23 Nov 2004 04:27:40 -0500 (EST) Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CWX1B-00025B-FV for mip6@ietf.org; Tue, 23 Nov 2004 04:31:28 -0500 Received: (qmail 19167 invoked for bounce); 23 Nov 2004 09:27:36 -0000 Received: from unknown (HELO ?130.79.90.171?) (montavont@unknown) by unknown with SMTP; 23 Nov 2004 09:27:36 -0000 Message-ID: <41A3013E.2090509@clarinet.u-strasbg.fr> Date: Tue, 23 Nov 2004 10:22:06 +0100 From: Nicolas Montavont User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] FW: MIP6 agenda (Final) References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> <419CEC8F.F29126E0@iprg.nokia.com> <20041119115503.4978b37f.ernst@sfc.wide.ad.jp><419E421D.BF063AA2@iprg.nokia.com> <41A1A03F.8070809@clarinet.u-strasbg.fr> <00d601c4d0b9$432ce780$0f6115ac@dcml.docomolabsusa.com> In-Reply-To: <00d601c4d0b9$432ce780$0f6115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Thierry Ernst , rajeev@iprg.nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Hi James and Rajeev, James Kempf wrote: >Nicolas, > > > >>I just wanted to come up on this point. Our intend is not to provide any >>solution at that time. As you say, and we totally agree on this point, >>what is important now is to gather our experience and ideas on "host" >>multihoming and discuss this. If we are able to identify clear needs >>and/or problem statement, we should investigate the solution space. >> >> >> > >This convinces me even more that this work should be done in MobOpts, as Raj >has requested. IETF is not a good place to do work where there is not a >general agreement on the architecture and basic design. Collecting data and >achieving consensus on the basic design and architecture based on the data >are research tasks, even though it may not be the kind of research that >lands one a prized spot on next year's MobiCom agenda. Therefore, I think if >there is not a solution that is well understood at hand, Mobopts is the >perfect place to do the work. Rajeev and Bill are making a strong effort to >have Mobopts be a place to mature good ideas rather than a graveyard for bad >ideas as some have accused the IRTF of being; in fact, from our last meeting >in Washington, Rajeev and Bill are planning to approve a couple drafts as >Research Group drafts, for eventual movement into IETF. > > Ok as I understand, we will submit next versions of our drafts in Mobopts ? > > >> From our recent work on this topic, we believe that host multihoming >>should be considered at the IETF (in any Working Group), at least to >>provide a problem statement on which people can decide if this work is >>relevant or not. We just need a place to discuss this officially, not >>just 5 minutes at the end of a meeting or something like that. >> >> >> > >What about v6ops? Erik Nordmark gave a talk at the ipv6 WG meeting in >Washington that the design team came up with. I believe they have been >stovepiped for quite a while in order to be able to make progress, but the >time may have come for someone with Mobile IP expertiese to take a look at >their solution and see how mobility and Mobile IP fits in. > > Unfortunatly I was not at the last IETF, I'll have to check the log. Was a desgin team already formed to investigate mobility feature in v6ops ? Nicolas > jak > > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 23 04:51:34 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21441 for ; Tue, 23 Nov 2004 04:51:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWXOM-00058m-BJ for mip6-web-archive@ietf.org; Tue, 23 Nov 2004 04:55:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWXIR-00056Y-EJ; Tue, 23 Nov 2004 04:49:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWXGX-0004lC-TO for mip6@megatron.ietf.org; Tue, 23 Nov 2004 04:47:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21177 for ; Tue, 23 Nov 2004 04:47:14 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWXK9-0004jA-4I for mip6@ietf.org; Tue, 23 Nov 2004 04:51:02 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id iAN9ltVx024592; Tue, 23 Nov 2004 02:47:57 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id iAN9hZt6018555; Tue, 23 Nov 2004 03:43:36 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 0CC1E8A3C60; Tue, 23 Nov 2004 10:46:14 +0100 (CET) Message-ID: <41A306DE.8000108@motorola.com> Date: Tue, 23 Nov 2004 10:46:06 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nicolas Montavont Subject: Re: [Mip6] FW: MIP6 agenda (Final) References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> <419CEC8F.F29126E0@iprg.nokia.com> <20041119115503.4978b37f.ernst@sfc.wide.ad.jp><419E421D.BF063AA2@iprg.nokia.com> <41A1A03F.8070809@clarinet.u-strasbg.fr> <00d601c4d0b9$432ce780$0f6115ac@dcml.docomolabsusa.com> <41A3013E.2090509@clarinet.u-strasbg.fr> In-Reply-To: <41A3013E.2090509@clarinet.u-strasbg.fr> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: mip6@ietf.org, Thierry Ernst , James Kempf , rajeev@iprg.nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2023589894==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============2023589894== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7C7DD4ADB45DD6FB0EC19349" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C7DD4ADB45DD6FB0EC19349 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit >> progress, but the time may have come for someone with Mobile IP >> expertiese to take a look at their solution and see how mobility >> and Mobile IP fits in. >> > Unfortunatly I was not at the last IETF, I'll have to check the log. > Was a desgin team already formed to investigate mobility feature in > v6ops ? v6ops is somehow rechartering nowadays and somehow re-focusing, which means somehow mobility is out-of-focus for them. OTOH there is a new public mip6-mip4-v6-v4 (miptrans) mailing list. That's not a DT. I think that's not about multi-homing either, but since it's new and inceptive I think you should check their drafts see how multihoming may fit in. My oppinion is it doesn't but check it out. http://tinyurl.com/5j8w6 I think better go to multi6. Alex --------------enig7C7DD4ADB45DD6FB0EC19349 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBowbkMmC0w56zj54RAv8qAKC/VIx2IvCod+2xiYxuYc4VrOz5hgCeId0Y Hn1REujI5xflROAqR3QIBJk= =7wB3 -----END PGP SIGNATURE----- --------------enig7C7DD4ADB45DD6FB0EC19349-- --===============2023589894== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2023589894==-- From mip6-bounces@ietf.org Tue Nov 23 08:37:53 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09976 for ; Tue, 23 Nov 2004 08:37:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWavO-0001Xp-FD for mip6-web-archive@ietf.org; Tue, 23 Nov 2004 08:41:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWaj1-0000ui-86; Tue, 23 Nov 2004 08:28:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWTCf-0004K6-De for mip6@megatron.ietf.org; Tue, 23 Nov 2004 00:27:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15985 for ; Tue, 23 Nov 2004 00:26:58 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.198]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWTGF-0004g8-B1 for mip6@ietf.org; Tue, 23 Nov 2004 00:30:43 -0500 Received: by wproxy.gmail.com with SMTP id 70so659087wra for ; Mon, 22 Nov 2004 21:26:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=hgsLONul3N8KBR/dEtrHLC1IQojdkg3KGGVNINOpxcw7alZr80sdJnRFOB+hCKjcf/04GuOYsJZEHOK2K8XVf17Y8azf81C1p63rbhfxXQr+H9vRs3+CNE6dFrwHoPNHaFjjIWs2LB+6TVDhB1G35ju3tzQAOoXc76+8ifleKn4= Received: by 10.54.31.5 with SMTP id e5mr198398wre; Mon, 22 Nov 2004 21:26:25 -0800 (PST) Received: by 10.54.10.77 with HTTP; Mon, 22 Nov 2004 21:26:25 -0800 (PST) Message-ID: <88b9e992041122212655a1592d@mail.gmail.com> Date: Tue, 23 Nov 2004 00:26:25 -0500 From: B Krishnamachari To: mipshop@ietf.org, podc@acm.org, mip4@ietf.org, manet@ietf.org, mip6@ietf.org, ontc@comsoc.org, itc@ieee.org, tcgn@ieee.org, commsoft@ieee.org, performance@haven.epm.ornl.gov.cnri.reston.va.us, tel-bcn@mat.upc.es, tel-vil@mat.upc.es, Disc-delegates@disc2000.org, alg@comm.toronto.edu, cabernet-events@ncl.ac.uk, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, end2end-interest@isi.edu, kuvs-elg@fokus.gmd.de, announce@tcos.org, testnet@canarie.ca, eapls-request@mailbase.ac.uk, dbworld@cs.wisc.edu, xtp-relay@cs.concordia.ca, siksleden@cs.uu.nl, int-serv@isi.edu, comm-theory@ieee.org, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comsys@brunet.bn, Conferencesa@comsoc.org, comswtc@ieee.org, multicomm@comsoc.org, sigcomm-members@acm.org, noe-one@prezzemolo.polito.it, sigmob@acm.org, info-confs@comsoc.org, iwqos@comsoc.org, mobicom@acm.org, news-announce-conferences@uunet.uu.net, stds-802-wpan@ieee.org In-Reply-To: <88b9e992041122212238fbd303@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <88b9e992041122212238fbd303@mail.gmail.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 23 Nov 2004 08:28:54 -0500 Subject: [Mip6] Broadnets 2005 Wireless Networking Symposium X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: B Krishnamachari List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: 7bit ---------------------------------------------------------------------- CALL FOR PAPERS Second Annual International Conference on Broadband Networks (BROADNETS 2005) Broadband Wireless Networking Symposium October 3 - 7, 2005 Boston, Massachusetts, USA http://www.broadnets.org Submission Deadline: February 1, 2005 ----------------------------------------------------------------------- SCOPE ----- BroadNets 2005 is an international conference focusing on broadband networking and covers the entire gamut of next generation networks with high bandwidth available for both wireless and wireline networks. The conference will consist of the following three symposia: ** Broadband Wireless Networking Symposium: covers mobility, routing for multihop, multimedia QoS and traffic management, cross-layer optimization, MAC and emerging physical layer technologies (UWB, MIMO) for high-speed wireless networking. ** Broadband Optical Networking Symposium: covers WDM technologies, Ethernet and MPLS integration into the optical layer, Next-Generation SONET/SDH, as well as SAN extensions over DWDM/SONET/SDH. ** Broadband Applications/Services Symposium: covers middleware and service architectures for broadband applications, pervasive computing and ubiquitous communications, and universal broadband access for information services. BroadNets 2005 will thus offer a unique forum for researchers from academia, government and industry to share ideas and disseminate new results in these important areas. This Call for Papers describes the details for the Broadband Wireless Networking Symposium ONLY. (Refer to the www.broadnets.org/2005 website for the details of Broadband Optical Symposium and Broadband Applications/Services Symposium.) We are soliciting full papers in all research, development, and deployment areas on broadband wireless networking. Topics of interest include, but not limited to, the following: - 3G/4G Systems - Fixed Broadband Wireless Access - Wireless Local Area Networks - Wireless Indoor & Home Networks - Wireless Mesh Networks - Wireless Sensor Networks - Ultra Wideband (UWB) Networks - Ad-hoc Networks - Wireless Personal Area Networks - Free-Space Optics - Internetworking Heterogeneous Wireless/Wireline Networks - Network Topology Management - Unicast and Multicast Routing - Resource Management - Neighbour Discovery - MAC Protocol Design and Analysis including IEEE 802.11/15/16 - Software-Defined Radio - Space-Time Processing, MIMO Systems - Joint Physical/MAC Design - Smart (directional) Antennas - Power Control - Mobility, Location and Handoff Management - Routing in Multihop, Ad-hoc and Sensor Networks - Multimedia QoS and Traffic Management - Security Techniques and Systems Conference proceedings will be published by IEEE Computer Society. A set of selected papers from the symposium will be published in a special issue of ACM/Kluwer Mobile Networks (MONET) Journal. IMPORTANT DATES --------------- Submission Deadline: February 1, 2005 Acceptance Notification: May 1, 2005 Final Manuscript Due: June 1, 2005 PAPER SUBMISSION INSTRUCTIONS ----------------------------- Authors are invited to submit full papers of up to 10 pages in IEEE conference proceedings format. Papers should be submitted in PDF format to the respective symposium through the EDAS system at http://edas.info/Conference.cgi. CONFERENCE ORGANIZING COMMITTEE ------------------------------- General Chair: Dr. Arun Somani, Iowa State University, arun@iastate.edu General Vice Chair: Dr. Thomas Hou, Virginia Tech, thou@vt.edu Technical Program Chair- Wireless Networking Symposium: Dr. Sherman Shen, Univ. of Waterloo, xshen@bbcr.uwaterloo.ca Technical Program Chairs - Optical Networking Symposium Dr. David Griffith, NIST, david.griffith@nist.gov Dr. Srini Ramasubramanian, Univ. of Arizona, srini@ece.arizona.edu Technical Program Chairs - Services and Applications Symposium Dr. Malathi Veeraraghavan, Univ. of Virginia, mv@cs.virginia.edu Dr. Admela Jukan, NSF, ajukan@nsf.gov Workshops Chairs: Dr. Wendi Heinzelman, University of Rochester, wheinzel@ece.rochester.edu Dr. Byrav Ramamurthy, University of Nebraska-Lincoln, byrav@cse.unl.edu Dr. Behcet Sarikaya, University of Northern British Columbia, sarikaya@unbc.ca Tutorials Chair: Dr. Steven Low, Cal. Tech., slow@caltech.edu Panels Chairs: Dr. Surendar Chandra, Univ. of Notre Dame, surendar@cse.nd.edu Dr. Rudra Dutta, NCSU, dutta@csc.ncsu.edu Publicity Chairs: Dr. Bhaskar Krishnamachari, USC, bkrishna@usc.edu Dr. Takeo Hamada, Fujitsu Labs of America, thamada@fla.fujitsu.com Website/Information Systems Chair: Dr. Shiwen Mao, Virginia Tech, smao@vt.edu Publications Chairs: Dr. Ahmed Kamal, Iowa State University, kamal@iastate.edu Dr. Hui Zang, Sprint Adv. Tech. Labs, hzang@sprintlabs.com Exhibits and Sponsorships Chair: Dr. Sai Shankar N, Philips Research USA, sai.shankar@philips.com Steering Committee Co-Chairs: Dr. Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu Dr. Krishna Sivalingam, Univ. of Maryland, Baltimore County, krishna@umbc.edu -------------------------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 24 02:29:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16838 for ; Wed, 24 Nov 2004 02:29:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrev-0003fJ-M4 for mip6-web-archive@ietf.org; Wed, 24 Nov 2004 02:33:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrXy-0001oQ-7h; Wed, 24 Nov 2004 02:26:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrUa-000060-78 for mip6@megatron.ietf.org; Wed, 24 Nov 2004 02:23:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11454 for ; Wed, 24 Nov 2004 02:23:06 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrYO-0002sk-Mo for mip6@ietf.org; Wed, 24 Nov 2004 02:27:05 -0500 Received: from samurai.local.sfc.wide.ad.jp (196.180.210.220.dy.bbexcite.jp [220.210.180.196]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id iAO7LYnG012025; Wed, 24 Nov 2004 16:21:34 +0900 Date: Wed, 24 Nov 2004 16:15:58 +0900 Message-ID: From: Ryuji Wakikawa To: kempf@docomolabs-usa.com Subject: Re: [Mip6] FW: MIP6 agenda (Final) In-Reply-To: <02f901c4ce55$810afee0$0f6115ac@dcml.docomolabsusa.com> References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> <419CEC8F.F29126E0@iprg.nokia.com> <20041119115503.4978b37f.ernst@sfc.wide.ad.jp> <02f901c4ce55$810afee0$0f6115ac@dcml.docomolabsusa.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: mip6@ietf.org, ernst@sfc.wide.ad.jp, rajeev@iprg.nokia.com, a-tamura@kddi.com, hr-horiuchi@kddilabs.jp X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Hi MIP6/NEMO protocol lacks capability to setup multiple paths to the Internet(i.e. HA). The problem is that a mobile host can not be configured as a multihomed node with the current spec. This is the basic issue of MIP6 that MIP6 WG should solve somehow immediately. KDDI is working on the multiple CoAs registration. KAME implementation also has the same feature with interoperability to KDDI. Some other companies uses our KAME stack to test multihoming experimentation, too. regards, ryuji At Fri, 19 Nov 2004 08:33:24 -0800, James Kempf wrote: > > Thierry, > > Are there any vendors interested in implementing this solution and/or > network operators interested in deploying it (note: I'm not asking for > detailed product plans, just the kind of committment that was given in, say, > the chartering discussion of the Mobike WG several IETFs ago)? Or other > standardization bodies (such as our good friends at 3GPP2) who are > interested in incorporating it into their standards? > > jak > > PS: BTW, if you haven't seen it, you should check out the literature on > Boeing's Connexion system. It uses BGP to manage routes to a mobile 802.11 > network in an airplane on a transcontinental flight. Lufthasa has deployed > it on their new A333-600's. > > > ----- Original Message ----- > From: "Thierry Ernst" > To: > Cc: > Sent: Thursday, November 18, 2004 6:55 PM > Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > > > > > Dear Rajeev, > > > > Mobopts is a reseach group (IRTF), the problem that we want to solve is > > much more clarified clarified than that, and solutions could be brought > > in a timely manner if we restrict ourselves to part of the exisiting > > problems and extensions to MIP6 and NEMO. > > > > Of course, taking a look at the whole picture would require much more > > consideration, and for the whole picture Mobopts could be the right > > place. But, my intention, right now, is not to open the pendora box; > > it's rather about bringing a solution to an immediate concern, in a > > timely manner: how can I make use of my MIP6/NEMO function when I have > > multiple interfaces on my MH/MR ? I can't do it right now, and not > > because it's np complex, but because there is no agreed solution between > > the parties involved. > > > > Regarding what has been said at the MIP6 meeting, taking into account > > the feedback from Erik, Thomas, and all the other, I would go for a BOF > > at next IETF, but not with the objective to set up a new WG, but just a > > one-time BOF to discuss the problem thoroughly. > > > > But, prior to doing that, the other people involved with me on the > > problem statement drafts, we should improve/clarify/extend our drafts. > > The target would be end of this year; based on new drafts we would > > consider setting up a BOF or not. (OK, guys, now we have pressure on our > > shoulders ;-) > > > > Thierry > > > > > > > > On Thu, 18 Nov 2004 10:40:15 -0800 > > Rajeev Koodli wrote: > > > > > Thierry Ernst wrote: > > > > > > > > Thus embarking on QoS sensitive, mobility specific multihoming > support > > > > > is both too open ended (on the QoS side) and too constraining (by > only > > > > > looking at cases when MIP/Nemo is used). > > > > > > > > > > So I think it would be useful for folks to try to think about and > > > > > discuss the bigger picture. > > > > > > > > Agree. But then, where should this discussion take place ? MIP6 WG ? > > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > > > > I would add to Erik's observation that we need to be able to assess a > topic to > > > see > > > the maturity of the problem and the state of solutions, as well as what > could > > > be standardized in IETF. The IETF should work on well-defined _and_ > > > well-agreed problems for which protocol specification could be > accomplished > > > in a timely manner. Topics where the problem needs to be crystalized, > and > > > solution > > > space needs "thinking" require a forum for discussion. And, MobOpts > could > > > be such a place. > > > > > > We (mip*, MobOpts co-chairs) are in the process of working out a model > to > > > facilitate closer co-operation between mip* groups and MobOpts. The > outcome > > > should be focussed discussion on topics of mutual interest that lead to > > > documents > > > which can be a) taken up in mip* groups for standardization, b) MobOpts > RG > > > RFCs. MobOpts would run milestones and try to produce documents within a > > > timeframe of interest to mip* groups. > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 24 02:48:27 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23436 for ; Wed, 24 Nov 2004 02:48:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrww-0005yI-Aj for mip6-web-archive@ietf.org; Wed, 24 Nov 2004 02:52:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrjK-0007r1-0K; Wed, 24 Nov 2004 02:38:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWrg5-0006Kg-7T for mip6@megatron.ietf.org; Wed, 24 Nov 2004 02:35:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20563 for ; Wed, 24 Nov 2004 02:34:59 -0500 (EST) Received: from shaku.sfc.wide.ad.jp ([203.178.143.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWrjt-00043p-QI for mip6@ietf.org; Wed, 24 Nov 2004 02:38:58 -0500 Received: from samurai.local.sfc.wide.ad.jp (196.180.210.220.dy.bbexcite.jp [220.210.180.196]) (authenticated bits=0) by shaku.sfc.wide.ad.jp (8.12.10/8.12.0) with ESMTP id iAO7LHnG012011; Wed, 24 Nov 2004 16:21:17 +0900 Date: Wed, 24 Nov 2004 15:38:04 +0900 Message-ID: From: Ryuji Wakikawa To: Alexandru.Petrescu@motorola.com Subject: Re: [Mip6] FW: MIP6 agenda (Final) In-Reply-To: <41A306DE.8000108@motorola.com> References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> <419CEC8F.F29126E0@iprg.nokia.com> <20041119115503.4978b37f.ernst@sfc.wide.ad.jp> <419E421D.BF063AA2@iprg.nokia.com> <41A1A03F.8070809@clarinet.u-strasbg.fr> <00d601c4d0b9$432ce780$0f6115ac@dcml.docomolabsusa.com> <41A3013E.2090509@clarinet.u-strasbg.fr> <41A306DE.8000108@motorola.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.2.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mip6@ietf.org, ernst@sfc.wide.ad.jp, kempf@docomolabs-usa.com, rajeev@iprg.nokia.com, montavont@clarinet.u-strasbg.fr X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hello Alex At Tue, 23 Nov 2004 10:46:06 +0100, Alexandru Petrescu wrote: > > [1 ] > [1.1 ] > >> progress, but the time may have come for someone with Mobile IP > >> expertiese to take a look at their solution and see how mobility > >> and Mobile IP fits in. > >> > > Unfortunatly I was not at the last IETF, I'll have to check the log. > > Was a desgin team already formed to investigate mobility feature in > > v6ops ? > > v6ops is somehow rechartering nowadays and somehow re-focusing, which > means somehow mobility is out-of-focus for them. > > OTOH there is a new public mip6-mip4-v6-v4 (miptrans) mailing list. > That's not a DT. I think that's not about multi-homing either, but > since it's new and inceptive I think you should check their drafts see > how multihoming may fit in. My oppinion is it doesn't but check it out. > http://tinyurl.com/5j8w6 > > I think better go to multi6. I agree that some issues can be discussed at multi6. But there is MIP6 specific issue. How can we discuss multihoming issues without capability of being multihomed mobile node? I think MIP6 WG should discuss how to setup multihomed mobile node/router at least. ryuji _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 24 05:04:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05406 for ; Wed, 24 Nov 2004 05:04:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWu4N-0006y3-M7 for mip6-web-archive@ietf.org; Wed, 24 Nov 2004 05:08:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWtz7-0004em-2a; Wed, 24 Nov 2004 05:02:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWttb-00032e-H7 for mip6@megatron.ietf.org; Wed, 24 Nov 2004 04:57:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04891 for ; Wed, 24 Nov 2004 04:57:05 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWtxR-0006A3-Pa for mip6@ietf.org; Wed, 24 Nov 2004 05:01:06 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iAO9wHNi022743; Wed, 24 Nov 2004 02:58:20 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (Motorola/il06exr03) with ESMTP id iAO9uc1L023416; Wed, 24 Nov 2004 03:56:39 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2E50C8A3C7A; Wed, 24 Nov 2004 10:56:38 +0100 (CET) Message-ID: <41A45ACF.3080800@motorola.com> Date: Wed, 24 Nov 2004 10:56:31 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [Mip6] FW: MIP6 agenda (Final) References: <697DAA22C5004B4596E033803A7CEF4403B1C10C@daebe007.americas.nokia.com> <20041111123630.1be973c6.ernst@sfc.wide.ad.jp> <4193C2B2.5050200@sun.com> <20041112061543.0a263a00.ernst@sfc.wide.ad.jp> <419CEC8F.F29126E0@iprg.nokia.com> <20041119115503.4978b37f.ernst@sfc.wide.ad.jp> <419E421D.BF063AA2@iprg.nokia.com> <41A1A03F.8070809@clarinet.u-strasbg.fr> <00d601c4d0b9$432ce780$0f6115ac@dcml.docomolabsusa.com> <41A3013E.2090509@clarinet.u-strasbg.fr> <41A306DE.8000108@motorola.com> In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: mip6@ietf.org, ernst@sfc.wide.ad.jp, kempf@docomolabs-usa.com, rajeev@iprg.nokia.com, montavont@clarinet.u-strasbg.fr X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1459614085==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1459614085== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig81DD11D3E360D2ECB7BF5F82" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig81DD11D3E360D2ECB7BF5F82 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Ryuji Wakikawa wrote: > I agree that some issues can be discussed at multi6. But there is > MIP6 specific issue. How can we discuss multihoming issues without > capability of being multihomed mobile node? Ryuji, do we know how a non-mobile but multihomed node works? > I think MIP6 WG should discuss how to setup multihomed mobile > node/router at least. Let's see... Alex --------------enig81DD11D3E360D2ECB7BF5F82 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBpFrVMmC0w56zj54RAjwIAKCrRdq/+4Ohl+/cUwfcwRBS+0v81ACgwX39 78gfK71QAbQTT+nn1MycmUg= =vLGs -----END PGP SIGNATURE----- --------------enig81DD11D3E360D2ECB7BF5F82-- --===============1459614085== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1459614085==-- From mip6-bounces@ietf.org Wed Nov 24 07:53:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18690 for ; Wed, 24 Nov 2004 07:53:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWwiL-000763-PS for mip6-web-archive@ietf.org; Wed, 24 Nov 2004 07:57:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWwUN-0005WS-V9; Wed, 24 Nov 2004 07:43:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWwQq-0004pU-6L for mip6@megatron.ietf.org; Wed, 24 Nov 2004 07:39:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17522 for ; Wed, 24 Nov 2004 07:39:34 -0500 (EST) Received: from bay17-f12.bay17.hotmail.com ([64.4.43.62] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWwUh-0005aO-27 for mip6@ietf.org; Wed, 24 Nov 2004 07:43:36 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 24 Nov 2004 04:39:02 -0800 Message-ID: Received: from 218.22.21.23 by by17fd.bay17.hotmail.msn.com with HTTP; Wed, 24 Nov 2004 12:38:24 GMT X-Originating-IP: [218.22.21.23] X-Originating-Email: [garthdawn@hotmail.com] X-Sender: garthdawn@hotmail.com From: "Lee Garth" To: alper.yegin@samsung.com Subject: Re: [Mip6] Comments on jee-mip6-bootstrap-pana Date: Wed, 24 Nov 2004 12:38:24 +0000 Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312; format=flowed X-OriginalArrivalTime: 24 Nov 2004 12:39:02.0135 (UTC) FILETIME=[93AA5070:01C4D222] X-Spam-Score: 3.7 (+++) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA17522 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 3.7 (+++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Sir: I have read your draft and got confused with one question. How is MN's bootstrap necessities been routed to HAh?=20 MN send user-name AVP to AAA Client in PANA-Auth-Answer, which seems=20 the only value that can identify MN. How can signaling among the many nod= es=20 supporting Diameter and PANA managed to deliver MN's Identity to the HA w= ho=20 can act as agents for the MN? Thank you! Sincere= ly=20 yours = =20 Garthdawn _________________________________________________________________ =CF=ED=D3=C3=CA=C0=BD=E7=C9=CF=D7=EE=B4=F3=B5=C4=B5=E7=D7=D3=D3=CA=BC=FE=CF= =B5=CD=B3=A1=AA MSN Hotmail=A1=A3 http://www.hotmail.com =20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 24 23:49:18 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10106 for ; Wed, 24 Nov 2004 23:49:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXBdK-0007x7-0e for mip6-web-archive@ietf.org; Wed, 24 Nov 2004 23:53:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXBUs-000220-Mi; Wed, 24 Nov 2004 23:44:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXBTh-0001hF-Kj for mip6@megatron.ietf.org; Wed, 24 Nov 2004 23:43:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09787 for ; Wed, 24 Nov 2004 23:43:30 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXBXg-0007qs-Th for mip6@ietf.org; Wed, 24 Nov 2004 23:47:42 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAP4hM001207; Thu, 25 Nov 2004 06:43:23 +0200 (EET) X-Scanned: Thu, 25 Nov 2004 06:46:12 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iAP4kCX8010321; Thu, 25 Nov 2004 06:46:12 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00qpwzGH; Thu, 25 Nov 2004 06:46:11 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAP4hAa27381; Thu, 25 Nov 2004 06:43:10 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Nov 2004 06:43:08 +0200 Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Nov 2004 06:43:07 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Nov 2004 06:43:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: MIP6 agenda (Final) Date: Thu, 25 Nov 2004 06:43:06 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D4321CC@esebe056.ntc.nokia.com> Thread-Topic: [Mip6] FW: MIP6 agenda (Final) Thread-Index: AcTSDkTOPKsLtq2RQSOkb9Eegq3kowAmsfJA To: X-OriginalArrivalTime: 25 Nov 2004 04:43:07.0378 (UTC) FILETIME=[421DED20:01C4D2A9] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Alex, > > I agree that some issues can be discussed at multi6. But there is=20 > > MIP6 specific issue. How can we discuss multihoming issues without=20 > > capability of being multihomed mobile node? >=20 > Ryuji, do we know how a non-mobile but multihomed node works? Lots of discussion about this in Multi6. Multi6 is working on site multihoming, but there has been a lot of discussion of host multihoming there as well. =20 John =20 > > I think MIP6 WG should discuss how to setup multihomed mobile=20 > > node/router at least. >=20 > Let's see... >=20 > Alex >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 25 01:40:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19230 for ; Thu, 25 Nov 2004 01:40:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXDN4-00021X-Up for mip6-web-archive@ietf.org; Thu, 25 Nov 2004 01:44:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXDHm-0002cl-VQ; Thu, 25 Nov 2004 01:39:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXDD5-0001gG-ID for mip6@megatron.ietf.org; Thu, 25 Nov 2004 01:34:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18747 for ; Thu, 25 Nov 2004 01:34:30 -0500 (EST) Received: from clarinet.u-strasbg.fr ([130.79.90.157]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CXDH6-0001u5-LY for mip6@ietf.org; Thu, 25 Nov 2004 01:38:41 -0500 Received: (qmail 13953 invoked for bounce); 25 Nov 2004 06:34:29 -0000 Received: from unknown (HELO ?10.0.0.1?) (montavont@unknown) by unknown with SMTP; 25 Nov 2004 06:34:29 -0000 Message-ID: <41A57C0B.2060202@clarinet.u-strasbg.fr> Date: Thu, 25 Nov 2004 07:30:35 +0100 From: Nicolas Montavont User-Agent: Mozilla Thunderbird 0.8 (X11/20040926) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [Mip6] FW: MIP6 agenda (Final) References: <3CF661B1787ABF41A869BE20108F8D6D4321CC@esebe056.ntc.nokia.com> In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D4321CC@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Alexandru.Petrescu@motorola.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Hi all, I do agree that many working group talk about host multihoming (at least in personal drafts). What we have to decide now, is in which charter this feature should be included. As Ryuji pointed out, there are MIP6 specific issues. But at the first step, I believe that we should describe a problem statement, independant from any protocol. Once we have clearly identified what we want to solve, we can propose specific solutions. Here is a proposed list of working group candidates: - Mobopts - Multi6 - Ipv6ops - Miptran - MIP6 - Other ? Nicolas john.loughney@nokia.com wrote: >Alex, > > > >>>I agree that some issues can be discussed at multi6. But there is >>>MIP6 specific issue. How can we discuss multihoming issues without >>>capability of being multihomed mobile node? >>> >>> >>Ryuji, do we know how a non-mobile but multihomed node works? >> >> > >Lots of discussion about this in Multi6. Multi6 is working on site >multihoming, but there has been a lot of discussion of host multihoming >there as well. > >John > > > >>>I think MIP6 WG should discuss how to setup multihomed mobile >>>node/router at least. >>> >>> >>Let's see... >> >>Alex >> >> >> > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 25 01:46:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19800 for ; Thu, 25 Nov 2004 01:46:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXDSV-00028g-Jy for mip6-web-archive@ietf.org; Thu, 25 Nov 2004 01:50:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXDIg-0002tS-Ai; Thu, 25 Nov 2004 01:40:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXDGl-0002Q5-KH for mip6@megatron.ietf.org; Thu, 25 Nov 2004 01:38:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19085 for ; Thu, 25 Nov 2004 01:38:18 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXDKl-0001zN-To for mip6@ietf.org; Thu, 25 Nov 2004 01:42:29 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAP6cAS00686; Thu, 25 Nov 2004 08:38:11 +0200 (EET) X-Scanned: Thu, 25 Nov 2004 08:40:45 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id iAP6ejHJ009220; Thu, 25 Nov 2004 08:40:45 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 004PmXP7; Thu, 25 Nov 2004 08:40:43 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAP6bhS07661; Thu, 25 Nov 2004 08:37:43 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Nov 2004 08:37:42 +0200 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Nov 2004 08:37:42 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Nov 2004 08:37:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: MIP6 agenda (Final) Date: Thu, 25 Nov 2004 08:37:42 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D4321D2@esebe056.ntc.nokia.com> Thread-Topic: [Mip6] FW: MIP6 agenda (Final) Thread-Index: AcTSuOlLl4nx3PQoQsirhEKkpuz7agAABPzw To: X-OriginalArrivalTime: 25 Nov 2004 06:37:41.0810 (UTC) FILETIME=[43990120:01C4D2B9] X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Alexandru.Petrescu@motorola.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Nicolas, > I do agree that many working group talk about host multihoming (at = least=20 > in personal drafts). > What we have to decide now, is in which charter this feature should be = > included. >=20 > As Ryuji pointed out, there are MIP6 specific issues. But at the first = > step, I believe that we should describe a problem statement, = independant=20 > from any protocol. > Once we have clearly identified what we want to solve, we can propose=20 > specific solutions. >=20 > Here is a proposed list of working group candidates: > - Mobopts > - Multi6 > - Ipv6ops > - Miptran > - MIP6 > - Other ? Multi6 is closing and chartering a new working group to work on a Multi6 = protocol. This might be a possible candidate. V6Ops is also rechartering and = potentially starting a new working group to develop a specific protocol. My = assumption is that this would be out of scope of both working groups. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 25 05:11:33 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24420 for ; Thu, 25 Nov 2004 05:11:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXGfC-0007M2-Pz for mip6-web-archive@ietf.org; Thu, 25 Nov 2004 05:15:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXGUL-0001KJ-Ej; Thu, 25 Nov 2004 05:04:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXGRf-0000kB-2H for mip6@megatron.ietf.org; Thu, 25 Nov 2004 05:01:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23000 for ; Thu, 25 Nov 2004 05:01:44 -0500 (EST) Received: from dpt-info.u-strasbg.fr ([130.79.44.193]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXGVh-00076x-4t for mip6@ietf.org; Thu, 25 Nov 2004 05:05:58 -0500 Received: from [130.79.44.193] (dpt-info.u-strasbg.fr [130.79.44.193]) by dpt-info.u-strasbg.fr (8.12.8p1/8.12.8) with ESMTP id iAPA2vif021782; Thu, 25 Nov 2004 11:02:57 +0100 (CET) (envelope-from montavont@clarinet.u-strasbg.fr) Message-ID: <41A5ADD1.5040700@clarinet.u-strasbg.fr> Date: Thu, 25 Nov 2004 11:02:57 +0100 From: Nicolas Montavont User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041104 X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [Mip6] FW: MIP6 agenda (Final) References: <3CF661B1787ABF41A869BE20108F8D6D4321D2@esebe056.ntc.nokia.com> In-Reply-To: <3CF661B1787ABF41A869BE20108F8D6D4321D2@esebe056.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Alexandru.Petrescu@motorola.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit John, Thanks for these information. It's good to have everybody's opinion, so I encourage folks to post their own. Nicolas john.loughney@nokia.com wrote: > Nicolas, > > >>I do agree that many working group talk about host multihoming (at least >>in personal drafts). >>What we have to decide now, is in which charter this feature should be >>included. >> >>As Ryuji pointed out, there are MIP6 specific issues. But at the first >>step, I believe that we should describe a problem statement, independant >>from any protocol. >>Once we have clearly identified what we want to solve, we can propose >>specific solutions. >> >>Here is a proposed list of working group candidates: >> - Mobopts >> - Multi6 >> - Ipv6ops >> - Miptran >> - MIP6 >> - Other ? > > > Multi6 is closing and chartering a new working group to work on a Multi6 protocol. > This might be a possible candidate. V6Ops is also rechartering and potentially > starting a new working group to develop a specific protocol. My assumption is > that this would be out of scope of both working groups. > > John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 25 08:14:40 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10133 for ; Thu, 25 Nov 2004 08:14:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXJWG-0003Jg-7S for mip6-web-archive@ietf.org; Thu, 25 Nov 2004 08:18:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXJOa-0000pR-Mw; Thu, 25 Nov 2004 08:10:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXJNs-0000Se-Cz for mip6@megatron.ietf.org; Thu, 25 Nov 2004 08:10:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09811 for ; Thu, 25 Nov 2004 08:10:03 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXJRx-0003DJ-27 for mip6@ietf.org; Thu, 25 Nov 2004 08:14:17 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAPDA2vD003412 for ; Thu, 25 Nov 2004 14:10:02 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Nov 2004 14:10:00 +0100 Received: from emyklnt163.ao.ericsson.se ([150.236.92.63]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XRD6AF93; Thu, 25 Nov 2004 14:09:59 +0100 Received: by emyklnt163.ao.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 25 Nov 2004 21:09:58 +0800 Message-ID: <2D255349D9B1A04683757BFAD6D36796074E84ED@ejptont100.nrj.ericsson.se> X-Sybari-Trust: 91cd5803 8ac546dc bac5c22d 00000979 From: "Shinta Sugimoto (TO/NRJ)" To: "'mip6@ietf.org'" Date: Thu, 25 Nov 2004 21:09:57 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-2022-jp" X-OriginalArrivalTime: 25 Nov 2004 13:10:00.0439 (UTC) FILETIME=[11B6C070:01C4D2F0] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Mip6] question: SA update in dynamic keying scenario X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Dear all, I need clarification on how MIPv6 and IPsec/IKE should interwork in dynamic keying scenario. According to RFC 3775 and 3776, there are two cases in dynamic keying scenario depending on availability of K-bit support negotiated between the MN and HA in home registration. When K-bit is ON, both MN and HA have capability to update IKE endpoints whenever the MN changes its primary CoA. When K-bit is OFF, MN and HA should re-establish phase 1 connection each other. It is clearly noted in the specification the difference between the outcome of the two scenarios is necessity of re-establishing phase 1 connection. However, I could not find clear description of how IPsec SAs (particularly tunnel mode SA pairs required to protect RR signals and user traffic) should be managed. My question is, "*who* is responsible for updating /re-establishing IPsec SA in dynamic keying scenarios upon MN's movement ?" Should MIPv6 always be responsible for updating the endpoint address of the tunnel mode SA (as it does in manual keying scenario) ? Or IKE daemon should run phase 2 negotiation to establish new IPsec SA ? When we discussed this issue with MIPv6 implementators from Linux and BSD community, we saw disparity of interpretation. (Some people say that MIPv6 should always be the one who updates tunnel endpoint, and some people say IKE daemon should re-establish IPsec SA in dynamic keying scenario) So, I just would like to clarify this issue on the list. Any comments are appreciated. Regards, Shinta _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 25 08:46:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12324 for ; Thu, 25 Nov 2004 08:46:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXK1e-0003xB-A2 for mip6-web-archive@ietf.org; Thu, 25 Nov 2004 08:51:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXJwG-00081b-LF; Thu, 25 Nov 2004 08:45:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXJp6-0006c7-7h for mip6@megatron.ietf.org; Thu, 25 Nov 2004 08:38:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11373 for ; Thu, 25 Nov 2004 08:38:10 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXJtB-0003iw-1x for mip6@ietf.org; Thu, 25 Nov 2004 08:42:25 -0500 Received: from ETRIYSLEE ([192.168.250.22]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Nov 2004 22:37:59 +0900 Message-ID: <000301c4d2f3$f0547810$16faa8c0@ETRIYSLEE> From: "Junghoon Jee" To: "Lee Garth" , "Alper Yegin" References: Subject: Re: [Mip6] Comments on jee-mip6-bootstrap-pana Date: Thu, 25 Nov 2004 22:37:42 +0900 Organization: CMS MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-OriginalArrivalTime: 25 Nov 2004 13:37:59.0329 (UTC) FILETIME=[FA690910:01C4D2F3] X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Junghoon Jee List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0601027381==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 --===============0601027381== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGksIEdhcnRoZGF3bi4NCg0KSW4gdGhlIEFBQSBpbmZyYXN0cnVjdHVyZSwgd2UgY2FuIHJvdXRl IHRoZSBNTidzIGJvb3RzdHJhcCByZXF1ZXN0DQp0byB0aGUgTU4ncyBob21lIEFBQSBzZXJ2ZXIs IEFBQWggdXNpbmcgdGhlIE5BSSB3aGljaCBpcyBjb250YWluZWQgaW4gdGhlIFVzZXItTmFtZSBB VlAuDQoNClRoZSBBQUFoIGFzc2lnbnMgdGhlIEhBaCBmb3IgdGhlIE1OLiBUaGUgYXNzaWduZWQg SEFoIGluZm9ybWF0aW9uIGlzDQpjb250YWluZWQgaW4gdGhlICBNSVB2Ni1Ib21lLUFnZW50LUFk ZHJlc3MgQVZQIHdoaWNoIGlzIGRlbGl2ZXJlZCBieSB0aGUgQU1BDQphbmQgUEFOQS1CSU5ELVJF UVVFU1QgbWVzc2FnZXMuDQoNCkp1bmdob29uDQoNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAt LS0tLSANCkZyb206ICJMZWUgR2FydGgiIDxnYXJ0aGRhd25AaG90bWFpbC5jb20+DQpUbzogPGFs cGVyLnllZ2luQHNhbXN1bmcuY29tPg0KQ2M6IDxtaXA2QGlldGYub3JnPg0KU2VudDogV2VkbmVz ZGF5LCBOb3ZlbWJlciAyNCwgMjAwNCA5OjM4IFBNDQpTdWJqZWN0OiBSZTogW01pcDZdIENvbW1l bnRzIG9uIGplZS1taXA2LWJvb3RzdHJhcC1wYW5hDQoNCg0KDQpTaXI6DQogICAgSSBoYXZlIHJl YWQgeW91ciBkcmFmdCBhbmQgZ290IGNvbmZ1c2VkIHdpdGggb25lIHF1ZXN0aW9uLg0KICAgIEhv dyBpcyBNTidzIGJvb3RzdHJhcCBuZWNlc3NpdGllcyBiZWVuIHJvdXRlZCB0byBIQWg/IA0KICAg IE1OIHNlbmQgdXNlci1uYW1lIEFWUCB0byBBQUEgQ2xpZW50IGluIFBBTkEtQXV0aC1BbnN3ZXIs IHdoaWNoIHNlZW1zIA0KdGhlIG9ubHkgdmFsdWUgdGhhdCBjYW4gaWRlbnRpZnkgTU4uIEhvdyBj YW4gc2lnbmFsaW5nIGFtb25nIHRoZSBtYW55IG5vZGVzIA0Kc3VwcG9ydGluZyBEaWFtZXRlciBh bmQgUEFOQSBtYW5hZ2VkIHRvIGRlbGl2ZXIgTU4ncyBJZGVudGl0eSB0byB0aGUgSEEgd2hvIA0K Y2FuIGFjdCBhcyBhZ2VudHMgZm9yIHRoZSBNTj8NCg0KICAgIFRoYW5rIHlvdSENCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgU2luY2VyZWx5IA0KeW91cnMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQpHYXJ0aGRhd24NCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCs/t08PKwL3nyc/X7rTztcS159fT08q8/s+1zbOhqiBNU04gSG90bWFpbKGjICBodHRw Oi8vd3d3LmhvdG1haWwuY29tICANCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KTWlwNiBtYWlsaW5nIGxpc3QNCk1pcDZAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pcDY= --===============0601027381== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0601027381==-- From mip6-bounces@ietf.org Thu Nov 25 09:01:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13712 for ; Thu, 25 Nov 2004 09:01:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXKGE-0004M3-AQ for mip6-web-archive@ietf.org; Thu, 25 Nov 2004 09:06:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXK2l-0001RR-6v; Thu, 25 Nov 2004 08:52:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXK19-0000hY-FP for mip6@megatron.ietf.org; Thu, 25 Nov 2004 08:50:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12803 for ; Thu, 25 Nov 2004 08:50:37 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXK5E-000431-Ar for mip6@ietf.org; Thu, 25 Nov 2004 08:54:53 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAPDoO000340 for ; Thu, 25 Nov 2004 15:50:35 +0200 (EET) X-Scanned: Thu, 25 Nov 2004 15:50:03 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id iAPDo3Ef018683 for ; Thu, 25 Nov 2004 15:50:03 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00mA5Ftg; Thu, 25 Nov 2004 15:50:01 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAPDo0a08386 for ; Thu, 25 Nov 2004 15:50:00 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Nov 2004 15:49:49 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Nov 2004 15:49:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Nov 2004 15:49:30 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D4321FA@esebe056.ntc.nokia.com> Thread-Topic: [Momipriv] MoMiPriv Problem Statement Thread-Index: AcTRfksG4xFvXO/wTXyQUfsRCuZljgBdu+sg To: X-OriginalArrivalTime: 25 Nov 2004 13:49:30.0878 (UTC) FILETIME=[969B09E0:01C4D2F5] X-Spam-Score: 0.4 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Content-Transfer-Encoding: quoted-printable Subject: [Mip6] IETF 61 minutes X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 Content-Transfer-Encoding: quoted-printable Hi all, Here are my rough notes from the meeting. Please send corrections, = additions. I missed the last 5 minutes of the meeting, as I had to run = to the airport. thanks, John 1. AGENDA, BLUESHEETS, NOTE-TAKERS AND JABBER SCRIBES 5 MINS 2. DOC STATUS AD Review -=20 extentions to socket api for mipv6 mipv6 route optimization security design background wglc completed=09 MIPv6 & FW several comments, document to be updated & resubmited MIB status=20 Updated review, comments from MIB doctors 3. AUTH-ID DISCUSSION Was consensus call on list, believe that there was consensus on the = list Issue tracker created & suggestions to the draft are welcome. Thomas Narten: Appeal of MIPv6 Consensus call Consensus was rough, nice if it was clearer We don't formally vote Packing the room is something to look for, but lurkers can be informed = / posters can be uninformed. Counting company votes is dangerous. =20 Question / choices: Do not publish at all - has consequences for the relevance of the IETF Publish on standards track - sends signal that this has IETF support Publish as info - Does get IETF review & has been done in other cases, = e.g. - 3GPP James K - has interoperability concerns, but if just for 3GPP2, then its = OK. 3GPP2 has come to the IETF, so we should do it. Concerned about = standards track, because it might cause interoperability issues due to = multiple mechanisms. Would like MIP community to work better with = 3GPP2. Thomas Narten - we've had a relationship for 3 years with 3GPP and have = engineer to engineer working, agrees that would be nice to have with = 3GPP2. Basavaraj - disagrees that there will be interop problems. People who = want to deploy it are from 3gpp2, but could have wider possibly = applicability. Haven't heard about what the concerns of folks who don't = want this work. 3gpp2 guy - 3GPP2 needs this work, working with Thomas on liason = statement. Doesn't see interp issue. James K - Explained twice already. IETF can specify two mechanisms, but = operator can deploy just one. If you have a terminal that supports both = mechanisms, it may be confused which one can be used. Problem is a = deployment. Hesham - it's not an interop problem but a deployment problem. In = similar circumstantes, sometimes a higher order mechanism is needed for = negotiation. Wants third option. =20 ?? - Disagrees with James. We cannot control deployments. This is not = 3GPP specific. Thomas - should be careful about calling it an interop problem. Its not = black or white. It might be that 3GPP2 wants to avoid the IPsec = mechanism. There can be a cost with multiple mechanisms. Eric Nordmark - unwise to have multiple mechanisms; we will have to = implement both or circumstances will not work. Thinks that some = assumptions are wrong. If we have multiple mechanisms, then we should = have a good reason for this. Basavaraj - saying that the HA will need to implement both, terminal = will only need one. Jari - it doesn't have to be a weaker option. interop issue - distintion = is that 2 random nodes will authenticate to each other. Pete - this mechanism is needed to interface with existing credentials, = removed IPsec from current architecture because IPsec / IKE v1 cannot = interface with existing credentials James - thinks we should go back to 3GPP2 and get them to find out about = what is needed for IKEv2 Someone - wonder if this could be handled in IPv6 host or MIPv6 host. 3GPP2 guy - only argument we have heard against this interoperability. = Don't we have rough consensus. Thomas - we don't vote, some people are debating the validity of the = consensus. 3GPP2 - from the business perspective, saying it won't interoperate = isn't convincing. Basavaraj - doesn't see the benefit of publishing this as info. Greg Daley - tried to stay out of this discussion. Thinks we need = encryption between the HA & MN, but how to get the key? Thinks we = should work on this, doesn't care about the status of the document, but = would like do work on this. We need an AS on this mechanism. Concerned = that the Security Area will barf on this. Thomas - 3GPP2 needs this soon, so we need to complete this. Greg Daily- then we need to get people involved in it. Concerned about = there is no ESP here. Need a checklist for this. Need strong = applicability statement on the features - multicast traffic might be = spoofed, etc. Ghopal - if we do go info, we will have deployment, then future work can = be dependent on it. =20 Thomas - thinks this will be an ongoing topic for discussion. Someone - thinks there is an impact on other MIP related topics. We = will have 2 solutions on the handset. Thomas=20 How many people don't want it at all - noone Do this as a standards track - 9 Publish as informational - 30 Greg Daily- Release this as an experimental doc, but work on it still. Thomas Narten- reasonable to pub as info, but work on it still Hesham - can't have a contract promising anything, shouldn't be a = problem releasing it as info.=20 Thomas Narten - 3GPP2 would prefer standards track. Pekka Savola - we cannot make a contract, publish as info/exp. because = of timing requirements, and then analyze the problem more. 4. MIP6 OPERATION WITH IKEV2 AND THE REVISED IPSEC ARCH 4.1 I-D: draft-ietf-mip6-ikev2-ipsec-00.txt - Vijay Devarapalli See slides Open issue on level of support of IKEv2 Richard Graves - question on support for manual vs dynamic keys Jari Arkko - on should / may / etc. - is this 3775-bis or is it IKEv2 = support. If it is the later, then it should be a MUST. Francis Dupont - have a concern about MUST=20 someone from Ericsson - question about IPsec SA, would like to see a = reference to the revised security arch Vijay Devarapalli- sees an interop issue with IPsec,=20 Hesham Soliman - are we moving away from tunnel-based mechanism. =20 Francis - Doesn't think this is a good way (use of EAP) PM - this is the most important mechanism & likely to be deployed James Kempf - thinks that Home Address Config should be a SHOULD EN - thinks that this is related to bootstrapping discussion. It would = be good to do as much as possible together. Jari Arkko - thinks bootstrapping support here is a good thing. 4.2 Using IPsec to protect signaling between MN and CN 5 Mins I-D: draft-dupont-mipv6-cn-ipsec-01.txt see presentation Question is that, can this mechanism be used to secure = route-optimizatoin Vijay Devarapalli- support this work James Kempf - thinking about mobike here. a bit early to think how = these will interact, but should think about this. Will this work for = transport as well as tunnel mode? then its a good idea. Francis Dupont - yes. Suresh - thinks its a good idea, applicability is clear. Objections to making this a WG item? No comments. It will become a wg = item, after confirmation on the ML. 4.3 Care-of address test procedure using a state cookie 5 Mins I-D: Annex of draft-dupont-mipv6-cn-ipsec-01.txt Francis Dupont Vijay Devarapalli- coa test can be used. Christian - comment about coa test James Kempf - rechartering discussed breaking-up the main spec into = functionalities, should we do this? EN ? - doesn't understand how this is related to the COA test in base = spec. Sees that this is general mechanism. Jari Arkko - when we do security, we should do it all in one place to = make sure we capture all the interactions in one place. 5. AAA AND MOBILE IPV6 20 MINS 5.1 I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt & I-D: = draft-yegin-mip6-aaa-fwk-00.txt =20 Giaretta Gerardo/Alper Yegin Junghoon Jee - question about scenario 1 - cannot understand where the = network service occurs. PM - possible to seperate NAS from MIPv6, so we should seperate the = authentication here. someone - have to think about how to authorize the network service. Hesham Soliman - Scenario 2 - do auth on NAI or something, not on the = home address option. Junghoon Jee - need some extention for Diameter / RADIUS Greg Daily- sounds like this is related with 3GPP2 provider case, would = be worth discussing. Hesham Soliman - this is good for IPsec. James Kempf - likes this, would like to remind people that there are = hotspots without link security and authenticates via web page. This = solution won't work if you don't have a AAA infra. Should we work on this? Hesham Soliman - what is the intention of this? Basavaraj Patil - development requirements for AAA work. 6. MIPV6 AUTHORIZATION AND CONFIGURATION BASED ON EAP 10 MINS I-D: draft-giaretta-mip6-authorization-eap-02.txt Giaretta Gerardo someone - how to define aaa server between ha & aaa server? Pasi Eronen - lots of info that would like to provision to user. EAP = isn't the right approach. Jari Arkko - agrees with Pasi. There are procedural issues as well as = technical. This approach might not require AP changes, but changes to = EAP methods. If you can re-use existing protocols, this is easier. If = you want to use EAP for new purposes, this is harder. James Kempf - would prefer to be minimalistic here. Hesham Soliman - agree we need to draw a limit, but there are 3 levels = of auth typically. There is interest in leveraging AAA infra for this. = Doesn't think this will change EAP much. 7. APPLICATION MASTER SESSION KEY (AMSK) FOR MOBILE IPV6 5 MINS I-D: draft-giaretta-mip6-amsk-00.txt Giaretta Gerardo Jari Arkko - question on changes to EAP framework. As a whole, there are = more requirements than just on EAP methods, may be changing EAP API. Hesham Soliman - does EAP SIM produce an AMSK? Jari Arkko - I think so. 8. DIAMETER MOBILE IPV6 BOOTSTRAPPING APPLICATION USING PANA 15 MINS I-D: draft-jee-mip6-bootstrap-pana-00.txt I-D: draft-tschofenig-mip6-bootstrapping-pana-00.txt Junghoon Jee, Hannes Tschofenig James Kempf - Question - PANA can work with EAP. Has a problem defining = PANA to go beyond 1st hop link. ICMP often doesn't work after 1st hop. Yoshihiro Ohba - PANA runs over UDP. James Kempf - takes back his issue.=20 9. MOBILE IPV6 BOOTSTRAPPING ARCHITECTURE USING DHCP 15 MINS I-D: draft-ohba-mip6-boot-arch-dhcp-00 Yoshihiro Ohba James Kempf - Ralph Droms mentioned that backending DHCP server into AAA = server is not a good idea. Same problem about=20 NAS pushing stuff into DHCP server. OK to put Home Address into DHCP = server. Concerned about the complications & bittleness of this. 10. BOOTSTRAP CONTROL FUNCTION MECHANISM FOR MOBILE IPV6 BOOTSTRAP 10 = MINS I-D: draft-deng-mip6-bootstrap-bcf-00.txt Hui Deng discuss on list with rest of the bootstrapping stuff. Possible design = team issue. 11. PRECOMPUTABLE BINDING MANAGEMENT KEY KBM FOR MOBILE IPV6 5 MINS I-D: draft-ietf-mip6-precfgkbm-01.txt Charles Perkins procede with this document. 12. IMPROVEMENT OF RETURN ROUTABILITY PROTOCOL 10 MINS I-D: draft-qiu-mip6-rr-improvement-00.txt Jianying ZHOU 13. Next steps Chairs 5 Mins Time permitting, we will discuss these IDs and interest in this work: a. Multihoming in MIP6 I-Ds: draft-montavont-mobileip-multihoming-pb-statement-02.txt draft-ernst-generic-goals-and-benefits-00.txt Nicolas Montavont b. Load Balance for Distributed Home Agents in Mobile IPv6 I-D: draft-deng-mip6-ha-loadbalance-02.txt Hui Deng _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 25 09:39:25 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16784 for ; Thu, 25 Nov 2004 09:39:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXKqS-0005I7-LU for mip6-web-archive@ietf.org; Thu, 25 Nov 2004 09:43:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXKcY-0002Qa-K2; Thu, 25 Nov 2004 09:29:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXKXZ-00019u-4U for mip6@megatron.ietf.org; Thu, 25 Nov 2004 09:24:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15673 for ; Thu, 25 Nov 2004 09:24:07 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXKbd-0004uv-Lf for mip6@ietf.org; Thu, 25 Nov 2004 09:28:22 -0500 Received: from iseran.local (Q118074.ppp.dion.ne.jp [61.204.118.74]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 204054C0BE for ; Thu, 25 Nov 2004 23:23:19 +0900 (JST) Date: Thu, 25 Nov 2004 23:26:10 +0900 From: Thierry Ernst To: mip6@ietf.org Subject: Re: [Mip6] FW: MIP6 agenda (Final) Message-Id: <20041125232610.4bc1f1ff.ernst@sfc.wide.ad.jp> In-Reply-To: <41A57C0B.2060202@clarinet.u-strasbg.fr> References: <3CF661B1787ABF41A869BE20108F8D6D4321CC@esebe056.ntc.nokia.com> <41A57C0B.2060202@clarinet.u-strasbg.fr> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Hi > Here is a proposed list of working group candidates: > - Mobopts > - Multi6 > - Ipv6ops > - Miptran > - MIP6 > - Other ? May be a special purpose BOF to discuss the topic at length (without interfering with topics of other WGs and ending up rushing up in 5 minutes at end of slot), or a new WG, with a charter limited to only produce a problem statement ? BTW, Thomas Narten pointed out the need for listing the problems specific to MIP6, if I didn't mixed what he said on the mic. Thierry _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 25 11:59:32 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29235 for ; Thu, 25 Nov 2004 11:59:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXN26-0000Au-7n for mip6-web-archive@ietf.org; Thu, 25 Nov 2004 12:03:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXMsE-0002Su-VW; Thu, 25 Nov 2004 11:53:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXMme-0001Fo-Qm for mip6@megatron.ietf.org; Thu, 25 Nov 2004 11:47:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28111 for ; Thu, 25 Nov 2004 11:47:49 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXMql-0008KR-1S for mip6@ietf.org; Thu, 25 Nov 2004 11:52:07 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iAPGkwl05041; Thu, 25 Nov 2004 17:46:58 +0100 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 iAPGkwSj068997; Thu, 25 Nov 2004 17:46:58 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411251646.iAPGkwSj068997@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Shinta Sugimoto (TO/NRJ)" Subject: Re: [Mip6] question: SA update in dynamic keying scenario In-reply-to: Your message of Thu, 25 Nov 2004 21:09:57 +0800. <2D255349D9B1A04683757BFAD6D36796074E84ED@ejptont100.nrj.ericsson.se> Date: Thu, 25 Nov 2004 17:46:58 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "'mip6@ietf.org'" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a In your previous mail you wrote: However, I could not find clear description of how IPsec SAs (particularly tunnel mode SA pairs required to protect RR signals and user traffic) should be managed. My question is, "*who* is responsible for updating /re-establishing IPsec SA in dynamic keying scenarios upon MN's movement ?" Should MIPv6 always be responsible for updating the endpoint address of the tunnel mode SA (as it does in manual keying scenario) ? Or IKE daemon should run phase 2 negotiation to establish new IPsec SA ? => MIPv6 is responsible of the update of the SAD and the SPD. If you'd like to make this by IKE you should go to the Mobike WG, not the Mip6 one. When we discussed this issue with MIPv6 implementators from Linux and BSD community, we saw disparity of interpretation. (Some people say that MIPv6 should always be the one who updates tunnel endpoint, and some people say IKE daemon should re-establish IPsec SA in dynamic keying scenario) => IKE cannot know what to do if the SPD is not updated. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 25 13:20:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05358 for ; Thu, 25 Nov 2004 13:20:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXOIA-0001wU-S3 for mip6-web-archive@ietf.org; Thu, 25 Nov 2004 13:24:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXOCI-0001Rm-TA; Thu, 25 Nov 2004 13:18:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXO9i-0000ig-5A for mip6@megatron.ietf.org; Thu, 25 Nov 2004 13:15:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05011 for ; Thu, 25 Nov 2004 13:15:42 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXODp-0001q5-8g for mip6@ietf.org; Thu, 25 Nov 2004 13:20:01 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iAPIEnG19654; Thu, 25 Nov 2004 20:15:01 +0200 Date: Thu, 25 Nov 2004 20:14:49 +0200 (EET) From: Pekka Savola To: Thierry Ernst Subject: Re: [Mip6] FW: MIP6 agenda (Final) In-Reply-To: <20041125232610.4bc1f1ff.ernst@sfc.wide.ad.jp> Message-ID: References: <3CF661B1787ABF41A869BE20108F8D6D4321CC@esebe056.ntc.nokia.com> <41A57C0B.2060202@clarinet.u-strasbg.fr> <20041125232610.4bc1f1ff.ernst@sfc.wide.ad.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi, On Thu, 25 Nov 2004, Thierry Ernst wrote: >> Here is a proposed list of working group candidates: >> - Mobopts >> - Multi6 >> - Ipv6ops >> - Miptran >> - MIP6 >> - Other ? > > May be a special purpose BOF to discuss the topic at length (without > interfering with topics of other WGs and ending up rushing up in 5 > minutes at end of slot), or a new WG, with a charter limited to only > produce a problem statement ? I agree, though I'd say there should be no need to spin up a WG just to provide a problem statement, a couple of good individuals and a BoF would probably be OK. :) And unless there are enough interested participants, a WG isn't going to help.. > BTW, Thomas Narten pointed out the need for listing the problems > specific to MIP6, if I didn't mixed what he said on the mic. His point was to: 1) identify the generic issues (not MIPv6 specific) * and maybe work on these somewhere else 2) identify the MIPv6 specific issues * and possibly work on these in MIP6 WG To get there, I might suggest that someone consider creating a 'host mobility & multihoming in ipv6' (hmm6?) mailing list, and try to discuss and work on the above two problems there. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 25 20:36:31 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04956 for ; Thu, 25 Nov 2004 20:36:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXV6S-0002Qd-QJ for mip6-web-archive@ietf.org; Thu, 25 Nov 2004 20:40:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXV0G-0001Pp-UW; Thu, 25 Nov 2004 20:34:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXUz9-0001Al-VM for mip6@megatron.ietf.org; Thu, 25 Nov 2004 20:33:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04250 for ; Thu, 25 Nov 2004 20:33:18 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXV3K-0002Hm-R4 for mip6@ietf.org; Thu, 25 Nov 2004 20:37:39 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 574014C0C5; Fri, 26 Nov 2004 10:32:27 +0900 (JST) Date: Fri, 26 Nov 2004 10:35:24 +0900 From: Thierry Ernst To: Pekka Savola Subject: Re: [Mip6] FW: MIP6 agenda (Final) Message-Id: <20041126103524.465408ed.ernst@sfc.wide.ad.jp> In-Reply-To: References: <3CF661B1787ABF41A869BE20108F8D6D4321CC@esebe056.ntc.nokia.com> <41A57C0B.2060202@clarinet.u-strasbg.fr> <20041125232610.4bc1f1ff.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Dear Pekka, > On Thu, 25 Nov 2004, Thierry Ernst wrote: > >> Here is a proposed list of working group candidates: > >> - Mobopts > >> - Multi6 > >> - Ipv6ops > >> - Miptran > >> - MIP6 > >> - Other ? > > > > May be a special purpose BOF to discuss the topic at length (without > > interfering with topics of other WGs and ending up rushing up in 5 > > minutes at end of slot), or a new WG, with a charter limited to only > > produce a problem statement ? > > I agree, though I'd say there should be no need to spin up a WG just > to provide a problem statement, a couple of good individuals and a BoF > would probably be OK. :) > > And unless there are enough interested participants, a WG isn't going > to help.. > > > BTW, Thomas Narten pointed out the need for listing the problems > > specific to MIP6, if I didn't mixed what he said on the mic. > > His point was to: > 1) identify the generic issues (not MIPv6 specific) > * and maybe work on these somewhere else > 2) identify the MIPv6 specific issues > * and possibly work on these in MIP6 WG Thanks for being more precise than myself. So, we already have 2 drafts, but they both need to be enhanced (our intention is to issue new documents before the end of the year - let's say by January 3rd since nobody in some parts in the world would read over the holidays) > To get there, I might suggest that someone consider creating a 'host > mobility & multihoming in ipv6' (hmm6?) mailing list, and try to > discuss and work on the above two problems there. That's my intention too. I can do this. I wait over the week-end to see reactions of other people, and they we can create it. I was thinking about other names, though: multiface (MULTIple interFACEs) or MM6 (hmm6 sounds better than MM6) ;-) Thierry. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 26 10:07:39 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13903 for ; Fri, 26 Nov 2004 10:07:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXhlK-0002hf-ON for mip6-web-archive@ietf.org; Fri, 26 Nov 2004 10:12:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhTx-0005wB-Jj; Fri, 26 Nov 2004 09:53:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhQY-0004Lr-9x for mip6@megatron.ietf.org; Fri, 26 Nov 2004 09:50:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06510 for ; Fri, 26 Nov 2004 08:08:16 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXfty-00006M-2B for mip6@ietf.org; Fri, 26 Nov 2004 08:12:43 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAQD8Eh5015651 for ; Fri, 26 Nov 2004 14:08:14 +0100 (MET) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Nov 2004 14:08:14 +0100 Received: from emyklnt163.ao.ericsson.se ([150.236.92.63]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id X4ZT9PY3; Fri, 26 Nov 2004 14:08:14 +0100 Received: by emyklnt163.ao.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 26 Nov 2004 21:08:12 +0800 Message-ID: <2D255349D9B1A04683757BFAD6D36796074E84FA@ejptont100.nrj.ericsson.se> X-Sybari-Trust: 0cc78145 96d33411 7f4b8de8 00000138 From: "Shinta Sugimoto (TO/NRJ)" To: "'Francis.Dupont@enst-bretagne.fr'" Subject: RE: [Mip6] question: SA update in dynamic keying scenario Date: Fri, 26 Nov 2004 21:08:10 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Nov 2004 13:08:14.0614 (UTC) FILETIME=[FD0CE360:01C4D3B8] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "'mip6@ietf.org'" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Dear Francis, Thank you for your comments. Please find my comments/questions inline. > -----Original Message----- > From: Francis.Dupont@enst-bretagne.fr > [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Friday, November 26, 2004 1:47 AM > To: Shinta Sugimoto (TO/NRJ) > Cc: 'mip6@ietf.org' > Subject: Re: [Mip6] question: SA update in dynamic keying scenario > > > In your previous mail you wrote: > > However, I could not find clear description of how IPsec > SAs (particularly > tunnel mode SA pairs required to protect RR signals and > user traffic) > should be managed. My question is, "*who* is responsible > for updating > /re-establishing IPsec SA in dynamic keying scenarios upon MN's > movement ?" Should MIPv6 always be responsible for updating the > endpoint address of the tunnel mode SA (as it does in manual keying > scenario) ? Or IKE daemon should run phase 2 negotiation > to establish > new IPsec SA ? > > => MIPv6 is responsible of the update of the SAD and the SPD. If you'd > like to make this by IKE you should go to the Mobike WG, not > the Mip6 one. I am not trying to make a big change to IKE(v1). Just would like to know what the correct interpretation of the spec is. More comments below. > When we discussed this issue with MIPv6 implementators from > Linux and BSD community, we saw disparity of interpretation. > (Some people say that MIPv6 should always be the one who updates > tunnel endpoint, and some people say IKE daemon should re-establish > IPsec SA in dynamic keying scenario) > > => IKE cannot know what to do if the SPD is not updated. There is no doubt that SPD should be updated by MIPv6. But then I believe that normal IKE daemon can be kicked by the acquire message since there is no appropriate SA entry. (from performance perspective, updating SADB by MIPv6 is far better than running IKE, of course) BTW, assuming that MIPv6 is totally responsible for updating SPD/SADB when the MN performs movement, I wonder what would the benefit of supporting K-bit be ? Is it just for saving bytes of message exchanges required for phase 1 negotiation ? It seems to me that K-bit capability does not improve latency nor minimize packet drop during the movement. Is my understanding correct? Regards, Shinta _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 26 10:27:17 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17235 for ; Fri, 26 Nov 2004 10:27:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXi4X-0003VF-9M for mip6-web-archive@ietf.org; Fri, 26 Nov 2004 10:31:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhmU-0006cU-Ec; Fri, 26 Nov 2004 10:13:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXhkA-0004IQ-8v for mip6@megatron.ietf.org; Fri, 26 Nov 2004 10:10:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07924 for ; Fri, 26 Nov 2004 08:29:49 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXgEq-0000YX-8Z for mip6@ietf.org; Fri, 26 Nov 2004 08:34:16 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id iAQDT9p21636; Fri, 26 Nov 2004 14:29:09 +0100 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 iAQDT9Sj073638; Fri, 26 Nov 2004 14:29:09 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200411261329.iAQDT9Sj073638@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Shinta Sugimoto (TO/NRJ)" Subject: Re: [Mip6] question: SA update in dynamic keying scenario In-reply-to: Your message of Fri, 26 Nov 2004 21:08:10 +0800. <2D255349D9B1A04683757BFAD6D36796074E84FA@ejptont100.nrj.ericsson.se> Date: Fri, 26 Nov 2004 14:29:09 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: "'mip6@ietf.org'" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 In your previous mail you wrote: Thank you for your comments. Please find my comments/questions inline. > => MIPv6 is responsible of the update of the SAD and the SPD. If you'd > like to make this by IKE you should go to the Mobike WG, not > the Mip6 one. I am not trying to make a big change to IKE(v1). Just would like to know what the correct interpretation of the spec is. => so you'd like to keep MIPv6... > When we discussed this issue with MIPv6 implementators from > Linux and BSD community, we saw disparity of interpretation. > (Some people say that MIPv6 should always be the one who updates > tunnel endpoint, and some people say IKE daemon should re-establish > IPsec SA in dynamic keying scenario) > > => IKE cannot know what to do if the SPD is not updated. There is no doubt that SPD should be updated by MIPv6. => note this is enough: when a packet matches a SPD entry requiring IPsec protection, if there is no suitable SA it will be established (cf. outgoing processing, PF_KEY acquire and of course IKE). But then I believe that normal IKE daemon can be kicked by the acquire message since there is no appropriate SA entry. (from performance perspective, updating SADB by MIPv6 is far better than running IKE, of course) => I agree. SPD update is mandatory, SAD is not but is highly recommended (better performance, no dangling SA). BTW, assuming that MIPv6 is totally responsible for updating SPD/SADB when the MN performs movement, I wonder what would the benefit of supporting K-bit be ? => with IKEv1 K=1 is fine for rekeying: when K=0 the idea is to have a short phase 1 in order to just setup the needed SAs. When K=1 the phase 1 can be kept as it is reusable in the long term. With IKEv2 IPsec SAs are managed and the IKE SA should be long term so K=1 is really needed (i.e., it is no more a marginal optimization). BTW to implement K=1 is very easy: IKE should keep a correct image of the SPD so when the SPD/SAD is updated IKE should be noticed by a message. In this message IKE can get the info (i.e., all the addresses). Is it just for saving bytes of message exchanges required for phase 1 negotiation ? => it is a bit more. Phase 1 adds a lot of delay, a movement can occur just at the bad time, etc. In fact K=1 simply gives more reliable operations. It seems to me that K-bit capability does not improve latency nor minimize packet drop during the movement. Is my understanding correct? => if you reduce movement to home registration you're right. But MIPv6 is supposed to be more. Regards Francis.Dupont@enst-bretagne.fr PS: more offline and with some delay? _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 26 14:41:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14831 for ; Fri, 26 Nov 2004 14:41:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXm2I-0003UT-WC for mip6-web-archive@ietf.org; Fri, 26 Nov 2004 14:45:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXlwa-0005BT-Ck; Fri, 26 Nov 2004 14:39:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXlvX-0004vN-Hp for mip6@megatron.ietf.org; Fri, 26 Nov 2004 14:38:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14573 for ; Fri, 26 Nov 2004 14:38:42 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXlzi-0003N1-6q for mip6@ietf.org; Fri, 26 Nov 2004 14:43:12 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id iAQJcUR2014794 for ; Fri, 26 Nov 2004 20:38:31 +0100 Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Nov 2004 20:38:30 +0100 Received: from emyklnt164.ao.ericsson.se ([150.236.92.64]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id X4Z4BG4Q; Fri, 26 Nov 2004 20:38:30 +0100 Received: by emyklnt164.ao.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Sat, 27 Nov 2004 03:38:29 +0800 Message-ID: <7765A5A64EAAA4418C80C8AD0298CCF2197C0404@ejptont100.nrj.ericsson.se> X-Sybari-Trust: 01d98935 96d33411 7f4b8de8 00000138 From: "Shinta Sugimoto (TO/NRJ)" To: "'Francis.Dupont@enst-bretagne.fr'" Subject: RE: [Mip6] question: SA update in dynamic keying scenario Date: Sat, 27 Nov 2004 03:38:24 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 26 Nov 2004 19:38:30.0905 (UTC) FILETIME=[823F5690:01C4D3EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: "'mip6@ietf.org'" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Hello Francis, Please find my further comments inline. > -----Original Message----- > From: Francis.Dupont@enst-bretagne.fr > [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Friday, November 26, 2004 10:29 PM > To: Shinta Sugimoto (TO/NRJ) > Cc: 'mip6@ietf.org' > Subject: Re: [Mip6] question: SA update in dynamic keying scenario > ...[snip]... > BTW, assuming that MIPv6 is totally responsible for > updating SPD/SADB > when the MN performs movement, I wonder what would the benefit of > supporting K-bit be ? > > => with IKEv1 K=1 is fine for rekeying: when K=0 the idea is to have a > short phase 1 in order to just setup the needed SAs. When K=1 > the phase 1 > can be kept as it is reusable in the long term. Ok. It makes sense to use relatively long lifetime of ISAKMP SA in case of K=1. > With IKEv2 IPsec SAs are managed and the IKE SA should be long term so > K=1 is really needed (i.e., it is no more a marginal optimization). Could you please elaborate more on this ? Why K-bit becomes more important in IKEv2 ? > BTW to implement K=1 is very easy: IKE should keep a correct image of > the SPD so when the SPD/SAD is updated IKE should be noticed > by a message. > In this message IKE can get the info (i.e., all the addresses). Ok. The "message" seems to be the key. > Is it just for saving bytes of message exchanges > required for phase 1 negotiation ? > > => it is a bit more. Phase 1 adds a lot of delay, a movement can occur > just at the bad time, etc. In fact K=1 simply gives more reliable > operations. What I wanted to point out was that phase 1 negotiation (when K=0) puts no impact (in terms of delay and # of packet loss) on traffic which goes through the IPsec tunnel established between the MN and HA. If K=0, phase 1 negotiation should be run right after the movement. If K=1, phase 1 negotiation is run only when rekeying is required. In both cases, during the phase 1 negotiation the (tunnel mode) IPsec SA should be still valid, which means that traffic which goes through the IPsec tunnel is not affected by the incidents. So, I tend to think that advantage of K-bit is minimized overhead of IKE in terms of bandiwidth consumption. Am I missing something? > It seems to me that K-bit capability > does not improve latency nor minimize packet drop during > the movement. > Is my understanding correct? > > => if you reduce movement to home registration you're right. But MIPv6 > is supposed to be more. I hope I've already covered the issue you imply. Regards, Shinta _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 26 20:24:04 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16267 for ; Fri, 26 Nov 2004 20:24:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXrO9-0000fQ-Fz for mip6-web-archive@ietf.org; Fri, 26 Nov 2004 20:28:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXrIX-0006yu-Rs; Fri, 26 Nov 2004 20:22:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CXrEk-0006YP-T0 for mip6@megatron.ietf.org; Fri, 26 Nov 2004 20:18:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15950 for ; Fri, 26 Nov 2004 20:18:53 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CXrJ7-0000Qn-Ov for mip6@ietf.org; Fri, 26 Nov 2004 20:23:26 -0500 Received: from shell4.bayarea.net (shell4.BAYAREA.NET [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id iAR1IMKk018384; Fri, 26 Nov 2004 17:18:22 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id iAR1ILQk025881; Fri, 26 Nov 2004 17:18:21 -0800 Received: from localhost (heard@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id iAR1IKYl025875; Fri, 26 Nov 2004 17:18:21 -0800 X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 26 Nov 2004 17:18:20 -0800 (PST) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: MIP6 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Cc: "Wijnen, Bert \(Bert\)" Subject: [Mip6] MIB Doctor review for: draft-ietf-mip6-mipv6-mib-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Greetings, This MIB Doctor review of the MOBILEIPV6-MIB document looks at draft-ietf-mip6-mipv6-mib-05.txt. It is a follow-up to a previous review posted to the MIP6 mailing list on 15 October 2004 that dealt with draft-ietf-mip6-mipv6-mib-04.txt. While all comments in the previous review have been addressed by the -05 draft (for which I thank the authors), there are a number of new issues raised in this draft because I have finally had time to do a detailed reading of the MIB module (which I did not do before). The new issues are for the most part "non-mechanical" things (such as lack of clarity in DESCRIPTION clauses) that can only be caught by a detailed reading of the MIB module. My apologies for not being able to do this sooner. Let me hasten to say that for the most part I am quite pleased with the overall quality of this MIB module, and I believe that all the issues that I raise here will be quite easy to correct. One thing that I need to point out to the WG group is that while I know a good deal about MIB design, I am _not_ an expert on the MIP6 protocol, and because of that I am not always able to determine if the right things are being instrumented, or if something necessary is being omitted. It is therefore STRONGLY recommended that WG members with that kind of knowledge carefully review the document with an eye to those sorts of issues. As before, the format of the review is patterned after the checklist in Appendix A of . Those who wish to comment on it are asked to post their remarks to the MIP6 mailing list with copies to Bert Wijnen and myself. 1.) I-D Boilerplate -- OK 2.) Abstract -- OK 3.) MIB Boilerplate -- OK 4.) IPR Notice -- OK 5.) References -- OK 6.) Security Considerations Section -- OK 7.) IANA Considerations Section -- OK 8.) Copyright Notices -- OK 9.) Other issues (e.g., from http://www.ietf.org/ID-Checklist.html) that are not covered elsewhere: Typos -- (a) In Section 2.1, 1st paragraph: OLD: Mobile IPv6 (MIPv6) [RFC3775] specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. An entity which implements the MIPv6 protocol is an MIPv6 entity. There __________________________________________________^ are three types of entities envisaged by the MIPv6 protocol. NEW: Mobile IPv6 (MIPv6) [RFC3775] specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 Internet. An entity which implements the MIPv6 protocol is an MIPv6 entity. There are three types of entities envisaged by the MIPv6 protocol. (b) In Section 4: s/mip6HaGlobalAddrTable/mip6HaGlAddrTable/ (c) In the MIB module, mip6BindingHistoryEntry definition: OLD: mip6BindingHistoryEntry OBJECT-TYPE SYNTAX Mip6BindingHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The record of a binding . ___________________________________________^ NEW: mip6BindingHistoryEntry OBJECT-TYPE SYNTAX Mip6BindingHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The record of a binding. (d) In the REFERENCE clauses of mip6CnSeqNumberOutOfWindow, mip6CnExpiredHomeNonceIndex, mip6CnExpiredCareOfNonceIndex, mip6CnExpiredNonce, and mip6CnRegTypeChangeDisallowed: OLD: "RFC3775 : Section 6.1.8 9.5.1" NEW: "RFC3775 : Section 6.1.8, 9.5.1" (e) In the DESCRIPTION clause of mip6CnRegTypeChangeDisallowed: OLD: "The total number of Binding Updates rejected by correspondent node with status code in the Binding Acknowledgment message indicating 'registration type change disallowed' (Code 139 i.e. a binding _____________________________________________________^____^ already exists for the given home address and the home registration flag has a different value than the Home Registration (H) bit in the Binding Update. _______________________________________________________________________^ NEW: "The total number of Binding Updates rejected by correspondent node with status code in the Binding Acknowledgment message indicating 'registration type change disallowed' (Code 139, i.e., a binding already exists for the given home address and the home registration flag has a different value than the Home Registration (H) bit in the Binding Update). 10.) Technical content -- review of actual technical content for compliance with : (a) MIB compilation using smilint -- The program smilint 0.4.3, as of Wed Aug 18 15:45:50 2004 has been used to process your request as follows: smilint -m -s -e -l 9 -i namelength-32 MOBILEIPV6-MIB MOBILEIPV6-MIB:187: [5] {index-exceeds-too-large} warning: index of row `mip6BindingCacheEntry' can exceed OID size limit by 142 subidentifier(s) MOBILEIPV6-MIB:401: [5] {index-exceeds-too-large} warning: index of row `mip6BindingHistoryEntry' can exceed OID size limit by 143 subidentifier(s) MOBILEIPV6-MIB:765: [5] {index-exceeds-too-large} warning: index of row `mip6NodeTrafficEntry' can exceed OID size limit by 142 subidentifier(s) MOBILEIPV6-MIB:994: [5] {index-exceeds-too-large} warning: index of row `mip6MnHomeAddressEntry' can exceed OID size limit by 142 subidentifier(s) MOBILEIPV6-MIB:1232: [5] {index-exceeds-too-large} warning: index of row `mip6MnBLEntry' can exceed OID size limit by 399 subidentifier(s) MOBILEIPV6-MIB:1897: [5] {index-exceeds-too-large} warning: index of row `mip6CnCounterEntry' can exceed OID size limit by 142 subidentifier(s) MOBILEIPV6-MIB:2503: [5] {index-exceeds-too-large} warning: index of row `mip6HaCounterEntry' can exceed OID size limit by 142 subidentifier(s) MOBILEIPV6-MIB:2641: [5] {index-exceeds-too-large} warning: index of row `mip6HaListEntry' can exceed OID size limit by 143 subidentifier(s) MOBILEIPV6-MIB:2756: [5] {index-exceeds-too-large} warning: index of row `mip6HaGlAddrEntry' can exceed OID size limit by 144 subidentifier(s) These warnings are an expected result of using InetAddress objects in the INDEX clauses, and simply serve to indicate that certain size restrictions have to be observed in order for the MIB module to be useable with SNMPv1, SNMPv2c, or SNMPv3. In each case the conceptual row DESCRIPTION clause documents those restrictions and thus complies with the MIB review guidelines. No corrective action is required. Compilation with SMICng and mosy resulted in no errors or warnings. (b) Persistence of read-write values -- Section 4.6.2 of draft-ietf-ops-mib-review-guidelines-03.txt makes the following recommendation: For read-write objects (other than columns in read-create tables that have well-defined persistence properties) it is RECOMMENDED that the DESCRIPTION clause specify what happens to the value after an agent reboot. Among the possibilities are that the value remains unchanged, that it reverts to a well-defined default value, or that the result is implementation-dependent. There are seven read-write objects in the MOBILEIPV6-MIB: mip6Status (a scalar), mip6BindingAdminStatus (a member of mip6BindingCacheEntry), and mip6HaAdvPreference, mip6HaAdvLifetime, mip6HaPrefixAdv, mip6HaPrefixSolicitation, and mip6HaMCastCtlMsgSupport (all members of mip6HaConfEntry). For none of these objects does the DESCRIPTION clause specify what happens to the value after an agent reboot. For mip6Status I would suggest that the DESCRIPTION clause say at least that the last value set SHOULD survive an agent reboot. For mip6BindingAdminStatus it seems the value should share fate with the other members of the corresponsing mip6BindingCacheEntry row instance. I would expect that the rows in this table would not survive a reboot, but I am not a MIP6 protocol expert and as such I don't actually know what is expected of an implementation. If I am correct in assuming that the mip6BindingCacheTable is flushed after a reboot, then a statement to that effect in the mip6BindingCacheTable or mip6BindingCacheEntry DESCRIPTION clause would suffice. For mip6HaAdvPreference and the other members of the mip6HaConfEntry object it would seem that the ideal policy would be for the last- written values to survice a reboot, at least when the agent does not renumber interfaces (i.e., assign new ifIndex/ipv6InterfaceIfIndex values) after a reboot. Subject to this proviso, I would suggest that it be RECOMMENDED that last-written values survive an agent reboot. It would be acceptable to have a statement to that effect in the DESCRIPTION clause of mip6HaConfTable or mip6HaConfEntry. (c) The REFERENCE clause for mip6Capabilities points to RFC 3775 Section 6.1.8, which does not seem to be appropriate for this object. This should be corrected. (d) There probably should be a REFERENCE clause for mip6BindingMaxSeq that points to RFC 3775 Section 9.1 (and possibly also Section 9.5.1), and its SYNTAX value probably should be Unsigned32 (0..65536). (e) The SYNTAX values for mip6BindingUsageCount and mip6BindingHstUsageCount are inconsistent: one is Counter32, and the other is Unsigned32. Both should probably be Gauge32, since that type stops at 2^32-1 (rather than rolling over) if it hits the maximum value. Counter32 is not appropriate here since its behaviour is inconsistent with the DESCRIPTION. (f) The mip6TotalTraffic HC counter definitions use an incorrect SYNTAX value (Counter32 instead of Counter64). Corrections follow. OLD: mip6HCInOctets OBJECT-TYPE SYNTAX Counter32 ______________________________^^ NEW: mip6HCInOctets OBJECT-TYPE SYNTAX Counter64 OLD: mip6HCInPkts OBJECT-TYPE SYNTAX Counter32 ______________________________^^ NEW: mip6HCInPkts OBJECT-TYPE SYNTAX Counter64 OLD: mip6HCOutOctets OBJECT-TYPE SYNTAX Counter32 ______________________________^^ NEW: mip6HCOutOctets OBJECT-TYPE SYNTAX Counter64 OLD: mip6HCOutPkts OBJECT-TYPE SYNTAX Counter32 ______________________________^^ NEW: mip6HCOutPkts OBJECT-TYPE SYNTAX Counter64 (g) As in (d) above, it seem that the SYNTAX value for mip6MnBLMaxSeq probably should be Unsigned32 (0..65536). (h) RFC 3775 specifies that the following piece of information should be available in the conceptual Binding Update List: o A flag specifying whether or not future Binding Updates should be sent to this destination. The mobile node sets this flag in the Binding Update List entry when it receives an ICMP Parameter Problem, Code 1, error message in response to a return routability message or Binding Update sent to that destination, as described in Section 11.3.5. However, it was not clear to me that this information was available from the objects in the mip6MnBLTable. If it can be inferred from the value of mip6MnBLAccepted perhaps some text explaining how that is done would be in order. (i) It might be a good idea to change the SYNTAX value of mip6MnBLRetransmissions to Gauge32 to ensure that it stops at 2^32-1 rather than rolling over. (j) It seems that mip6MnBUAcksFromHA should probably have a REFERENCE clause pointing to RFC 3775 Section 11.7.3 (as does mip6MnBUAcksFromCN). (k) It seems that mip6CnBUsAccepted and mip6CnBUsRejected should both have a REFERENCE clause that points to RFC 3775 Sections 9.5.1 and 9.5.4. The former has no reference clause; the latter has one, but it points only to Section 9.5.1. (l) The DESCRIPTION clauses for mip6HaAdvsRecd and mip6HaAdvsSent do not refer to a discontinuity counter. Since these are global counters, mip6CounterDiscontinuityTime could be used, i.e., it would be appropriate to add the following text to the end of the DESCRIPTION clause: Discontinuities in the value of this counter can occur at re-initialization of the management system, and at other times as indicated by the value of mip6CounterDiscontinuityTime. (m) The REFERENCE clauses for mip6HaAdvsRecd and mip6HaAdvsSent point to REF 3775 Sections 6.1.8 and 9.5.1, which do not appear to be relevant. These clauses should be corrected (or removed). (n) The DESCRIPTION clauses of mip6HaPrefixAdv, mip6HaPrefixSolicitation, and mip6HaMCastCtlMsgSupport COULD be interpreted to mean that a SetRequest can only change the value from enabled(1) to disabled(2) but not vice-versa. I don't believe that was the intent. Some wordsmithing is probably in order to clarify this point. See the DESCRIPTION clause for mip6Status for a possible template. (o) The SYNTAX clause for mip6HaGaAddrSeqNo reads: SYNTAX Integer32 (1..1024) -- put the max value GYM I was not able to figure out what "max value GYM" means, either from the draft (since the acronym GYM is not defined anywhere) nor from the target of the REFERENCE clause (RFC 3775 Section 10.1). I assume that this is intended to motivate the range 1..1024, which would be a good thing to do; some clarification would probably be a good idea. (p) It was not entirely clear to me whether the notifications mip6MnRegistered, mip6MnDeRegistered, and mip6MnMoved are to be sent by a Mobile Node only or both by a Mobile Node and by a Home Agent. Clarification would be appreciated. Also, it is not clear why mip6MnDeRegistered has a reference clause while the other two do not. (q) mip6CoreCompliance lists the minimum conformance requirements for all InetAddressType/InetAddress INDEX objects in its DESCRIPTION clause, but the only conformance GROUP mentioned is the mip6SystemGroup, which includes only the two scalars mip6Capabilities and mip6Status. Hence a statements about minimum conformance requirements for INDEX objects is out of place in this compliance statement. My recommendation would be to remove the INDEX-related text from the DESCRIPTION clause of this compliance statement, and then to cut-and-past the appropriate parts into the DESCRIPTION clauses of the other compliance statements. This completes the review of draft-ietf-mip6-mipv6-mib-05.txt. Regards, Mike Heard _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 28 10:21:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21243 for ; Sun, 28 Nov 2004 10:21:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYQwD-00036U-KS for mip6-web-archive@ietf.org; Sun, 28 Nov 2004 10:26:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYQph-0000Jn-KZ; Sun, 28 Nov 2004 10:19:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYQjc-0006vH-E7 for mip6@megatron.ietf.org; Sun, 28 Nov 2004 10:13:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20250 for ; Sun, 28 Nov 2004 10:13:06 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYQoJ-0002sy-E6 for mip6@ietf.org; Sun, 28 Nov 2004 10:18:00 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 28 Nov 2004 16:12:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: MIP6 agenda (Final) Date: Sun, 28 Nov 2004 16:12:51 +0100 Message-ID: Thread-Topic: [Mip6] FW: MIP6 agenda (Final) thread-index: AcTQvGSmwPbr8zKSSmqMBn9dlYzIgQEhcCrg From: "NJEDJOU Eric RD-RESA-REN" To: "James Kempf" , "Thierry Ernst" , X-OriginalArrivalTime: 28 Nov 2004 15:12:51.0646 (UTC) FILETIME=[BA88EDE0:01C4D55C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 Content-Transfer-Encoding: quoted-printable Hi James, The Problem i guess Operators have with the Seamoby Protocols is more = complex.=20 First, the Seamoby protocols were meant to be operations to be performed = prior/post to running the Fats Handoffs protocols. And Fast Handoffs = protocols themselves are not deployed because operators are still only = assessing the real need to have IP mobility services for their customers = as provided by Mobile IP. Another issue is that the Fast Handoffs = protocols were designed with the 802.11 AP/AR to 802.11 AP/AR handover = scenario in mind. And We can effectively see that people have only be = able to implement the Fast Handoffs protocols for 802.11 handover. Fast = Handoffs do not apply to GPRS <-> 802.11 handover scnearios. This is = because the handover signalling is something to be exchanged at the very = edge of the network (access routers) and exchanging FMIP signalling = between an AR in the 802.11 network and the GGSN in the GPRS core = network require the flows to pass via too many hops, rendering the = handover process not reactive as is the will of having a fast handoff = scheme.=20 Therefore for the GPRS <-> 802.11, the only possible fallback is to use = simple Mobile IPv4/v6. Further, using simple Mipv4/MIPv6 will not = require Operators to modify their edge to include SEAMOBY/MIPSHOP = operations. When the need for MIpv4/MIPv6 will really be ascertained, = then those protocols will be considered, but again not for the = inter-technology handovers. Another reason why SEAMOBY/MIPSHOP protocols would not likely be = deployed on a large scale is that even that 802.11 AP to AP handover = scenario ( those protocols fit for) does not require a subnet change in = most of the cases. The whole thing can therefore be handled within L2 as = Task Group R of IEEE 802.11 is doing.=20 Eric Njedjou France Telecom=20 -----Message d'origine----- De : mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] De la part de = James Kempf Envoy=E9 : lundi 22 novembre 2004 18:43 =C0 : Thierry Ernst; mip6@ietf.org Objet : Re: [Mip6] FW: MIP6 agenda (Final) Hi Thierry, Please don't feel offended, but I tend to discount attestations from = researchers that there is product and deployment interest. For 4 years, = we had researchers saying that there was product and deployment interest = in Seamoby, yet prior to switching the drafts to experimental, we had = not a single vendor or operator willing to say that they were interested = in developing and deploying the protocols. That's why they were switched = to experimental. If there are not vendors and operators willing to come = on the list and participate in the process so their customers can enjoy = the benefits of interoperability, then I don't think this is an = appropriate topic for the mip6 WG, since mip6 isn't chartered to do = experimental work. Regarding ISO, if there's another standardization body that needs the = work, then a liason letter to the IETF via the IAB requesting an = Internet standard might be in order. However, I believe a more productive track would be to take the work to = Mobopts as Raj and Rajeev have requested, possibly in conjunction with = examining the multihoming work that v6ops is doing for mobility = implications. Rajeev and Bill are working hard to make Mobopts a venue = for maturing good ideas, and I think that this work may now be showing = results, since we now have two drafts there that they are interested in = making research group drafts, for eventual re-introduction into IETF. jak ----- Original Message ----- From: "Thierry Ernst" To: Sent: Sunday, November 21, 2004 8:07 PM Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > Hi James, > > > Are there any vendors interested in implementing this solution = and/or > > network operators interested in deploying it (note: I'm not asking = for > > detailed product plans, just the kind of committment that was given = in, say, > > the chartering discussion of the Mobike WG several IETFs ago)? Or = other > > standardization bodies (such as our good friends at 3GPP2) who are > > interested in incorporating it into their standards? > > Peole from various companies have told me so and I would rather let = them > express their opinions directly to demonstrate their true interest. = But > many of them may not be on the list. > > Also, there are proprietary solutions and these manufacturers may not = be > eager to standardize their solutions (unless some raise the topic at = the > IETF, in which case they would have to). > > For instance, mobile phone company A may want terminals allowing their > users to switch between 3G/GPRS and 802.11. In their scenario, both > access networks would belong to the same operator, so a proprietary > solution is fine. > > But from a user perspective, I and other people think standardization = is > important, and there is an important need. > > There are for instance the car manufacturers or those making products > for them (unfortunately, they don't speak up at the IETF because it's > not in their culture) who need to manage multiple interfaces on their > MIP6/NEMO MN/MR. The ISO TC204 WG16 is one of those efforts where such > feature is needed (in their CALM architecture). > > About implementation, there is an effort ongoing in a branch of the = KAME > ipv6 stack (don't look for it on the KAME page, you won't find it now) > and people willing to do the same in USAGI. I don't want to speak up = for > USAGI and KAME people, but as far as reference implementations are > concerned, we better implement standards rather than proprietary > solutions, I think you would agree on this. > > Thierry. > > > > > jak > > > > PS: BTW, if you haven't seen it, you should check out the literature = on > > Boeing's Connexion system. It uses BGP to manage routes to a mobile 802.11 > > network in an airplane on a transcontinental flight. Lufthasa has deployed > > it on their new A333-600's. > > > > > > ----- Original Message -----=20 > > From: "Thierry Ernst" > > To: > > Cc: > > Sent: Thursday, November 18, 2004 6:55 PM > > Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > > > > > > > > > Dear Rajeev, > > > > > > Mobopts is a reseach group (IRTF), the problem that we want to = solve is > > > much more clarified clarified than that, and solutions could be brought > > > in a timely manner if we restrict ourselves to part of the = exisiting > > > problems and extensions to MIP6 and NEMO. > > > > > > Of course, taking a look at the whole picture would require much = more > > > consideration, and for the whole picture Mobopts could be the = right > > > place. But, my intention, right now, is not to open the pendora = box; > > > it's rather about bringing a solution to an immediate concern, in = a > > > timely manner: how can I make use of my MIP6/NEMO function when I = have > > > multiple interfaces on my MH/MR ? I can't do it right now, and not > > > because it's np complex, but because there is no agreed solution between > > > the parties involved. > > > > > > Regarding what has been said at the MIP6 meeting, taking into = account > > > the feedback from Erik, Thomas, and all the other, I would go for = a BOF > > > at next IETF, but not with the objective to set up a new WG, but = just a > > > one-time BOF to discuss the problem thoroughly. > > > > > > But, prior to doing that, the other people involved with me on the > > > problem statement drafts, we should improve/clarify/extend our = drafts. > > > The target would be end of this year; based on new drafts we would > > > consider setting up a BOF or not. (OK, guys, now we have pressure = on our > > > shoulders ;-) > > > > > > Thierry > > > > > > > > > > > > On Thu, 18 Nov 2004 10:40:15 -0800 > > > Rajeev Koodli wrote: > > > > > > > Thierry Ernst wrote: > > > > > > > > > > Thus embarking on QoS sensitive, mobility specific = multihoming > > support > > > > > > is both too open ended (on the QoS side) and too = constraining (by > > only > > > > > > looking at cases when MIP/Nemo is used). > > > > > > > > > > > > So I think it would be useful for folks to try to think = about and > > > > > > discuss the bigger picture. > > > > > > > > > > Agree. But then, where should this discussion take place ? = MIP6 WG ? > > > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > > > > > > > I would add to Erik's observation that we need to be able to = assess a > > topic to > > > > see > > > > the maturity of the problem and the state of solutions, as well = as what > > could > > > > be standardized in IETF. The IETF should work on well-defined = _and_ > > > > well-agreed problems for which protocol specification could be > > accomplished > > > > in a timely manner. Topics where the problem needs to be crystalized, > > and > > > > solution > > > > space needs "thinking" require a forum for discussion. And, = MobOpts > > could > > > > be such a place. > > > > > > > > We (mip*, MobOpts co-chairs) are in the process of working out a model > > to > > > > facilitate closer co-operation between mip* groups and MobOpts. = The > > outcome > > > > should be focussed discussion on topics of mutual interest that = lead to > > > > documents > > > > which can be a) taken up in mip* groups for standardization, b) MobOpts > > RG > > > > RFCs. MobOpts would run milestones and try to produce documents within a > > > > timeframe of interest to mip* groups. > > > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 28 11:35:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26332 for ; Sun, 28 Nov 2004 11:35:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYS5z-0005pR-UV for mip6-web-archive@ietf.org; Sun, 28 Nov 2004 11:40:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYRzo-0005WE-Fm; Sun, 28 Nov 2004 11:33:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYRyN-00059V-4i for mip6@megatron.ietf.org; Sun, 28 Nov 2004 11:32:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26182 for ; Sun, 28 Nov 2004 11:32:24 -0500 (EST) Received: from jens241.inetcore.com ([202.33.8.241] helo=gw.inetcore.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYS2v-0005he-Uv for mip6@ietf.org; Sun, 28 Nov 2004 11:37:20 -0500 Received: from [IPv6???1] (localhost [127.0.0.1]) by gw.inetcore.com (Postfix) with ESMTP id 77F2B1D1CB9; Mon, 29 Nov 2004 01:31:43 +0900 (JST) In-Reply-To: <20041126103524.465408ed.ernst@sfc.wide.ad.jp> References: <3CF661B1787ABF41A869BE20108F8D6D4321CC@esebe056.ntc.nokia.com> <41A57C0B.2060202@clarinet.u-strasbg.fr> <20041125232610.4bc1f1ff.ernst@sfc.wide.ad.jp> <20041126103524.465408ed.ernst@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0B77CB4B-415B-11D9-9F51-000D9335C3BC@inetcore.com> Content-Transfer-Encoding: 7bit From: Nobuo Ogashiwa Subject: Re: [Mip6] FW: MIP6 agenda (Final) Date: Mon, 29 Nov 2004 01:32:07 +0900 To: Thierry Ernst , mip6@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: Nobuo Ogashiwa X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Dear Thierry, On 2004/11/26, at 10:35, Thierry Ernst wrote: > > Dear Pekka, > >> On Thu, 25 Nov 2004, Thierry Ernst wrote: >>>> Here is a proposed list of working group candidates: >>>> - Mobopts >>>> - Multi6 >>>> - Ipv6ops >>>> - Miptran >>>> - MIP6 >>>> - Other ? >>> >>> May be a special purpose BOF to discuss the topic at length (without >>> interfering with topics of other WGs and ending up rushing up in 5 >>> minutes at end of slot), or a new WG, with a charter limited to only >>> produce a problem statement ? >> >> I agree, though I'd say there should be no need to spin up a WG just >> to provide a problem statement, a couple of good individuals and a BoF >> would probably be OK. :) >> >> And unless there are enough interested participants, a WG isn't going >> to help.. >> >>> BTW, Thomas Narten pointed out the need for listing the problems >>> specific to MIP6, if I didn't mixed what he said on the mic. >> >> His point was to: >> 1) identify the generic issues (not MIPv6 specific) >> * and maybe work on these somewhere else >> 2) identify the MIPv6 specific issues >> * and possibly work on these in MIP6 WG > > Thanks for being more precise than myself. > > So, we already have 2 drafts, but they both need to be enhanced (our > intention is to issue new documents before the end of the year - let's > say by January 3rd since nobody in some parts in the world would read > over the holidays) > >> To get there, I might suggest that someone consider creating a 'host >> mobility & multihoming in ipv6' (hmm6?) mailing list, and try to >> discuss and work on the above two problems there. > > That's my intention too. I can do this. I wait over the week-end to see > reactions of other people, and they we can create it. > > I was thinking about other names, though: multiface (MULTIple > interFACEs) or MM6 (hmm6 sounds better than MM6) ;-) The name "multiface" reminds me the ML is just for multiple interface cases. I think that a discussion of multihoming should include the case of a single interface, multiple upstream routers. Regards, Nobuo Ogashiwa > > Thierry. > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > --- Intec NetCore, Inc. 1-3-3, Shinsuna, Koto-ku, Tokyo, 136-0075 Japan TEL +81-(0)3-5665-5069 FAX +81-(0)3-5665-5094 Nobuo Ogashiwa _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 28 23:16:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19588 for ; Sun, 28 Nov 2004 23:16:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYd28-0005kM-JG for mip6-web-archive@ietf.org; Sun, 28 Nov 2004 23:21:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYcsH-0003OR-6W; Sun, 28 Nov 2004 23:10:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYcrF-0003BS-Ek for mip6@megatron.ietf.org; Sun, 28 Nov 2004 23:09:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19253 for ; Sun, 28 Nov 2004 23:09:47 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYcw4-0005dw-Mk for mip6@ietf.org; Sun, 28 Nov 2004 23:14:49 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAT49jF03311; Mon, 29 Nov 2004 06:09:45 +0200 (EET) X-Scanned: Mon, 29 Nov 2004 06:09:35 +0200 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id iAT49Z4g029916; Mon, 29 Nov 2004 06:09:35 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00vfHcFQ; Mon, 29 Nov 2004 06:09:35 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id iAT49Ma16231; Mon, 29 Nov 2004 06:09:22 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Nov 2004 06:08:52 +0200 Received: from esebe056.NOE.Nokia.com ([172.21.143.51]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 29 Nov 2004 06:08:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: MIP6 agenda (Final) Date: Mon, 29 Nov 2004 06:08:52 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D095898@esebe056.ntc.nokia.com> Thread-Topic: [Mip6] FW: MIP6 agenda (Final) Thread-Index: AcTQvGSmwPbr8zKSSmqMBn9dlYzIgQEhcCrgACFYDZA= To: , X-OriginalArrivalTime: 29 Nov 2004 04:08:52.0340 (UTC) FILETIME=[22DF0340:01C4D5C9] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Hi Eric, > The Problem i guess Operators have with the Seamoby Protocols=20 > is more complex.=20 I think what James is getting at is that backers of the SeaMoby technology oversold the technology. There were supposedly companies planning a lot of products and absolutely needed the IETF to do something in this area. > First, the Seamoby protocols were meant to be operations to=20 > be performed prior/post to running the Fats Handoffs=20 > protocols. And Fast Handoffs protocols themselves are not=20 > deployed because operators are still only assessing the real=20 > need to have IP mobility services for their customers as=20 > provided by Mobile IP. Another issue is that the Fast=20 > Handoffs protocols were designed with the 802.11 AP/AR to=20 > 802.11 AP/AR handover scenario in mind. And We can=20 > effectively see that people have only be able to implement=20 > the Fast Handoffs protocols for 802.11 handover. Fast=20 > Handoffs do not apply to GPRS <-> 802.11 handover scnearios.=20 > This is because the handover signalling is something to be=20 > exchanged at the very edge of the network (access routers)=20 > and exchanging FMIP signalling between an AR in the 802.11=20 > network and the GGSN in the GPRS core network require the=20 > flows to pass via too many hops, rendering the handover=20 > process not reactive as is the will of having a fast handoff scheme.=20 > Therefore for the GPRS <-> 802.11, the only possible fallback=20 > is to use simple Mobile IPv4/v6. Further, using simple=20 > Mipv4/MIPv6 will not require Operators to modify their edge=20 > to include SEAMOBY/MIPSHOP operations. When the need for=20 > MIpv4/MIPv6 will really be ascertained, then those protocols=20 > will be considered, but again not for the inter-technology handovers. Well, some operators are looking at layer 2 mobility still. If you have followed any of the UMA work, you can see how some operators are looking at integrating 802.11 into their GSM networks, without any Mobile IP. 3GPP is looking at some level of support of Mobile IP in Release 7 for WLAN interworking scenarios. 3GPP2 has MIPv4, working on support for MIPv6 and are also considering how to integrate WLAN interworking into their network. I do think that there is some need for SeaMoby, MIPshop work, but I do think that carriers have less ambitious plans and are much more conservative than in 2000. John > Another reason why SEAMOBY/MIPSHOP protocols would not likely=20 > be deployed on a large scale is that even that 802.11 AP to=20 > AP handover scenario ( those protocols fit for) does not=20 > require a subnet change in most of the cases. The whole thing=20 > can therefore be handled within L2 as Task Group R of IEEE=20 > 802.11 is doing.=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 29 02:39:02 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23759 for ; Mon, 29 Nov 2004 02:39:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYgCa-0001vG-CH for mip6-web-archive@ietf.org; Mon, 29 Nov 2004 02:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYg6X-0003AK-J1; Mon, 29 Nov 2004 02:37:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CY5mA-00060O-LD for mip6@megatron.ietf.org; Sat, 27 Nov 2004 11:50:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21072 for ; Sat, 27 Nov 2004 09:01:34 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CY3DL-0003Hb-5y for mip6@ietf.org; Sat, 27 Nov 2004 09:06:15 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id iARE12lY006427 for ; Sat, 27 Nov 2004 08:01:03 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 27 Nov 2004 15:01:02 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15503C79FBA@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "'C. M. Heard'" , MIP6 Date: Sat, 27 Nov 2004 15:01:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 75ac735ede4d089f7192d230671d536e X-Mailman-Approved-At: Mon, 29 Nov 2004 02:37:34 -0500 Cc: "Wijnen, Bert \(Bert\)" Subject: [Mip6] RE: MIB Doctor review for: draft-ietf-mip6-mipv6-mib-05.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae Thanks for your thourough review Mike! Bert > -----Original Message----- > From: C. M. Heard [mailto:heard@pobox.com] > Sent: Saturday, November 27, 2004 02:18 > To: MIP6 > Cc: Wijnen, Bert (Bert) > Subject: MIB Doctor review for: draft-ietf-mip6-mipv6-mib-05.txt > > > Greetings, > > This MIB Doctor review of the MOBILEIPV6-MIB document looks at > draft-ietf-mip6-mipv6-mib-05.txt. It is a follow-up to a previous > review posted to the MIP6 mailing list on 15 October 2004 that dealt > with draft-ietf-mip6-mipv6-mib-04.txt. While all comments in the > previous review have been addressed by the -05 draft (for which I > thank the authors), there are a number of new issues raised in this > draft because I have finally had time to do a detailed reading of > the MIB module (which I did not do before). The new issues are for > the most part "non-mechanical" things (such as lack of clarity in > DESCRIPTION clauses) that can only be caught by a detailed reading > of the MIB module. My apologies for not being able to do this > sooner. Let me hasten to say that for the most part I am quite > pleased with the overall quality of this MIB module, and I believe > that all the issues that I raise here will be quite easy to correct. > > One thing that I need to point out to the WG group is that while I > know a good deal about MIB design, I am _not_ an expert on the MIP6 > protocol, and because of that I am not always able to determine if > the right things are being instrumented, or if something necessary > is being omitted. It is therefore STRONGLY recommended that WG > members with that kind of knowledge carefully review the document > with an eye to those sorts of issues. > > As before, the format of the review is patterned after the checklist > in Appendix A of . > Those who wish to comment on it are asked to post their remarks to > the MIP6 mailing list with copies to Bert Wijnen and myself. > > 1.) I-D Boilerplate -- OK > > 2.) Abstract -- OK > > 3.) MIB Boilerplate -- OK > > 4.) IPR Notice -- OK > > 5.) References -- OK > > 6.) Security Considerations Section -- OK > > 7.) IANA Considerations Section -- OK > > 8.) Copyright Notices -- OK > > 9.) Other issues (e.g., from http://www.ietf.org/ID-Checklist.html) > that are not covered elsewhere: > > Typos -- > > (a) In Section 2.1, 1st paragraph: > > OLD: > Mobile IPv6 (MIPv6) [RFC3775] specifies a protocol which > allows nodes > to remain reachable while moving around in the IPv6 Internet. An > entity which implements the MIPv6 protocol is an MIPv6 > entity. There > __________________________________________________^ > are three types of entities envisaged by the MIPv6 protocol. > > NEW: > Mobile IPv6 (MIPv6) [RFC3775] specifies a protocol which > allows nodes > to remain reachable while moving around in the IPv6 Internet. An > entity which implements the MIPv6 protocol is an MIPv6 > entity. There > are three types of entities envisaged by the MIPv6 protocol. > > (b) In Section 4: > > s/mip6HaGlobalAddrTable/mip6HaGlAddrTable/ > > (c) In the MIB module, mip6BindingHistoryEntry definition: > > OLD: > mip6BindingHistoryEntry OBJECT-TYPE > SYNTAX Mip6BindingHistoryEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The record of a binding . > ___________________________________________^ > > NEW: > mip6BindingHistoryEntry OBJECT-TYPE > SYNTAX Mip6BindingHistoryEntry > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The record of a binding. > > (d) In the REFERENCE clauses of mip6CnSeqNumberOutOfWindow, > mip6CnExpiredHomeNonceIndex, mip6CnExpiredCareOfNonceIndex, > mip6CnExpiredNonce, and mip6CnRegTypeChangeDisallowed: > > OLD: > "RFC3775 : Section 6.1.8 9.5.1" > NEW: > "RFC3775 : Section 6.1.8, 9.5.1" > > (e) In the DESCRIPTION clause of mip6CnRegTypeChangeDisallowed: > > OLD: > "The total number of Binding Updates rejected by > correspondent node with status code in the Binding > Acknowledgment message indicating 'registration > type change disallowed' (Code 139 i.e. a binding > _____________________________________________________^____^ > already exists for the given home address and the > home registration flag has a different value than > the Home Registration (H) bit in the > Binding Update. > ______________________________________________________________ > _________^ > NEW: > "The total number of Binding Updates rejected by > correspondent node with status code in the Binding > Acknowledgment message indicating 'registration > type change disallowed' (Code 139, i.e., a binding > already exists for the given home address and the > home registration flag has a different value than > the Home Registration (H) bit in the Binding > Update). > > 10.) Technical content -- review of actual technical content for > compliance with : > > (a) MIB compilation using smilint -- > > The program smilint 0.4.3, as of Wed Aug 18 15:45:50 2004 > has been used to process your request as follows: > > smilint -m -s -e -l 9 -i namelength-32 MOBILEIPV6-MIB > > MOBILEIPV6-MIB:187: [5] {index-exceeds-too-large} warning: index of > row `mip6BindingCacheEntry' can exceed OID size limit by 142 > subidentifier(s) > MOBILEIPV6-MIB:401: [5] {index-exceeds-too-large} warning: index of > row `mip6BindingHistoryEntry' can exceed OID size limit by 143 > subidentifier(s) > MOBILEIPV6-MIB:765: [5] {index-exceeds-too-large} warning: index of > row `mip6NodeTrafficEntry' can exceed OID size limit by 142 > subidentifier(s) > MOBILEIPV6-MIB:994: [5] {index-exceeds-too-large} warning: index of > row `mip6MnHomeAddressEntry' can exceed OID size limit by 142 > subidentifier(s) > MOBILEIPV6-MIB:1232: [5] {index-exceeds-too-large} warning: index of > row `mip6MnBLEntry' can exceed OID size limit by 399 > subidentifier(s) > MOBILEIPV6-MIB:1897: [5] {index-exceeds-too-large} warning: index of > row `mip6CnCounterEntry' can exceed OID size limit by 142 > subidentifier(s) > MOBILEIPV6-MIB:2503: [5] {index-exceeds-too-large} warning: index of > row `mip6HaCounterEntry' can exceed OID size limit by 142 > subidentifier(s) > MOBILEIPV6-MIB:2641: [5] {index-exceeds-too-large} warning: index of > row `mip6HaListEntry' can exceed OID size limit by 143 > subidentifier(s) > MOBILEIPV6-MIB:2756: [5] {index-exceeds-too-large} warning: index of > row `mip6HaGlAddrEntry' can exceed OID size limit by 144 > subidentifier(s) > > These warnings are an expected result of using InetAddress objects in > the INDEX clauses, and simply serve to indicate that certain size > restrictions have to be observed in order for the MIB module to be > useable with SNMPv1, SNMPv2c, or SNMPv3. In each case the conceptual > row DESCRIPTION clause documents those restrictions and thus complies > with the MIB review guidelines. No corrective action is required. > > Compilation with SMICng and mosy resulted in no errors or warnings. > > (b) Persistence of read-write values -- Section 4.6.2 of > draft-ietf-ops-mib-review-guidelines-03.txt makes the following > recommendation: > > For read-write objects (other than columns in read-create > tables that > have well-defined persistence properties) it is > RECOMMENDED that the > DESCRIPTION clause specify what happens to the value after an agent > reboot. Among the possibilities are that the value remains > unchanged, that it reverts to a well-defined default value, or that > the result is implementation-dependent. > > There are seven read-write objects in the MOBILEIPV6-MIB: mip6Status > (a scalar), mip6BindingAdminStatus (a member of > mip6BindingCacheEntry), > and mip6HaAdvPreference, mip6HaAdvLifetime, mip6HaPrefixAdv, > mip6HaPrefixSolicitation, and mip6HaMCastCtlMsgSupport (all members of > mip6HaConfEntry). For none of these objects does the DESCRIPTION > clause specify what happens to the value after an agent reboot. > > For mip6Status I would suggest that the DESCRIPTION clause say at > least that the last value set SHOULD survive an agent reboot. > > For mip6BindingAdminStatus it seems the value should share fate with > the other members of the corresponsing mip6BindingCacheEntry row > instance. I would expect that the rows in this table would not > survive a reboot, but I am not a MIP6 protocol expert and as such > I don't actually know what is expected of an implementation. If > I am correct in assuming that the mip6BindingCacheTable is flushed > after a reboot, then a statement to that effect in the > mip6BindingCacheTable or mip6BindingCacheEntry DESCRIPTION clause > would suffice. > > For mip6HaAdvPreference and the other members of the mip6HaConfEntry > object it would seem that the ideal policy would be for the last- > written values to survice a reboot, at least when the agent does not > renumber interfaces (i.e., assign new ifIndex/ipv6InterfaceIfIndex > values) after a reboot. Subject to this proviso, I would suggest > that it be RECOMMENDED that last-written values survive an agent > reboot. It would be acceptable to have a statement to that effect > in the DESCRIPTION clause of mip6HaConfTable or mip6HaConfEntry. > > (c) The REFERENCE clause for mip6Capabilities points to RFC 3775 > Section 6.1.8, which does not seem to be appropriate for this > object. This should be corrected. > > (d) There probably should be a REFERENCE clause for mip6BindingMaxSeq > that points to RFC 3775 Section 9.1 (and possibly also Section 9.5.1), > and its SYNTAX value probably should be Unsigned32 (0..65536). > > (e) The SYNTAX values for mip6BindingUsageCount and > mip6BindingHstUsageCount are inconsistent: one is Counter32, and > the other is Unsigned32. Both should probably be Gauge32, since > that type stops at 2^32-1 (rather than rolling over) if it hits > the maximum value. Counter32 is not appropriate here since its > behaviour is inconsistent with the DESCRIPTION. > > (f) The mip6TotalTraffic HC counter definitions use an incorrect > SYNTAX value (Counter32 instead of Counter64). Corrections follow. > > OLD: > mip6HCInOctets OBJECT-TYPE > SYNTAX Counter32 > ______________________________^^ > NEW: > mip6HCInOctets OBJECT-TYPE > SYNTAX Counter64 > > OLD: > mip6HCInPkts OBJECT-TYPE > SYNTAX Counter32 > ______________________________^^ > NEW: > mip6HCInPkts OBJECT-TYPE > SYNTAX Counter64 > > OLD: > mip6HCOutOctets OBJECT-TYPE > SYNTAX Counter32 > ______________________________^^ > NEW: > mip6HCOutOctets OBJECT-TYPE > SYNTAX Counter64 > > OLD: > mip6HCOutPkts OBJECT-TYPE > SYNTAX Counter32 > ______________________________^^ > NEW: > mip6HCOutPkts OBJECT-TYPE > SYNTAX Counter64 > > (g) As in (d) above, it seem that the SYNTAX value for > mip6MnBLMaxSeq probably should be Unsigned32 (0..65536). > > (h) RFC 3775 specifies that the following piece of information > should be available in the conceptual Binding Update List: > > o A flag specifying whether or not future Binding Updates should be > sent to this destination. The mobile node sets this flag in the > Binding Update List entry when it receives an ICMP Parameter > Problem, Code 1, error message in response to a return routability > message or Binding Update sent to that destination, as described > in Section 11.3.5. > > However, it was not clear to me that this information was available > from the objects in the mip6MnBLTable. If it can be inferred from > the value of mip6MnBLAccepted perhaps some text explaining how that > is done would be in order. > > (i) It might be a good idea to change the SYNTAX value of > mip6MnBLRetransmissions to Gauge32 to ensure that it stops > at 2^32-1 rather than rolling over. > > (j) It seems that mip6MnBUAcksFromHA should probably have a REFERENCE > clause pointing to RFC 3775 Section 11.7.3 (as does > mip6MnBUAcksFromCN). > > (k) It seems that mip6CnBUsAccepted and mip6CnBUsRejected should both > have a REFERENCE clause that points to RFC 3775 Sections 9.5.1 and > 9.5.4. The former has no reference clause; the latter has one, but > it points only to Section 9.5.1. > > (l) The DESCRIPTION clauses for mip6HaAdvsRecd and mip6HaAdvsSent do > not refer to a discontinuity counter. Since these are global > counters, > mip6CounterDiscontinuityTime could be used, i.e., it would be > appropriate to add the following text to the end of the DESCRIPTION > clause: > Discontinuities in the value of this counter can > occur at re-initialization of the > management system, > and at other times as indicated by the value of > mip6CounterDiscontinuityTime. > > (m) The REFERENCE clauses for mip6HaAdvsRecd and mip6HaAdvsSent point > to REF 3775 Sections 6.1.8 and 9.5.1, which do not appear to be > relevant. These clauses should be corrected (or removed). > > (n) The DESCRIPTION clauses of mip6HaPrefixAdv, > mip6HaPrefixSolicitation, > and mip6HaMCastCtlMsgSupport COULD be interpreted to mean that a > SetRequest can only change the value from enabled(1) to > disabled(2) but > not vice-versa. I don't believe that was the intent. Some > wordsmithing > is probably in order to clarify this point. See the > DESCRIPTION clause > for mip6Status for a possible template. > > (o) The SYNTAX clause for mip6HaGaAddrSeqNo reads: > SYNTAX Integer32 (1..1024) -- put the max value GYM > I was not able to figure out what "max value GYM" means, either from > the draft (since the acronym GYM is not defined anywhere) nor from the > target of the REFERENCE clause (RFC 3775 Section 10.1). I assume that > this is intended to motivate the range 1..1024, which would be a good > thing to do; some clarification would probably be a good idea. > > (p) It was not entirely clear to me whether the notifications > mip6MnRegistered, mip6MnDeRegistered, and mip6MnMoved are to be > sent by a Mobile Node only or both by a Mobile Node and by a Home > Agent. Clarification would be appreciated. Also, it is not clear > why mip6MnDeRegistered has a reference clause while the other two > do not. > > (q) mip6CoreCompliance lists the minimum conformance requirements > for all InetAddressType/InetAddress INDEX objects in its DESCRIPTION > clause, but the only conformance GROUP mentioned is the > mip6SystemGroup, > which includes only the two scalars mip6Capabilities and mip6Status. > Hence a statements about minimum conformance requirements for INDEX > objects is out of place in this compliance statement. My > recommendation > would be to remove the INDEX-related text from the > DESCRIPTION clause of > this compliance statement, and then to cut-and-past the appropriate > parts into the DESCRIPTION clauses of the other compliance statements. > > This completes the review of draft-ietf-mip6-mipv6-mib-05.txt. > > Regards, > > Mike Heard > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 29 02:42:10 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23903 for ; Mon, 29 Nov 2004 02:42:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYgFc-0001yG-Kc for mip6-web-archive@ietf.org; Mon, 29 Nov 2004 02:47:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYg6m-0003EG-QZ; Mon, 29 Nov 2004 02:38:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYENP-0002c8-Ae for mip6@megatron.ietf.org; Sat, 27 Nov 2004 21:03:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09361 for ; Sat, 27 Nov 2004 21:01:14 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.204]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYERW-0003hp-Jd for mip6@ietf.org; Sat, 27 Nov 2004 21:06:03 -0500 Received: by wproxy.gmail.com with SMTP id 50so584920wri for ; Sat, 27 Nov 2004 18:00:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=ErBoilCFyMgP5RlBOxETcgiRPIH4kKpTmBSuetQ1/qG0ZbfeF25YuyxfwW4dnIoGi8N2PpuCra+ljMoll0UCmjxJONuGk0ThueoaW5sN5o+6hhiIFM6E6boMv/IjBEz2P1+vVOf/8dYNnRJmvU9WqJvVAPPP4E6pTliKbCqfXGQ= Received: by 10.54.51.78 with SMTP id y78mr2039498wry; Sat, 27 Nov 2004 18:00:21 -0800 (PST) Received: by 10.54.10.75 with HTTP; Sat, 27 Nov 2004 18:00:21 -0800 (PST) Message-ID: <88b9e992041127180016138a2e@mail.gmail.com> Date: Sat, 27 Nov 2004 21:00:21 -0500 From: B Krishnamachari To: mipshop@ietf.org, podc@acm.org, mip4@ietf.org, manet@ietf.org, mip6@ietf.org, itc@ieee.org, tcgn@ieee.org, commsoft@ieee.org, performance@haven.epm.ornl.gov.cnri.reston.va.us, tel-bcn@mat.upc.es, tel-vil@mat.upc.es, disc-delegates@disc2000.org, alg@comm.toronto.edu, cabernet-events@ncl.ac.uk, cost237-transport@comp.lancs.ac.uk, ctc-members@redbank.tinac.com, end2end-interest@isi.edu, announce@tcos.org, testnet@canarie.ca, eapls-request@mailbase.ac.uk, dbworld@cs.wisc.edu, xtp-relay@cs.concordia.ca, siksleden@cs.uu.nl, int-serv@isi.edu, comm-theory@ieee.org, comsoc.bog@tab.ieee.org, comsoc.tac@tab.ieee.org, comsoc-chapters@ieee.org, comsoc-gicb@ieee.org, comsys@brunet.bn, comswtc@ieee.org, sigcomm-members@acm.org, noe-one@prezzemolo.polito.it, sigmob@acm.org, mobicom@acm.org, news-announce-conferences@uunet.uu.net, stds-802-wpan@ieee.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 29 Nov 2004 02:37:34 -0500 Subject: [Mip6] CFP Broadnets 2005 Broadband Optical Networking Symposium X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: B Krishnamachari List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit ----------------------------------------------------------------------- CALL FOR PAPERS Second Annual International Conference on Broadband Networks (BROADNETS 2005) Broadband Optical Networking Symposium October 3 - 7, 2005 Boston, Massachusetts, USA http://www.broadnets.org Submission Deadline: February 1, 2005 ----------------------------------------------------------------------- SCOPE ----- BROADNETS 2005 is an international conference focusing on broadband networking and covers the entire gamut of next generation networks with high bandwidth available for both wireless and wireline networks. The conference will consist of the following three symposia: ** Broadband Optical Networking Symposium: covers WDM technologies, Ethernet and MPLS integration into the optical layer, Next-Generation SONET/SDH, as well as SAN extensions over DWDM/SONET/SDH. ** Broadband Wireless Networking Symposium: covers mobility, routing for multihop, multimedia QoS and traffic management, cross-layer optimization, MAC and emerging physical layer technologies (UWB, MIMO) for high-speed wireless networking. ** Broadband Applications/Services Symposium: covers middleware and service architectures for broadband applications, pervasive computing and ubiquitous communications, and universal broadband access for information services. BROADNETS 2005 will thus offer a unique forum for researchers from academia, government and industry to share ideas and disseminate new results in these important areas. This Call for Papers describes the details for the Broadband Optical Networking Symposium ONLY. (Refer to the www.broadnets.org/2005 website for the details of Broadband Wireless Symposium and Broadband Applications/Services Symposium.) We are soliciting full papers in all research, development, and deployment areas on broadband optical networking. Topics of interest include, but not limited to, the following: - Wavelength-routed WDM networks - Integration of Ethernet and RPR into the optical layer - IP and MPLS over DWDM: integration and interworking - Next-generation SONET/SDH and MSPP - SAN over SONET/SDH and DWDM - Network control and management, GMPLS - Survivability in the data, TDM or optical layers - Optical packet switching and burst switching - High-speed switch and router architectures - Optical multicasting - Standards for multi-service networks - Long-haul optical transport networks - Metropolitan and regional optical networks - Access optical networks, PONs - Optical networking for video-on-demand - Trial implementations and test-beds - Multi-layer network design and optimization - Grid computing over optical networks - Optical technologies: switching, transmission and multiplexing Conference proceedings will be published by IEEE Computer Society. A set of selected papers from the symposium will be published in a special issue of Elsevier Optical Switching and Networking Journal. IMPORTANT DATES --------------- Submission Deadline: February 1, 2005 Acceptance Notification: May 1, 2005 Final Manuscript Due: June 1, 2005 PAPER SUBMISSION INSTRUCTIONS ----------------------------- Authors are invited to submit full papers of up to 10 pages in IEEE conference proceedings format. Papers should be submitted in PDF format to the respective symposium through the EDAS system at http://edas.info/Conference.cgi. CONFERENCE ORGANIZING COMMITTEE ------------------------------- General Chair: Dr. Arun Somani, Iowa State University, arun@iastate.edu General Vice Chair: Dr. Thomas Hou, Virginia Tech, thou@vt.edu Technical Program Chairs - Optical Networking Symposium Dr. David Griffith, NIST, david.griffith@nist.gov Dr. Srini Ramasubramanian, University of Arizona, srini@ece.arizona.edu Technical Program Chair- Wireless Networking Symposium: Dr. Sherman Shen, Univ. of Waterloo, xshen@bbcr.uwaterloo.ca Technical Program Chairs - Services and Applications Symposium Dr. Malathi Veeraraghavan, Univ. of Virginia, mv@cs.virginia.edu Dr. Admela Jukan, NSF, ajukan@nsf.gov Workshops Chairs: Dr. Wendi Heinzelman, University of Rochester, wheinzel@ece.rochester.edu Dr. Byrav Ramamurthy, University of Nebraska-Lincoln, byrav@cse.unl.edu Dr. Behcet Sarikaya, University of Northern British Columbia, sarikaya@unbc.ca Tutorials Chair: Dr. Steven Low, CalTech., slow@caltech.edu Panels Chairs: Dr. Surendar Chandra, Univ. of Notre Dame, surendar@cse.nd.edu Dr. Rudra Dutta, NCSU, dutta@csc.ncsu.edu Publicity Chairs: Dr. Bhaskar Krishnamachari, USC, bkrishna@usc.edu Dr. Takeo Hamada, Fujitsu Labs of America, thamada@fla.fujitsu.com Website/Information Systems Chair: Dr. Shiwen Mao, Virginia Tech, smao@vt.edu Publications Chairs: Dr. Ahmed Kamal, Iowa State University, kamal@iastate.edu Dr. Hui Zang, Sprint Adv. Tech. Labs, hzang@sprintlabs.com Exhibits and Sponsorships Chair: Dr. Sai Shankar N, Philips Research USA, sai.shankar@philips.com Steering Committee Co-Chairs: Dr. Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu Dr. Krishna Sivalingam, Univ. of Maryland, Baltimore County, krishna@umbc.edu -------------------------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 29 02:44:36 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24079 for ; Mon, 29 Nov 2004 02:44:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYgHy-00020V-9D for mip6-web-archive@ietf.org; Mon, 29 Nov 2004 02:49:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYg6p-0003HF-4j; Mon, 29 Nov 2004 02:38:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYXRL-0005k8-Pt; Sun, 28 Nov 2004 17:22:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21158; Sun, 28 Nov 2004 17:22:41 -0500 (EST) Received: from rome.ucdavis.edu ([169.237.104.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYXW7-00078x-HV; Sun, 28 Nov 2004 17:27:40 -0500 Received: from phaenicia.ucdavis.edu (phaenicia.ucdavis.edu [169.237.104.170]) by rome.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id iASMMW4a022966; Sun, 28 Nov 2004 14:22:33 -0800 (PST) Received: from phaenicia.ucdavis.edu (localhost [127.0.0.1]) by phaenicia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id iASMMWE1009821; Sun, 28 Nov 2004 14:22:32 -0800 (PST) Received: (from www@localhost) by phaenicia.ucdavis.edu (8.12.10/8.12.9/Submit) id iASMMVNR009820; Sun, 28 Nov 2004 14:22:31 -0800 (PST) Date: Sun, 28 Nov 2004 14:22:31 -0800 (PST) Message-Id: <200411282222.iASMMVNR009820@phaenicia.ucdavis.edu> To: fanzhao@ucdavis.edu From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 2.4 (++) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 X-Mailman-Approved-At: Mon, 29 Nov 2004 02:37:34 -0500 Cc: nemo@ietf.org, mip6@ietf.org, mipshop@ietf.org, mip4@ietf.org, multi6@ops.ietf.org, v6ops@ops.ietf.org, mobopts@irtf.org, manet@ietf.org, hipsec@honor.trusecure.com Subject: [Mip6] Call for Papers: IEEE JSAC MRNM X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.4 (++) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 PLEASE ACCEPT OUR APOLOGIES IF YOU RECEIVE MULTIPLE COPIES CALL FOR PAPERS IEEE Journal on Selected Areas in Communications MOBILE ROUTERS AND NETWORK MOBILITY http://www.argreenhouse.com/society/J-SAC/Calls/mobile_routers.html Network mobility support is concerned with managing the mobility of an entire network that is changing its point of attachment to the Internet and thus its reachability in the Internet topology. If network mobility is not explicitly supported by some mechanisms, existing sessions break and connectivity to the global Internet is lost. A mobile network is composed of Mobile Router(s) (MR) and Mobile Network Nodes (MNN) that can be fixed or mobile. There has been rapid development in network mobility support, i.e., providing Internet connectivity to the networks that move using mobile routers since the inception of Mobile IPv4 in 1996. Seamless Internet access in public transportation such as in trains and busses can be possible if mobile routers are used. Cars with low-power sensors seamlessly connected to the Internet constitute yet another example of networks which move. To date, some airline companies announced Internet connectivity support during commercial flights and this trend is expected to accelerate and cover most if not all flights. This issue is focused on modeling, analysis, and simulation of network mobility support protocols. We solicit papers presenting original and unpublished work including, but not limited to the following topics: * Modeling and Analysis of Network Mobility o Modeling, analysis and simulation of mobile router o Protocols for route optimization o Mobility issues inside a mobile network o Mobile IPv6 extensions for route optimization o Nested mobile networks o Multihomed mobile networks o Operational issues to deploy mobile networks o Auto-configuration for mobile networks o Mobile router support on cellular phone platforms * Services in the Networks that Move o Service advertisement and discovery protocols in networks that move o Specifications and models of services for network mobility o Encryption and authentication in service access for network mobility * Security Issues in Network Mobility o Security analysis of present network mobility support protocols o Applications of AAA and EAP to network mobility o Interaction with security-enhanced modules in other layers (vertically) or other middle boxes (horizontally) Prospective authors should follow the IEEE J-SAC manuscript format described in the Information for Authors. Authors MUST submit their draft manuscripts through the EDAS peer review website, together with a short abstract (approximately 150 words) in the EDAS website form. Please note potential authors should create their own accounts through the EDAS peer review website before submitting manuscript(s). EDAS will accept manuscripts in PDF format only. There will be one round of reviewers and acceptance will be limited to those papers requiring only moderate revisions. The following timetable applies: Manuscript Submission: JUNE 1, 2005 Acceptance Notification: December 1, 2005 Final Manuscript Due: March 1, 2006 Publication: 3rd Quarter 2006 Guest Editorial Board: Behcet Sarikaya Computer Science Dept Univ of Northern British Columbia Prince George, BC Canada V2N 4Z9 sarikaya@unbc.ca S. Felix Wu Dept of Computer Science Univ of California at Davis Davis, CA 95616 USA wu@cs.ucdavis.edu Gopal Dommety Cisco Systems, Inc 170 West Tasman Dr San Jose, CA 95134-1706 USA gdommety@cisco.com Claude Castelluccia INRIA Rhône-Alpes ZIRST 655 Ave de l'Europe Montbonnot 38334 Saint Ismier cedex France claude.castelluccia@inria.fr Thierry Ernst Jun Murai Lab Keio Univ K-square Town Campus 1488-8 Ogura, Saiwai-ku, Kawasaki, Kanagawa 212-0054 Japan ernst@sfc.wide.ad.jp Charles E. Perkins Communication Systems Lab Nokia Research Center 313 Fairchild Dr Mountain View, CA 94943 USA charliep@iprg.nokia.com _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 29 12:31:59 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12203 for ; Mon, 29 Nov 2004 12:31:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYpSV-0006xp-Qk for mip6-web-archive@ietf.org; Mon, 29 Nov 2004 12:37:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYpDl-0000yX-UJ; Mon, 29 Nov 2004 12:21:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYp8X-000723-Ty for mip6@megatron.ietf.org; Mon, 29 Nov 2004 12:16:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10114 for ; Mon, 29 Nov 2004 12:16:27 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYpDK-0006a1-5W for mip6@ietf.org; Mon, 29 Nov 2004 12:21:36 -0500 Message-ID: <02a001c4d637$3e546480$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: , , References: <3CF661B1787ABF41A869BE20108F8D6D095898@esebe056.ntc.nokia.com> Subject: Re: [Mip6] FW: MIP6 agenda (Final) Date: Mon, 29 Nov 2004 09:16:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hi John, >Well, some operators are looking at layer 2 mobility still. If you >have followed any of the UMA work, you can see how some operators >are looking at integrating 802.11 into their GSM networks, without >any Mobile IP. 3GPP is looking at some level of support of Mobile >IP in Release 7 for WLAN interworking scenarios. 3GPP2 has MIPv4, >working on support for MIPv6 and are also considering how >to integrate WLAN interworking into their network. jak>> UMA currently does not include any support for mobility, to my understanding. But it does use IKEv2, so I assume once Mobike is done, it will use Mobike for mobility. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 29 13:25:07 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16834 for ; Mon, 29 Nov 2004 13:25:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqHx-00088r-4Z for mip6-web-archive@ietf.org; Mon, 29 Nov 2004 13:30:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYq7q-0003AI-P1; Mon, 29 Nov 2004 13:19:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYq6w-00031Q-Si for mip6@megatron.ietf.org; Mon, 29 Nov 2004 13:18:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16444 for ; Mon, 29 Nov 2004 13:18:51 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqBs-00080f-WA for mip6@ietf.org; Mon, 29 Nov 2004 13:24:01 -0500 Message-ID: <030c01c4d640$01dfc630$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "NJEDJOU Eric RD-RESA-REN" , "Thierry Ernst" , References: Subject: Re: [Mip6] FW: MIP6 agenda (Final) Date: Mon, 29 Nov 2004 10:19:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9e5c23589e6cce06555030c0194c9e2b Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1 Content-Transfer-Encoding: quoted-printable Eric, I can't find anything specific to object to in your analysis, but I was making a broader point. My point was, that researchers often tend to oversell the interest in implementing and deploying their work, particula= rly in the IETF. This then leads WGs to get chartered that develop protocols which don't get deployed. Given the enormous amount of time and effort involved in doing IETF work (particularly for the WG chairs and draft editors), I believe it is important to weed out those tendencies early, prior to chartering, and re-direct such research work to the IRTF, where = it properly belongs. jak ----- Original Message -----=20 From: "NJEDJOU Eric RD-RESA-REN" To: "James Kempf" ; "Thierry Ernst" ; Sent: Sunday, November 28, 2004 7:12 AM Subject: RE: [Mip6] FW: MIP6 agenda (Final) Hi James, The Problem i guess Operators have with the Seamoby Protocols is more complex. First, the Seamoby protocols were meant to be operations to be performed prior/post to running the Fats Handoffs protocols. And Fast Handoffs protocols themselves are not deployed because operators are still only assessing the real need to have IP mobility services for their customers = as provided by Mobile IP. Another issue is that the Fast Handoffs protocols were designed with the 802.11 AP/AR to 802.11 AP/AR handover scenario in mind. And We can effectively see that people have only be able to impleme= nt the Fast Handoffs protocols for 802.11 handover. Fast Handoffs do not ap= ply to GPRS <-> 802.11 handover scnearios. This is because the handover signalling is something to be exchanged at the very edge of the network (access routers) and exchanging FMIP signalling between an AR in the 802.= 11 network and the GGSN in the GPRS core network require the flows to pass v= ia too many hops, rendering the handover process not reactive as is the will= of having a fast handoff scheme. Therefore for the GPRS <-> 802.11, the only possible fallback is to use simple Mobile IPv4/v6. Further, using simple Mipv4/MIPv6 will not require Operators to modify their edge to include SEAMOBY/MIPSHOP operations. Whe= n the need for MIpv4/MIPv6 will really be ascertained, then those protocols will be considered, but again not for the inter-technology handovers. Another reason why SEAMOBY/MIPSHOP protocols would not likely be deployed= on a large scale is that even that 802.11 AP to AP handover scenario ( those protocols fit for) does not require a subnet change in most of the cases. The whole thing can therefore be handled within L2 as Task Group R of IEE= E 802.11 is doing. Eric Njedjou France Telecom -----Message d'origine----- De : mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] De la part de James Kempf Envoy=E9 : lundi 22 novembre 2004 18:43 =C0 : Thierry Ernst; mip6@ietf.org Objet : Re: [Mip6] FW: MIP6 agenda (Final) Hi Thierry, Please don't feel offended, but I tend to discount attestations from researchers that there is product and deployment interest. For 4 years, w= e had researchers saying that there was product and deployment interest in Seamoby, yet prior to switching the drafts to experimental, we had not a single vendor or operator willing to say that they were interested in developing and deploying the protocols. That's why they were switched to experimental. If there are not vendors and operators willing to come on t= he list and participate in the process so their customers can enjoy the benefits of interoperability, then I don't think this is an appropriate topic for the mip6 WG, since mip6 isn't chartered to do experimental work= . Regarding ISO, if there's another standardization body that needs the wor= k, then a liason letter to the IETF via the IAB requesting an Internet stand= ard might be in order. However, I believe a more productive track would be to take the work to Mobopts as Raj and Rajeev have requested, possibly in conjunction with examining the multihoming work that v6ops is doing for mobility implicati= ons . Rajeev and Bill are working hard to make Mobopts a venue for maturing g= ood ideas, and I think that this work may now be showing results, since we no= w have two drafts there that they are interested in making research group drafts, for eventual re-introduction into IETF. jak ----- Original Message ----- From: "Thierry Ernst" To: Sent: Sunday, November 21, 2004 8:07 PM Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > Hi James, > > > Are there any vendors interested in implementing this solution and/or > > network operators interested in deploying it (note: I'm not asking fo= r > > detailed product plans, just the kind of committment that was given i= n, say, > > the chartering discussion of the Mobike WG several IETFs ago)? Or oth= er > > standardization bodies (such as our good friends at 3GPP2) who are > > interested in incorporating it into their standards? > > Peole from various companies have told me so and I would rather let the= m > express their opinions directly to demonstrate their true interest. But > many of them may not be on the list. > > Also, there are proprietary solutions and these manufacturers may not b= e > eager to standardize their solutions (unless some raise the topic at th= e > IETF, in which case they would have to). > > For instance, mobile phone company A may want terminals allowing their > users to switch between 3G/GPRS and 802.11. In their scenario, both > access networks would belong to the same operator, so a proprietary > solution is fine. > > But from a user perspective, I and other people think standardization i= s > important, and there is an important need. > > There are for instance the car manufacturers or those making products > for them (unfortunately, they don't speak up at the IETF because it's > not in their culture) who need to manage multiple interfaces on their > MIP6/NEMO MN/MR. The ISO TC204 WG16 is one of those efforts where such > feature is needed (in their CALM architecture). > > About implementation, there is an effort ongoing in a branch of the KAM= E > ipv6 stack (don't look for it on the KAME page, you won't find it now) > and people willing to do the same in USAGI. I don't want to speak up fo= r > USAGI and KAME people, but as far as reference implementations are > concerned, we better implement standards rather than proprietary > solutions, I think you would agree on this. > > Thierry. > > > > > jak > > > > PS: BTW, if you haven't seen it, you should check out the literature = on > > Boeing's Connexion system. It uses BGP to manage routes to a mobile 802.11 > > network in an airplane on a transcontinental flight. Lufthasa has deployed > > it on their new A333-600's. > > > > > > ----- Original Message -----=20 > > From: "Thierry Ernst" > > To: > > Cc: > > Sent: Thursday, November 18, 2004 6:55 PM > > Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > > > > > > > > > Dear Rajeev, > > > > > > Mobopts is a reseach group (IRTF), the problem that we want to solv= e is > > > much more clarified clarified than that, and solutions could be brought > > > in a timely manner if we restrict ourselves to part of the exisitin= g > > > problems and extensions to MIP6 and NEMO. > > > > > > Of course, taking a look at the whole picture would require much mo= re > > > consideration, and for the whole picture Mobopts could be the right > > > place. But, my intention, right now, is not to open the pendora box= ; > > > it's rather about bringing a solution to an immediate concern, in a > > > timely manner: how can I make use of my MIP6/NEMO function when I h= ave > > > multiple interfaces on my MH/MR ? I can't do it right now, and not > > > because it's np complex, but because there is no agreed solution between > > > the parties involved. > > > > > > Regarding what has been said at the MIP6 meeting, taking into accou= nt > > > the feedback from Erik, Thomas, and all the other, I would go for a BOF > > > at next IETF, but not with the objective to set up a new WG, but ju= st a > > > one-time BOF to discuss the problem thoroughly. > > > > > > But, prior to doing that, the other people involved with me on the > > > problem statement drafts, we should improve/clarify/extend our draf= ts. > > > The target would be end of this year; based on new drafts we would > > > consider setting up a BOF or not. (OK, guys, now we have pressure o= n our > > > shoulders ;-) > > > > > > Thierry > > > > > > > > > > > > On Thu, 18 Nov 2004 10:40:15 -0800 > > > Rajeev Koodli wrote: > > > > > > > Thierry Ernst wrote: > > > > > > > > > > Thus embarking on QoS sensitive, mobility specific multihomin= g > > support > > > > > > is both too open ended (on the QoS side) and too constraining (by > > only > > > > > > looking at cases when MIP/Nemo is used). > > > > > > > > > > > > So I think it would be useful for folks to try to think about and > > > > > > discuss the bigger picture. > > > > > > > > > > Agree. But then, where should this discussion take place ? MIP6= WG ? > > > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > > > > > > > I would add to Erik's observation that we need to be able to asse= ss a > > topic to > > > > see > > > > the maturity of the problem and the state of solutions, as well a= s what > > could > > > > be standardized in IETF. The IETF should work on well-defined _an= d_ > > > > well-agreed problems for which protocol specification could be > > accomplished > > > > in a timely manner. Topics where the problem needs to be crystalized, > > and > > > > solution > > > > space needs "thinking" require a forum for discussion. And, MobOp= ts > > could > > > > be such a place. > > > > > > > > We (mip*, MobOpts co-chairs) are in the process of working out a model > > to > > > > facilitate closer co-operation between mip* groups and MobOpts. T= he > > outcome > > > > should be focussed discussion on topics of mutual interest that l= ead to > > > > documents > > > > which can be a) taken up in mip* groups for standardization, b) MobOpts > > RG > > > > RFCs. MobOpts would run milestones and try to produce documents within a > > > > timeframe of interest to mip* groups. > > > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 29 13:39:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17961 for ; Mon, 29 Nov 2004 13:39:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqVX-0008QB-JE for mip6-web-archive@ietf.org; Mon, 29 Nov 2004 13:44:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYqNS-00059k-HQ; Mon, 29 Nov 2004 13:35:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYqIT-0004Tx-Oy for mip6@megatron.ietf.org; Mon, 29 Nov 2004 13:30:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17430 for ; Mon, 29 Nov 2004 13:30:46 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqNQ-0008GG-Gh for mip6@ietf.org; Mon, 29 Nov 2004 13:35:57 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 19:30:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: MIP6 agenda (Final) Date: Mon, 29 Nov 2004 19:30:37 +0100 Message-ID: Thread-Topic: [Mip6] FW: MIP6 agenda (Final) thread-index: AcTWP+IEHHmJJdM7RZKBRqdaFyjY7gAAL3lA From: "NJEDJOU Eric RD-RESA-REN" To: "James Kempf" , "Thierry Ernst" , X-OriginalArrivalTime: 29 Nov 2004 18:30:39.0442 (UTC) FILETIME=[86B4A320:01C4D641] X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10dcc25e55b9b5f7d6ded516404bdc4c Content-Transfer-Encoding: quoted-printable Hi James, I agree with your statement below. It looks like some mobility protocols = have been brought to completion within the IETF more with the only = desire to satisty the will to produce those protocols than with the will = to ear the market needs. This is what bring so many protocols to the = state of unuseness. =20 Eric Njedjou -----Message d'origine----- De : James Kempf [mailto:kempf@docomolabs-usa.com]=20 Envoy=E9 : lundi 29 novembre 2004 19:20 =C0 : NJEDJOU Eric RD-RESA-REN; Thierry Ernst; mip6@ietf.org Objet : Re: [Mip6] FW: MIP6 agenda (Final) Eric, I can't find anything specific to object to in your analysis, but I was = making a broader point. My point was, that researchers often tend to = oversell the interest in implementing and deploying their work, = particularly in the IETF. This then leads WGs to get chartered that = develop protocols which don't get deployed. Given the enormous amount of = time and effort involved in doing IETF work (particularly for the WG = chairs and draft editors), I believe it is important to weed out those = tendencies early, prior to chartering, and re-direct such research work = to the IRTF, where it properly belongs. jak ----- Original Message ----- From: "NJEDJOU Eric RD-RESA-REN" To: "James Kempf" ; "Thierry Ernst" ; Sent: Sunday, November 28, 2004 7:12 AM Subject: RE: [Mip6] FW: MIP6 agenda (Final) Hi James, The Problem i guess Operators have with the Seamoby Protocols is more complex. First, the Seamoby protocols were meant to be operations to be performed prior/post to running the Fats Handoffs protocols. And Fast Handoffs protocols themselves are not deployed because operators are still only assessing the real need to have IP mobility services for their customers = as provided by Mobile IP. Another issue is that the Fast Handoffs protocols were designed with the 802.11 AP/AR to 802.11 AP/AR handover scenario in mind. And We can effectively see that people have only be able to = implement the Fast Handoffs protocols for 802.11 handover. Fast Handoffs do not = apply to GPRS <-> 802.11 handover scnearios. This is because the handover signalling is something to be exchanged at the very edge of the network (access routers) and exchanging FMIP signalling between an AR in the = 802.11 network and the GGSN in the GPRS core network require the flows to pass = via too many hops, rendering the handover process not reactive as is the = will of having a fast handoff scheme. Therefore for the GPRS <-> 802.11, the only possible fallback is to use simple Mobile IPv4/v6. Further, using simple Mipv4/MIPv6 will not = require Operators to modify their edge to include SEAMOBY/MIPSHOP operations. = When the need for MIpv4/MIPv6 will really be ascertained, then those = protocols will be considered, but again not for the inter-technology handovers. Another reason why SEAMOBY/MIPSHOP protocols would not likely be = deployed on a large scale is that even that 802.11 AP to AP handover scenario ( = those protocols fit for) does not require a subnet change in most of the = cases. The whole thing can therefore be handled within L2 as Task Group R of = IEEE 802.11 is doing. Eric Njedjou France Telecom -----Message d'origine----- De : mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] De la part de James Kempf Envoy=E9 : lundi 22 novembre 2004 18:43 =C0 : Thierry Ernst; mip6@ietf.org Objet : Re: [Mip6] FW: MIP6 agenda (Final) Hi Thierry, Please don't feel offended, but I tend to discount attestations from researchers that there is product and deployment interest. For 4 years, = we had researchers saying that there was product and deployment interest in Seamoby, yet prior to switching the drafts to experimental, we had not a single vendor or operator willing to say that they were interested in developing and deploying the protocols. That's why they were switched to experimental. If there are not vendors and operators willing to come on = the list and participate in the process so their customers can enjoy the benefits of interoperability, then I don't think this is an appropriate topic for the mip6 WG, since mip6 isn't chartered to do experimental = work. Regarding ISO, if there's another standardization body that needs the = work, then a liason letter to the IETF via the IAB requesting an Internet = standard might be in order. However, I believe a more productive track would be to take the work to Mobopts as Raj and Rajeev have requested, possibly in conjunction with examining the multihoming work that v6ops is doing for mobility = implications . Rajeev and Bill are working hard to make Mobopts a venue for maturing = good ideas, and I think that this work may now be showing results, since we = now have two drafts there that they are interested in making research group drafts, for eventual re-introduction into IETF. jak ----- Original Message ----- From: "Thierry Ernst" To: Sent: Sunday, November 21, 2004 8:07 PM Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > Hi James, > > > Are there any vendors interested in implementing this solution = and/or > > network operators interested in deploying it (note: I'm not asking = for > > detailed product plans, just the kind of committment that was given = in, say, > > the chartering discussion of the Mobike WG several IETFs ago)? Or = other > > standardization bodies (such as our good friends at 3GPP2) who are > > interested in incorporating it into their standards? > > Peole from various companies have told me so and I would rather let = them > express their opinions directly to demonstrate their true interest. = But > many of them may not be on the list. > > Also, there are proprietary solutions and these manufacturers may not = be > eager to standardize their solutions (unless some raise the topic at = the > IETF, in which case they would have to). > > For instance, mobile phone company A may want terminals allowing their > users to switch between 3G/GPRS and 802.11. In their scenario, both > access networks would belong to the same operator, so a proprietary > solution is fine. > > But from a user perspective, I and other people think standardization = is > important, and there is an important need. > > There are for instance the car manufacturers or those making products > for them (unfortunately, they don't speak up at the IETF because it's > not in their culture) who need to manage multiple interfaces on their > MIP6/NEMO MN/MR. The ISO TC204 WG16 is one of those efforts where such > feature is needed (in their CALM architecture). > > About implementation, there is an effort ongoing in a branch of the = KAME > ipv6 stack (don't look for it on the KAME page, you won't find it now) > and people willing to do the same in USAGI. I don't want to speak up = for > USAGI and KAME people, but as far as reference implementations are > concerned, we better implement standards rather than proprietary > solutions, I think you would agree on this. > > Thierry. > > > > > jak > > > > PS: BTW, if you haven't seen it, you should check out the literature = on > > Boeing's Connexion system. It uses BGP to manage routes to a mobile 802.11 > > network in an airplane on a transcontinental flight. Lufthasa has deployed > > it on their new A333-600's. > > > > > > ----- Original Message -----=20 > > From: "Thierry Ernst" > > To: > > Cc: > > Sent: Thursday, November 18, 2004 6:55 PM > > Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > > > > > > > > > Dear Rajeev, > > > > > > Mobopts is a reseach group (IRTF), the problem that we want to = solve is > > > much more clarified clarified than that, and solutions could be brought > > > in a timely manner if we restrict ourselves to part of the = exisiting > > > problems and extensions to MIP6 and NEMO. > > > > > > Of course, taking a look at the whole picture would require much = more > > > consideration, and for the whole picture Mobopts could be the = right > > > place. But, my intention, right now, is not to open the pendora = box; > > > it's rather about bringing a solution to an immediate concern, in = a > > > timely manner: how can I make use of my MIP6/NEMO function when I = have > > > multiple interfaces on my MH/MR ? I can't do it right now, and not > > > because it's np complex, but because there is no agreed solution between > > > the parties involved. > > > > > > Regarding what has been said at the MIP6 meeting, taking into = account > > > the feedback from Erik, Thomas, and all the other, I would go for = a BOF > > > at next IETF, but not with the objective to set up a new WG, but = just a > > > one-time BOF to discuss the problem thoroughly. > > > > > > But, prior to doing that, the other people involved with me on the > > > problem statement drafts, we should improve/clarify/extend our = drafts. > > > The target would be end of this year; based on new drafts we would > > > consider setting up a BOF or not. (OK, guys, now we have pressure = on our > > > shoulders ;-) > > > > > > Thierry > > > > > > > > > > > > On Thu, 18 Nov 2004 10:40:15 -0800 > > > Rajeev Koodli wrote: > > > > > > > Thierry Ernst wrote: > > > > > > > > > > Thus embarking on QoS sensitive, mobility specific = multihoming > > support > > > > > > is both too open ended (on the QoS side) and too = constraining (by > > only > > > > > > looking at cases when MIP/Nemo is used). > > > > > > > > > > > > So I think it would be useful for folks to try to think = about and > > > > > > discuss the bigger picture. > > > > > > > > > > Agree. But then, where should this discussion take place ? = MIP6 WG ? > > > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > > > > > > > I would add to Erik's observation that we need to be able to = assess a > > topic to > > > > see > > > > the maturity of the problem and the state of solutions, as well = as what > > could > > > > be standardized in IETF. The IETF should work on well-defined = _and_ > > > > well-agreed problems for which protocol specification could be > > accomplished > > > > in a timely manner. Topics where the problem needs to be crystalized, > > and > > > > solution > > > > space needs "thinking" require a forum for discussion. And, = MobOpts > > could > > > > be such a place. > > > > > > > > We (mip*, MobOpts co-chairs) are in the process of working out a model > > to > > > > facilitate closer co-operation between mip* groups and MobOpts. = The > > outcome > > > > should be focussed discussion on topics of mutual interest that = lead to > > > > documents > > > > which can be a) taken up in mip* groups for standardization, b) MobOpts > > RG > > > > RFCs. MobOpts would run milestones and try to produce documents within a > > > > timeframe of interest to mip* groups. > > > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 29 13:48:55 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18858 for ; Mon, 29 Nov 2004 13:48:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqex-0000Bf-OH for mip6-web-archive@ietf.org; Mon, 29 Nov 2004 13:54:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYqU6-00068j-NT; Mon, 29 Nov 2004 13:42:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYqPR-0005KZ-5c for mip6@megatron.ietf.org; Mon, 29 Nov 2004 13:38:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17877 for ; Mon, 29 Nov 2004 13:37:58 -0500 (EST) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYqUO-0008OU-2e for mip6@ietf.org; Mon, 29 Nov 2004 13:43:08 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Nov 2004 19:37:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] FW: MIP6 agenda (Final) Date: Mon, 29 Nov 2004 19:37:54 +0100 Message-ID: Thread-Topic: [Mip6] FW: MIP6 agenda (Final) thread-index: AcTWP+IEHHmJJdM7RZKBRqdaFyjY7gAAiUxA From: "NJEDJOU Eric RD-RESA-REN" To: "James Kempf" , "Thierry Ernst" , X-OriginalArrivalTime: 29 Nov 2004 18:37:56.0067 (UTC) FILETIME=[8AF45330:01C4D642] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 Content-Transfer-Encoding: quoted-printable I thing the multihoming problem could potentially have future markets = interests and could be worthwile looking at though. As an example access = service providers would be selling ubiquitous wireless services. These = may require that the multihoming problem be well understood =20 Eric=20 -----Message d'origine----- De : James Kempf [mailto:kempf@docomolabs-usa.com]=20 Envoy=E9 : lundi 29 novembre 2004 19:20 =C0 : NJEDJOU Eric RD-RESA-REN; Thierry Ernst; mip6@ietf.org Objet : Re: [Mip6] FW: MIP6 agenda (Final) Eric, I can't find anything specific to object to in your analysis, but I was = making a broader point. My point was, that researchers often tend to = oversell the interest in implementing and deploying their work, = particularly in the IETF. This then leads WGs to get chartered that = develop protocols which don't get deployed. Given the enormous amount of = time and effort involved in doing IETF work (particularly for the WG = chairs and draft editors), I believe it is important to weed out those = tendencies early, prior to chartering, and re-direct such research work = to the IRTF, where it properly belongs. jak ----- Original Message ----- From: "NJEDJOU Eric RD-RESA-REN" To: "James Kempf" ; "Thierry Ernst" ; Sent: Sunday, November 28, 2004 7:12 AM Subject: RE: [Mip6] FW: MIP6 agenda (Final) Hi James, The Problem i guess Operators have with the Seamoby Protocols is more complex. First, the Seamoby protocols were meant to be operations to be performed prior/post to running the Fats Handoffs protocols. And Fast Handoffs protocols themselves are not deployed because operators are still only assessing the real need to have IP mobility services for their customers = as provided by Mobile IP. Another issue is that the Fast Handoffs protocols were designed with the 802.11 AP/AR to 802.11 AP/AR handover scenario in mind. And We can effectively see that people have only be able to = implement the Fast Handoffs protocols for 802.11 handover. Fast Handoffs do not = apply to GPRS <-> 802.11 handover scnearios. This is because the handover signalling is something to be exchanged at the very edge of the network (access routers) and exchanging FMIP signalling between an AR in the = 802.11 network and the GGSN in the GPRS core network require the flows to pass = via too many hops, rendering the handover process not reactive as is the = will of having a fast handoff scheme. Therefore for the GPRS <-> 802.11, the only possible fallback is to use simple Mobile IPv4/v6. Further, using simple Mipv4/MIPv6 will not = require Operators to modify their edge to include SEAMOBY/MIPSHOP operations. = When the need for MIpv4/MIPv6 will really be ascertained, then those = protocols will be considered, but again not for the inter-technology handovers. Another reason why SEAMOBY/MIPSHOP protocols would not likely be = deployed on a large scale is that even that 802.11 AP to AP handover scenario ( = those protocols fit for) does not require a subnet change in most of the = cases. The whole thing can therefore be handled within L2 as Task Group R of = IEEE 802.11 is doing. Eric Njedjou France Telecom -----Message d'origine----- De : mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] De la part de James Kempf Envoy=E9 : lundi 22 novembre 2004 18:43 =C0 : Thierry Ernst; mip6@ietf.org Objet : Re: [Mip6] FW: MIP6 agenda (Final) Hi Thierry, Please don't feel offended, but I tend to discount attestations from researchers that there is product and deployment interest. For 4 years, = we had researchers saying that there was product and deployment interest in Seamoby, yet prior to switching the drafts to experimental, we had not a single vendor or operator willing to say that they were interested in developing and deploying the protocols. That's why they were switched to experimental. If there are not vendors and operators willing to come on = the list and participate in the process so their customers can enjoy the benefits of interoperability, then I don't think this is an appropriate topic for the mip6 WG, since mip6 isn't chartered to do experimental = work. Regarding ISO, if there's another standardization body that needs the = work, then a liason letter to the IETF via the IAB requesting an Internet = standard might be in order. However, I believe a more productive track would be to take the work to Mobopts as Raj and Rajeev have requested, possibly in conjunction with examining the multihoming work that v6ops is doing for mobility = implications . Rajeev and Bill are working hard to make Mobopts a venue for maturing = good ideas, and I think that this work may now be showing results, since we = now have two drafts there that they are interested in making research group drafts, for eventual re-introduction into IETF. jak ----- Original Message ----- From: "Thierry Ernst" To: Sent: Sunday, November 21, 2004 8:07 PM Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > Hi James, > > > Are there any vendors interested in implementing this solution = and/or > > network operators interested in deploying it (note: I'm not asking = for > > detailed product plans, just the kind of committment that was given = in, say, > > the chartering discussion of the Mobike WG several IETFs ago)? Or = other > > standardization bodies (such as our good friends at 3GPP2) who are > > interested in incorporating it into their standards? > > Peole from various companies have told me so and I would rather let = them > express their opinions directly to demonstrate their true interest. = But > many of them may not be on the list. > > Also, there are proprietary solutions and these manufacturers may not = be > eager to standardize their solutions (unless some raise the topic at = the > IETF, in which case they would have to). > > For instance, mobile phone company A may want terminals allowing their > users to switch between 3G/GPRS and 802.11. In their scenario, both > access networks would belong to the same operator, so a proprietary > solution is fine. > > But from a user perspective, I and other people think standardization = is > important, and there is an important need. > > There are for instance the car manufacturers or those making products > for them (unfortunately, they don't speak up at the IETF because it's > not in their culture) who need to manage multiple interfaces on their > MIP6/NEMO MN/MR. The ISO TC204 WG16 is one of those efforts where such > feature is needed (in their CALM architecture). > > About implementation, there is an effort ongoing in a branch of the = KAME > ipv6 stack (don't look for it on the KAME page, you won't find it now) > and people willing to do the same in USAGI. I don't want to speak up = for > USAGI and KAME people, but as far as reference implementations are > concerned, we better implement standards rather than proprietary > solutions, I think you would agree on this. > > Thierry. > > > > > jak > > > > PS: BTW, if you haven't seen it, you should check out the literature = on > > Boeing's Connexion system. It uses BGP to manage routes to a mobile 802.11 > > network in an airplane on a transcontinental flight. Lufthasa has deployed > > it on their new A333-600's. > > > > > > ----- Original Message -----=20 > > From: "Thierry Ernst" > > To: > > Cc: > > Sent: Thursday, November 18, 2004 6:55 PM > > Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > > > > > > > > > Dear Rajeev, > > > > > > Mobopts is a reseach group (IRTF), the problem that we want to = solve is > > > much more clarified clarified than that, and solutions could be brought > > > in a timely manner if we restrict ourselves to part of the = exisiting > > > problems and extensions to MIP6 and NEMO. > > > > > > Of course, taking a look at the whole picture would require much = more > > > consideration, and for the whole picture Mobopts could be the = right > > > place. But, my intention, right now, is not to open the pendora = box; > > > it's rather about bringing a solution to an immediate concern, in = a > > > timely manner: how can I make use of my MIP6/NEMO function when I = have > > > multiple interfaces on my MH/MR ? I can't do it right now, and not > > > because it's np complex, but because there is no agreed solution between > > > the parties involved. > > > > > > Regarding what has been said at the MIP6 meeting, taking into = account > > > the feedback from Erik, Thomas, and all the other, I would go for = a BOF > > > at next IETF, but not with the objective to set up a new WG, but = just a > > > one-time BOF to discuss the problem thoroughly. > > > > > > But, prior to doing that, the other people involved with me on the > > > problem statement drafts, we should improve/clarify/extend our = drafts. > > > The target would be end of this year; based on new drafts we would > > > consider setting up a BOF or not. (OK, guys, now we have pressure = on our > > > shoulders ;-) > > > > > > Thierry > > > > > > > > > > > > On Thu, 18 Nov 2004 10:40:15 -0800 > > > Rajeev Koodli wrote: > > > > > > > Thierry Ernst wrote: > > > > > > > > > > Thus embarking on QoS sensitive, mobility specific = multihoming > > support > > > > > > is both too open ended (on the QoS side) and too = constraining (by > > only > > > > > > looking at cases when MIP/Nemo is used). > > > > > > > > > > > > So I think it would be useful for folks to try to think = about and > > > > > > discuss the bigger picture. > > > > > > > > > > Agree. But then, where should this discussion take place ? = MIP6 WG ? > > > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > > > > > > > I would add to Erik's observation that we need to be able to = assess a > > topic to > > > > see > > > > the maturity of the problem and the state of solutions, as well = as what > > could > > > > be standardized in IETF. The IETF should work on well-defined = _and_ > > > > well-agreed problems for which protocol specification could be > > accomplished > > > > in a timely manner. Topics where the problem needs to be crystalized, > > and > > > > solution > > > > space needs "thinking" require a forum for discussion. And, = MobOpts > > could > > > > be such a place. > > > > > > > > We (mip*, MobOpts co-chairs) are in the process of working out a model > > to > > > > facilitate closer co-operation between mip* groups and MobOpts. = The > > outcome > > > > should be focussed discussion on topics of mutual interest that = lead to > > > > documents > > > > which can be a) taken up in mip* groups for standardization, b) MobOpts > > RG > > > > RFCs. MobOpts would run milestones and try to produce documents within a > > > > timeframe of interest to mip* groups. > > > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 29 17:22:24 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19958 for ; Mon, 29 Nov 2004 17:22:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYtzb-0000mE-GK for mip6-web-archive@ietf.org; Mon, 29 Nov 2004 17:27:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYtei-0006a3-Im; Mon, 29 Nov 2004 17:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYsDw-00087l-Rk for mip6@megatron.ietf.org; Mon, 29 Nov 2004 15:34:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29422 for ; Mon, 29 Nov 2004 15:34:15 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYsIr-0002cO-Mz for mip6@ietf.org; Mon, 29 Nov 2004 15:39:25 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iATK57C22198; Mon, 29 Nov 2004 12:05:07 -0800 X-mProtect: <200411292005> Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnd0hM6; Mon, 29 Nov 2004 12:05:05 PST Message-ID: <41AB8840.CAF0CF90@iprg.nokia.com> Date: Mon, 29 Nov 2004 12:36:16 -0800 From: "Charles E.Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: NJEDJOU Eric RD-RESA-REN Subject: Re: [Mip6] FW: MIP6 agenda (Final) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Hello Eric, It's hard to work towards a solution of the problem you raise, without knowing which protocols you mean. Presumably you at least include the [seamoby] protocols and maybe Mobile IPv6. In the case of Mobile IPv6, the protocol work was done according to original requirements for IPv6. I don't see exactly which market interaction would satisfy your apparent request in this case. Fast Handover was developed to work with Mobile IPv6, and so the same comments would apply. The same point could be applied to [seamoby], roughly speaking, but the results were adapted for IPv4, and anyway were strongly influenced by a weird amount of politicking, problem statement haggling, requirements documentation, and generalized abstraction detraction. If, instead, you meant to discuss Mobile IP for IPv4, then I think the barriers for more widespread deployment have much more to do with (current) operator business models than with protocol design. Even so, We are seeing continued good growth in deployment, and are poised for much more growth in the future. If you didn't mean any of these, then I guess I missed your message and so please forgive my irrelevant reply. Lastly, I have several comments your point: > ..... > brought to completion within the IETF more with the > only desire to satisty the will to produce those > protocols than with the will to ear the market needs. - First, I believe you always want to have people working on protocols who believe in them, and yet are open minded about community involvement - Second, I really think most IETF engineers are in fact responsive to their perception of market needs. As an example, the work on Fast Handovers was motivated quite strongly by the perceived need to enable Mobile IP to work with VoIP. - Third, the market does not want protocols. The market wants systems. IETF should not, in my opinion, get into the business of designing market-ready systems. Instead, I think we should make protocol components that can readily be built into many systems of various kinds. There is a lot of room for expertise at various levels. Protocol engineering is one area of expertise, and system integration is another, for instance. Both work better with good understanding of other areas of expertise, e.g. security, and systems programming. Maybe what we are getting now in the IETF isn't such a bad mix of the various areas of expertise. We can ask for some of the participants to be economists or policy experts, but it might be asking too much to require in every case. Regards, Charlie P. NJEDJOU Eric RD-RESA-REN wrote: > > Hi James, > I agree with your statement below. It looks like some mobility protocols have been brought to completion within the IETF more with the only desire to satisty the will to produce those protocols than with the will to ear the market needs. This is what bring so many protocols to the state of unuseness. > Eric Njedjou _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 29 17:31:06 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21202 for ; Mon, 29 Nov 2004 17:31:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYu81-00018u-KV for mip6-web-archive@ietf.org; Mon, 29 Nov 2004 17:36:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYtz8-0002TU-Ts; Mon, 29 Nov 2004 17:27:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYtom-00039r-D6 for mip6@megatron.ietf.org; Mon, 29 Nov 2004 17:16:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18815 for ; Mon, 29 Nov 2004 17:16:22 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYttk-0000S1-W2 for mip6@ietf.org; Mon, 29 Nov 2004 17:21:33 -0500 Message-ID: <039001c4d661$2b2fef30$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "NJEDJOU Eric RD-RESA-REN" , "Thierry Ernst" , References: Subject: Re: [Mip6] FW: MIP6 agenda (Final) Date: Mon, 29 Nov 2004 14:17:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Content-Transfer-Encoding: quoted-printable Eric, This is exactly the kind of speculative grounds that I am trying to warn against. If the problem is not well understood, then IRTF is the right pl= ace for it. If it is well understood and people are ready to design a protoco= l to solve it, then IETF is the right place for it. Having a good problem statement is a start, and I believe there has been some discussion about that on the list. The process of developing the problem statement, and the problem statement itself, should reveal a good deal about how well understood the problem is. jak ----- Original Message -----=20 From: "NJEDJOU Eric RD-RESA-REN" To: "James Kempf" ; "Thierry Ernst" ; Sent: Monday, November 29, 2004 10:37 AM Subject: RE: [Mip6] FW: MIP6 agenda (Final) I thing the multihoming problem could potentially have future markets interests and could be worthwile looking at though. As an example access service providers would be selling ubiquitous wireless services. These ma= y require that the multihoming problem be well understood Eric -----Message d'origine----- De : James Kempf [mailto:kempf@docomolabs-usa.com] Envoy=E9 : lundi 29 novembre 2004 19:20 =C0 : NJEDJOU Eric RD-RESA-REN; Thierry Ernst; mip6@ietf.org Objet : Re: [Mip6] FW: MIP6 agenda (Final) Eric, I can't find anything specific to object to in your analysis, but I was making a broader point. My point was, that researchers often tend to oversell the interest in implementing and deploying their work, particula= rly in the IETF. This then leads WGs to get chartered that develop protocols which don't get deployed. Given the enormous amount of time and effort involved in doing IETF work (particularly for the WG chairs and draft editors), I believe it is important to weed out those tendencies early, prior to chartering, and re-direct such research work to the IRTF, where = it properly belongs. jak ----- Original Message ----- From: "NJEDJOU Eric RD-RESA-REN" To: "James Kempf" ; "Thierry Ernst" ; Sent: Sunday, November 28, 2004 7:12 AM Subject: RE: [Mip6] FW: MIP6 agenda (Final) Hi James, The Problem i guess Operators have with the Seamoby Protocols is more complex. First, the Seamoby protocols were meant to be operations to be performed prior/post to running the Fats Handoffs protocols. And Fast Handoffs protocols themselves are not deployed because operators are still only assessing the real need to have IP mobility services for their customers = as provided by Mobile IP. Another issue is that the Fast Handoffs protocols were designed with the 802.11 AP/AR to 802.11 AP/AR handover scenario in mind. And We can effectively see that people have only be able to impleme= nt the Fast Handoffs protocols for 802.11 handover. Fast Handoffs do not ap= ply to GPRS <-> 802.11 handover scnearios. This is because the handover signalling is something to be exchanged at the very edge of the network (access routers) and exchanging FMIP signalling between an AR in the 802.= 11 network and the GGSN in the GPRS core network require the flows to pass v= ia too many hops, rendering the handover process not reactive as is the will= of having a fast handoff scheme. Therefore for the GPRS <-> 802.11, the only possible fallback is to use simple Mobile IPv4/v6. Further, using simple Mipv4/MIPv6 will not require Operators to modify their edge to include SEAMOBY/MIPSHOP operations. Whe= n the need for MIpv4/MIPv6 will really be ascertained, then those protocols will be considered, but again not for the inter-technology handovers. Another reason why SEAMOBY/MIPSHOP protocols would not likely be deployed= on a large scale is that even that 802.11 AP to AP handover scenario ( those protocols fit for) does not require a subnet change in most of the cases. The whole thing can therefore be handled within L2 as Task Group R of IEE= E 802.11 is doing. Eric Njedjou France Telecom -----Message d'origine----- De : mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] De la part de James Kempf Envoy=E9 : lundi 22 novembre 2004 18:43 =C0 : Thierry Ernst; mip6@ietf.org Objet : Re: [Mip6] FW: MIP6 agenda (Final) Hi Thierry, Please don't feel offended, but I tend to discount attestations from researchers that there is product and deployment interest. For 4 years, w= e had researchers saying that there was product and deployment interest in Seamoby, yet prior to switching the drafts to experimental, we had not a single vendor or operator willing to say that they were interested in developing and deploying the protocols. That's why they were switched to experimental. If there are not vendors and operators willing to come on t= he list and participate in the process so their customers can enjoy the benefits of interoperability, then I don't think this is an appropriate topic for the mip6 WG, since mip6 isn't chartered to do experimental work= . Regarding ISO, if there's another standardization body that needs the wor= k, then a liason letter to the IETF via the IAB requesting an Internet stand= ard might be in order. However, I believe a more productive track would be to take the work to Mobopts as Raj and Rajeev have requested, possibly in conjunction with examining the multihoming work that v6ops is doing for mobility implicati= ons . Rajeev and Bill are working hard to make Mobopts a venue for maturing g= ood ideas, and I think that this work may now be showing results, since we no= w have two drafts there that they are interested in making research group drafts, for eventual re-introduction into IETF. jak ----- Original Message ----- From: "Thierry Ernst" To: Sent: Sunday, November 21, 2004 8:07 PM Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > Hi James, > > > Are there any vendors interested in implementing this solution and/or > > network operators interested in deploying it (note: I'm not asking fo= r > > detailed product plans, just the kind of committment that was given i= n, say, > > the chartering discussion of the Mobike WG several IETFs ago)? Or oth= er > > standardization bodies (such as our good friends at 3GPP2) who are > > interested in incorporating it into their standards? > > Peole from various companies have told me so and I would rather let the= m > express their opinions directly to demonstrate their true interest. But > many of them may not be on the list. > > Also, there are proprietary solutions and these manufacturers may not b= e > eager to standardize their solutions (unless some raise the topic at th= e > IETF, in which case they would have to). > > For instance, mobile phone company A may want terminals allowing their > users to switch between 3G/GPRS and 802.11. In their scenario, both > access networks would belong to the same operator, so a proprietary > solution is fine. > > But from a user perspective, I and other people think standardization i= s > important, and there is an important need. > > There are for instance the car manufacturers or those making products > for them (unfortunately, they don't speak up at the IETF because it's > not in their culture) who need to manage multiple interfaces on their > MIP6/NEMO MN/MR. The ISO TC204 WG16 is one of those efforts where such > feature is needed (in their CALM architecture). > > About implementation, there is an effort ongoing in a branch of the KAM= E > ipv6 stack (don't look for it on the KAME page, you won't find it now) > and people willing to do the same in USAGI. I don't want to speak up fo= r > USAGI and KAME people, but as far as reference implementations are > concerned, we better implement standards rather than proprietary > solutions, I think you would agree on this. > > Thierry. > > > > > jak > > > > PS: BTW, if you haven't seen it, you should check out the literature = on > > Boeing's Connexion system. It uses BGP to manage routes to a mobile 802.11 > > network in an airplane on a transcontinental flight. Lufthasa has deployed > > it on their new A333-600's. > > > > > > ----- Original Message -----=20 > > From: "Thierry Ernst" > > To: > > Cc: > > Sent: Thursday, November 18, 2004 6:55 PM > > Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > > > > > > > > > Dear Rajeev, > > > > > > Mobopts is a reseach group (IRTF), the problem that we want to solv= e is > > > much more clarified clarified than that, and solutions could be brought > > > in a timely manner if we restrict ourselves to part of the exisitin= g > > > problems and extensions to MIP6 and NEMO. > > > > > > Of course, taking a look at the whole picture would require much mo= re > > > consideration, and for the whole picture Mobopts could be the right > > > place. But, my intention, right now, is not to open the pendora box= ; > > > it's rather about bringing a solution to an immediate concern, in a > > > timely manner: how can I make use of my MIP6/NEMO function when I h= ave > > > multiple interfaces on my MH/MR ? I can't do it right now, and not > > > because it's np complex, but because there is no agreed solution between > > > the parties involved. > > > > > > Regarding what has been said at the MIP6 meeting, taking into accou= nt > > > the feedback from Erik, Thomas, and all the other, I would go for a BOF > > > at next IETF, but not with the objective to set up a new WG, but ju= st a > > > one-time BOF to discuss the problem thoroughly. > > > > > > But, prior to doing that, the other people involved with me on the > > > problem statement drafts, we should improve/clarify/extend our draf= ts. > > > The target would be end of this year; based on new drafts we would > > > consider setting up a BOF or not. (OK, guys, now we have pressure o= n our > > > shoulders ;-) > > > > > > Thierry > > > > > > > > > > > > On Thu, 18 Nov 2004 10:40:15 -0800 > > > Rajeev Koodli wrote: > > > > > > > Thierry Ernst wrote: > > > > > > > > > > Thus embarking on QoS sensitive, mobility specific multihomin= g > > support > > > > > > is both too open ended (on the QoS side) and too constraining (by > > only > > > > > > looking at cases when MIP/Nemo is used). > > > > > > > > > > > > So I think it would be useful for folks to try to think about and > > > > > > discuss the bigger picture. > > > > > > > > > > Agree. But then, where should this discussion take place ? MIP6= WG ? > > > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > > > > > > > I would add to Erik's observation that we need to be able to asse= ss a > > topic to > > > > see > > > > the maturity of the problem and the state of solutions, as well a= s what > > could > > > > be standardized in IETF. The IETF should work on well-defined _an= d_ > > > > well-agreed problems for which protocol specification could be > > accomplished > > > > in a timely manner. Topics where the problem needs to be crystalized, > > and > > > > solution > > > > space needs "thinking" require a forum for discussion. And, MobOp= ts > > could > > > > be such a place. > > > > > > > > We (mip*, MobOpts co-chairs) are in the process of working out a model > > to > > > > facilitate closer co-operation between mip* groups and MobOpts. T= he > > outcome > > > > should be focussed discussion on topics of mutual interest that l= ead to > > > > documents > > > > which can be a) taken up in mip* groups for standardization, b) MobOpts > > RG > > > > RFCs. MobOpts would run milestones and try to produce documents within a > > > > timeframe of interest to mip* groups. > > > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 29 18:00:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23608 for ; Mon, 29 Nov 2004 18:00:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYuaK-0001wb-F2 for mip6-web-archive@ietf.org; Mon, 29 Nov 2004 18:05:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYuNJ-00027i-O6; Mon, 29 Nov 2004 17:52:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYtAh-0000YH-Pl for mip6@megatron.ietf.org; Mon, 29 Nov 2004 16:35:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10873 for ; Mon, 29 Nov 2004 16:34:57 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYtFW-0006JB-N4 for mip6@ietf.org; Mon, 29 Nov 2004 16:40:08 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id iATLaW67004474 for ; Mon, 29 Nov 2004 14:36:32 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id iATLYSvl013597 for ; Mon, 29 Nov 2004 15:34:29 -0600 Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.72) id ; Mon, 29 Nov 2004 15:34:46 -0600 Message-ID: From: Singh Ajoy-ASINGH1 To: "'NJEDJOU Eric RD-RESA-REN'" , James Kempf , Thierry Ernst , mip6@ietf.org Subject: RE: [Mip6] FW: MIP6 agenda (Final) Date: Mon, 29 Nov 2004 15:34:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 29 Nov 2004 17:52:04 -0500 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bcdb6f0ba9636bf286b7e28ccb8bd9b Content-Transfer-Encoding: quoted-printable Hi Eric,=20 Well this is in response to some of the embedded emails. I am not sure = if the statement that Seamoby and Fast Handoff protocols cannot be = deployed is correct. I do agree that current architecture of 3GPP may = not be useful for Seamoby protocols but SeaMoby and Fast Handoff = protocols can be deployed if there is desire to do so. I do not see any = significant technical reason for not being able to deploy SeaMoby and = Fast Handoff protocols in next generation access networks.=20 Regards, Ajoy=20 -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of = NJEDJOU Eric RD-RESA-REN Sent: Monday, November 29, 2004 12:31 PM To: James Kempf; Thierry Ernst; mip6@ietf.org Subject: RE: [Mip6] FW: MIP6 agenda (Final) Hi James, I agree with your statement below. It looks like some mobility = protocols have been brought to completion within the IETF more with the = only desire to satisty the will to produce those protocols than with = the will to ear the market needs. This is what bring so many protocols = to the state of unuseness. =20 Eric Njedjou -----Message d'origine----- De : James Kempf [mailto:kempf@docomolabs-usa.com]=20 Envoy=E9 : lundi 29 novembre 2004 19:20 =C0 : NJEDJOU Eric RD-RESA-REN; Thierry Ernst; mip6@ietf.org Objet : Re: [Mip6] FW: MIP6 agenda (Final) Eric, I can't find anything specific to object to in your analysis, but I was = making a broader point. My point was, that researchers often tend to = oversell the interest in implementing and deploying their work, = particularly in the IETF. This then leads WGs to get chartered that = develop protocols which don't get deployed. Given the enormous amount = of time and effort involved in doing IETF work (particularly for the WG = chairs and draft editors), I believe it is important to weed out those = tendencies early, prior to chartering, and re-direct such research work = to the IRTF, where it properly belongs. jak ----- Original Message ----- From: "NJEDJOU Eric RD-RESA-REN" To: "James Kempf" ; "Thierry Ernst" ; Sent: Sunday, November 28, 2004 7:12 AM Subject: RE: [Mip6] FW: MIP6 agenda (Final) Hi James, The Problem i guess Operators have with the Seamoby Protocols is more complex. First, the Seamoby protocols were meant to be operations to be = performed prior/post to running the Fats Handoffs protocols. And Fast Handoffs protocols themselves are not deployed because operators are still only assessing the real need to have IP mobility services for their = customers as provided by Mobile IP. Another issue is that the Fast Handoffs = protocols were designed with the 802.11 AP/AR to 802.11 AP/AR handover scenario = in mind. And We can effectively see that people have only be able to = implement the Fast Handoffs protocols for 802.11 handover. Fast Handoffs do not = apply to GPRS <-> 802.11 handover scnearios. This is because the handover signalling is something to be exchanged at the very edge of the network (access routers) and exchanging FMIP signalling between an AR in the = 802.11 network and the GGSN in the GPRS core network require the flows to pass = via too many hops, rendering the handover process not reactive as is the = will of having a fast handoff scheme. Therefore for the GPRS <-> 802.11, the only possible fallback is to use simple Mobile IPv4/v6. Further, using simple Mipv4/MIPv6 will not = require Operators to modify their edge to include SEAMOBY/MIPSHOP operations. = When the need for MIpv4/MIPv6 will really be ascertained, then those = protocols will be considered, but again not for the inter-technology handovers. Another reason why SEAMOBY/MIPSHOP protocols would not likely be = deployed on a large scale is that even that 802.11 AP to AP handover scenario ( = those protocols fit for) does not require a subnet change in most of the = cases. The whole thing can therefore be handled within L2 as Task Group R of = IEEE 802.11 is doing. Eric Njedjou France Telecom -----Message d'origine----- De : mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] De la part de James Kempf Envoy=E9 : lundi 22 novembre 2004 18:43 =C0 : Thierry Ernst; mip6@ietf.org Objet : Re: [Mip6] FW: MIP6 agenda (Final) Hi Thierry, Please don't feel offended, but I tend to discount attestations from researchers that there is product and deployment interest. For 4 years, = we had researchers saying that there was product and deployment interest = in Seamoby, yet prior to switching the drafts to experimental, we had not = a single vendor or operator willing to say that they were interested in developing and deploying the protocols. That's why they were switched = to experimental. If there are not vendors and operators willing to come on = the list and participate in the process so their customers can enjoy the benefits of interoperability, then I don't think this is an appropriate topic for the mip6 WG, since mip6 isn't chartered to do experimental = work. Regarding ISO, if there's another standardization body that needs the = work, then a liason letter to the IETF via the IAB requesting an Internet = standard might be in order. However, I believe a more productive track would be to take the work to Mobopts as Raj and Rajeev have requested, possibly in conjunction with examining the multihoming work that v6ops is doing for mobility = implications . Rajeev and Bill are working hard to make Mobopts a venue for = maturing good ideas, and I think that this work may now be showing results, since we = now have two drafts there that they are interested in making research group drafts, for eventual re-introduction into IETF. jak ----- Original Message ----- From: "Thierry Ernst" To: Sent: Sunday, November 21, 2004 8:07 PM Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > Hi James, > > > Are there any vendors interested in implementing this solution = and/or > > network operators interested in deploying it (note: I'm not asking = for > > detailed product plans, just the kind of committment that was given = in, say, > > the chartering discussion of the Mobike WG several IETFs ago)? Or = other > > standardization bodies (such as our good friends at 3GPP2) who are > > interested in incorporating it into their standards? > > Peole from various companies have told me so and I would rather let = them > express their opinions directly to demonstrate their true interest. = But > many of them may not be on the list. > > Also, there are proprietary solutions and these manufacturers may not = be > eager to standardize their solutions (unless some raise the topic at = the > IETF, in which case they would have to). > > For instance, mobile phone company A may want terminals allowing = their > users to switch between 3G/GPRS and 802.11. In their scenario, both > access networks would belong to the same operator, so a proprietary > solution is fine. > > But from a user perspective, I and other people think standardization = is > important, and there is an important need. > > There are for instance the car manufacturers or those making products > for them (unfortunately, they don't speak up at the IETF because it's > not in their culture) who need to manage multiple interfaces on their > MIP6/NEMO MN/MR. The ISO TC204 WG16 is one of those efforts where = such > feature is needed (in their CALM architecture). > > About implementation, there is an effort ongoing in a branch of the = KAME > ipv6 stack (don't look for it on the KAME page, you won't find it = now) > and people willing to do the same in USAGI. I don't want to speak up = for > USAGI and KAME people, but as far as reference implementations are > concerned, we better implement standards rather than proprietary > solutions, I think you would agree on this. > > Thierry. > > > > > jak > > > > PS: BTW, if you haven't seen it, you should check out the = literature on > > Boeing's Connexion system. It uses BGP to manage routes to a mobile 802.11 > > network in an airplane on a transcontinental flight. Lufthasa has deployed > > it on their new A333-600's. > > > > > > ----- Original Message -----=20 > > From: "Thierry Ernst" > > To: > > Cc: > > Sent: Thursday, November 18, 2004 6:55 PM > > Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > > > > > > > > > Dear Rajeev, > > > > > > Mobopts is a reseach group (IRTF), the problem that we want to = solve is > > > much more clarified clarified than that, and solutions could be brought > > > in a timely manner if we restrict ourselves to part of the = exisiting > > > problems and extensions to MIP6 and NEMO. > > > > > > Of course, taking a look at the whole picture would require much = more > > > consideration, and for the whole picture Mobopts could be the = right > > > place. But, my intention, right now, is not to open the pendora = box; > > > it's rather about bringing a solution to an immediate concern, in = a > > > timely manner: how can I make use of my MIP6/NEMO function when I = have > > > multiple interfaces on my MH/MR ? I can't do it right now, and = not > > > because it's np complex, but because there is no agreed solution between > > > the parties involved. > > > > > > Regarding what has been said at the MIP6 meeting, taking into = account > > > the feedback from Erik, Thomas, and all the other, I would go for = a BOF > > > at next IETF, but not with the objective to set up a new WG, but = just a > > > one-time BOF to discuss the problem thoroughly. > > > > > > But, prior to doing that, the other people involved with me on = the > > > problem statement drafts, we should improve/clarify/extend our = drafts. > > > The target would be end of this year; based on new drafts we = would > > > consider setting up a BOF or not. (OK, guys, now we have pressure = on our > > > shoulders ;-) > > > > > > Thierry > > > > > > > > > > > > On Thu, 18 Nov 2004 10:40:15 -0800 > > > Rajeev Koodli wrote: > > > > > > > Thierry Ernst wrote: > > > > > > > > > > Thus embarking on QoS sensitive, mobility specific = multihoming > > support > > > > > > is both too open ended (on the QoS side) and too = constraining (by > > only > > > > > > looking at cases when MIP/Nemo is used). > > > > > > > > > > > > So I think it would be useful for folks to try to think = about and > > > > > > discuss the bigger picture. > > > > > > > > > > Agree. But then, where should this discussion take place ? = MIP6 WG ? > > > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > > > > > > > I would add to Erik's observation that we need to be able to = assess a > > topic to > > > > see > > > > the maturity of the problem and the state of solutions, as well = as what > > could > > > > be standardized in IETF. The IETF should work on well-defined = _and_ > > > > well-agreed problems for which protocol specification could be > > accomplished > > > > in a timely manner. Topics where the problem needs to be crystalized, > > and > > > > solution > > > > space needs "thinking" require a forum for discussion. And, = MobOpts > > could > > > > be such a place. > > > > > > > > We (mip*, MobOpts co-chairs) are in the process of working out = a model > > to > > > > facilitate closer co-operation between mip* groups and MobOpts. = The > > outcome > > > > should be focussed discussion on topics of mutual interest that = lead to > > > > documents > > > > which can be a) taken up in mip* groups for standardization, b) MobOpts > > RG > > > > RFCs. MobOpts would run milestones and try to produce documents within a > > > > timeframe of interest to mip* groups. > > > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 29 21:20:00 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10184 for ; Mon, 29 Nov 2004 21:20:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYxhY-0006K3-Uz for mip6-web-archive@ietf.org; Mon, 29 Nov 2004 21:25:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYxPU-0008Ku-Vk; Mon, 29 Nov 2004 21:06:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CYxKS-00072P-2Y for mip6@megatron.ietf.org; Mon, 29 Nov 2004 21:01:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08824 for ; Mon, 29 Nov 2004 21:01:18 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CYxPP-0005wS-4b for mip6@ietf.org; Mon, 29 Nov 2004 21:06:31 -0500 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id A95764C0AF for ; Tue, 30 Nov 2004 11:00:31 +0900 (JST) Date: Tue, 30 Nov 2004 11:03:32 +0900 From: Thierry Ernst To: mip6@ietf.org Subject: Re: [Mip6] FW: MIP6 agenda (Final) Message-Id: <20041130110332.0971bdae.ernst@sfc.wide.ad.jp> In-Reply-To: <039001c4d661$2b2fef30$596015ac@dcml.docomolabsusa.com> References: <039001c4d661$2b2fef30$596015ac@dcml.docomolabsusa.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a Content-Transfer-Encoding: quoted-printable Hi James, > This is exactly the kind of speculative grounds that I am trying to warn > against. If the problem is not well understood, then IRTF is the right pl= ace > for it. If it is well understood and people are ready to design a protocol > to solve it, then IETF is the right place for it. The problem is sufficiently well understood, but no sufficiently well stated. We are working on the a problem statement, which I agree must be improved. We just haven't invested so much time on it because we wanted to sense the need for such a document before. But now, I clearly see the need to make this statement clearer. Besides this, tens of solutions have been proposed. The only problem is that each solution brings an answer to an individual issue. So, the purpose of the problem statement is not to get a better understanding of the problem, but to write it black on white to that we can work together on a comprehensive solution, hopefully giving an answer to more than one issue. I don't see a need to shift such work to the IRTF as this is clearly not academic, but highly technical. Bringing features allowing the use of multiple interfaces in MIPv6 (well, both to MIP6 and NEMO, indeed) is something very concrete. If the intend is to consider the host multihoming issues with no specific protocol in mind, then, yes, I would agree that this belongs to the IRTF. If the purpose of the IETF is to produce protocols that have a better chance to be deployed, the support of multiple interfaces in MIP6 is surely one means that will help a wider deployment of the (so long ...) work produced by this WG. If I was to follow your position on IRTF vs IETF, I think most of the work conducted at the IETF could have been shifted there, and WGs like IPNG, Multi6, Mobile IP wouldn't have ever existed. > Having a good problem statement is a start, and I believe there has been > some discussion about that on the list. The process of developing the > problem statement, and the problem statement itself, should reveal a good > deal about how well understood the problem is. BTW, I don't buy your (could be offending ;-) statement about "researchers". Thierry. >=20 > ----- Original Message -----=20 > From: "NJEDJOU Eric RD-RESA-REN" > To: "James Kempf" ; "Thierry Ernst" > ; > Sent: Monday, November 29, 2004 10:37 AM > Subject: RE: [Mip6] FW: MIP6 agenda (Final) >=20 >=20 >=20 > I thing the multihoming problem could potentially have future markets > interests and could be worthwile looking at though. As an example access > service providers would be selling ubiquitous wireless services. These may > require that the multihoming problem be well understood > Eric >=20 > -----Message d'origine----- > De : James Kempf [mailto:kempf@docomolabs-usa.com] > Envoy=E9 : lundi 29 novembre 2004 19:20 > =C0 : NJEDJOU Eric RD-RESA-REN; Thierry Ernst; mip6@ietf.org > Objet : Re: [Mip6] FW: MIP6 agenda (Final) >=20 > Eric, >=20 > I can't find anything specific to object to in your analysis, but I was > making a broader point. My point was, that researchers often tend to > oversell the interest in implementing and deploying their work, particula= rly > in the IETF. This then leads WGs to get chartered that develop protocols > which don't get deployed. Given the enormous amount of time and effort > involved in doing IETF work (particularly for the WG chairs and draft > editors), I believe it is important to weed out those tendencies early, > prior to chartering, and re-direct such research work to the IRTF, where = it > properly belongs. >=20 > jak >=20 > ----- Original Message ----- > From: "NJEDJOU Eric RD-RESA-REN" > To: "James Kempf" ; "Thierry Ernst" > ; > Sent: Sunday, November 28, 2004 7:12 AM > Subject: RE: [Mip6] FW: MIP6 agenda (Final) >=20 >=20 > Hi James, >=20 > The Problem i guess Operators have with the Seamoby Protocols is more > complex. > First, the Seamoby protocols were meant to be operations to be performed > prior/post to running the Fats Handoffs protocols. And Fast Handoffs > protocols themselves are not deployed because operators are still only > assessing the real need to have IP mobility services for their customers = as > provided by Mobile IP. Another issue is that the Fast Handoffs protocols > were designed with the 802.11 AP/AR to 802.11 AP/AR handover scenario in > mind. And We can effectively see that people have only be able to impleme= nt > the Fast Handoffs protocols for 802.11 handover. Fast Handoffs do not ap= ply > to GPRS <-> 802.11 handover scnearios. This is because the handover > signalling is something to be exchanged at the very edge of the network > (access routers) and exchanging FMIP signalling between an AR in the 802.= 11 > network and the GGSN in the GPRS core network require the flows to pass v= ia > too many hops, rendering the handover process not reactive as is the will= of > having a fast handoff scheme. > Therefore for the GPRS <-> 802.11, the only possible fallback is to use > simple Mobile IPv4/v6. Further, using simple Mipv4/MIPv6 will not require > Operators to modify their edge to include SEAMOBY/MIPSHOP operations. When > the need for MIpv4/MIPv6 will really be ascertained, then those protocols > will be considered, but again not for the inter-technology handovers. > Another reason why SEAMOBY/MIPSHOP protocols would not likely be deployed= on > a large scale is that even that 802.11 AP to AP handover scenario ( those > protocols fit for) does not require a subnet change in most of the cases. > The whole thing can therefore be handled within L2 as Task Group R of IEEE > 802.11 is doing. >=20 >=20 > Eric Njedjou > France Telecom >=20 > -----Message d'origine----- > De : mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] De la part de > James Kempf > Envoy=E9 : lundi 22 novembre 2004 18:43 > =C0 : Thierry Ernst; mip6@ietf.org > Objet : Re: [Mip6] FW: MIP6 agenda (Final) >=20 > Hi Thierry, >=20 > Please don't feel offended, but I tend to discount attestations from > researchers that there is product and deployment interest. For 4 years, we > had researchers saying that there was product and deployment interest in > Seamoby, yet prior to switching the drafts to experimental, we had not a > single vendor or operator willing to say that they were interested in > developing and deploying the protocols. That's why they were switched to > experimental. If there are not vendors and operators willing to come on t= he > list and participate in the process so their customers can enjoy the > benefits of interoperability, then I don't think this is an appropriate > topic for the mip6 WG, since mip6 isn't chartered to do experimental work. >=20 > Regarding ISO, if there's another standardization body that needs the wor= k, > then a liason letter to the IETF via the IAB requesting an Internet stand= ard > might be in order. >=20 > However, I believe a more productive track would be to take the work to > Mobopts as Raj and Rajeev have requested, possibly in conjunction with > examining the multihoming work that v6ops is doing for mobility implicati= ons > . Rajeev and Bill are working hard to make Mobopts a venue for maturing g= ood > ideas, and I think that this work may now be showing results, since we now > have two drafts there that they are interested in making research group > drafts, for eventual re-introduction into IETF. >=20 > jak >=20 >=20 > ----- Original Message ----- > From: "Thierry Ernst" > To: > Sent: Sunday, November 21, 2004 8:07 PM > Subject: Re: [Mip6] FW: MIP6 agenda (Final) >=20 >=20 > > > > Hi James, > > > > > Are there any vendors interested in implementing this solution and/or > > > network operators interested in deploying it (note: I'm not asking for > > > detailed product plans, just the kind of committment that was given i= n, > say, > > > the chartering discussion of the Mobike WG several IETFs ago)? Or oth= er > > > standardization bodies (such as our good friends at 3GPP2) who are > > > interested in incorporating it into their standards? > > > > Peole from various companies have told me so and I would rather let them > > express their opinions directly to demonstrate their true interest. But > > many of them may not be on the list. > > > > Also, there are proprietary solutions and these manufacturers may not be > > eager to standardize their solutions (unless some raise the topic at the > > IETF, in which case they would have to). > > > > For instance, mobile phone company A may want terminals allowing their > > users to switch between 3G/GPRS and 802.11. In their scenario, both > > access networks would belong to the same operator, so a proprietary > > solution is fine. > > > > But from a user perspective, I and other people think standardization is > > important, and there is an important need. > > > > There are for instance the car manufacturers or those making products > > for them (unfortunately, they don't speak up at the IETF because it's > > not in their culture) who need to manage multiple interfaces on their > > MIP6/NEMO MN/MR. The ISO TC204 WG16 is one of those efforts where such > > feature is needed (in their CALM architecture). > > > > About implementation, there is an effort ongoing in a branch of the KAME > > ipv6 stack (don't look for it on the KAME page, you won't find it now) > > and people willing to do the same in USAGI. I don't want to speak up for > > USAGI and KAME people, but as far as reference implementations are > > concerned, we better implement standards rather than proprietary > > solutions, I think you would agree on this. > > > > Thierry. > > > > > > > > > jak > > > > > > PS: BTW, if you haven't seen it, you should check out the literature = on > > > Boeing's Connexion system. It uses BGP to manage routes to a mobile > 802.11 > > > network in an airplane on a transcontinental flight. Lufthasa has > deployed > > > it on their new A333-600's. > > > > > > > > > ----- Original Message -----=20 > > > From: "Thierry Ernst" > > > To: > > > Cc: > > > Sent: Thursday, November 18, 2004 6:55 PM > > > Subject: Re: [Mip6] FW: MIP6 agenda (Final) > > > > > > > > > > > > > > Dear Rajeev, > > > > > > > > Mobopts is a reseach group (IRTF), the problem that we want to solve > is > > > > much more clarified clarified than that, and solutions could be > brought > > > > in a timely manner if we restrict ourselves to part of the exisiting > > > > problems and extensions to MIP6 and NEMO. > > > > > > > > Of course, taking a look at the whole picture would require much mo= re > > > > consideration, and for the whole picture Mobopts could be the right > > > > place. But, my intention, right now, is not to open the pendora box; > > > > it's rather about bringing a solution to an immediate concern, in a > > > > timely manner: how can I make use of my MIP6/NEMO function when I h= ave > > > > multiple interfaces on my MH/MR ? I can't do it right now, and not > > > > because it's np complex, but because there is no agreed solution > between > > > > the parties involved. > > > > > > > > Regarding what has been said at the MIP6 meeting, taking into accou= nt > > > > the feedback from Erik, Thomas, and all the other, I would go for a > BOF > > > > at next IETF, but not with the objective to set up a new WG, but ju= st > a > > > > one-time BOF to discuss the problem thoroughly. > > > > > > > > But, prior to doing that, the other people involved with me on the > > > > problem statement drafts, we should improve/clarify/extend our draf= ts. > > > > The target would be end of this year; based on new drafts we would > > > > consider setting up a BOF or not. (OK, guys, now we have pressure on > our > > > > shoulders ;-) > > > > > > > > Thierry > > > > > > > > > > > > > > > > On Thu, 18 Nov 2004 10:40:15 -0800 > > > > Rajeev Koodli wrote: > > > > > > > > > Thierry Ernst wrote: > > > > > > > > > > > > Thus embarking on QoS sensitive, mobility specific multihoming > > > support > > > > > > > is both too open ended (on the QoS side) and too constraining > (by > > > only > > > > > > > looking at cases when MIP/Nemo is used). > > > > > > > > > > > > > > So I think it would be useful for folks to try to think about > and > > > > > > > discuss the bigger picture. > > > > > > > > > > > > Agree. But then, where should this discussion take place ? MIP6= WG > ? > > > > > > NEMO WG ? IPv6 WG ? Somewhere else ? BOF needed ? > > > > > > > > > > > > > > > > I would add to Erik's observation that we need to be able to asse= ss > a > > > topic to > > > > > see > > > > > the maturity of the problem and the state of solutions, as well as > what > > > could > > > > > be standardized in IETF. The IETF should work on well-defined _an= d_ > > > > > well-agreed problems for which protocol specification could be > > > accomplished > > > > > in a timely manner. Topics where the problem needs to be > crystalized, > > > and > > > > > solution > > > > > space needs "thinking" require a forum for discussion. And, MobOp= ts > > > could > > > > > be such a place. > > > > > > > > > > We (mip*, MobOpts co-chairs) are in the process of working out a > model > > > to > > > > > facilitate closer co-operation between mip* groups and MobOpts. T= he > > > outcome > > > > > should be focussed discussion on topics of mutual interest that l= ead > to > > > > > documents > > > > > which can be a) taken up in mip* groups for standardization, b) > MobOpts > > > RG > > > > > RFCs. MobOpts would run milestones and try to produce documents > within a > > > > > timeframe of interest to mip* groups. > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 30 09:21:47 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20656 for ; Tue, 30 Nov 2004 09:21:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ8yA-0004dH-Ex for mip6-web-archive@ietf.org; Tue, 30 Nov 2004 09:27:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ8kN-0005EQ-ES; Tue, 30 Nov 2004 09:12:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZ7DE-0002wO-EZ; Tue, 30 Nov 2004 07:34:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12943; Tue, 30 Nov 2004 07:34:31 -0500 (EST) Received: from mx1.iit.cnr.it ([146.48.98.40] helo=mx.iit.cnr.it) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZ7IK-0002Fl-4Z; Tue, 30 Nov 2004 07:39:49 -0500 Received: from localhost (mx.iit.cnr.it [127.0.0.1]) by mx.iit.cnr.it (Postfix) with ESMTP id 0CB7B2EEBD; Tue, 30 Nov 2004 13:33:52 +0100 (CET) Received: from mx.iit.cnr.it ([127.0.0.1]) by localhost (mx.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25694-11; Tue, 30 Nov 2004 13:33:45 +0100 (CET) Received: from delmastro1 (delmastrof.iit.cnr.it [146.48.98.74]) by mx.iit.cnr.it (Postfix) with ESMTP id 2B0BE2EE35; Tue, 30 Nov 2004 13:33:43 +0100 (CET) Message-ID: <00d301c4d6d8$dd5bd6c0$4a623092@delmastro1> From: "Franca Delmastro" To: "Franca Delmastro" Date: Tue, 30 Nov 2004 13:33:50 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Virus-Scanned: by Content Checker at iit.cnr.it X-Spam-Score: 1.3 (+) X-Scan-Signature: 343d06d914165ffd9d590a64755216ca X-Mailman-Approved-At: Tue, 30 Nov 2004 09:12:49 -0500 Subject: [Mip6] [ACC2005]Cfp: 1st IEEE WoWMoM Workshop on Autonomic Communications and Computing X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0211713439==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b This is a multi-part message in MIME format. --===============0211713439== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D0_01C4D6E1.3A5919C0" This is a multi-part message in MIME format. ------=_NextPart_000_00D0_01C4D6E1.3A5919C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We apologize in advance if you receive multiple copies of this CFP.=20 ----------------------------------------------------------------------=20 Call for Papers=20 ACC 2005=20 1st IEEE WoWMoM Workshop on=20 Autonomic Communications and Computing=20 June 18, 2005 - Taormina, Italy=20 in conjunction with IEEE WoWMoM 2005=20 http://www.autonomic-communication.org/acc/index.html=20 Sponsored by IEEE WoWMoM=20 Ubiquitous and self-organized Internet, ad hoc networks, wireless sensor = networks are expected to be some of the basic building blocks of=20 pervasive computing=20 environments. However, the promise of pervasive computing environments=20 will not be realized unless these systems can effectively "disappear".=20 In order to do that they need to become autonomous by managing their own = evolution and configuration changes without explicit user or=20 administrator action.=20 The goal of this workshop is to provide a forum to exchange ideas,=20 discuss solutions, and share experiences among researchers,=20 professionals, and application developers both from industry and=20 academia. Original papers addressing both theoretical and practical=20 aspects of autonomic communications and computing are solicited. Papers=20 describing prototype implementations and deployment are particularly=20 welcome. Topics of interest include but are not limited to:=20 - Architecture and models for autonomic communication and computing=20 systems=20 - Tools and techniques for designing, analyzing and building=20 autonomic systems and networks=20 - Adaptive security for self protection of systems and networks=20 - Economic, biological and social models used for autonomic=20 communications=20 - Novel management techniques for autonomic communication and=20 computing systems=20 - Sensing, monitoring and measurements for self-managing systems and=20 networks=20 - Languages, development and securely programmable environments for=20 autonomic communications systems=20 - Advanced technologies for enabling autonomic communication and=20 computing systems=20 - Autonomic communication and computing testbeds and measurements=20 SUBMISSION INSTRUCTIONS=20 Papers should contain original material and not be previously published, = or currently submitted for consideration elsewhere. Manuscripts must be=20 limited to 5 pages in IEEE 8.5x11 conference format, and formatted in=20 strict accordance with the IEEE Computer Society author guidelines. All=20 submissions will be handled electronically. Authors should prepare a PDF = file and submit it to acc2005@autonomic-communication.org. Accepted=20 papers will be published by the IEEE Computer Society Press in the=20 combined WoWMoM 2005 workshop proceedings.=20 IMPORTANT DATES:=20 Papers due -------------------------- Dec. 20, 2004=20 Notification of acceptance ------------ Jan. 31, 2005=20 Camera-ready papers due --------------- Feb. 28, 2005=20 TECHNICAL PROGRAM COMMITTEE N. Anerousis, IBM T.J. Watson Research Center, USA=20 O. Babaoglu, University of Bologna, Italy=20 L. Chapin, ACM, USA=20 M. Conti, IIT-CNR, Italy=20 S. Crosby, Intel Research, USA=20 C. Diot, INTEL, UK=20 J. Dowling, Trinity College Dublin, Ireland=20 S. Fdida, UPMC, France=20 L. Gambardella, IDSIA, Switzerland=20 W.-D. Grover, TRLabs and University of Alberta, Canada=20 P. Gunningberg, Upsala University, Sweden=20 H.-G. Hegering, Munich University, Germany=20 D. Hutchison, ULanc, UK=20 D. Lewis, Trinity College, Dublin=20 A. Sahai, HP Labs, USA=20 J. Sch=F6nw=E4lder, University Bremen, Germany=20 A. Seneviratne, UNSW, Australia=20 F. Sestini, FET, CEC=20 I. Stavrakakis, UOA, Greece=20 J. Strassner, MDAPCE, USA=20 C. Tschudin, University of Basel, Switzerland=20 J. Vicente, ISTG Research, Intel, USA=20 L. Wolf, U. Braunschweig, Germany =20 For more information, please contact the workshop co-organizer=20 Silvia Giordano (silvia.giordano@supsi.ch), or consult the workshop=20 webpage.=20 ************************************************************ Franca Delmastro Pervasive Computing & Networking Lab. (PerLab) IIT- National Research Council via G. Moruzzi,1 56124 Pisa, Italy phone: +39 050 3152407 (direct) ******************************************************** ------=_NextPart_000_00D0_01C4D6E1.3A5919C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
We apologize in advance = if you=20 receive multiple copies of this CFP.=20
---------------------------------------------------------------------= -=20
 
Call for Papers
 
ACC 2005
 
1st IEEE WoWMoM Workshop on
Autonomic Communications and = Computing=20
 
June 18, 2005 - Taormina, Italy
in conjunction with IEEE WoWMoM = 2005=20
 
 
Sponsored by IEEE WoWMoM
 
Ubiquitous and self-organized Internet, ad hoc networks, wireless = sensor=20
networks are expected to be some of the basic building blocks of=20
pervasive computing
environments. However, the promise of = pervasive=20 computing environments
will not be realized unless these systems can = effectively "disappear".
In order to do that they need to become = autonomous=20 by managing their own
evolution and configuration changes without = explicit=20 user or
administrator action.
 
The goal of this workshop is to provide a forum to exchange ideas,=20
discuss solutions, and share experiences among researchers,=20
professionals, and application developers both from industry and=20
academia. Original papers addressing both theoretical and practical=20
aspects of autonomic communications and computing are solicited. = Papers=20
describing prototype implementations and deployment are particularly =
welcome. Topics of interest include but are not limited to:
 
-    Architecture and models for autonomic = communication and=20 computing
systems
-    Tools and techniques for=20 designing, analyzing and building
autonomic systems and networks=20
-    Adaptive security for self protection of systems = and=20 networks
-    Economic, biological and social models = used for=20 autonomic
communications
-    Novel management = techniques=20 for  autonomic communication and
computing systems=20
-    Sensing, monitoring and measurements for = self-managing=20 systems and
networks
-    Languages, development = and=20 securely programmable environments for
autonomic communications = systems=20
-    Advanced technologies for enabling autonomic=20 communication and
computing systems
-    = Autonomic=20 communication and computing testbeds and measurements
 
 
 
SUBMISSION INSTRUCTIONS
 
Papers should contain original material and not be previously = published,=20
or currently submitted for consideration elsewhere. Manuscripts must = be=20
limited to 5 pages in IEEE 8.5x11 conference format, and formatted = in=20
strict accordance with the IEEE Computer Society author guidelines. = All=20
submissions will be handled electronically. Authors should prepare a = PDF=20
file and submit it to acc2005@autonomic-communication.org. Accepted =
papers will be published by the IEEE Computer Society Press in the=20
combined WoWMoM 2005 workshop proceedings.
IMPORTANT DATES: =
 
Papers due   -------------------------- Dec. 20,  = 2004=20
Notification of acceptance ------------ Jan.  31,  2005=20
Camera-ready papers due --------------- Feb. 28,  2005
 

TECHNICAL PROGRAM = COMMITTEE
 

N. Anerousis, IBM T.J. Watson = Research=20 Center, USA
O. Babaoglu, University of Bologna, Italy
L. Chapin, = ACM,=20 USA
M. Conti, IIT-CNR, Italy
S. Crosby, Intel Research, USA =
C. Diot,=20 INTEL, UK
J. Dowling, Trinity College Dublin, Ireland
S. Fdida, = UPMC,=20 France
L. Gambardella, IDSIA, Switzerland
W.-D. Grover, TRLabs = and=20 University of Alberta, Canada
P. Gunningberg, Upsala University, = Sweden=20
H.-G. Hegering, Munich University, Germany
D. Hutchison, ULanc, = UK=20
D. Lewis, Trinity College, Dublin
A. Sahai, HP Labs, USA
J.=20 Sch=F6nw=E4lder, University Bremen, Germany
A. Seneviratne, UNSW, = Australia=20
F. Sestini, FET, CEC
I. Stavrakakis, UOA, Greece
J. = Strassner,=20 MDAPCE, USA
C. Tschudin, University of Basel, Switzerland
J. = Vicente,=20 ISTG Research, Intel, USA
L. Wolf, U. Braunschweig, Germany =20
 
 
 

For more information, please = contact the=20 workshop co-organizer
Silvia Giordano (silvia.giordano@supsi.ch), or=20 consult the workshop
webpage.
 
 
************************************************************
= Franca=20 Delmastro
Pervasive Computing & Networking Lab. = (PerLab)
 
IIT- National Research = Council
via G.=20 Moruzzi,1
56124 Pisa, Italy
phone: +39 050 3152407=20 (direct)
********************************************************
------=_NextPart_000_00D0_01C4D6E1.3A5919C0-- --===============0211713439== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0211713439==-- From mip6-bounces@ietf.org Tue Nov 30 11:52:23 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06182 for ; Tue, 30 Nov 2004 11:52:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZBJx-00008Z-FX for mip6-web-archive@ietf.org; Tue, 30 Nov 2004 11:57:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZB0K-0006wL-5w; Tue, 30 Nov 2004 11:37:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZArq-0004cM-5s for mip6@megatron.ietf.org; Tue, 30 Nov 2004 11:28:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03867 for ; Tue, 30 Nov 2004 11:28:39 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZAwy-0007x1-Rr for mip6@ietf.org; Tue, 30 Nov 2004 11:34:01 -0500 Message-ID: <03ed01c4d6f9$c7a7f310$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Thierry Ernst" , References: <039001c4d661$2b2fef30$596015ac@dcml.docomolabsusa.com> <20041130110332.0971bdae.ernst@sfc.wide.ad.jp> Subject: Re: [Mip6] FW: MIP6 agenda (Final) Date: Tue, 30 Nov 2004 08:29:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Thierry, I don't see a need to shift such work to the IRTF as this is clearly not academic, but highly technical. Bringing features allowing the use of multiple interfaces in MIPv6 (well, both to MIP6 and NEMO, indeed) is something very concrete. If the intend is to consider the host multihoming issues with no specific protocol in mind, then, yes, I would agree that this belongs to the IRTF. jak>> This expresses a common misconception about IRTF. IRTF is not meant to be academic, it is meant to be a place where ideas are refined before they are well enough understood for concensus to be achieved on the basic architecture and design of the protocol, when the problem is not well understood. It is not meant to be a place to do research without any connection to IETF standardization work. jak>> Regarding this particular problem, I can think of a few cases where there might be some specific enhancements to mip6 that might not require IRTF work (for example, allowing the registration of multiple home addresses) because they are well enough understood but what I am concerned about is that the people will immediately push for more. An example here is nemo. While the initial problem of using Mobile IP for mobile networks was well understood, people were pushing from the very beginning to do route optimization, which has even proved a hard problem for individual hosts. IMHO, the route optimization work for networks should have been moved to IRTF immediately when the WG was chartered, and the WG should have concentrated on solving the near term problem. Unfortuantely, at that time, there was no mobopts RG, which would have been the right place for the work, so it was put into the charter for later. That had the effect of essentially delaying any work to understand the problem better, whereas, if it had been put into the IRTF, the issues (particularly regarding security) could have been studied in parallel with the standardization of Mobile IP for mobile networks. jak>> So, in the end, it actually helps get the whole problem solved if the easy, well-understood parts are done in IETF and the harder ones are done in IRTF. If the purpose of the IETF is to produce protocols that have a better chance to be deployed, the support of multiple interfaces in MIP6 is surely one means that will help a wider deployment of the (so long ...) work produced by this WG. jak>> The purpose of IETF is to produce protocols that *get deployed*, IMHO. Work should be chartered only if the preconditions for that are available. BTW, I don't buy your (could be offending ;-) statement about "researchers". jak>> Point noted. It was not meant to be offensive, just a summary of my experience with Seamoby. After all, I do a certain amount of research myself. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 30 20:19:09 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09585 for ; Tue, 30 Nov 2004 20:19:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZJEQ-00016g-Vc for mip6-web-archive@ietf.org; Tue, 30 Nov 2004 20:24:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZJ60-0004pH-DT; Tue, 30 Nov 2004 20:15:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZJ3M-0003rt-Qe for mip6@megatron.ietf.org; Tue, 30 Nov 2004 20:13:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09115 for ; Tue, 30 Nov 2004 20:13:06 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZJ8a-0000y1-1B for mip6@ietf.org; Tue, 30 Nov 2004 20:18:32 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iB10i2n12751; Tue, 30 Nov 2004 16:44:02 -0800 X-mProtect: <200412010044> Nokia Silicon Valley Messaging Protection Received: from rajeev.iprg.nokia.com (205.226.2.90) by darkstar.iprg.nokia.com smtpd81NjNk; Tue, 30 Nov 2004 16:44:00 PST Received: from iprg.nokia.com (localhost [127.0.0.1]) by rajeev.iprg.nokia.com (8.9.3/8.6.12) with ESMTP id RAA85660; Tue, 30 Nov 2004 17:12:24 -0800 (PST) Message-ID: <41AD1A78.7DCC3400@iprg.nokia.com> Date: Tue, 30 Nov 2004 17:12:24 -0800 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: Thierry Ernst Subject: Re: [Mip6] FW: MIP6 agenda (Final) References: <039001c4d661$2b2fef30$596015ac@dcml.docomolabsusa.com> <20041130110332.0971bdae.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajeev@iprg.nokia.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > > Besides this, tens of solutions have been proposed. The only problem is > that each solution brings an answer to an individual issue. So, the > purpose of the problem statement is not to get a better understanding of > the problem, but to write it black on white to that we can work together > on a comprehensive solution, hopefully giving an answer to more than one > issue. > > I don't see a need to shift such work to the IRTF as this is clearly not > academic, but highly technical. Bringing features allowing the use of > multiple interfaces in MIPv6 (well, both to MIP6 and NEMO, indeed) is > something very concrete. If the intend is to consider the host > multihoming issues with no specific protocol in mind, then, yes, I would > agree that this belongs to the IRTF. > As I mentioned in a previous e-mail, IRTF MobOpts is not working on things academic, although I would not discorage academic work. Instead, our intention is to work on focussed topics of relevance to IETF and bring them back to IETF. In other words, all the fun discussion surrounding multiple proposals could take place in MobOpts. Specific to host multi-homing using MIP: One approach could be to write a single problem statement for both MIP6 & MobOpts, produce a document in MobOpts and bring it back to MIP6 for standardization. That way, the solution would already be well-understood for standardization. -Rajeev > > Thierry. > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6