From mip6-bounces@ietf.org Fri Jul 01 10:54:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoMuG-0002AO-Up; Fri, 01 Jul 2005 10:54:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoFuG-0002tF-GY; Fri, 01 Jul 2005 03:25:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02077; Fri, 1 Jul 2005 03:25:46 -0400 (EDT) Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoGKB-00030j-9a; Fri, 01 Jul 2005 03:52:35 -0400 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.11/8.12.9) with ESMTP id j617AWN5008640; Fri, 1 Jul 2005 09:10:32 +0200 Received: from sophia.inria.fr (penguin.inria.fr [138.96.240.36]) by sophia.inria.fr (8.12.11/8.12.9) with ESMTP id j61768g3007492; Fri, 1 Jul 2005 09:06:09 +0200 Message-ID: <42C4EB60.D0BE2291@sophia.inria.fr> Date: Fri, 01 Jul 2005 09:06:08 +0200 From: Sara Alouf X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.23 i686) X-Accept-Language: en, fr, pt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: undisclosed-recipients:; X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (sophia.inria.fr [138.96.64.20]); Fri, 01 Jul 2005 09:08:57 +0200 (MEST) X-Virus-Scanned: by amavisd-new at sophia.inria.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 01 Jul 2005 10:54:15 -0400 Subject: [Mip6] Performance 2005: Last Call for Posters 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 Dear colleague, Please accept my sincere apologies if you receive multiple copies of this message. I would like to draw your attention to the deadline for submitting posters to Performance 2005, it is on *July 7*. All details can be found on the conference web site: http://www-sop.inria.fr/maestro/performance2005/posters.html I have copied the complete Call for Posters at the end of the message for your convenience. Best regards, Sara Alouf Publicity Chair of Performance 2005 ------------------------------------------------------------------ PERFORMANCE 2005 IFIP WG 7.3 International Symposium on Computer Performance, Modeling, Measurements and Evaluation Oct. 3-7, Juan-les-Pins, France http://www-sop.inria.fr/maestro/performance2005/ CALL FOR POSTERS The PERFORMANCE 2005 conference solicits posters on recent or ongoing research in the areas of: * Performance-oriented design and evaluation of: communication networks, mobile and wireless systems, Internet servers and E-commerce systems, Web services, Web architectures, peer-to-peer systems, grid computing, computer architectures, database systems, operating systems, software systems, distributed systems, multimedia systems, file and I/O systems, memory systems, real-time systems, and fault-tolerant systems. * Techniques and algorithms: analytic modeling, performance optimization, queueing analysis, stochastic scheduling, model verification and validation, power analysis, hybrid models, experimental design, system or network measurement and monitoring, workload characterization, simulation, and statistical analysis. The poster session is intended to present and discuss innovative research work in an informal setting. The submission by students is especially encouraged. SUBMISSION GUIDELINES A poster submission consists of an extended abstract of up to 2 pages (double column, 9-point or larger fonts) including the names and affiliations of the authors. Poster submissions must be sent by email to posters.perf2005(at)sophia.inria.fr as Postscript or Adobe PDF files. Posters will be selected by the Poster Committee. The extended abstracts of accepted posters will be published in a special issue of the Performance Evaluation Review. Any question must be directed to the Poster Committee Chair at posters.perf2005(at)sophia.inria.fr. IMPORTANT DATES Submission due: July 7, 2005 Notification to authors: July 22, 2005 Camera ready extended abstract due: August 19, 2005 POSTER COMMITTEE Thomas Bonald, France Telecom (chair) Sem Borst, Bell Labs and CWI Mor Harchol-Balter, Carnegie Mellon U. Alain Jean-Marie, U. Montpellier and INRIA _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 04 04:58:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpMmY-000687-Er; Mon, 04 Jul 2005 04:58:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpMmS-00066c-4H for mip6@megatron.ietf.org; Mon, 04 Jul 2005 04:58:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09184 for ; Mon, 4 Jul 2005 04:58:18 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpNCv-0005jD-1X for mip6@ietf.org; Mon, 04 Jul 2005 05:25:46 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j648w5ni028651; Mon, 4 Jul 2005 17:58:05 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j648w47s029640; Mon, 4 Jul 2005 17:58:04 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j648w4UU029635; Mon, 4 Jul 2005 17:58:04 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j648w41X015008; Mon, 4 Jul 2005 17:58:04 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j648w3Rf015003; Mon, 4 Jul 2005 17:58:03 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j648w3F5007301; Mon, 4 Jul 2005 17:58:03 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j648w36C018172; Mon, 4 Jul 2005 17:58:03 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (ime0.m.ecl.ntt.co.jp [129.60.5.143]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j648w3K0018169; Mon, 4 Jul 2005 17:58:03 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id RAA23321; Mon, 4 Jul 2005 17:58:02 +0900 (JST) Message-ID: <42C8FA1A.30309@lab.ntt.co.jp> Date: Mon, 04 Jul 2005 17:58:02 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Bootstrapping DT solution draft References: <42C368D1.3000504@lab.ntt.co.jp> <005101c57d8c$a6713e60$016115ac@dcml.docomolabsusa.com> In-Reply-To: <005101c57d8c$a6713e60$016115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tama5.ecl.ntt.co.jp id j648w5ni028651 X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: Gerardo Giaretta , 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 Hi James, > What is the "domain provider"? A separate administrative entity from=20 the MSP > or MSA? I think that MN can be assigned FQDN, which is used for IP=20 reachability, from "domain provider" such as =93Yahoo! Domain=94. Is my understanding correct? > If so, then what network entity will be updating the DNS server with=20 the HoA > (which the MN will get from the MSP)? I don=92t think that network entity can update DNS server with HoA when= =20 =93domain provider=94 is separated from MSP or MSA. Only MN can update DN= S=20 server after binding update has been completed successfully. --Mayumi > jak > > ----- Original Message ----- > From: "Mayumi Yanagiya" > To: "Gerardo Giaretta" > Cc: > Sent: Wednesday, June 29, 2005 8:36 PM > Subject: Re: [Mip6] Bootstrapping DT solution draft > > > Hi Gerardo and solution DT members, > > First, I'd like to express my appreciation for your work. > > I have a comment about dynamic DNS update in this draft. > > In section6, it is described that dynamic DNS update function is > important to keep IP reachability when MN is assigned HoA dynamically. > I agree this. But, is it essential function for MIPv6 bootstrapping? > I think we can use FQDN assigned by a domain name provider, which is > different from MSP/MSA, for IP reachability even if we get HoA from MS= P. > > I understood that DT has selected the split scenario, which was simple= r > scenario, in order to make the first solution generic. In the split > scenario, we don=92t assume that there is relationship between MSP and > access service provider. Should we assume that there is relationship > between MSP and DNS provider? > > Best Regards, > --Mayumi > > >>Dear WG, >> >>the bootstrapping DT has submitted a solution draft. The document >>defines how a Mobile Node can bootstrap MIPv6 operations from >>non-topological information and pre-configured security credentials. T= he >>solution solves the boostrapping problem when the Mobile Node's mobili= ty >>service is authorized by a different service provider than basic netwo= rk >>access (i.e. split scenario). >> >>The draft can be found at >>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-spli= t- >>00.txt. >> >>The DT is currently working on optimized solutions for integrated >>scenario (i.e. mobility service and basic network access are authorize= d >>by the same entity). >> >>Please read the document and provide comments. >> >>Thanks and regards, >> >>--Gerardo (DT editor) >> >> >> >> >> >> >> >> >>Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia=20 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 >> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 04 05:26:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpNE6-0002Oy-B9; Mon, 04 Jul 2005 05:26:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpNE3-0002O6-MN for mip6@megatron.ietf.org; Mon, 04 Jul 2005 05:26:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14480 for ; Mon, 4 Jul 2005 05:26:46 -0400 (EDT) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpNRg-0007Ex-2O for mip6@ietf.org; Mon, 04 Jul 2005 05:40:58 -0400 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j649DRKD003910; Mon, 4 Jul 2005 18:13:27 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j649DRA6007110; Mon, 4 Jul 2005 18:13:27 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j649DQwc007105; Mon, 4 Jul 2005 18:13:26 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j649DQOm021976; Mon, 4 Jul 2005 18:13:26 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j649DQBp021973; Mon, 4 Jul 2005 18:13:26 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j649DP0m009830; Mon, 4 Jul 2005 18:13:25 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j649DPmN022330; Mon, 4 Jul 2005 18:13:25 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (ime0.m.ecl.ntt.co.jp [129.60.5.143]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j649DPmp022327; Mon, 4 Jul 2005 18:13:25 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id SAA25110; Mon, 4 Jul 2005 18:13:25 +0900 (JST) Message-ID: <42C8FDB5.1040600@lab.ntt.co.jp> Date: Mon, 04 Jul 2005 18:13:25 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] Bootstrapping DT solution draft References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tama5.ecl.ntt.co.jp id j649DRKD003910 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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 Hi Gerardo, Please see my comments inline. > Hi Mayumi, > > thanks for your comments. Please see below.. > > >>Hi Gerardo and solution DT members, >> >>First, I'd like to express my appreciation for your work. >> >>I have a comment about dynamic DNS update in this draft. >> >>In section6, it is described that dynamic DNS update function is >>important to keep IP reachability when MN is assigned HoA >>dynamically. >>I agree this. But, is it essential function for MIPv6 bootstrapping? > > > The DT thinks that this is essential for IP reachability and thus for > Mobile IPv6. However there has been a lot of discussion about this top= ic > even within the DT. We can consider it as a possible open issue to be > solved within the WG. I=92m so sorry that I didn't ask the question in DT. >>I think we can use FQDN assigned by a domain name provider, which is >>different from MSP/MSA, for IP reachability even if we get >>HoA from MSP. >> > > > Could you please describe a scenario where the domain name provider is > different from the MSP or MSA? I think that MN can be assigned FQDN, which is used for IP=20 reachability, from "domain provider" such as =93Yahoo! Domain=94. Is my understanding correct? >>I understood that DT has selected the split scenario, which >>was simpler >>scenario, in order to make the first solution generic. In the split >>scenario, we don't assume that there is relationship between MSP and >>access service provider. Should we assume that there is relationship >>between MSP and DNS provider? > > > I think that, if there is a trust relationship between MSP and DNS > provider (whatever it can be), the solution described in the draft may > also be applied in this scenario (it needs a AAA communication between > MSP and the domain name provider to authorize the usage of a particula= r > name and to update the DNS entry). But, let's discuss about the scenar= io > first. I agree that this solution can be applied. The main point which I would like to ask is whether it is necessary to describe DNS update in the body of the draft, not whether we can apply this solution even if the trust relationship isn=92t established. IMHO, if we assume a simple scenario, we should not assume any trust relationship between MSP and other provider. Best Regards, --Mayumi > Regards, > --Gerardo > > >>Best Regards, >>--Mayumi >> >> >>>Dear WG, >>> >>>the bootstrapping DT has submitted a solution draft. The document >>>defines how a Mobile Node can bootstrap MIPv6 operations from >>>non-topological information and pre-configured security >> >>credentials. The >> >>>solution solves the boostrapping problem when the Mobile >> >>Node's mobility >> >>>service is authorized by a different service provider than >> >>basic network >> >>>access (i.e. split scenario). >>> >>>The draft can be found at >>> >> >>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > > ing-split- > >>00.txt. >> >>The DT is currently working on optimized solutions for integrated >>scenario (i.e. mobility service and basic network access are > > authorized > >>by the same entity). >> >>Please read the document and provide comments. >> >>Thanks and regards, >> >>--Gerardo (DT editor) >> >> >> >> >> >> >> >> >>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 >> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 05 08:51:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpmto-0001Sp-Gb; Tue, 05 Jul 2005 08:51:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpmtm-0001S5-90 for mip6@megatron.ietf.org; Tue, 05 Jul 2005 08:51:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26708 for ; Tue, 5 Jul 2005 08:51:34 -0400 (EDT) Received: from smtp.um.es ([155.54.212.105] helo=mail.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dpm4p-0002C2-Bz for mip6@ietf.org; Tue, 05 Jul 2005 07:59:00 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id CF78E23C368; Tue, 5 Jul 2005 13:31:04 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31156-01-88; Tue, 5 Jul 2005 13:31:04 +0200 (CEST) Received: from [192.168.1.100] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id B291C23C2CB; Tue, 5 Jul 2005 13:31:01 +0200 (CEST) Message-ID: <42CA6F71.4010608@dif.um.es> Date: Tue, 05 Jul 2005 13:30:57 +0200 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] Bootstrapping DT solution draft References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 56904003e9d74831849863e83b1962ec 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 Hi Gerardo, DT members Firstly, i would like to thank you about this so expected work. Following, please see inline my comments... > > 3. Split scenario > In the problem statement draft [4] there is a clear assumption that > mobility service and network access service can be separate. This > assumption implies that mobility service and network access service > may be authorized by different entities. As an example, the service > model defined in [4] allows an enterprise network to deploy a Home > Agent and offer Mobile IPv6 service to a user, even if the user is > accessing the Internet independent of its enterprise account (e.g., by > using his personal WiFi hotspot account at a coffee shop). > Therefore, in this document it is assumed that network access and > mobility service are authorized by different entities, which means > that authentication and authorization for mobility service and network > access will be considered separately. This scenario is called split > scenario. > > > Moreover, the model defined in [4] separates the entity providing the > service from the entity that authenticates and authorizes the user. > This is similar to the roaming model for network access. > $Rafa> I was wondering what is the role of MSP AAA server in the roaming scenario. For example considering following example: MN <---------IKEv2(EAP)------------>HA<------Diameter(EAP) -------> MSA's AAA server HA can request a redirect agent to contact directly with MSA's AAA server (at least this policy is being followed with network access service as far as I know). So what is the role of MSP's AAA server?? only AAA routing?? Another related question is about authorization. Under my point of view , MSP's AAA server is the entity that finally takes decision about if the mobility service is authorized or not. MSA's AAA server could send to MSP's AAA some kind of evidences or attributes related with authenticated user.Following these attributes and internal policies MSP's AAA server takes a final decision. In particular , I was thinking a similar model than it is shown in Diameter EAP application I-D (Scenario 3: Direct EAP, authorization via agents). Note this dicussion could be also valid for other services (i.e. network access service). > Therefore, in the split scenario, two different cases can be > identified depending on the relationship between the entity that > provides the mobility service (i.e. Mobility Service Provider, MSP) > and the entity that authenticates and authorizes the user (i.e. > Mobility Service Authorizer, MSA). > Figure 1 depicts the split scenario when the MSP and the MSA are the > same entity. This means that the network operator that provides the > Home Agent authenticates and authorizes the user for mobility service. $Rafa> During text, you also consider PKI as backend infrastructure. Maybe it should appear in the figure 1 not only AAA. > > Mobility Service Provider and Authorizer > +-------------------------------------------+ | | | +-------------+ > +--+ | | | MSA/MSP AAA | <-------------> |HA| | | | server | AAA > protocol +--+ | | +-------------+ | | | > +-------------------------------------------+ +--+ |MN| +--+ Figure 1 > - Split Scenario (MSA == MSP) G. Giaretta, Ed. Expires December 22, > 2005 [Page 6] > > > > > 4. Components of the solution > The bootstrapping problem is composed of different sub-problems that > can be solved independently in a modular way. The components > identified and a brief overview of their solution follow. > o HA address discovery. The Mobile Node needs to discover the address > of its Home Agent. The main objective of a bootstrapping solution is > to minimize the data pre-configured on the Mobile Node. For this > reason, the DHAAD defined in [2] may not be applicable in real > deployments since it is required that the Mobile Node is > pre-configured with the home network prefix and it does not allow an > operator to load balance by having Mobile Nodes dynamically assigned > to Home Agents located in different subnets. This document defines a > solution for Home Agent address discovery that is based on Domain Name > Service (DNS), introducing a new DNS SRV record [5]. > > The unique information that needs to be pre- > configured on the Mobile Node is the domain name of the MSP. > > o IPsec Security Associations setup. MIPv6 requires that a Mobile Node > and its Home Agent share an IPsec SA in order to protect binding > updates and other MIPv6 signaling. This document provides a solution > that is based on IKEv2 and follows what is specified in [6]. The IKEv2 > peer authentication can be performed both using certificates and using > EAP, depending on the network operator's deployment model. > o HoA assignment. The Mobile Node needs to know its Home Address in > order to bootstrap Mobile IPv6 operation. The Home Address is assigned > by the Home Agent during the IKEv2 exchange (as described in [6]). The > solution defined in this draft also allows the Mobile Node to > auto-configure its Home Address based on stateless auto- > configuration ([20]), Cryptographically Generated Addresses ([9]) or > privacy addresses ([10]). > o Authentication and Authorization with MSA. The user must be > authenticated in order for the MSA to grant the service. <$Rafa> Here appears "MSA to grant the service" and in page 10 section 5.1.1 "MSP granting the mobility service". Would it not be in the first case "MSP to grant the service" too? > > 5. Protocol Operations > This section describes in detail the procedures needed to perform > Mobile IPv6 bootstrapping based on the components identified in the > previous section. > > 5.1. Home Agent Address Discovery > Once a Mobile Node has obtained network access, it can perform Mobile > IPv6 bootstrapping. For this purpose, the Mobile Node queries the DNS > server to request information on Home Agent service. As mentioned > before in the document, the only information that needs to be auto- > configured <$Rafa> autoconfigured---> pre-configured?? > on the Mobile Node is the domain name of the Mobility Service Provider. > The Mobile Node needs to obtain the IP address of the DNS server > before it can send a DNS request. This can be pre-configured on the > Mobile Node or obtained through DHCPv6 from the visited link [11]. In > any case, it is assumed that there is some kind of mechanism by which > the Mobile Node is configured with a DNS server since a DNS server is > needed for many other reasons. > Two options for DNS lookup for a Home Agent address are identified in > this document: DNS lookup by Home Agent Name and DNS lookup by service > name. > While this document specifies a Home Agent Address Discovery solution > based on DNS, when the ASP and the MSP are the same entity DHCP may be > used. See [15] for details. > > > 5.4. Authorization and Authentication with MSA > In a scenario where the Home Agent is discovered dynamically by the > Mobile Node, it is very likely that the Home Agent is not able to > verify by its own the credentials provided by the Mobile Node during > the IKEv2 exchange. Moreover, the mobility service needs to be > explicitly authorized based on the user's profile. > As an example, the Home Agent might not be aware if the mobility > service can be granted at a particular time of the day or if the > credit of the Mobile Node is going to expire. > <$Rafa> In the example, could MSA know that mobility service can be or cannot be granted at a particular time depending on internal policies in the MSP? I guess this example considers that user's profile says that this user cannot use the service during a particular time of the day.However it does not consider that user has no restricction about this time but MSP decides that mobility service cannot be granted during a particular time of the day. Home Agent should be aware of this too. > > > Due to all these reasons, the Home Agent may need to contact the MSA > in order to authenticate > > the Mobile Node and authorize mobility G. Giaretta, Ed. Expires > December 22, 2005 [Page 14] > > > > > > > Internet-Draft MIPv6 bootstrapping in split scenario June 2005 > service. This can be accomplished based on a Public Key Infrastructure > if certificates are used and a PKI > <$Rafa> For authorization ... are you considering attributes certificates when PKI is used...?? > is deployed by the MSP and MSA. On the other hand, if the Mobile Node > is provided with other types of credentials, the AAA infrastructure > must be used. > The definition of this backend communication is out of the scope of > this document. In [12] a list of goals for such a communication is > provided. > > > 6. Home Address registration in the DNS > In order that the Mobile Node is reachable through its dynamically > assigned Home Address, the DNS needs to be updated with the new Home > Address. Since applications make use of DNS lookups on FQDN to find a > node, the DNS update is essential for providing IP reachability to the > Mobile Node, which is the main purpose of the Mobile IPv6 protocol. > The need of DNS update is not discussed in RFC 3775 since it assumes > that the Mobile Node is provisioned with a static home address. > However, when a dynamic Home Address is assigned to the Mobile Node, > any existing DNS entry becomes invalid and the Mobile Node becomes > unreachable unless a DNS update is performed. > Since the DNS update must be performed securely in order to prevent > attacks or modifications from malicious nodes, the node performing > this update must share a security association with the DNS server. > Having all possible Mobile Nodes sharing a security association with > the DNS servers of the MSP might be cumbersome from an administrative > perspective. Moreover, even if a Mobile Node has a security > association with a DNS server of its MSP, an address authorization > issue comes into the picture. A detailed analysis of possible threats > against DNS update is provided in section 9.5. > Therefore, due to security and administrative reasons, it is > RECOMMENDED that the Home Agent perform DNS entry update for the > Mobile Node. For this purpose the Mobile Node MAY include a new > mobility option, the DNS Update option, with the flag R not set in the > Binding Update. This option is defined in section 8 and includes the > FQDN that needs to be updated. After receiving the Binding Update, the > Home Agent MUST update the DNS entry with the identifier provided by > the Mobile Node and the Home Address included in the Home Address > Option. The procedure for sending a dynamic DNS update message is > specified in [14]. The dynamic DNS update SHOULD be performed in a > secure way; for this reason, the usage of TKEY and TSEC or DNSSEC is > recommended (see section 9.5 for details). As soon as the Home Agent > has updated the DNS, it MUST send a Binding Acknowledgement message to > the Mobile Node including the DNS Update mobility option with the > correct value in the Status field (see section 8.1). > This procedure can be performed directly by the Home Agent if the Home > Agent has a security association with the domain specified in the > Mobile Node's FQDN. > > <$Rafa> Why don't MSP's AAA server could do DNS update instead of MSA's AAA server?? > On the other hand, if the Mobile Node wants to be reachable through a > FQDN that belongs to the MSA, the Home Agent and the DNS server that > must be updated belong to different administrative domain. In this G. > Giaretta, Ed. Expires December 22, 2005 [Page 16] > > > > > > > Internet-Draft MIPv6 bootstrapping in split scenario June 2005 > case the Home Agent may not share a security association with the DNS > server and the DNS entry update can be performed by the AAA server of > the MSA. In order to accomplish this, the Home Agent sends to the AAA > server the FQDN-HoA pair through the AAA protocol. This message is > proxied by the AAA infrastructure of the MSP and is received by the > AAA server of the MSA. The AAA server of the MSA perform the DNS > update based on [14]. The detailed description of the communication > between Home Agent and AAA is out of the scope of this draft. More > details are provided in [12]. > > > 9. Security Considerations > 9.1. HA Address Discovery > Use of DNS for address discovery carries certain security risks. DNS > transactions in the Internet are typically done without any > authentication of the DNS server by the client or of the client by the > server. There are two risks involved: > 1) A legitimate client obtains a bogus Home Agent address from a bogus > DNS server. This is sometimes called a "pharming" attack, > 2) An attacking client obtains a legitimate Home Agent address from a > legitimate server. > <$Rafa>I have a comment regarding this case 1): I think any user already authenticated and authorized to use mobility service could launch this attack becuase user already owns a valid certificate and therefore a legitimate client could verify this certificate. The issue is this user is NOT AUTHORIZED to be a Home Agent. what do you think?? > The risk in Case 1 is mitigated because the Mobile Node is required to > conduct an IKE transaction with the Home Agent prior to performing a > Binding Update to establish Mobile IPv6 service. According to the > IKEv2 specification [7], the responder must present the initiator with > a valid certificate containing the responder's public key, and the > responder to initiator IKE_AUTH message must be protected with an > authenticator calculated using the public key in the certificate. > Thus, an attacker would have to set up both a bogus DNS server and a > bogus Home Agent, and provision the Home Agent with a certificate that > a victim Mobile Node could verify. If the Mobile Node can detect that > the certificate is not trustworthy, the attack will be foiled when the > Mobile Node attempts to set up the IKE SA. > > > > 9.5. Dynamic DNS Update > Mobile IPv6 bootstrapping recommends the Home Agent to update the > Mobile Node's FQDN with a dynamically assigned home address rather > than have the Mobile Node itself do it (see Section 6 above). This > choice was motivated by a concern for preventing redirection-based > flooding attacks (see draft-ietf-mip6-ro-sec [19] for more information > about redirection-based flooding attacks and the role preventing them > played in the design of Mobile IPv6 route optimization security). > Exactly as for route optimization, it is possible for a node that is > the legitimate owner of a DNS FQDN - in the sense that it has a > security association with the DNS server allowing it to perform > dynamic DNS update of its FQDN - to bind its FQDN to the address of a > victim, then redirect large volumes of traffic at the victim. The > attack may be propagated without the owner's knowledge, for example, > if the node is compromised by malware, or it may be intentional if the > node itself is the attacker. > While it is possible to prevent redirection attacks through ingress > filtering on access routers, ISPs have little or no incentive to > deploy ingress filtering. In some cases, if an attack could result in > substantial financial gain, it is even possible that a corrupt ISP may > have an incentive not to deploy ingress filters such as has been the > case for spam. Consequently, the security for dynamic Mobile Node FQDN > update has been assigned to the Home Agent, where active network > administration and vigilant defense measures are more likely to (but > G. Giaretta, Ed. Expires December 22, 2005 [Page 25] > > > > > > > Internet-Draft MIPv6 bootstrapping in split scenario June 2005 > are not assured of) mitigating problems, and the owner of the Mobile > Node is more likely to detect a problem if it occurs. > If a Home Agent performs dynamic DNS update on behalf of the Mobile > Node directly with the DNS server, the Home Agent MUST have a security > association of some type with the DNS server. The security association > MAY be established either using DNSSEC [16] or TSIG/TKEY [17][18]. A > security association is required even if the DNS server is in the same > administrative domain as the Home Agent. The security association > SHOULD be separate from the security associations used for other > purposes, such as AAA. > In the case where the Mobility Service Provider is different from the > Mobility Service Authorizer, the network administrators may want to > limit the number of cross-administrative domain security associations. > If the Mobile Node's FQDN is in the Mobility Service Authorizer's > domain, since a security association for AAA signaling involved in > mobility service authorization is required in any case, the Home Agent > can send the Mobile Node's FQDN to the AAA server under the HA-AAA > server security association, $Rafa> MSA's AAA Server?? or MSP's AAA server?? So far, these are my comments. Regards. -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ Gerardo Giaretta wrote: > Dear WG, > > the bootstrapping DT has submitted a solution draft. The document > defines how a Mobile Node can bootstrap MIPv6 operations from > non-topological information and pre-configured security credentials. The > solution solves the boostrapping problem when the Mobile Node's mobility > service is authorized by a different service provider than basic network > access (i.e. split scenario). > > The draft can be found at > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- > 00.txt. > > The DT is currently working on optimized solutions for integrated > scenario (i.e. mobility service and basic network access are authorized > by the same entity). > > Please read the document and provide comments. > > Thanks and regards, > > --Gerardo (DT editor) > > > > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > S.p.A. > > ==================================================================== > 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 > ==================================================================== > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > > Gerardo Giaretta wrote: >Dear WG, > >the bootstrapping DT has submitted a solution draft. The document >defines how a Mobile Node can bootstrap MIPv6 operations from >non-topological information and pre-configured security credentials. The >solution solves the boostrapping problem when the Mobile Node's mobility >service is authorized by a different service provider than basic network >access (i.e. split scenario). > >The draft can be found at >http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- >00.txt. > >The DT is currently working on optimized solutions for integrated >scenario (i.e. mobility service and basic network access are authorized >by the same entity). > >Please read the document and provide comments. > >Thanks and regards, > >--Gerardo (DT editor) > > > > > > > > >Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > >==================================================================== >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 >==================================================================== > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 05 12:16:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpq3l-0004UE-Pz; Tue, 05 Jul 2005 12:14:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dpq3j-0004Qb-Uo for mip6@megatron.ietf.org; Tue, 05 Jul 2005 12:14:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15786 for ; Tue, 5 Jul 2005 12:14:03 -0400 (EDT) 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 1DpqQp-0004Ed-N9 for mip6@ietf.org; Tue, 05 Jul 2005 12:38:02 -0400 Message-ID: <05a101c5817c$37c396e0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Mayumi Yanagiya" References: <42C368D1.3000504@lab.ntt.co.jp> <005101c57d8c$a6713e60$016115ac@dcml.docomolabsusa.com> <42C8FA1A.30309@lab.ntt.co.jp> Subject: Re: [Mip6] Bootstrapping DT solution draft Date: Tue, 5 Jul 2005 09:11:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Cc: Gerardo Giaretta , 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 Mayumi, > I don=92t think that network entity can update DNS server with HoA whe= n >=93domain provider=94 is separated from MSP or MSA. Only MN can update D= NS >server after binding update has been completed successfully. We discussed this at some length in the DT and the concensus is that ther= e is no way to prevent redirection attacks if the MN does the update. There= is no provision for return routability in dynamic DNS, so a MN could update = the DNS with an address that it was not at, and thereby DoS a victim, just as with MIPv6 return routability. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 05 12:30:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpqK3-0008UZ-LZ; Tue, 05 Jul 2005 12:30:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpqK2-0008Tp-84 for mip6@megatron.ietf.org; Tue, 05 Jul 2005 12:30:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18322 for ; Tue, 5 Jul 2005 12:30:53 -0400 (EDT) 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 1DpqbZ-0005Qz-IT for mip6@ietf.org; Tue, 05 Jul 2005 12:49:07 -0400 Message-ID: <05ab01c5817d$c4b4b740$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Mayumi Yanagiya" , "Gerardo Giaretta" References: <42C8FDB5.1040600@lab.ntt.co.jp> Subject: Re: [Mip6] Bootstrapping DT solution draft Date: Tue, 5 Jul 2005 09:22:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 First off, if you agree that bootstrapping must provide full support for Internet reachability, then I think DNS update for a dynamically assigned HoA is necessary. RFC 3775 doesn't have this issue because it doesn't support dynamic HoA assignment. With regard to: > I agree that this solution can be applied. > The main point which I would like to ask is whether it is necessary > to describe DNS update in the body of the draft, not whether we can > apply this solution even if the trust relationship isn=92t established= . It is possible for the MN to perform dynamic DNS update, but not with ful= l security, as I described in a separate email. The HA can perform a secure update, because it is supposed to be keeping track of whether the MN is actually at the CoA or not (how it does that i= s not described in RFC 3775, however that's a separate issue). So it can securely update the DNS. Given that, there is a need for some way for the MN to send its FQDN to t= he HA and ask for an update. We decided to put it into the bootstrapping dra= ft so all the information necessary to implement full Internet reachability = is in one place. > IMHO, if we assume a simple scenario, we should not > assume any trust relationship between MSP and other provider. Well, the MSP and MSA need to have a trust relationship, otherwise they w= ill not be able to exchange Radius messages securely (of course, if they are = the same administrative entity, there is no issue). jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 05 13:36:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DprLk-000175-QB; Tue, 05 Jul 2005 13:36:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DprLg-00015U-Gk for mip6@megatron.ietf.org; Tue, 05 Jul 2005 13:36:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28069 for ; Tue, 5 Jul 2005 13:36:39 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dprgq-0002yG-RP for mip6@ietf.org; Tue, 05 Jul 2005 13:58:37 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IJ600G1Y0IF30@dns1.cselt.it> for mip6@ietf.org; Tue, 05 Jul 2005 19:27:51 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 05 Jul 2005 19:34:06 +0200 Date: Tue, 05 Jul 2005 18:58:40 +0200 From: Gerardo Giaretta Subject: RE: [Mip6] Bootstrapping DT solution draft To: Mayumi Yanagiya Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Bootstrapping DT solution draft thread-index: AcWAeKuiY4kvww/JTUaO4+JyIfyXlgA7ydyg Content-Class: urn:content-classes:message X-OriginalArrivalTime: 05 Jul 2005 17:34:06.0625 (UTC) FILETIME=[BE7B5910:01C58187] X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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 Hi Mayumi, thanks for your reply. Please see below. > >>I think we can use FQDN assigned by a domain name=20 > provider, which is > >>different from MSP/MSA, for IP reachability even if we get > >>HoA from MSP. > >> > > > > > > Could you please describe a scenario where the domain name=20 > provider is > > different from the MSP or MSA? >=20 > I think that MN can be assigned FQDN, which is used for IP=20 > reachability, from "domain provider" such as "Yahoo! Domain". > Is my understanding correct? >=20 This is a scenario that we have not considered during the DT work. If I understand correctly, this would mean to introduce a new entity, a sort of "naming service provider". Putting aside whether it is a good idea or not, I think naming issues are out of scope of MIP6 bootstrapping.=20 > >>I understood that DT has selected the split scenario, which > >>was simpler > >>scenario, in order to make the first solution generic. In the split > >>scenario, we don't assume that there is relationship=20 > between MSP and > >>access service provider. Should we assume that there is=20 > relationship > >>between MSP and DNS provider? > > > > > > I think that, if there is a trust relationship between MSP and DNS > > provider (whatever it can be), the solution described in=20 > the draft may > > also be applied in this scenario (it needs a AAA=20 > communication between > > MSP and the domain name provider to authorize the usage of=20 > a particular > > name and to update the DNS entry). But, let's discuss=20 > about the scenario > > first. >=20 > I agree that this solution can be applied. > The main point which I would like to ask is whether it is necessary > to describe DNS update in the body of the draft, not whether we can > apply this solution even if the trust relationship isn't=20 > established. >=20 James have just deeply answered this issue. > IMHO, if we assume a simple scenario, we should not > assume any trust relationship between MSP and other provider. >=20 MSA and MSP MUST have a trust relationship in order to exchange authentication and authorization data in a secure way. Regards, --Gerardo >=20 > Best Regards, > --Mayumi >=20 > > Regards, > > --Gerardo > > > > > >>Best Regards, > >>--Mayumi > >> > >> > >>>Dear WG, > >>> > >>>the bootstrapping DT has submitted a solution draft. The document > >>>defines how a Mobile Node can bootstrap MIPv6 operations from > >>>non-topological information and pre-configured security > >> > >>credentials. The > >> > >>>solution solves the boostrapping problem when the Mobile > >> > >>Node's mobility > >> > >>>service is authorized by a different service provider than > >> > >>basic network > >> > >>>access (i.e. split scenario). > >>> > >>>The draft can be found at > >>> > >> > >>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > > > > ing-split- > > > >>00.txt. > >> > >>The DT is currently working on optimized solutions for integrated > >>scenario (i.e. mobility service and basic network access are > > > > authorized > > > >>by the same entity). > >> > >>Please read the document and provide comments. > >> > >>Thanks and regards, > >> > >>--Gerardo (DT editor) > >> > >> > >> > >> > >> > >> > >> > >> > >>Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > > > > S.p.A. > > > =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=3D=3D=3D=3D > >>CONFIDENTIALITY NOTICE > >>This message and its attachments are addressed solely to=20 > the persons > >>above and may contain confidential information. If you=20 > have received > >>the message in error, be informed that any use of the=20 > content hereof > >>is prohibited. Please return it immediately to the sender=20 > and delete > >>the message. Should you have any questions, please send an=20 > e_mail to > >>MailAdmin@tilab.com. Thank you > =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=3D=3D=3D=3D > >> > >>_______________________________________________ > >>Mip6 mailing list > >>Mip6@ietf.org > >>https://www1.ietf.org/mailman/listinfo/mip6 > >> > > > > >=20 >=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=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 Tue Jul 05 15:56:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DptXM-0004UG-V5; Tue, 05 Jul 2005 15:56:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DptNn-000126-OY for mip6@megatron.ietf.org; Tue, 05 Jul 2005 15:47:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13959 for ; Tue, 5 Jul 2005 15:46:59 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DptjX-0003ln-Al for mip6@ietf.org; Tue, 05 Jul 2005 16:09:32 -0400 Received: from MINDLAP2 (mindlap2.cs.umd.edu [172.16.0.37]) (authenticated bits=0) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j65JfWtZ017067 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 5 Jul 2005 15:41:36 -0400 (EDT) Message-Id: <200507051941.j65JfWtZ017067@carrierpigeon.cs.umd.edu> From: "Moustafa Youssef" To: Date: Tue, 5 Jul 2005 15:41:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Subject: [Mip6] 1st CFP: 2nd IEEE Workshop on Dependability and Security in Sensor Networks and Systems 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 (Our apologies if you receive multiple copies of this CFP) ------------------------------------------------------------- First Call for Papers Second IEEE Workshop on Dependability and Security in Sensor Networks and Systems (DSSNS=922006) http://www.dssns.org In conjunction with 2nd NASA/IEEE Systems and Software Week 30th NASA/IEEE Software Engineering Workshop (SEW=922006) April 24-28, 2006 Recently, there has been a growing interest in the potential use of networked sensors in applications such as smart environments,=20 disaster management, combat field reconnaissance, and security=20 surveillance. While the initial view of the community was that=20 networked sensors will play a complementary role that enhances=20 the quality of these applications, recent research results have=20 encouraged practitioners to envision an increased reliance on sensor=20 networks and systems (SN&S) in such critical and sensitive applications. Therefore to realize their potential, necessary dependability and=20 security (D&S) measures have to be incorporated in the design and=20 during the operation of SN&S. Dependability is usually specified=20 using attributes like reliability, survivability, safety, maintainability,=20 and availability in presence of failure, while security is specified by=20 attributes like integrity, authenticity, confidentiality, and availability=20 in presence of attacks. D&S services accomplish tasks for attack and failure prevention, detection and response. The scope of D&S services may span the deployed sensors to command nodes and likely beyond. It also=20 involves D&S support at, and cross-cutting, the protocol stack layers=20 from physical to application. Achieving dependability and security in SN&S will require non-conventional=20 mechanisms due to many factors including: (1) sensors are significantly constrained in the amount of available resources such as energy, storage and computation; (2) sensors are expected to be deployed in very large numbers in normal as well as harsh/hostile environments; (3) sensor networks suffer from structural weakness and limited physical protection, and (4) localization of impact is complicated due to the un-tethered nature of SN&S and of the potential attackers. In addition, D&S requirements may vary according to mission defined over a multi-dimensional context, such as field of deployment (e.g., hostile versus friendly), type of application (e.g., monitoring, tracking, data collection), mode of operation (e.g., normal, exception, post-event recovery), and time. This workshop will foster a forum for discussing and presenting recent research results on dependability and security in SN&S. Topics of interest include, although not limited to, the following: - Fault and intrusion-tolerant architectures, middleware and operational models=20 - Robust routing, storage, and processing of sensed data - D&S architectures, protocols and tools - Vulnerabilities, attacks and countermeasures - Monitoring and evaluation techniques - Robust clustering techniques - Self-awareness and context-awareness=20 - Resilient virtual infrastructures - Autonomic and adaptive D&S support. - Formal representation and verification of D&S properties - Network inference support for D&S - Quality of service provisioning - Models, metrics, and measurements for D&S - Privacy-aware D&S services - Testbeds, simulation and visualization=20 - Agent-based D&S management=20 - SN&S support for D&S in larger information grids - SN&S application development environments Submission Guidelines --------------------- For guidelines regarding paper submission, please refer to the workshop=92s website (http://www.dssns.org). Papers should contain original material and not be previously published, or currently submitted for consideration elsewhere. The manuscript should not exceed 20 single-column double-space pages in PDF format, font size 11 or larger. The first page should include title, authors' contact information, abstract and five keywords.=20 Important Dates ---------------- Submission deadline: November 7, 2004 Decision notification: December 20, 2004 Final manuscript due: January 20, 2005 The best paper will be recognized and selected papers will be invited to a Special Issue of the Journal of Ad Hoc and Sensor Wireless Networks.=20 Workshop Co-Chairs ------------------- Mohamed Eltoweissy Virginia Tech, USA E-mail: toweissy@vt.edu=20 Mohamed Younis University of Maryland Baltimore County, USA E-mail: younis@csee.umbc.edu=20 Publicity Co-Chairs -------------------- Denis Gracanin Virginia Tech, USA E-mail: gracanin@vt.edu Moustafa Youssef University of Maryland at College Park, USA E-mail: moustafa@cs.umd.edu=20 Program Committee ------------------ Farooq Anjum, Telcordia & U of Penn, USA David Carman, Johns Hopkins Univ.=96 Applied Physics Lab, USA Ing-Ray Chen, Virginia Tech, USA M. Nazih Elderini, Alexandria Univ, Egypt Sushil Jajodia, George Mason Univ., USA Shivakant Mishra, Univ, of Colorado, USA Peng Ning, North Carolina State U, USA Stephan Olariu, Old Dominion Univ., USA David Simplot-Ryl, Univ. Lille, INRIA Futurs, France John A. Stankovic, University of Virginia, USA Ivan Stojmenovic, Univ. of Ottawa, Canada Cliff Wang, Army Research Office, USA Stephen D. Wolthusen, Fraunhofer-IGD, Germany Albert Zomaya, Univ. of Sydney, Australia _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 05 22:01:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpzE0-0000cq-Ae; Tue, 05 Jul 2005 22:01:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DpzDy-0000cI-0z for mip6@megatron.ietf.org; Tue, 05 Jul 2005 22:01:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05443 for ; Tue, 5 Jul 2005 22:01:14 -0400 (EDT) Received: from [218.249.29.198] (helo=center.njtu.edu.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DpzXq-0005i2-Ns for mip6@ietf.org; Tue, 05 Jul 2005 22:21:52 -0400 Received: from zhanghk (remotehost [127.0.0.1]) by mail.student.njtu.edu.cn (ecMail) with ESMTP id 8995918C00A; Wed, 6 Jul 2005 10:09:58 +0800 (CST) Date: Wed, 6 Jul 2005 09:55:28 +0800 From: "HKzhang@center.njtu.edu.cn" To: "gdommety" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20050706020958.8995918C00A@mail.student.njtu.edu.cn> X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: mip6 , "basavaraj.patil" Subject: [Mip6] Could you kindly arrange some time to let us introduce and discuss the draft at the 63rd IETF meeting in Paris 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="===============0103820561==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --===============0103820561== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGksRGVhciBDaGFpcm1hbg0KICBJJ20gSG9uZy1LZSBaaGFuZywgb25lIG9mIHRoZSBhdXRob3Jz IG9mIGRyYWZ0LXpoYW5nLW1pcHNob3AtbXVsdGljYXN0LWRtYS0wMC50eHQgd2hpY2ggaGFzIGJl ZW4gcHV0IGludG8geW91ciBtYWlsIGxpc3QgYXMgd2VsbC4gV2UgaG9wZSB0byBtYWtlIHByZXNl bnRhdGlvbiBmb3IgdGhpcyBkcmFmdCBhdCB0aGUgNjNyZCBJRVRGIG1lZXRpbmcgaW4gUGFyaXMu IFdlIGhhdmUgZmluZCB5b3UgY2FuIGFycmFuZ2UgdGltZSB0byB0aGUgZHJhZnQgaW4gdGhlIG1l ZXRpbmcuIEZvciBpdCBpcyBkaWZmaWN1bHQgZm9yIHVzIHRvIGdldCB0aW1lIGluIG90aGVyIFdH LCBzbyB3ZSBoYWQgdG8gYXNrIGZvciB5b3UgdG8gYXJyYW5nZSBzb21lIHRpbWUgdG8gdGhpcyBk cmFmdC4gTWF5YmUgaXQgd2lsbCBiZSBtb3JlIGRpZmZpY3VsdCBpbiB5b3UgV0cuIA0KICBDb3Vs ZCB5b3Uga2luZGx5IGFycmFuZ2Ugc29tZSB0aW1lIHRvIGxldCB1cyBpbnRyb2R1Y2UgYW5kIGRp c2N1c3MgdGhlIGRyYWZ0IGF0IHRoZSA2M3JkIElFVEYgbWVldGluZyBpbiBQYXJpcz8gTWFueSB0 aGFua3MgDQphbmQgYXBwcmVjaWF0aW9uIGlmIHlvdSBjYW4gYXJyYW5nZSBpdC4NCg0KQmVzdCBS ZWdhcmRzLA0KRHIuIEhvbmctS2UgWmhhbmcNClByZXNpZGVudCBvZiBDb2xsZWdlIG9mIEVsZWN0 cm9uaWNzIGFuZCBJbmZvcm1hdGlvbiBFbmdpbmVlcmluZywgQmVpamluZyBKaWFvdG9uZyBVbml2 ZXJzaXR5DQqhoaGhoaGhoaGhoaGhoaGhSEt6aGFuZw0KoaGhoaGhoaGhoaGhoaGhoUhLemhhbmdA Y2VudGVyLm5qdHUuZWR1LmNuDQqhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDUtMDctMDYNCg== --===============0103820561== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0103820561==-- From mip6-bounces@ietf.org Thu Jul 07 04:40:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqRw2-0004R1-EA; Thu, 07 Jul 2005 04:40:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqNJH-0006St-Md; Wed, 06 Jul 2005 23:44:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00329; Wed, 6 Jul 2005 23:44:21 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqNkO-0003bt-Gl; Thu, 07 Jul 2005 00:12:24 -0400 Received: from [24.52.170.51] (account margaret HELO [192.168.1.105]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 423832; Wed, 06 Jul 2005 23:38:41 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 6 Jul 2005 23:41:45 -0400 To: int-area@ietf.org From: Margaret Wasserman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Thu, 07 Jul 2005 04:40:40 -0400 Cc: Subject: [Mip6] NEW!! Internet Area Mailing List 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 [This message is bcc:ed to all INT area WGs, the IESG and the IAB.] Hi All, We have created an Internet Area mailing list -- int-area@ietf.org. This list will be used to announce Internet area BOFs, to discuss Internet area WG charter updates and to discuss other issues related to the Internet Area, as they arise -- such as whether we should hold an Internet area meeting in Paris. If you wish to join the list, you can do so at: https://www1.ietf.org/mailman/listinfo/int-area The archives should be available at: http://www.ietf.org/mail-archive/web/int-area/index.html (Hopefully this will be the first message in the archive). If you are interested in issues concerning the overall structure or scope of the Internet area and/or are interested in influencing how the Internet area is managed, I hope you will join this list. Thanks, Margaret _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 07 04:40:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqRw2-0004RQ-Tp; Thu, 07 Jul 2005 04:40:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqQeU-0002nN-OG; Thu, 07 Jul 2005 03:18:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06005; Thu, 7 Jul 2005 03:18:28 -0400 (EDT) Received: from mantis.cs.colorado.edu ([128.138.206.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqR5b-0001Qy-SJ; Thu, 07 Jul 2005 03:46:33 -0400 Received: from mantis.cs.colorado.edu (localhost [127.0.0.1]) by mantis.cs.colorado.edu (Postfix) with ESMTP id DF430121513; Thu, 7 Jul 2005 01:17:14 -0600 (MDT) X-Original-To: securecomm-cfp@mantis.cs.colorado.edu Delivered-To: securecomm-cfp@mantis.cs.colorado.edu Received: from research.cs.colorado.edu (research.cs.colorado.edu [128.138.242.225]) by mantis.cs.colorado.edu (Postfix) with ESMTP id E98DD12120F for ; Thu, 7 Jul 2005 01:14:41 -0600 (MDT) Received: from [127.0.0.1] (c-24-8-166-41.hsd1.co.comcast.net [24.8.166.41]) by research.cs.colorado.edu (8.12.10/8.12.6) with ESMTP id j677FQik085965 for ; Thu, 7 Jul 2005 01:15:27 -0600 (MDT) Message-ID: <42CCD68A.3030406@cs.colorado.edu> Date: Thu, 07 Jul 2005 01:15:22 -0600 From: Richard Han Organization: University of Colorado at Boulder User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: securecomm-cfp@mantis.cs.colorado.edu Content-Type: text/plain; charset=windows-1252; format=flowed X-Mailman-Approved-At: Thu, 07 Jul 2005 01:17:11 -0600 X-BeenThere: securecomm-cfp@mantis.cs.colorado.edu X-Mailman-Version: 2.1.5 Precedence: list List-Archive: Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 07 Jul 2005 04:40:40 -0400 Cc: Subject: [Mip6] [Securecomm-cfp] Call For Participation - IEEE/CreateNet SecureComm 2005 X-BeenThere: mip6@ietf.org List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Dear Colleague, Please find attached the call for participation for the First IEEE/CreateNet International Conference on Security and Privacy for Emerging Areas in Communication Networks (SecureComm 2005) to be held in Athens, Greece from Sep. 5-9, 2005. The conference program consists of 32 full papers and 20 short papers, keynote and invited talks, and a panel. In addition, there are four workshops on related topics. The complete information is available on the website: www.securecomm.org Note that Early Registration Ends August 25, 2005! We apologize if you receive multiple copies of this message. Please feel free to distribute this to colleagues who might be interested. regards, SecureComm 2005 Organizing Committee *************************************************************** CALL FOR PARTICIPATION First IEEE/CreateNet International Conference on Security and Privacy for Emerging Areas in Communication Networks Athens, Greece / Hotel Amarilia / 5 - 9 September, 2005 www.securecomm.org EARLY REGISTRATION ENDS August 25, 2005 CO-SPONSORED BY: IEEE Communications Society (www.comsoc.org) CreateNet (www.create-net.it) Corporate/Government Sponsors: National Science Foundation (Travel Grants) Telcordia Technologies (Silver sponsor) Toshiba TARI(Bronze sponsor) In Cooperation With the IEEE Computer Society TC on Security and Privacy In Cooperation with ACM SIGSAC *************************************************************** TENTATIVE TECHNICAL PROGRAM Monday, Sep 5, 2005 First IEEE/CreateNet International Workshop on Computer Network=20 Forensics Research (CNFR): www.cnfr.org First IEEE/CreateNet International Workshop on Trust and Security in=20 Pervasive Networking: http://www.securecomm.org/pervasivetrust/ *************************************************************** Tuesday, Sep 6, 2005 8.30AM - 9.00 AM: Welcome, Introduction, Best Paper award 9.00AM - 10.30AM: Plenary Session: Bill Cheswick, Lumeta, Title: Pondering and Patrolling Network=20 Perimeters Andrea Servida, EU, Title: Security, privacy and dependability=20 in Information Society: key challenges for European R&D in FP7 10.30AM - 11.00AM: Break 11.00AM - 12.40PM: Full Paper Session 1: Insecurity Implications of Unlicensed Mobile Access (UMA) for GSM security Sandro Grech, Pasi Eronen=09 Computationally, Memory and Bandwidth Efficient Distillation Codes to=20 Mitigate DoS in Multicast Roberto Di Pietro, Stefano Chessa, Piero Maestrini =09 Spread Identity mechanisms for Security Dhananjay Phatak =09 On the Security of Distributed Position Services Xiaoxin Wu, Cristina Nita-Rotaru =09 12.40PM - 2:00PM: Lunch 2:00PM - 2.45PM: Invited talk: David Wagner, Berkeley, Title: Privacy in=20 pervasive computing: What can technologists do? 3:00 PM - 4:40 PM: Full Paper Session 2: RFID Picking Virtual Pockets using Relay Attacks on Contactless Smartcard Syst= ems Ziv Kfir, Avishai Wool =09 A Lightweight RFID Protocol to protect against Traceability and Cloning=20 attacks Tassos Dimitriou =09 An RFID distance bounding protocol Gerhard Hancke, Markus Kuhn =09 Security and Privacy Issues in e-Passports Ari Juels, David Molnar, David Wagner 5:00 PM - 6.30PM: Panel 1: RFID, Lead Panelist: TBA *************************************************************** Wednesday, Sep 7, 2005 8.30AM - 9.15 AM: Keynote: Jean Pierre-Hubaux, EPFL, Title: The Security = of Vehicular Networks 9.30AM - 10.45AM: Full Paper Session 3: Sensor Networks DICAS: Detection, Diagnosis and Isolation of Control Attacks in Sensor=20 Networks Issa Khalil, Saurabh Bagchi, Cristina Nita-Rotaru =09 Securing Topology Maintenance Protocols for sensor networks: attacks and=20 counter- measures Andrea Gabrielli, Luigi Mancini, Sanjeev Setia, Sushil Jajodia =09 Countermeasures Against Traffic Analysis Attacks in Wireless Sensor Netwo= rks Jing Deng, Richard Han, Shivakant Mishra =09 11.00AM - 12.40PM: Full Paper Session 4: Authentication Improving Cross-domain Authentication over Wireless Local Area Networks Hahnsang Kim, Kang Shin, Walid Dabbous =09 Reducing Reauthentication Delay in Wireless Networks Tuomas Aura, Michael Roe Providing Distributed Certificate Authority Service in Mobile Ad Hoc=20 Networks Ying Dong, Wing Go, Aifen Sui, Victor Li, Lucas C.K. Hui, Siu Ming Yiu =09 On Improving the Performance of Role-Based Cascaded Delegation in=20 Ubiquitous Computing Danfeng Yao, Roberto Tamassia, Seth Proctor =09 12.40PM - 2:00PM: Lunch 2:00PM - 2:45PM: Invited Talk: William Arbaugh, Title: Ad-hoc network=20 security: is it a real problem? 3:00PM - 4:40PM: Full Paper Session 5: Privacy A Privacy Preserving Reputation System for Mobile Information=20 Dissemination Networks Marco Voss, Andreas Heinemann, Max M=9Fhlh=8Auser =09 A Privacy Service for Context-Aware Mobile Computing Vagner Sacramento, Markus Endler, Fernando Nascimento =09 Protecting Location Privacy Through Path Confusion Baik Hoh, Marco Gruteser A Solution for Wireless Privacy and Payments based on E-cash Yiannis Tsiounis, Tom Karygiannis, Aggelos Kiayias =09 5:00PM - 6:40PM: Short paper Session 1 A Signal Fingerprinting Paradigm for Physical Layer Security in=20 Conventional and Sensor Networks, Thomas Daniels, Mani Mina, Steve Russell Location Privacy with IP Mobility Rajeev Koodli, Vijay Devarapalli, Hannu Flinck, Charles Perkins Fellowship in Mobile Ad hoc Networks, Venkatesan Balakrishnan, Vijay Varadharajan 802.11 Active Attack Traffic Profile Classification Using Management=20 Frame Clustering Wenzhe Zhou, Alan Marshall, Qiang Gu =09 A Secure Interworking Scheme for UMTS-WLAN Yen-Chieh Ouyang, Chung-Hua Chu, Chang-Bu Jang bufSTAT - A Tool for Early Detection and Classification of Buffer Overflow Attacks Svetlana Radosavac, Karl Seamon, John S. Baras LRBAC: A Location-Aware Role-Based Access Control Model Indrakshi Ray,Lijun Yu Tri-party TLS Adaptation for Trust Delegation in Home Networks Khaled Masmoudi, Mureed Hussain, Hossam Afifi, Dominique Seret =09 PATRIOT: a Policy-Based, Multi-level Security Protocol for Safekeeping=20 Audit Logs on Wireless Devices, Wassim Itani, Ayman Kayssi, Ali Chehab Harnessing Emergent Ubiquitous Computing Properties to Prevent Malicious=20 Code Propagation, David Llewellyn-Jones, Madjid Merabti, Qi Shi, Bob Askwith *************************************************************** Thursday, Sep 8, 2005 8.30AM - 10.35 AM: Full Paper Session 6: Key management A Level Key Infrastructure for Secure and Efficient Group Communication=20 in Wireless Sensor Networks Jyh-How Huang, Jason Buckingham, Richard Han A Modified Secure Remote Password (SRP) Protocol for Key Initialization=20 and Exchange in Bluetooth Systems Amir Sayegh, Mahmoud El-hadidi Hi-KD: An Efficient Key Management Algorithm for Hierarchical Group Hani Ragab Hassan, Abdelmadjid Bouabdallah, Hatem Bettahar, Yacine Challal =09 A Deterministic Pairwise Key Pre-distribution Scheme for Mobile Sensor=20 Networks David Sanchez, Heribert Baldus =09 A Practical Study of Transitory Master Key Establishment For Wireless=20 Sensor Networks Jing Deng, Carl Hartung, Richard Han, Shivakant Mishra =09 11:00 - 12:40: Full Paper Session 7: Routing Applying emergence to the design of routing protocols for the security=20 of wireless ad hoc networks, Ioannis Pavlosoglou, Mark Leeson, Roger Green SPINAT: Integrating IPsec into Overlay Routing Jukka Ylitalo, Patrik Salmela, Hannes Tschofenig On the Survivability of Routing Protocols in Ad Hoc Wireless Networks Baruch Awerbuch, Reza Curtmola, David Holmer, Cristina Nita-Rotaru, Herbert Rubens =09 An Extensible Environment for Evaluating Secure MANET, Yongguang Zhang, Yi-an Huang, Wenke Lee =09 12.40PM - 2:00PM: Lunch 2:00PM - 3:40 PM: Full Paper Session 8: Cryptographic algorithms and=20 protocols Soft-Timeout Distributed Key Generation for Digital Signature based on=20 Elliptic Curve D- log for Low-power Devices, Caimu Tang, Anthony T. Chronopoulos and Cauligi S. Raghavendra =09 A Uniform Framework for Cryptanalysis of the Bluetooth E_0 Cipher, Ophir Levy, Avishai Wool =09 MOTET: Mobile Transactions using Electronic Tickets Daniele Quercia, Stephen Hailes =09 Exploiting Hierarchical Identity-Based Encryption for Access Control to Pervasive Computing Information Urs Hengartner, Peter Steenkiste 3:40PM - 4:00 PM: Break 4:00PM - 5:40 PM: Short paper Session 2 GKE: Efficient Group-based Key Establishment for Large Sensor Networks Li Zhou,Jinfeng Ni, Chinya Ravishankar Practically Unbounded One-Way Chains for Authentication with Backward Secrecy Vishwas Patil, Luigi Mancini, Antonio Durante, Roberto Di Pietro Limitations of Key Escrow in Identity-Based Schemes in Ad Hoc Networks Katrin Hoeper, Guang Gong Enhanced 1-D Chaotic Key-Based Algorithm for Image Encryption Daniel Socek, Shujun Li, Spyros Magliveras, Borko Furht Schemes for Enhancing the Denial-of-Service Tolerance of SRTP Sachin Garg, Navjot Singh, Timothy Tsai Thor: The Hybrid Online Repository Timothy van der Horst, Kent Seamons Random IDs for preserving location privacy Stefan Schlott, Frank Kargl, Michael Weber Denial-of-Service Countermeasure with Immunization and Regulation Qin Yu, Hong Liu A Distributed Cross-Layer Intrusion Detection System for Ad Hoc Networks Yu Liu, Yang Li, Hong Man A Control Formulation of the Network Security Problem via a Risk Manageme= nt Approach Nicholas Bambos *************************************************************** Friday, Sep 9, 2005 First IEEE/CreateNet International Workshop on The Value of Security=20 through Collaboration (SECOVAL): www.secoval.org First IEEE/CreateNet International Workshop on Integration of Security=20 and Quality of Service (SecQoS): www.secqos.org *************************************************************** _______________________________________________ Securecomm-cfp mailing list Securecomm-cfp@mantis.cs.colorado.edu http://mantis.cs.colorado.edu/mailman/listinfo/securecomm-cfp _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 11 07:43:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrwhF-0003Kh-GR; Mon, 11 Jul 2005 07:43:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrwhD-0003Jh-Dd for mip6@megatron.ietf.org; Mon, 11 Jul 2005 07:43:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02792 for ; Mon, 11 Jul 2005 07:43:34 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Drx97-0002m0-Ns for mip6@ietf.org; Mon, 11 Jul 2005 08:12:31 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJG00A6KOJ4B3@szxga01-in.huawei.com> for mip6@ietf.org; Mon, 11 Jul 2005 19:42:41 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJG002WWOJ4H0@szxga01-in.huawei.com> for mip6@ietf.org; Mon, 11 Jul 2005 19:42:40 +0800 (CST) Received: from sachin1734 ([10.18.4.197]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJG008YVOQAN7@szxml01-in.huawei.com> for mip6@ietf.org; Mon, 11 Jul 2005 19:47:00 +0800 (CST) Date: Mon, 11 Jul 2005 04:38:27 -0700 From: Sachin To: mip6@ietf.org, maoshx@huawei.com, deshbandhus@huawei.com, surajs@huawei.com Message-id: <000001c5860d$0e5bc800$c504120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7BIT Cc: Subject: [Mip6] Draft on Securing Home Agent List X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sachind@huawei.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 Dear MIP6 Group We have submitted a new internet draft for securing home agent list in Mobile IPV6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-dutta-mip6-ra-00.txt Technical Summary: The home agent list is learnt by receiving the RA messages. So any rogue node on the link can send spurious RA on behalf of non existent nodes. This results in non-reachable and non-existent entries in the home agent list causing delay in getting service for a MN or not getting service at all. We are looking forward for your feedback. Thanks in advance for your kind consideration. Best Regards Mao Shanxiang , Suraj , Deshbandhu & Sachin (Authors) _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 11 09:14:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dry7M-0006KN-Sj; Mon, 11 Jul 2005 09:14:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dry7L-0006IG-N5 for mip6@megatron.ietf.org; Mon, 11 Jul 2005 09:14:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08730 for ; Mon, 11 Jul 2005 09:14:38 -0400 (EDT) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DryZL-0006Ph-4N for mip6@ietf.org; Mon, 11 Jul 2005 09:43:36 -0400 Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJG00IP4SS09H@mailout3.samsung.com> for mip6@ietf.org; Mon, 11 Jul 2005 22:14:24 +0900 (KST) Received: from srkrishnan ([107.108.71.58]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IJG00JS1SRVP5@mmp2.samsung.com> for mip6@ietf.org; Mon, 11 Jul 2005 22:14:24 +0900 (KST) Date: Mon, 11 Jul 2005 18:40:55 +0530 From: "Radhakrishnan.S" Subject: Re: [Mip6] Draft on Securing Home Agent List To: sachind@huawei.com, mip6@ietf.org, maoshx@huawei.com, deshbandhus@huawei.com, surajs@huawei.com Message-id: <025b01c58619$fbdbaf30$3a476c6b@sisodomain.com> Organization: Samsung India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <000001c5860d$0e5bc800$c504120a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7BIT Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Radhakrishnan.S" List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi, This draft has brought out an interesting problem. SEND could help solve this problem. So why this method?????? Anyway, i am posting few comments i have: (1) I feel the use of STALE and REACHABLE in places referring to states in both HA List and NCE is little confusing. Maybe use of different words like VALID/INVALID to indicate state of an entry in HA List would be better. (2) Sec 3.1 " o If the entry exists and it state is STALE then simply ignore this RA message." -> Only if RA parameters are identically same with prev one, isnt it? (3) In section 3.1 -> What about RAs with global address as source address???? (4) In section 3.4 " o In case the DHAAD reply message becomes more then PMTU then HA must include self Home Agent address. This will ensure at least one valid reachable home agent address" -> Very good thought. I feel making it mandatory for the HA to carry its address in HA list in DHAAD reply irrespective of message size will guarantee atleast one valid reachable HA. :-) (5) What happens in case of a node replying with bogus NA when HA sends NS??? SEND can help in such a case. maybe security considerations section needs to be updated for such a scenario. (6) There are grammatical errors at quite few places and missing punctuations. Regards Radhakrishnan ----- Original Message ----- From: "Sachin" To: ; ; ; Sent: Monday, July 11, 2005 5:08 PM Subject: [Mip6] Draft on Securing Home Agent List > Dear MIP6 Group > > We have submitted a new internet draft for securing home agent list in > Mobile IPV6. A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-dutta-mip6-ra-00.txt > > Technical Summary: > The home agent list is learnt by receiving the RA messages. So > any rogue node on the link can send spurious RA on behalf of non > existent nodes. This results in non-reachable and non-existent entries > in the home agent list causing delay in getting service for a MN or not > getting service at all. > > We are looking forward for your feedback. Thanks in advance for your > kind consideration. > > Best Regards > > Mao Shanxiang , Suraj , Deshbandhu & Sachin > (Authors) > > > _______________________________________________ > 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 Jul 11 09:46:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrycD-0006w4-I3; Mon, 11 Jul 2005 09:46:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DrycB-0006vt-EL for mip6@megatron.ietf.org; Mon, 11 Jul 2005 09:46:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11490 for ; Mon, 11 Jul 2005 09:46:29 -0400 (EDT) Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Drz4A-0007wW-4a for mip6@ietf.org; Mon, 11 Jul 2005 10:15:28 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 15:46:26 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Mip6] Draft on Securing Home Agent List Date: Mon, 11 Jul 2005 15:46:23 +0200 Message-ID: Thread-Topic: [Mip6] Draft on Securing Home Agent List Thread-Index: AcWGHGRJ2vfnetOlTmWuf30snFKaVwAAGs0Q From: "COMBES Jean-Michel RD-MAPS-ISS" To: "Radhakrishnan.S" , , , , , X-OriginalArrivalTime: 11 Jul 2005 13:46:26.0248 (UTC) FILETIME=[EEBDBC80:01C5861E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable Cc: 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 Hi, The problem with SEND is that it only proves the router has the rights = to be a router for some prefixes (linked to the router's certs). But here, I think, the simplest solution is to use IPsec. Hoping a HA = manager knows all his HAs, it is simple to him to set up IPsec between = them based on pre-shared keys or certs if SEND is deployed :) Regards. JMC. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 =20 > -----Message d'origine----- > De : mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] De=20 > la part de Radhakrishnan.S > Envoy=E9 : lundi 11 juillet 2005 15:11 > =C0 : sachind@huawei.com; mip6@ietf.org; maoshx@huawei.com;=20 > deshbandhus@huawei.com; surajs@huawei.com > Objet : Re: [Mip6] Draft on Securing Home Agent List >=20 > Hi, > This draft has brought out an interesting problem. SEND=20 > could help solve this problem. So why this method?????? >=20 > Anyway, i am posting few comments i have: > (1) I feel the use of STALE and REACHABLE in places referring=20 > to states in both HA List and NCE is little confusing. Maybe=20 > use of different words like VALID/INVALID to indicate state=20 > of an entry in HA List would be better. >=20 > (2) Sec 3.1 > " o If the entry exists and it state is STALE then simply ignore > this RA message." > -> Only if RA parameters are identically same with prev one, isnt it? >=20 > (3) In section 3.1 > -> What about RAs with global address as source address???? >=20 > (4) In section 3.4 > " o In case the DHAAD reply message becomes more then=20 > PMTU then HA > must include self Home Agent address. This will=20 > ensure at least > one valid reachable home agent address" > -> Very good thought. I feel making it mandatory for the HA=20 > to carry its > address in HA list in DHAAD reply irrespective of message=20 > size will guarantee atleast one valid reachable HA. :-) >=20 > (5) What happens in case of a node replying with bogus NA=20 > when HA sends NS??? SEND can help in such a case. maybe=20 > security considerations section needs to be updated for such=20 > a scenario. >=20 > (6) There are grammatical errors at quite few places and=20 > missing punctuations. >=20 > Regards > Radhakrishnan > ----- Original Message ----- > From: "Sachin" > To: ; ;=20 > ; > Sent: Monday, July 11, 2005 5:08 PM > Subject: [Mip6] Draft on Securing Home Agent List >=20 >=20 > > Dear MIP6 Group > > > > We have submitted a new internet draft for securing home=20 > agent list in=20 > > Mobile IPV6. A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-dutta-mip6-ra-00.txt > > > > Technical Summary: > > The home agent list is learnt by receiving the RA messages. So any=20 > > rogue node on the link can send spurious RA on behalf of=20 > non existent=20 > > nodes. This results in non-reachable and non-existent=20 > entries in the=20 > > home agent list causing delay in getting service for a MN or not=20 > > getting service at all. > > > > We are looking forward for your feedback. Thanks in advance=20 > for your=20 > > kind consideration. > > > > Best Regards > > > > Mao Shanxiang , Suraj , Deshbandhu & Sachin > > (Authors) > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > >=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 Mon Jul 11 10:01:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DryqS-00026t-5S; Mon, 11 Jul 2005 10:01:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DryqP-00026o-DP for mip6@megatron.ietf.org; Mon, 11 Jul 2005 10:01:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12691 for ; Mon, 11 Jul 2005 10:01:11 -0400 (EDT) Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DrzIQ-000095-5z for mip6@ietf.org; Mon, 11 Jul 2005 10:30:10 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 16:01:10 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Mip6] Draft on Securing Home Agent List Date: Mon, 11 Jul 2005 16:01:06 +0200 Message-ID: Thread-Topic: [Mip6] Draft on Securing Home Agent List Thread-Index: AcWGHGRJ2vfnetOlTmWuf30snFKaVwAAGs0QAAD50EA= From: "COMBES Jean-Michel RD-MAPS-ISS" To: "Radhakrishnan.S" , , , , , X-OriginalArrivalTime: 11 Jul 2005 14:01:10.0260 (UTC) FILETIME=[FDA74340:01C58620] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: quoted-printable Cc: 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 > But here, I think, the simplest solution is to use IPsec.=20 > Hoping a HA manager knows all his HAs, it is simple to him to=20 > set up IPsec between them based on pre-shared keys or certs=20 > if SEND is deployed :) Forget this ... I forgot that the destination address may be a multicast = address :( Regards. JMC. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 =20 > -----Message d'origine----- > De : mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] De=20 > la part de COMBES Jean-Michel RD-MAPS > Envoy=E9 : lundi 11 juillet 2005 15:46 > =C0 : Radhakrishnan.S; sachind@huawei.com; mip6@ietf.org;=20 > maoshx@huawei.com; deshbandhus@huawei.com; surajs@huawei.com > Objet : RE: [Mip6] Draft on Securing Home Agent List >=20 > Hi, >=20 > The problem with SEND is that it only proves the router has=20 > the rights to be a router for some prefixes (linked to the=20 > router's certs). > But here, I think, the simplest solution is to use IPsec.=20 > Hoping a HA manager knows all his HAs, it is simple to him to=20 > set up IPsec between them based on pre-shared keys or certs=20 > if SEND is deployed :) >=20 > Regards. >=20 > JMC. >=20 > France Telecom - R&D Division - MAPS/NSS =20 > Jean-Michel COMBES, Internet/Intranet Security > E-Mail: jeanmichel.combes@francetelecom.com > Phone: +33 (0)1 45 29 45 94 > Fax: +33 (0)1 45 29 65 19 > Mobile: +33 (0)6 07 29 30 16=20 > =20 >=20 > > -----Message d'origine----- > > De : mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]=20 > De la part=20 > > de Radhakrishnan.S Envoy=E9 : lundi 11 juillet 2005 15:11 =C0 :=20 > > sachind@huawei.com; mip6@ietf.org; maoshx@huawei.com;=20 > > deshbandhus@huawei.com; surajs@huawei.com Objet : Re:=20 > [Mip6] Draft on=20 > > Securing Home Agent List > >=20 > > Hi, > > This draft has brought out an interesting problem. SEND could=20 > > help solve this problem. So why this method?????? > >=20 > > Anyway, i am posting few comments i have: > > (1) I feel the use of STALE and REACHABLE in places referring to=20 > > states in both HA List and NCE is little confusing. Maybe use of=20 > > different words like VALID/INVALID to indicate state of an=20 > entry in HA=20 > > List would be better. > >=20 > > (2) Sec 3.1 > > " o If the entry exists and it state is STALE then=20 > simply ignore > > this RA message." > > -> Only if RA parameters are identically same with prev=20 > one, isnt it? > >=20 > > (3) In section 3.1 > > -> What about RAs with global address as source address???? > >=20 > > (4) In section 3.4 > > " o In case the DHAAD reply message becomes more then=20 > > PMTU then HA > > must include self Home Agent address. This will ensure at=20 > > least > > one valid reachable home agent address" > > -> Very good thought. I feel making it mandatory for the HA > > to carry its > > address in HA list in DHAAD reply irrespective of message size will=20 > > guarantee atleast one valid reachable HA. :-) > >=20 > > (5) What happens in case of a node replying with bogus NA when HA=20 > > sends NS??? SEND can help in such a case. maybe security=20 > > considerations section needs to be updated for such a scenario. > >=20 > > (6) There are grammatical errors at quite few places and missing=20 > > punctuations. > >=20 > > Regards > > Radhakrishnan > > ----- Original Message ----- > > From: "Sachin" > > To: ; ; ;=20 > > > > Sent: Monday, July 11, 2005 5:08 PM > > Subject: [Mip6] Draft on Securing Home Agent List > >=20 > >=20 > > > Dear MIP6 Group > > > > > > We have submitted a new internet draft for securing home > > agent list in > > > Mobile IPV6. A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-dutta-mip6-ra-00.txt > > > > > > Technical Summary: > > > The home agent list is learnt by receiving the RA=20 > messages. So any=20 > > > rogue node on the link can send spurious RA on behalf of > > non existent > > > nodes. This results in non-reachable and non-existent > > entries in the > > > home agent list causing delay in getting service for a MN or not=20 > > > getting service at all. > > > > > > We are looking forward for your feedback. Thanks in advance > > for your > > > kind consideration. > > > > > > Best Regards > > > > > > Mao Shanxiang , Suraj , Deshbandhu & Sachin > > > (Authors) > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > >=20 > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=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 Mon Jul 11 17:16:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5db-00025T-MV; Mon, 11 Jul 2005 17:16:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5da-00025K-4b for mip6@megatron.ietf.org; Mon, 11 Jul 2005 17:16:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17121 for ; Mon, 11 Jul 2005 17:16:23 -0400 (EDT) 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.43) id 1Ds65e-0001Un-IA for mip6@ietf.org; Mon, 11 Jul 2005 17:45:27 -0400 Message-ID: <019c01c5865d$ca4b9a40$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , , , , References: <000001c5860d$0e5bc800$c504120a@china.huawei.com> Subject: Re: [Mip6] Draft on Securing Home Agent List Date: Mon, 11 Jul 2005 14:16:23 -0700 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: 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 So if the Home Agent list is built up from RAs, why can't RFC 3791 be used for security? jak ----- Original Message ----- From: "Sachin" To: ; ; ; Sent: Monday, July 11, 2005 4:38 AM Subject: [Mip6] Draft on Securing Home Agent List > Dear MIP6 Group > > We have submitted a new internet draft for securing home agent list in > Mobile IPV6. A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-dutta-mip6-ra-00.txt > > Technical Summary: > The home agent list is learnt by receiving the RA messages. So > any rogue node on the link can send spurious RA on behalf of non > existent nodes. This results in non-reachable and non-existent entries > in the home agent list causing delay in getting service for a MN or not > getting service at all. > > We are looking forward for your feedback. Thanks in advance for your > kind consideration. > > Best Regards > > Mao Shanxiang , Suraj , Deshbandhu & Sachin > (Authors) > > > _______________________________________________ > 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 Jul 11 17:21:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5iK-0003C6-Tm; Mon, 11 Jul 2005 17:21:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds5iI-0003Bx-N5 for mip6@megatron.ietf.org; Mon, 11 Jul 2005 17:21:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17438 for ; Mon, 11 Jul 2005 17:21:16 -0400 (EDT) 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.43) id 1Ds6AN-0001gR-7w for mip6@ietf.org; Mon, 11 Jul 2005 17:50:19 -0400 Message-ID: <01b001c5865e$78a89890$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "COMBES Jean-Michel RD-MAPS-ISS" , "Radhakrishnan.S" , , , , , References: Subject: Re: [Mip6] Draft on Securing Home Agent List Date: Mon, 11 Jul 2005 14:21:15 -0700 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: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable Cc: 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 SEND proves its a router, the IPsec SA establishment procedure requires t= he HA to present a cert that the host must verify. So there's a filter at bo= th phases. That said, I don't think RFC 3775 requires the HA's cert to be annotated with an attribute saying that it is authorized to act as a home agent. SE= ND does allow the router cert to be so attributed (specifically with a list = of prefixes that the router is authorized to route) but it does not require that. jak ----- Original Message ----- From: "COMBES Jean-Michel RD-MAPS-ISS" To: "Radhakrishnan.S" ; ; ; ; ; Sent: Monday, July 11, 2005 6:46 AM Subject: RE: [Mip6] Draft on Securing Home Agent List Hi, The problem with SEND is that it only proves the router has the rights to= be a router for some prefixes (linked to the router's certs). But here, I think, the simplest solution is to use IPsec. Hoping a HA manager knows all his HAs, it is simple to him to set up IPsec between th= em based on pre-shared keys or certs if SEND is deployed :) Regards. JMC. France Telecom - R&D Division - MAPS/NSS Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16 > -----Message d'origine----- > De : mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] De > la part de Radhakrishnan.S > Envoy=E9 : lundi 11 juillet 2005 15:11 > =C0 : sachind@huawei.com; mip6@ietf.org; maoshx@huawei.com; > deshbandhus@huawei.com; surajs@huawei.com > Objet : Re: [Mip6] Draft on Securing Home Agent List > > Hi, > This draft has brought out an interesting problem. SEND > could help solve this problem. So why this method?????? > > Anyway, i am posting few comments i have: > (1) I feel the use of STALE and REACHABLE in places referring > to states in both HA List and NCE is little confusing. Maybe > use of different words like VALID/INVALID to indicate state > of an entry in HA List would be better. > > (2) Sec 3.1 > " o If the entry exists and it state is STALE then simply ignore > this RA message." > -> Only if RA parameters are identically same with prev one, isnt it? > > (3) In section 3.1 > -> What about RAs with global address as source address???? > > (4) In section 3.4 > " o In case the DHAAD reply message becomes more then > PMTU then HA > must include self Home Agent address. This will > ensure at least > one valid reachable home agent address" > -> Very good thought. I feel making it mandatory for the HA > to carry its > address in HA list in DHAAD reply irrespective of message > size will guarantee atleast one valid reachable HA. :-) > > (5) What happens in case of a node replying with bogus NA > when HA sends NS??? SEND can help in such a case. maybe > security considerations section needs to be updated for such > a scenario. > > (6) There are grammatical errors at quite few places and > missing punctuations. > > Regards > Radhakrishnan > ----- Original Message ----- > From: "Sachin" > To: ; ; > ; > Sent: Monday, July 11, 2005 5:08 PM > Subject: [Mip6] Draft on Securing Home Agent List > > > > Dear MIP6 Group > > > > We have submitted a new internet draft for securing home > agent list in > > Mobile IPV6. A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-dutta-mip6-ra-00.txt > > > > Technical Summary: > > The home agent list is learnt by receiving the RA messages. So any > > rogue node on the link can send spurious RA on behalf of > non existent > > nodes. This results in non-reachable and non-existent > entries in the > > home agent list causing delay in getting service for a MN or not > > getting service at all. > > > > We are looking forward for your feedback. Thanks in advance > for your > > kind consideration. > > > > Best Regards > > > > Mao Shanxiang , Suraj , Deshbandhu & Sachin > > (Authors) > > > > > > _______________________________________________ > > 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 Jul 11 18:33:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6pj-0003gv-M4; Mon, 11 Jul 2005 18:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds6pi-0003fF-J4; Mon, 11 Jul 2005 18:33:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27059; Mon, 11 Jul 2005 18:32:59 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ds7Hn-0005QE-4w; Mon, 11 Jul 2005 19:02:04 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6BM1Kn24594; Mon, 11 Jul 2005 15:01:20 -0700 X-mProtect: <200507112201> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14166.americas.nokia.com (172.18.141.66, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdnmdxxb; Mon, 11 Jul 2005 15:01:16 PDT Message-ID: <42D2F384.6050107@iprg.nokia.com> Date: Mon, 11 Jul 2005 15:32:36 -0700 From: Rajeev Koodli 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: mobopts@irtf.org, mip6@ietf.org Content-Type: multipart/mixed; boundary="------------040308060001000300010107" X-Spam-Score: 2.4 (++) X-Scan-Signature: 64b72a8e61417554b4b727cb14e7034d Cc: Subject: [Mip6] [Fwd: FW: resubmit draft-irtf-mobopts-location-privacy-ps-00.txt with revised boilerplate] 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 This is a multi-part message in MIME format. --------------040308060001000300010107 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello folks, I submitted the draft on Friday, I believe with the correct boilerplate (see attached draft). I still got an error message. Anyway, please find the Location Privacy Problem Statement draft. Regards, -Rajeev > -----Original Message----- > From: Koodli Rajeev (Nokia-NRC/MtView) > Sent: Friday, July 08, 2005 7:42 PM > To: 'internet-drafts@ietf.org' > Subject: resubmit draft-irtf-mobopts-location-privacy-ps-00.txt with revised boilerplate > > > Here it is.. > > Thanks, > > -Rajeev Koodli > > > <> > > http://people.nokia.net/~rajeev > --------------040308060001000300010107 Content-Type: text/plain; name="draft-irtf-mobopts-location-privacy-ps-00.txt" Content-Disposition: inline; filename="draft-irtf-mobopts-location-privacy-ps-00.txt" Content-Transfer-Encoding: 7bit MobOpts Research Group Rajeev Koodli INTERNET DRAFT Nokia Research Center 11 July 2005 IP Address Location Privacy and Mobile IPv6: Problem Statement draft-irtf-mobopts-location-privacy-ps-00.txt By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is a submission of the IRTF MobOpts RG. Comments should be directed to the MobOpts RG mailing list, mobopts@irtf.org. Abstract In this document, we discuss Location Privacy as applicable to Mobile IPv6. We document the concerns arising from revealing Home Address to an on-looker and from disclosing Care of Address to a correspondent. Koodli Expires 11 January 2005 [Page i] Internet Draft IP Location Privacy Problem 11 July 2005 Contents Abstract i 1. Introduction 1 2. Problem Definition 2 2.1. Disclosing the Care of Address . . . . . . . . . . . . . 2 2.2. Revealing the Home Address . . . . . . . . . . . . . . . 2 3. Problem Illustration 3 4. Conclusion 4 5. IANA Considerations 5 6. Security Considerations 5 7. Acknowledgment 5 A. Background 5 Intellectual Property Statement 6 Disclaimer of Validity 6 Copyright Statement 6 Acknowledgment 7 1. Introduction The problems of location privacy, and privacy when using IP for communication have become important. IP privacy is broadly concerned with protecting user communication from unwittingly revealing information that could be used to analyze and gather sensitive user data. Examples include gathering data at certain vantage points, collecting information related to specific traffic, and monitoring (perhaps) certain populations of users for activity during specific times of the day, etc. In this document, we refer to this as the "profiling" problem. Location privacy is concerned with the problem of revealing user roaming. A constant identifier with global scope can reveal that a user has roamed. The globally visible identifier could be a user Koodli Expires 11 January 2005 [Page 1] Internet Draft IP Location Privacy Problem 11 July 2005 identifier or a device identifier, and sometimes a binding between the two may also be available, e.g., through DNS. This problem is particularly applicable to Mobile IP where the Home Address on a visited network can reveal device roaming and, together with a user identifier (such as an NAI), can reveal user roaming. When roaming is revealed, it could lead to more targetted profiling. Even when the binding between user identifier and the Home Address is unavailable, freely available tools on the Internet can map the Home Address to the owner of the Home Prefix, which can reveal that a user from a particular ISP has roamed. So, the location privacy problem is a subset of the profiling problem in which revealing a globally visible identifier compromises a user's location privacy. In addition, a user may not wish to reveal roaming to correspondent(s). In Mobile IP, this translates to the use of Care of Address. In this document, the concerns arising from the use of a globally visible identifier, such as a Home Address, when roaming outside the home network are described. Similarly, the concerns from revealing a Care of Address to a correspondent are also outlined. The solutions to these problems are meant to be specified in a separate document. This document is only concerned with IP Address Location Privacy in the presence of IP Mobility, as applied to Mobile IPv6. It does not address the overall profiling problem. Specifically, it does not concern itself with MAC addresses. Some other work may address the problem of profiling IP and MAC identifiers (see for instance [1]). 2. Problem Definition 2.1. Disclosing the Care of Address When a Mobile IP MN roams from its home network to a visited network, use of Care of Address in communication with a correspondent reveals that the MN has roamed. The assumption here is that the correspondent somehow knows the Home Address of the MN. For instance, a correspondent may obtain it from DNS, which may contain the Home Address or the IP address of an agent to which the user identifier (such as a SIP URI) is mapped to. 2.2. Revealing the Home Address When a Mobile IP MN roams from its home network to a visited network, use of Home Address in communication with a correspondent reveals to an on-looker that the MN has roamed. When a binding of Home Address to a user identifier (such as a SIP URI or NAI) is available, the Home Address can be used to also determine that the user has roamed. This problem is independent of whether the MN uses Care of Address to communicate directly with the correspondent (i.e., uses route Koodli Expires 11 January 2005 [Page 2] Internet Draft IP Location Privacy Problem 11 July 2005 optimization), or the MN communicates via the Home Agent (i.e., uses reverse tunneling). 3. Problem Illustration This section is intended to provide the overall scope under which the above problems are applicable. Consider a Mobile Node at its home network. Whenever it is involved in IP communication, its correspondents can see an IP address valid on the home network. Elaborating further, the users involved in peer - peer communication are likely to see a user-friendly identifier such as a SIP URI, and the communication end-points in the IP stack will see IP addresses. Users uninterested in or unaware of IP communication details will not see any difference when the MN acquires a new IP address. Of course any user can ``tcpdump'' or ``ethereal'' a session, capture IP packets and map the MN's IP address to an approximate geo-location. When this mapping reveals a ``home location'' of the user, the correspondent can conclude that the user has not roamed. Assessing the physical location based on IP addresses is similar to assessing the geographical location based on the area-code of a telephone number. The granularity of the physical area corresponding to an IP address can vary depending on how sophisticated the available tools are, how often an ISP conducts its network re-numbering, etc. Now consider that the MN roams to a new IP network, acquires a Care of Address and would like to communicate with its correspondents. It can either communicate directly or reverse tunnel its packets through the Home Agent. Using reverse tunneling does not reveal the new IP address of the MN, although performance may vary depending on the particular scenario. In some instances, the performance difference could be noticeable enough to serve as a hint to the correspondent. With those correspondents with which it can disclose its new IP address ``on the wire'', the MN has the option of using route-optimized communication. The transport protocol still sees the Home Address with route optimization. Unless the correspondent runs some packet capturing utility, the user cannot see which mode (reverse tunneling or route optimization) is being used, but knows that it is communicating with the same peer whose URI it knows. This is similar to conversing with a roaming cellphone user whose phone number, like the URI, remains unchanged. Let us consider the roaming mobile node again. Regardless of whether it uses route optimization or reverse tunneling, its Home Address is revealed in data packets. When equipped with an ability to inspect packets ``on the wire'', an on-looker can determine that the MN has roamed and could possibly also determine that the user has roamed. Koodli Expires 11 January 2005 [Page 3] Internet Draft IP Location Privacy Problem 11 July 2005 This could compromise the location privacy even if the MN took steps to hide its roaming information from a correspondent. The above description is valid regardless of whether a Home Address is static or is dynamically allocated. In either case, the mapping of IP address to geo-location will most likely yield results with the same level of granularity. With the freely available tools on the Internet, this granularity is the physical address of the ISP or the organization which registers ownership of a prefix chunk. Since an ISP or an organization is not, rightly, required to provide a blue-print of its subnets, the granularity remains fairly coarse for a mobile wireless network. However, sophisticated attackers might be able to conduct site mapping and obtain more fine-grained subnet information. A compromise in location privacy could lead to more targetted profiling of user data. An eavesdropper may specifically track the traffic containing the Home Address, and monitor the movement of the Mobile Node with changing Care of Address. The profiling problem is not specific to Mobile IPv6, but could be triggered by a compromise in location privacy due to revealing the Home Address. A correspondent may take advantage of the knowledge that a user has roamed when Care of Address is revealed, and modulate actions based on such a knowledge. Such an information could cause concern to a mobile user especially when the correspondent turns out be untrustworthy. Finally, it is also worthwhile to note that both the Home Address and the Care of Address could be subject to profiling, just as any other user traffic. However, applying existing techniques to thwart profiling may have implications to Mobile IPv6 signaling performance. For instance, changing the Care of Address often would cause additional Return Routability and binding management signaling. And, changing the Home Address often has implications on IPSec security association management. These issues need to be addressed in the solutions. 4. Conclusion In this document, we have formulated the IP Location Privacy problem in the presence of Mobile IPv6. The problem can be summarized as follows: disclosing Care of Address to a correspondent and revealing Home Address to an on-looker can compromise the location privacy of a Mobile Node, and hence that of a user. Solutions to this problem are expected to specifically address the use of Mobile IPv6 addresses, and not other identifiers (such as MAC addresses). Koodli Expires 11 January 2005 [Page 4] Internet Draft IP Location Privacy Problem 11 July 2005 5. IANA Considerations There are no IANA considerations introduced by this draft. 6. Security Considerations This document discusses location privacy because of IP mobility. Solutions to provide location privacy, especially any signaling over the Internet, must be secure in order to be effective. Individual solutions must describe the security implications. 7. Acknowledgment James Kempf and Qiu Ying reviewed an earlier version and provided feedback. References [1] W. Haddad and et al. Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement (work in progress). Internet Draft, Internet Engineering Task Force, October 2004. [2] J. Polk, J. Schnizlein, and M. Linsner. DHCP Option for Coordinate-based Location Configuration Information. Request for Comments 3825, Internet Engineering Task Force, July 2004. A. Background The location privacy topic is broad and often has different connotations. It also spans multiple layers in the OSI reference model. Besides, there are attributes beyond an IP address alone that can reveal hints about location. For instance, even if a correspondent is communicating with the same end-point it is used to, the ``time of the day'' attribute can reveal a hint to the user. Some roaming cellphone users may have noticed that their SMS messages carry a timestamp of their ``home network'' timezone (for location privacy or otherwise) which can reveal that the user is in a different timezone when messages are sent during ``normal'' time of the day. Furthermore, tools exist on the Internet which can map an IP address to the physical address of an ISP or the organization which owns the prefix chunk. Taking this to another step, with in-built GPS receivers on IP hosts, applications can be devised to map geo-locations to IP network information. Even without GPS receivers, geo-location can also be obtained in environments where [Geopriv] is supported, for instance as a DHCP option [2]. Koodli Expires 11 January 2005 [Page 5] Internet Draft IP Location Privacy Problem 11 July 2005 In summary, a user's physical location can be determined or guessed with some certainty and with varying levels of granularity by different means even though IP addresses themselves do not inherently provide any geo-location information. It is perhaps useful to bear this broad scope in mind as the problem of IP address location privacy in the presence of IP Mobility is addressed. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Koodli Expires 11 January 2005 [Page 6] Internet Draft IP Location Privacy Problem 11 July 2005 Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Koodli Expires 11 January 2005 [Page 7] --------------040308060001000300010107 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------040308060001000300010107-- From mip6-bounces@ietf.org Mon Jul 11 23:50:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsBn5-0003h8-7n; Mon, 11 Jul 2005 23:50:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsBn3-0003gy-CT for mip6@megatron.ietf.org; Mon, 11 Jul 2005 23:50:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22454 for ; Mon, 11 Jul 2005 23:50:34 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsCFB-0000Yo-D7 for mip6@ietf.org; Tue, 12 Jul 2005 00:19:41 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 248B28004AD; Tue, 12 Jul 2005 06:50:23 +0300 (EEST) Date: Tue, 12 Jul 2005 06:50:23 +0300 (EEST) From: Wassim Haddad To: Rajeev Koodli Subject: Re: [Mip6] [Fwd: FW: resubmit draft-irtf-mobopts-location-privacy-ps-00.txt with revised boilerplate] In-Reply-To: <42D2F384.6050107@iprg.nokia.com> Message-ID: References: <42D2F384.6050107@iprg.nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 2.4 (++) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: mip6@ietf.org, mobopts@irtf.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 Hi Rajeev, Thanks for writing this draft. I just want to add that tracing the BU messages via the sequence number can also reveal in real time to an eavesdropper the path taken by an unknown mobile node, i.e., by linking the BU messages and consequently the pseudo-IP addresses. However, the ability to follow the movements in real time, combined with some prior infos about one particular target can lead to break the user's anonymity. IMHO, it makes sense to add such scenario in the problem statement. We have addressed this particular issue in our "anonymity and unlinkability solution for omipv6" (draft-haddad-privacy-omipv6-anonymity-00). Regards, Wassim H. On Mon, 11 Jul 2005, Rajeev Koodli wrote: > > Hello folks, > > I submitted the draft on Friday, I believe with the correct boilerplate > (see attached draft). I still got an error message. > > Anyway, please find the Location Privacy Problem Statement draft. > > Regards, > > -Rajeev > > > > -----Original Message----- > > > From: Koodli Rajeev (Nokia-NRC/MtView) > > Sent: Friday, July 08, 2005 7:42 PM > > To: 'internet-drafts@ietf.org' > > Subject: resubmit draft-irtf-mobopts-location-privacy-ps-00.txt with revised boilerplate > > > > > > Here it is.. > > > > Thanks, > > > > -Rajeev Koodli > > > > > <> > > > > http://people.nokia.net/~rajeev > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 12 00:16:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsCBu-00047v-VF; Tue, 12 Jul 2005 00:16:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsCBo-00043T-Cp for mip6@megatron.ietf.org; Tue, 12 Jul 2005 00:16:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23772 for ; Tue, 12 Jul 2005 00:16:06 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsCds-0001DM-Th for mip6@ietf.org; Tue, 12 Jul 2005 00:45:14 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJH00H3TYGXBT@mailout2.samsung.com> for mip6@ietf.org; Tue, 12 Jul 2005 13:14:57 +0900 (KST) Received: from srkrishnan ([107.108.71.58]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IJH00I7IYGTXF@mmp1.samsung.com> for mip6@ietf.org; Tue, 12 Jul 2005 13:14:57 +0900 (KST) Date: Tue, 12 Jul 2005 09:41:28 +0530 From: "Radhakrishnan.S" Subject: Re: [Mip6] Draft on Securing Home Agent List To: James Kempf , sachind@huawei.com, mip6@ietf.org, maoshx@huawei.com, deshbandhus@huawei.com, surajs@huawei.com Message-id: <02c101c58697$c91bc070$3a476c6b@sisodomain.com> Organization: Samsung India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <000001c5860d$0e5bc800$c504120a@china.huawei.com> <019c01c5865d$ca4b9a40$016115ac@dcml.docomolabsusa.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7BIT Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Radhakrishnan.S" List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Jak, you mean RFC 3971???? ----- Original Message ----- From: "James Kempf" To: ; ; ; ; Sent: Tuesday, July 12, 2005 2:46 AM Subject: Re: [Mip6] Draft on Securing Home Agent List > So if the Home Agent list is built up from RAs, why can't RFC 3791 be > used > for security? > > jak > > ----- Original Message ----- > From: "Sachin" > To: ; ; ; > > Sent: Monday, July 11, 2005 4:38 AM > Subject: [Mip6] Draft on Securing Home Agent List > > >> Dear MIP6 Group >> >> We have submitted a new internet draft for securing home agent list in >> Mobile IPV6. A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-dutta-mip6-ra-00.txt >> >> Technical Summary: >> The home agent list is learnt by receiving the RA messages. So >> any rogue node on the link can send spurious RA on behalf of non >> existent nodes. This results in non-reachable and non-existent entries >> in the home agent list causing delay in getting service for a MN or not >> getting service at all. >> >> We are looking forward for your feedback. Thanks in advance for your >> kind consideration. >> >> Best Regards >> >> Mao Shanxiang , Suraj , Deshbandhu & Sachin >> (Authors) >> >> >> _______________________________________________ >> 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 Tue Jul 12 08:40:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsK3Q-0003nT-U7; Tue, 12 Jul 2005 08:40:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsK3P-0003mm-1q for mip6@megatron.ietf.org; Tue, 12 Jul 2005 08:40:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17357 for ; Tue, 12 Jul 2005 08:40:01 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsKVZ-0002M7-TR for mip6@ietf.org; Tue, 12 Jul 2005 09:09:11 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IJI00F08L7Z9Z@dns2.cselt.it> for mip6@ietf.org; Tue, 12 Jul 2005 14:26:24 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 12 Jul 2005 14:38:17 +0200 Date: Tue, 12 Jul 2005 14:39:48 +0200 From: Gerardo Giaretta Subject: RE: [Mip6] Bootstrapping DT solution draft To: Rafa Marin Lopez Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Bootstrapping DT solution draft thread-index: AcWBVRIk8N91BfPPSQmuMUSQtJ5jQAAp4TTA Content-Class: urn:content-classes:message X-OriginalArrivalTime: 12 Jul 2005 12:38:17.0125 (UTC) FILETIME=[93D8D550:01C586DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: a83e8b750067501be8b56bf02fb6582d 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 Hi Rafa, thank you very much for your detailed review and sorry for my late response. Please see my comments inline. >=20 > Hi Gerardo, DT members >=20 > Firstly, i would like to thank you about this so expected work. >=20 > Following, please see inline my comments... >=20 > >=20 > > > > 3. Split scenario > > In the problem statement draft [4] there is a clear assumption that=20 > > mobility service and network access service can be separate. This=20 > > assumption implies that mobility service and network access service=20 > > may be authorized by different entities. As an example, the service=20 > > model defined in [4] allows an enterprise network to deploy a Home=20 > > Agent and offer Mobile IPv6 service to a user, even if the user is=20 > > accessing the Internet independent of its enterprise=20 > account (e.g., by=20 > > using his personal WiFi hotspot account at a coffee shop). > > Therefore, in this document it is assumed that network access and=20 > > mobility service are authorized by different entities, which means=20 > > that authentication and authorization for mobility service=20 > and network=20 > > access will be considered separately. This scenario is called split=20 > > scenario. > > > > > > Moreover, the model defined in [4] separates the entity=20 > providing the=20 > > service from the entity that authenticates and authorizes the user.=20 > > This is similar to the roaming model for network access. > > > $Rafa> I was wondering what is the role of MSP AAA server in=20 > the roaming > scenario. For example considering following example: >=20 > MN <---------IKEv2(EAP)------------>HA<------Diameter(EAP) -------> > MSA's AAA server >=20 > HA can request a redirect agent to contact directly with MSA's AAA > server (at least this policy is being followed with network=20 > access service > as far as I know). So what is the role of MSP's AAA server?? only AAA > routing?? >=20 AAA server is involved in AAA routing. But, as you mention below, it should have an active role also in the authorization step, since the usage of the HA in the MSP may need to be explicetly authorized by the MSP itself.=20 > Another related question is about authorization. Under my=20 > point of view > , MSP's AAA server is the entity that finally takes decision about if > the mobility service is authorized or not. MSA's AAA server could send > to MSP's AAA some kind of evidences or attributes related with > authenticated user.Following these attributes and internal policies > MSP's AAA server takes a final decision. >=20 I tend to agree. This is the reason why AAA server of the MSP should be involved. I think that these issues should be covered by draft-mip6-aaa-ha-goals. As you know, in this DT draft, we have not spcified the backend communitcation between HA and AAA infrastructure since we consider it out of the scope of the DT. > In particular , I was thinking a similar model than it is shown in > Diameter EAP application I-D (Scenario 3: Direct EAP,=20 > authorization via > agents). >=20 > Note this dicussion could be also valid for other services=20 > (i.e. network > access service). >=20 I tend to agree also here. The MSP might need to add some authorization AVPs. But, again, I think this is out of the scope of this draft. These issues will be considered when we'll discuss the AAA backend protocol specification. > > Therefore, in the split scenario, two different cases can be=20 > > identified depending on the relationship between the entity that=20 > > provides the mobility service (i.e. Mobility Service Provider, MSP)=20 > > and the entity that authenticates and authorizes the user (i.e.=20 > > Mobility Service Authorizer, MSA). > > Figure 1 depicts the split scenario when the MSP and the=20 > MSA are the=20 > > same entity. This means that the network operator that provides the=20 > > Home Agent authenticates and authorizes the user for=20 > mobility service. >=20 >=20 > $Rafa> During text, you also consider PKI as backend infrastructure. > Maybe it should appear in the figure 1 not only AAA. >=20 Yes, you are right. I'll add it as a possible choice. > > > > Mobility Service Provider and Authorizer=20 > > +-------------------------------------------+ | | | +-------------+=20 > > +--+ | | | MSA/MSP AAA | <-------------> |HA| | | | server | AAA=20 > > protocol +--+ | | +-------------+ | | |=20 > > +-------------------------------------------+ +--+ |MN|=20 > +--+ Figure 1=20 > > - Split Scenario (MSA =3D=3D MSP) G. Giaretta, Ed. Expires December = 22,=20 > > 2005 [Page 6] > > > > > > > > > >=20 > > 4. Components of the solution > > The bootstrapping problem is composed of different=20 > sub-problems that=20 > > can be solved independently in a modular way. The components=20 > > identified and a brief overview of their solution follow. > > o HA address discovery. The Mobile Node needs to discover=20 > the address=20 > > of its Home Agent. The main objective of a bootstrapping=20 > solution is=20 > > to minimize the data pre-configured on the Mobile Node. For this=20 > > reason, the DHAAD defined in [2] may not be applicable in real=20 > > deployments since it is required that the Mobile Node is=20 > > pre-configured with the home network prefix and it does not=20 > allow an=20 > > operator to load balance by having Mobile Nodes dynamically=20 > assigned=20 > > to Home Agents located in different subnets. This document=20 > defines a=20 > > solution for Home Agent address discovery that is based on=20 > Domain Name=20 > > Service (DNS), introducing a new DNS SRV record [5]. > > > > The unique information that needs to be pre- > > configured on the Mobile Node is the domain name of the MSP. > > > >=20 > > o IPsec Security Associations setup. MIPv6 requires that a=20 > Mobile Node=20 > > and its Home Agent share an IPsec SA in order to protect binding=20 > > updates and other MIPv6 signaling. This document provides a=20 > solution=20 > > that is based on IKEv2 and follows what is specified in=20 > [6]. The IKEv2=20 > > peer authentication can be performed both using=20 > certificates and using=20 > > EAP, depending on the network operator's deployment model. > > o HoA assignment. The Mobile Node needs to know its Home Address in=20 > > order to bootstrap Mobile IPv6 operation. The Home Address=20 > is assigned=20 > > by the Home Agent during the IKEv2 exchange (as described=20 > in [6]). The=20 > > solution defined in this draft also allows the Mobile Node to=20 > > auto-configure its Home Address based on stateless auto- > > configuration ([20]), Cryptographically Generated Addresses=20 > ([9]) or=20 > > privacy addresses ([10]). > > o Authentication and Authorization with MSA. The user must be=20 > > authenticated in order for the MSA to grant the service. >=20 >=20 > <$Rafa> Here appears "MSA to grant the service" and in page=20 > 10 section=20 > 5.1.1 > "MSP granting the mobility service". Would it not be in the first case > "MSP to grant the service" too? >=20 Yes. What about the following text? " Authentication and Authorization with MSA. The user must be authenticated in order for the MSP to grant the service. Since the user credentials can be verified only by the MSA, this authorization step is performed by the MSA. Moreover, the mobility service must be explicitly authorized by the MSA based on the user's profile. These operations are performed in different ways depending on the credentials used by the Mobile Node during the IKEv2 peer authentication and on the backend infrastructure (PKI or AAA).=20 " > >=20 > > > > 5. Protocol Operations > > This section describes in detail the procedures needed to perform=20 > > Mobile IPv6 bootstrapping based on the components identified in the=20 > > previous section. > > > > 5.1. Home Agent Address Discovery > > Once a Mobile Node has obtained network access, it can=20 > perform Mobile=20 > > IPv6 bootstrapping. For this purpose, the Mobile Node=20 > queries the DNS=20 > > server to request information on Home Agent service. As mentioned=20 > > before in the document, the only information that needs to be auto- > > configured >=20 >=20 > <$Rafa> autoconfigured---> pre-configured?? >=20 fixed. > > on the Mobile Node is the domain name of the Mobility=20 > Service Provider. > > The Mobile Node needs to obtain the IP address of the DNS server=20 > > before it can send a DNS request. This can be pre-configured on the=20 > > Mobile Node or obtained through DHCPv6 from the visited=20 > link [11]. In=20 > > any case, it is assumed that there is some kind of=20 > mechanism by which=20 > > the Mobile Node is configured with a DNS server since a DNS=20 > server is=20 > > needed for many other reasons. > > Two options for DNS lookup for a Home Agent address are=20 > identified in=20 > > this document: DNS lookup by Home Agent Name and DNS lookup=20 > by service=20 > > name. > > While this document specifies a Home Agent Address=20 > Discovery solution=20 > > based on DNS, when the ASP and the MSP are the same entity=20 > DHCP may be=20 > > used. See [15] for details. > > > >=20 > > > > 5.4. Authorization and Authentication with MSA > > In a scenario where the Home Agent is discovered dynamically by the=20 > > Mobile Node, it is very likely that the Home Agent is not able to=20 > > verify by its own the credentials provided by the Mobile=20 > Node during=20 > > the IKEv2 exchange. Moreover, the mobility service needs to be=20 > > explicitly authorized based on the user's profile. >=20 >=20 >=20 > > As an example, the Home Agent might not be aware if the mobility=20 > > service can be granted at a particular time of the day or if the=20 > > credit of the Mobile Node is going to expire. > > > <$Rafa> In the example, could MSA know that mobility service can be or > cannot be granted at a particular time depending on internal=20 > policies in > the MSP? I guess this example considers that user's profile says that > this user cannot use the service during a particular time of the > day.However it does not consider that user has no restricction about > this time but MSP decides that mobility service cannot be=20 > granted during > a particular time of the day. Home Agent should be aware of this too. >=20 Yes. The text refers to policies that the MSA might send to the MSP based on the user's profile. However, as you mention, some policies can be also forced by the MSP. Do you think we need some text about that in the draft?=20 > > > > > > Due to all these reasons, the Home Agent may need to=20 > contact the MSA=20 > > in order to authenticate > > > > the Mobile Node and authorize mobility G. Giaretta, Ed. Expires=20 > > December 22, 2005 [Page 14] > > > > > > > > > > > > > > Internet-Draft MIPv6 bootstrapping in split scenario June 2005 > > service. This can be accomplished based on a Public Key=20 > Infrastructure=20 > > if certificates are used and a PKI > > > <$Rafa> For authorization ... are you considering attributes=20 > certificates when > PKI is used...?? >=20 How to use PKI for authorization purposes is actually a general open issue, not only in this draft. We mentioned this in the draft but I think this is more in the scoper of AAA-HA interface solution. Maybe Hannes could be more precise about that since he had some ideas during DT discussion. > > is deployed by the MSP and MSA. On the other hand, if the=20 > Mobile Node=20 > > is provided with other types of credentials, the AAA infrastructure=20 > > must be used. > > The definition of this backend communication is out of the scope of=20 > > this document. In [12] a list of goals for such a communication is=20 > > provided. > > > > > > 6. Home Address registration in the DNS > > In order that the Mobile Node is reachable through its dynamically=20 > > assigned Home Address, the DNS needs to be updated with the=20 > new Home=20 > > Address. Since applications make use of DNS lookups on FQDN=20 > to find a=20 > > node, the DNS update is essential for providing IP=20 > reachability to the=20 > > Mobile Node, which is the main purpose of the Mobile IPv6 protocol.=20 > > The need of DNS update is not discussed in RFC 3775 since=20 > it assumes=20 > > that the Mobile Node is provisioned with a static home address.=20 > > However, when a dynamic Home Address is assigned to the=20 > Mobile Node,=20 > > any existing DNS entry becomes invalid and the Mobile Node becomes=20 > > unreachable unless a DNS update is performed. > > Since the DNS update must be performed securely in order to prevent=20 > > attacks or modifications from malicious nodes, the node performing=20 > > this update must share a security association with the DNS server.=20 > > Having all possible Mobile Nodes sharing a security=20 > association with=20 > > the DNS servers of the MSP might be cumbersome from an=20 > administrative=20 > > perspective. Moreover, even if a Mobile Node has a security=20 > > association with a DNS server of its MSP, an address authorization=20 > > issue comes into the picture. A detailed analysis of=20 > possible threats=20 > > against DNS update is provided in section 9.5. > > Therefore, due to security and administrative reasons, it is=20 > > RECOMMENDED that the Home Agent perform DNS entry update for the=20 > > Mobile Node. For this purpose the Mobile Node MAY include a new=20 > > mobility option, the DNS Update option, with the flag R not=20 > set in the=20 > > Binding Update. This option is defined in section 8 and=20 > includes the=20 > > FQDN that needs to be updated. After receiving the Binding=20 > Update, the=20 > > Home Agent MUST update the DNS entry with the identifier=20 > provided by=20 > > the Mobile Node and the Home Address included in the Home Address=20 > > Option. The procedure for sending a dynamic DNS update message is=20 > > specified in [14]. The dynamic DNS update SHOULD be performed in a=20 > > secure way; for this reason, the usage of TKEY and TSEC or=20 > DNSSEC is=20 > > recommended (see section 9.5 for details). As soon as the=20 > Home Agent=20 > > has updated the DNS, it MUST send a Binding Acknowledgement=20 > message to=20 > > the Mobile Node including the DNS Update mobility option with the=20 > > correct value in the Status field (see section 8.1). > > This procedure can be performed directly by the Home Agent=20 > if the Home=20 > > Agent has a security association with the domain specified in the=20 > > Mobile Node's FQDN. > > > > > <$Rafa> Why don't MSP's AAA server could do DNS update=20 > instead of MSA's > AAA server?? >=20 It could. But I don't see a reason for that. Do you see any issue with the current solution?=20 > > On the other hand, if the Mobile Node wants to be reachable=20 > through a=20 > > FQDN that belongs to the MSA, the Home Agent and the DNS=20 > server that=20 > > must be updated belong to different administrative domain.=20 > In this G.=20 > > Giaretta, Ed. Expires December 22, 2005 [Page 16] > > > > > > > > > > > > > > Internet-Draft MIPv6 bootstrapping in split scenario June 2005 > > case the Home Agent may not share a security association=20 > with the DNS=20 > > server and the DNS entry update can be performed by the AAA=20 > server of=20 > > the MSA. In order to accomplish this, the Home Agent sends=20 > to the AAA=20 > > server the FQDN-HoA pair through the AAA protocol. This message is=20 > > proxied by the AAA infrastructure of the MSP and is received by the=20 > > AAA server of the MSA. The AAA server of the MSA perform the DNS=20 > > update based on [14]. The detailed description of the communication=20 > > between Home Agent and AAA is out of the scope of this draft. More=20 > > details are provided in [12]. > > > > > >=20 > > 9. Security Considerations > > 9.1. HA Address Discovery > > Use of DNS for address discovery carries certain security=20 > risks. DNS=20 > > transactions in the Internet are typically done without any=20 > > authentication of the DNS server by the client or of the=20 > client by the=20 > > server. There are two risks involved: > > 1) A legitimate client obtains a bogus Home Agent address=20 > from a bogus=20 > > DNS server. This is sometimes called a "pharming" attack, > > 2) An attacking client obtains a legitimate Home Agent=20 > address from a=20 > > legitimate server. > > > <$Rafa>I have a comment regarding this case 1): I think any=20 > user already > authenticated and authorized to use mobility service could launch > this attack becuase user already owns a valid certificate and=20 > therefore > a legitimate client could verify this certificate. The issue is this > user is NOT AUTHORIZED to be a Home Agent. what do you think?? >=20 I don't get your point. Which scenario are you referring to? Are you assuming only certificates is used or also AAA? > > The risk in Case 1 is mitigated because the Mobile Node is=20 > required to=20 > > conduct an IKE transaction with the Home Agent prior to=20 > performing a=20 > > Binding Update to establish Mobile IPv6 service. According to the=20 > > IKEv2 specification [7], the responder must present the=20 > initiator with=20 > > a valid certificate containing the responder's public key, and the=20 > > responder to initiator IKE_AUTH message must be protected with an=20 > > authenticator calculated using the public key in the certificate.=20 > > Thus, an attacker would have to set up both a bogus DNS=20 > server and a=20 > > bogus Home Agent, and provision the Home Agent with a=20 > certificate that=20 > > a victim Mobile Node could verify. If the Mobile Node can=20 > detect that=20 > > the certificate is not trustworthy, the attack will be=20 > foiled when the=20 > > Mobile Node attempts to set up the IKE SA. > > > > > >=20 > > > > 9.5. Dynamic DNS Update > > Mobile IPv6 bootstrapping recommends the Home Agent to update the=20 > > Mobile Node's FQDN with a dynamically assigned home address rather=20 > > than have the Mobile Node itself do it (see Section 6 above). This=20 > > choice was motivated by a concern for preventing redirection-based=20 > > flooding attacks (see draft-ietf-mip6-ro-sec [19] for more=20 > information=20 > > about redirection-based flooding attacks and the role=20 > preventing them=20 > > played in the design of Mobile IPv6 route optimization security).=20 > > Exactly as for route optimization, it is possible for a=20 > node that is=20 > > the legitimate owner of a DNS FQDN - in the sense that it has a=20 > > security association with the DNS server allowing it to perform=20 > > dynamic DNS update of its FQDN - to bind its FQDN to the=20 > address of a=20 > > victim, then redirect large volumes of traffic at the victim. The=20 > > attack may be propagated without the owner's knowledge, for=20 > example,=20 > > if the node is compromised by malware, or it may be=20 > intentional if the=20 > > node itself is the attacker. > > While it is possible to prevent redirection attacks through ingress=20 > > filtering on access routers, ISPs have little or no incentive to=20 > > deploy ingress filtering. In some cases, if an attack could=20 > result in=20 > > substantial financial gain, it is even possible that a=20 > corrupt ISP may=20 > > have an incentive not to deploy ingress filters such as has=20 > been the=20 > > case for spam. Consequently, the security for dynamic=20 > Mobile Node FQDN=20 > > update has been assigned to the Home Agent, where active network=20 > > administration and vigilant defense measures are more=20 > likely to (but=20 > > G. Giaretta, Ed. Expires December 22, 2005 [Page 25] > > > > > > > > > > > > > > Internet-Draft MIPv6 bootstrapping in split scenario June 2005 > > are not assured of) mitigating problems, and the owner of=20 > the Mobile=20 > > Node is more likely to detect a problem if it occurs. > > If a Home Agent performs dynamic DNS update on behalf of the Mobile=20 > > Node directly with the DNS server, the Home Agent MUST have=20 > a security=20 > > association of some type with the DNS server. The security=20 > association=20 > > MAY be established either using DNSSEC [16] or TSIG/TKEY=20 > [17][18]. A=20 > > security association is required even if the DNS server is=20 > in the same=20 > > administrative domain as the Home Agent. The security association=20 > > SHOULD be separate from the security associations used for other=20 > > purposes, such as AAA. > > In the case where the Mobility Service Provider is=20 > different from the=20 > > Mobility Service Authorizer, the network administrators may want to=20 > > limit the number of cross-administrative domain security=20 > associations.=20 > > If the Mobile Node's FQDN is in the Mobility Service Authorizer's=20 > > domain, since a security association for AAA signaling involved in=20 > > mobility service authorization is required in any case, the=20 > Home Agent=20 > > can send the Mobile Node's FQDN to the AAA server under the HA-AAA=20 > > server security association, >=20 >=20 > $Rafa> MSA's AAA Server?? or MSP's AAA server?? >=20 To the MSA's AAA server through the MSP's AAA server. The MSA's AAA server updates the MSA's DNS server.=20 >=20 > So far, these are my comments. >=20 Thanks again, --Gerardo > Regards. >=20 > --=20 > ------------------------------------------------------ > Rafael Marin Lopez > Faculty of Computer Science-University of Murcia > 30071 Murcia - Spain > Telf: +34968367645 e-mail: rafa@dif.um.es > ------------------------------------------------------ >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Gerardo Giaretta wrote: >=20 > > Dear WG, > > > > the bootstrapping DT has submitted a solution draft. The document > > defines how a Mobile Node can bootstrap MIPv6 operations from > > non-topological information and pre-configured security=20 > credentials. The > > solution solves the boostrapping problem when the Mobile=20 > Node's mobility > > service is authorized by a different service provider than=20 > basic network > > access (i.e. split scenario). > > > > The draft can be found at > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > ing-split- > > 00.txt. > > > > The DT is currently working on optimized solutions for integrated > > scenario (i.e. mobility service and basic network access=20 > are authorized > > by the same entity). > > > > Please read the document and provide comments. > > > > Thanks and regards, > > > > --Gerardo (DT editor) > > > > > > > > > > > > > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia=20 > > 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 > > > > > > > > >=20 >=20 >=20 >=20 > Gerardo Giaretta wrote: >=20 > >Dear WG, > > > >the bootstrapping DT has submitted a solution draft. The document > >defines how a Mobile Node can bootstrap MIPv6 operations from > >non-topological information and pre-configured security=20 > credentials. The > >solution solves the boostrapping problem when the Mobile=20 > Node's mobility > >service is authorized by a different service provider than=20 > basic network > >access (i.e. split scenario). > > > >The draft can be found at > >http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap > ping-split- > >00.txt. > > > >The DT is currently working on optimized solutions for integrated > >scenario (i.e. mobility service and basic network access are=20 > authorized > >by the same entity). > > > >Please read the document and provide comments. > > > >Thanks and regards, > > > >--Gerardo (DT editor) > > > > > > > > > > > > > > > > > >Gruppo Telecom Italia - Direzione e coordinamento di Telecom=20 > 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 > > > > > > >=20 >=20 > --=20 > ------------------------------------------------------ > Rafael Marin Lopez > Faculty of Computer Science-University of Murcia > 30071 Murcia - Spain > Telf: +34968367645 e-mail: rafa@dif.um.es > ------------------------------------------------------ >=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 Jul 12 12:59:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsO6f-0007Hp-WE; Tue, 12 Jul 2005 12:59:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsO6e-0007Hj-70 for mip6@megatron.ietf.org; Tue, 12 Jul 2005 12:59:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15953 for ; Tue, 12 Jul 2005 12:59:37 -0400 (EDT) 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.43) id 1DsOYt-0006WT-3q for mip6@ietf.org; Tue, 12 Jul 2005 13:28:51 -0400 Message-ID: <046c01c58703$15861e90$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Radhakrishnan.S" , , , , , References: <000001c5860d$0e5bc800$c504120a@china.huawei.com> <019c01c5865d$ca4b9a40$016115ac@dcml.docomolabsusa.com> <02c101c58697$c91bc070$3a476c6b@sisodomain.com> Subject: Re: [Mip6] Draft on Securing Home Agent List Date: Tue, 12 Jul 2005 09:59:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: 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 Yes, sorry. jak ----- Original Message ----- From: "Radhakrishnan.S" To: "James Kempf" ; ; ; ; ; Sent: Monday, July 11, 2005 9:11 PM Subject: Re: [Mip6] Draft on Securing Home Agent List > Jak, > you mean RFC 3971???? > > ----- Original Message ----- > From: "James Kempf" > To: ; ; ; > ; > Sent: Tuesday, July 12, 2005 2:46 AM > Subject: Re: [Mip6] Draft on Securing Home Agent List > > > > So if the Home Agent list is built up from RAs, why can't RFC 3791 be > > used > > for security? > > > > jak > > > > ----- Original Message ----- > > From: "Sachin" > > To: ; ; ; > > > > Sent: Monday, July 11, 2005 4:38 AM > > Subject: [Mip6] Draft on Securing Home Agent List > > > > > >> Dear MIP6 Group > >> > >> We have submitted a new internet draft for securing home agent list in > >> Mobile IPV6. A URL for this Internet-Draft is: > >> > >> http://www.ietf.org/internet-drafts/draft-dutta-mip6-ra-00.txt > >> > >> Technical Summary: > >> The home agent list is learnt by receiving the RA messages. So > >> any rogue node on the link can send spurious RA on behalf of non > >> existent nodes. This results in non-reachable and non-existent entries > >> in the home agent list causing delay in getting service for a MN or not > >> getting service at all. > >> > >> We are looking forward for your feedback. Thanks in advance for your > >> kind consideration. > >> > >> Best Regards > >> > >> Mao Shanxiang , Suraj , Deshbandhu & Sachin > >> (Authors) > >> > >> > >> _______________________________________________ > >> 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 Tue Jul 12 19:52:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsUYM-0007rZ-Hh; Tue, 12 Jul 2005 19:52:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsUYL-0007rU-7n for mip6@megatron.ietf.org; Tue, 12 Jul 2005 19:52:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08892 for ; Tue, 12 Jul 2005 19:52:38 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsV0b-0004ud-Tu for mip6@ietf.org; Tue, 12 Jul 2005 20:21:56 -0400 Received: from MINDLAP2 (bay2-13.dial.umd.edu [128.8.22.77]) (authenticated bits=0) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j6CNpufL024546 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 12 Jul 2005 19:52:27 -0400 (EDT) Message-Id: <200507122352.j6CNpufL024546@carrierpigeon.cs.umd.edu> From: "Moustafa Youssef" To: Date: Tue, 12 Jul 2005 19:51:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable Subject: [Mip6] 2nd CFP: 2nd IEEE Workshop on Dependability and Security in Sensor Networks and Systems 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 (Our apologies if you receive multiple copies of this CFP) ------------------------------------------------------------- Second Call for Papers Second IEEE Workshop on Dependability and Security in Sensor Networks and Systems (DSSNS'2006) http://www.dssns.org In conjunction with 2nd NASA/IEEE Systems and Software Week 30th NASA/IEEE Software Engineering Workshop (SEW'2006) Columbia, Maryland, USA ~ April 24-28, 2006 Recently, there has been a growing interest in the potential use of networked sensors in applications such as smart environments,=20 disaster management, combat field reconnaissance, and security=20 surveillance. While the initial view of the community was that=20 networked sensors will play a complementary role that enhances=20 the quality of these applications, recent research results have=20 encouraged practitioners to envision an increased reliance on sensor=20 networks and systems (SN&S) in such critical and sensitive applications. Therefore to realize their potential, necessary dependability and=20 security (D&S) measures have to be incorporated in the design and=20 during the operation of SN&S. Dependability is usually specified=20 using attributes like reliability, survivability, safety, maintainability,=20 and availability in presence of failure, while security is specified by=20 attributes like integrity, authenticity, confidentiality, and availability=20 in presence of attacks. D&S services accomplish tasks for attack and failure prevention, detection and response. The scope of D&S services may span the deployed sensors to command nodes and likely beyond. It also=20 involves D&S support at, and cross-cutting, the protocol stack layers=20 from physical to application. Achieving dependability and security in SN&S will require non-conventional=20 mechanisms due to many factors including: (1) sensors are significantly constrained in the amount of available resources such as energy, storage and computation; (2) sensors are expected to be deployed in very large=20 numbers in normal as well as harsh/hostile environments; (3) sensor=20 networks suffer from structural weakness and limited physical protection,=20 and (4) localization of impact is complicated due to the un-tethered nature=20 of SN&S and of the potential attackers. In addition, D&S requirements may=20 vary according to mission defined over a multi-dimensional context, such as field of deployment (e.g., hostile versus friendly), type of=20 application (e.g., monitoring, tracking, data collection), mode of=20 operation (e.g., normal, exception, post-event recovery), and time. This workshop will foster a forum for discussing and presenting recent=20 research results on dependability and security in SN&S. Topics of interest=20 include, although not limited to, the following: - Fault and intrusion-tolerant architectures, middleware and operational models=20 - Robust routing, storage, and processing of sensed data - D&S architectures, protocols and tools - Vulnerabilities, attacks and countermeasures - Monitoring and evaluation techniques - Robust clustering techniques - Self-awareness and context-awareness=20 - Resilient virtual infrastructures - Autonomic and adaptive D&S support. - Formal representation and verification of D&S properties - Network inference support for D&S - Quality of service provisioning - Models, metrics, and measurements for D&S - Privacy-aware D&S services - Testbeds, simulation and visualization=20 - Agent-based D&S management=20 - SN&S support for D&S in larger information grids - SN&S application development environments Submission Guidelines --------------------- For guidelines regarding paper submission, please refer to the workshop=92s=20 website (http://www.dssns.org). Papers should contain original material=20 and not be previously published, or currently submitted for consideration=20 elsewhere. The manuscript should not exceed 20 single-column double-space=20 pages in PDF format, font size 11 or larger. The first page should include=20 title, authors' contact information, abstract and five keywords.=20 Important Dates ---------------- Submission deadline: November 7, 2005 Decision notification: December 20, 2005 Final manuscript due: January 20, 2006 The best paper will be recognized and selected papers will be invited to a Special Issue of the Journal of Ad Hoc and Sensor Wireless Networks.=20 Workshop Co-Chairs ------------------- Mohamed Eltoweissy Virginia Tech, USA E-mail: toweissy@vt.edu=20 Mohamed Younis University of Maryland Baltimore County, USA E-mail: younis@csee.umbc.edu=20 Publicity Co-Chairs -------------------- Denis Gracanin Virginia Tech, USA E-mail: gracanin@vt.edu Moustafa Youssef University of Maryland at College Park, USA E-mail: moustafa@cs.umd.edu=20 Program Committee ------------------ Farooq Anjum, Telcordia & U. of Penn, USA David Carman, Johns Hopkins U.=96 Applied Physics Lab, USA Ing-Ray Chen, Virginia Tech, USA M. Nazih Elderini, Alexandria U, Egypt Deborah Frincke, Pacific Northwest National Lab and U. of Idaho, USA Sushil Jajodia, George Mason U., USA Shivakant Mishra, U. of Colorado, USA Peng Ning, North Carolina State U., USA Cristina Nita-Rotaru, Purdue U., USA Stephan Olariu, Old Dominion U., USA David Simplot-Ryl, U. Lille, INRIA Futurs, France Mani B. Srivastava, U. of California =96 Los Angeles, USA John A. Stankovic, U. of Virginia, USA Ivan Stojmenovic, U. of Ottawa, Canada Gene Tsudik, U. of California-Irvine, USA Cliff Wang, Army Research Office, USA Stephen D. Wolthusen, Fraunhofer-IGD, Germany Albert Zomaya, U. of Sydney, Australia _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 14 07:37:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt225-0005US-Hh; Thu, 14 Jul 2005 07:37:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt223-0005Tv-0B; Thu, 14 Jul 2005 07:37:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01117; Thu, 14 Jul 2005 07:37:33 -0400 (EDT) Received: from 203.141.155.85.user.ca.il24.net ([203.141.155.85] helo=doller.momose.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt2Uc-0005wb-Pa; Thu, 14 Jul 2005 08:07:08 -0400 Received: from [10.0.0.71] (kame199.kame.net [203.178.141.199]) (authenticated (0 bits)) by doller.momose.org (8.12.11/8.11.4) with ESMTP id j6EBbBsB020730; Thu, 14 Jul 2005 20:37:12 +0900 (JST) (envelope-from t-momose@kame.net) Mime-Version: 1.0 (Apple Message framework v733) References: Content-Type: text/plain; charset=ISO-2022-JP; delsp=yes; format=flowed Message-Id: <75C72FAD-4664-4129-A064-F2CBE938F21E@kame.net> Content-Transfer-Encoding: 7bit From: Tsuyoshi MOMOSE Date: Thu, 14 Jul 2005 20:37:09 +0900 To: mip6@ietf.org, nemo@ietf.org X-Mailer: Apple Mail (2.733) X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: Subject: [Mip6] Fwd: I-D ACTION:draft-momose-mip6-mipsock-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 Dear all, We have submitted a draft regarding a new API for Mobile IPv6 and Nemo. Any comments are appreciated. Regards, --- Tsuyoshi MOMOSE NEC Corporation KAME Project http://www.kame.net/ Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: 2005$BG/(B7$B7n(B13$BF|(B 4:50:03:JST > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-momose-mip6-mipsock-00.txt > Reply-To: internet-drafts@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The application interface to exchange mobility > information with Mobility subsystem > (Mobility > Socket, AF_MOBILITY) > Author(s) : T. Momose, et al. > Filename : draft-momose-mip6-mipsock-00.txt > Pages : 23 > Date : 2005-7-12 > > This memo describes the interface to exchange mobility related > information between processes or between processes and a kernel, > using a socket interface. A new address family is defined for the > purpose. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-momose-mip6-mipsock-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-momose-mip6-mipsock-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-momose-mip6-mipsock-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2005-7-12150049.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 14 08:01:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt2P8-0007Vg-Cw; Thu, 14 Jul 2005 08:01:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt2P2-0007T7-S3 for mip6@megatron.ietf.org; Thu, 14 Jul 2005 08:01:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02325 for ; Thu, 14 Jul 2005 08:01:18 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt2rP-0006c2-Ew for mip6@ietf.org; Thu, 14 Jul 2005 08:30:54 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJM003SF9GX5Q@szxga02-in.huawei.com> for mip6@ietf.org; Thu, 14 Jul 2005 20:02:58 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJM00AP59GXUY@szxga02-in.huawei.com> for mip6@ietf.org; Thu, 14 Jul 2005 20:02:57 +0800 (CST) Received: from sachin1734 ([10.18.4.197]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJM00BDZ9GPS7@szxml02-in.huawei.com>; Thu, 14 Jul 2005 20:02:51 +0800 (CST) Date: Thu, 14 Jul 2005 04:57:18 -0700 From: Sachin Dutta Subject: RE: [Mip6] Draft on Securing Home Agent List In-reply-to: <01b001c5865e$78a89890$016115ac@dcml.docomolabsusa.com> To: "'James Kempf'" , "'COMBES Jean-Michel RD-MAPS-ISS'" , "'Radhakrishnan.S'" Message-id: <000001c5886b$304a2190$c504120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, deshbandhus@huawei.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sachind@huawei.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 HI Jak , Jean and Radhakrishnan, Thanks for reviewing the draft; I have consolidated the comments,=20 > Use SEND SEND can be an alternate solution but MIP6 implementation should not mandate SEND to be implemented and link to be secured The solution suggested is quite simple and does not require much change and can be used by nodes not implementing SEND=09 And Jak I feel for transition scenarios section [8] should be updated for Home Agent list to have secured and unsecured flag as suggested for prefix list and neighbor cache by SEND. And MIP6 to consider secured link and prioritize DHAAD reply based on these flags =09 > (1) I feel the use of STALE and REACHABLE in places referring to states in=20 > both HA List and NCE is little confusing. Maybe use of different words like=20 > VALID/INVALID to indicate state of an entry in HA List would be better. Here=20 Like in ND on receiving RA, neighbor cache entry created is in STALE state, same ND logic has been borrowed and extended in HAL. That's why state has been kept same as ND State as both imply one and same thing=20 > (2) Sec 3.1 > " o If the entry exists and it state is STALE then simply ignore > this RA message." > -> Only if RA parameters are identically same with prev one, isnt it? This was kept this was as the frequency of RA messages in MIP6 can be very fast & processing each RA messages can be an expensive operation and is a kind of attack only in MIP6. Ignoring that also is not an issue as RA is periodic & next RA will correct HAL if it was changed in-between > (3) In section 3.1 > -> What about RAs with global address as source address???? Basic ND RFC mandate source of RA to be link local so packet will be discarded before only > (5) What happens in case of a node replying with bogus NA when HA sends=20 > NS???=20 ND Protocol issues are not being addressed here and the Security provided is same as maximum possible on unsecured link.=20 I accept the suggestion and will update the security section > (6) There are grammatical errors at quite few places and missing=20 > punctuations. Will be taken care in the next update :-) > use IPsec Not possible, I think JMC already clarified this issue Please let me know for any other issue Best Regards, Sachin -----Original Message----- From: James Kempf [mailto:Kempf@docomolabs-usa.com]=20 Sent: Monday, July 11, 2005 14:21 To: COMBES Jean-Michel RD-MAPS-ISS; Radhakrishnan.S; sachind@huawei.com; mip6@ietf.org; maoshx@huawei.com; deshbandhus@huawei.com; surajs@huawei.com Subject: Re: [Mip6] Draft on Securing Home Agent List SEND proves its a router, the IPsec SA establishment procedure requires the HA to present a cert that the host must verify. So there's a filter at both phases. That said, I don't think RFC 3775 requires the HA's cert to be annotated with an attribute saying that it is authorized to act as a home agent. SEND does allow the router cert to be so attributed (specifically with a list of prefixes that the router is authorized to route) but it does not require that. jak ----- Original Message ----- From: "COMBES Jean-Michel RD-MAPS-ISS" To: "Radhakrishnan.S" ; ; ; ; ; Sent: Monday, July 11, 2005 6:46 AM Subject: RE: [Mip6] Draft on Securing Home Agent List Hi, The problem with SEND is that it only proves the router has the rights to be a router for some prefixes (linked to the router's certs). But here, I think, the simplest solution is to use IPsec. Hoping a HA manager knows all his HAs, it is simple to him to set up IPsec between them based on pre-shared keys or certs if SEND is deployed :) Regards. JMC. France Telecom - R&D Division - MAPS/NSS Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16 > -----Message d'origine----- > De : mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] De > la part de Radhakrishnan.S > Envoy=E9 : lundi 11 juillet 2005 15:11 > =C0 : sachind@huawei.com; mip6@ietf.org; maoshx@huawei.com; > deshbandhus@huawei.com; surajs@huawei.com > Objet : Re: [Mip6] Draft on Securing Home Agent List > > Hi, > This draft has brought out an interesting problem. SEND > could help solve this problem. So why this method?????? > > Anyway, i am posting few comments i have: > (1) I feel the use of STALE and REACHABLE in places referring > to states in both HA List and NCE is little confusing. Maybe > use of different words like VALID/INVALID to indicate state > of an entry in HA List would be better. > > (2) Sec 3.1 > " o If the entry exists and it state is STALE then simply ignore > this RA message." > -> Only if RA parameters are identically same with prev one, isnt it? > > (3) In section 3.1 > -> What about RAs with global address as source address???? > > (4) In section 3.4 > " o In case the DHAAD reply message becomes more then > PMTU then HA > must include self Home Agent address. This will > ensure at least > one valid reachable home agent address" > -> Very good thought. I feel making it mandatory for the HA > to carry its > address in HA list in DHAAD reply irrespective of message > size will guarantee atleast one valid reachable HA. :-) > > (5) What happens in case of a node replying with bogus NA > when HA sends NS??? SEND can help in such a case. maybe > security considerations section needs to be updated for such > a scenario. > > (6) There are grammatical errors at quite few places and > missing punctuations. > > Regards > Radhakrishnan > ----- Original Message ----- > From: "Sachin" > To: ; ; > ; > Sent: Monday, July 11, 2005 5:08 PM > Subject: [Mip6] Draft on Securing Home Agent List > > > > Dear MIP6 Group > > > > We have submitted a new internet draft for securing home > agent list in > > Mobile IPV6. A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-dutta-mip6-ra-00.txt > > > > Technical Summary: > > The home agent list is learnt by receiving the RA messages. So any > > rogue node on the link can send spurious RA on behalf of > non existent > > nodes. This results in non-reachable and non-existent > entries in the > > home agent list causing delay in getting service for a MN or not > > getting service at all. > > > > We are looking forward for your feedback. Thanks in advance > for your > > kind consideration. > > > > Best Regards > > > > Mao Shanxiang , Suraj , Deshbandhu & Sachin > > (Authors) > > > > > > _______________________________________________ > > 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 Thu Jul 14 14:47:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt8k1-0000kn-64; Thu, 14 Jul 2005 14:47:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt8jy-0000du-Cm for mip6@megatron.ietf.org; Thu, 14 Jul 2005 14:47:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08723 for ; Thu, 14 Jul 2005 14:47:20 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt9Cc-0006ML-9O for mip6@ietf.org; Thu, 14 Jul 2005 15:16:59 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A0E8989879; Thu, 14 Jul 2005 21:47:04 +0300 (EEST) Message-ID: <42D6B334.6040404@kolumbus.fi> Date: Thu, 14 Jul 2005 21:47:16 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sachind@huawei.com Subject: Re: [Mip6] Draft on Securing Home Agent List References: <000001c5886b$304a2190$c504120a@china.huawei.com> In-Reply-To: <000001c5886b$304a2190$c504120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: deshbandhus@huawei.com, mip6@ietf.org, 'James Kempf' , 'COMBES Jean-Michel RD-MAPS-ISS' 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 I have reviewed this draft. I agree that the security of the home agents list on the home link can be a problem. Or more generally, the security between the different home agents on the home link can be a problem. Thanks for writing a draft on this! I do have some issues with the proposed scheme, however. Perhaps it would be worthwhile to update this draft to talk more about the problem, as well as outline a number of different solutions (not just one) that could be used to mitigate the problem. One issue that I have with the proposed scheme is that it seems equally easy to send a fake RA than to respond to a NS probe generated as a part of the scheme. SEND and IPsec were mentioned as potential candidate solutions in the mailing list discussion. If you look at the problem from the 10.000 ft viewpoint, its obvious that you can find many solutions where some additional work by the network admin will buy better security. The simplest scheme is perhaps configuring the home agent list in the home agents directly, and not relying on RAs at all... at least not for verifying the existence of another home agent. A slightly more advanced scheme would rely on SEND, which also requires configuration effort but if you wanted to do that anyway its not additional effort. Even more advanced schemes could be devised, perhaps based on adding home agent authorization information to SEND certificates, or some sort of a general purpose security mechanism that secures not only the home agent list construction but also load-balancing and failover signaling between home agents. The main questions to me are how important this problem is, how complicated mechanism we need to solve it, and whether there's a need for Mobile IPv6 specific mechanisms or if general IPv6 mechanisms suffice. Are there other router -to- router communications, for example? In conclusion I would suggest this be discussed at the IETF, preferrably after a draft update has addressed some of the tradeoffs and alternative solutions above -- maybe in Vancouver if this can't be done before that. (Assuming of course people on this list think that this is an important enough problem to solve.) --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 14 15:52:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9lQ-0000MM-Ix; Thu, 14 Jul 2005 15:52:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9iy-0007l1-LH; Thu, 14 Jul 2005 15:50:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13797; Thu, 14 Jul 2005 15:50:18 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtABL-0008Rr-HL; Thu, 14 Jul 2005 16:19:48 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Dt9ie-0006IN-Mn; Thu, 14 Jul 2005 15:50:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 14 Jul 2005 15:50:04 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-bootstrap-ps-03.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Problem Statement for bootstrapping Mobile IPv6 Author(s) : A. Patel Filename : draft-ietf-mip6-bootstrap-ps-03.txt Pages : 31 Date : 2005-7-14 A mobile node needs at least the following information: a home address, home agent address and a security association with home agent to register with the home agent. The process of obtaining this information is called bootstrapping. This document discuss the issues involved with how the mobile node can be bootstrapped for Mobile IPv6 and various potential deployment scenarios for bootstrapping the mobile node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-bootstrap-ps-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-bootstrap-ps-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-14153510.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-bootstrap-ps-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-bootstrap-ps-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-14153510.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Thu Jul 14 16:18:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtAA8-0003L6-Kr; Thu, 14 Jul 2005 16:18:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtAA5-0003G8-SB for mip6@megatron.ietf.org; Thu, 14 Jul 2005 16:18:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22393 for ; Thu, 14 Jul 2005 16:18:23 -0400 (EDT) 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.43) id 1DtAch-0003HJ-EO for mip6@ietf.org; Thu, 14 Jul 2005 16:48:02 -0400 Message-ID: <0cc101c588b1$2bc2c1e0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "'COMBES Jean-Michel RD-MAPS-ISS'" , "'Radhakrishnan.S'" References: <000001c5886b$304a2190$c504120a@china.huawei.com> Subject: Re: [Mip6] Draft on Securing Home Agent List Date: Thu, 14 Jul 2005 13:18:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, deshbandhus@huawei.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 > Use SEND SEND can be an alternate solution but MIP6 implementation should not mandate SEND to be implemented and link to be secured jak>> Why not? jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 14 21:37:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtF9B-0004kD-JF; Thu, 14 Jul 2005 21:37:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtF9A-0004k5-2C for mip6@megatron.ietf.org; Thu, 14 Jul 2005 21:37:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28063 for ; Thu, 14 Jul 2005 21:37:45 -0400 (EDT) Received: from av11-2-sn2.hy.skanova.net ([81.228.8.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtFbr-0002OO-KZ for mip6@ietf.org; Thu, 14 Jul 2005 22:07:28 -0400 Received: by av11-2-sn2.hy.skanova.net (Postfix, from userid 502) id 9E7AB37EC4; Fri, 15 Jul 2005 03:37:28 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-2-sn2.hy.skanova.net (Postfix) with ESMTP id 7B4DB37EC3 for ; Fri, 15 Jul 2005 03:37:28 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 6D8DD37E43 for ; Fri, 15 Jul 2005 03:37:28 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DtF8n-00027g-G6 for mip6@ietf.org; Fri, 15 Jul 2005 03:37:28 +0200 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Vijay Devarapalli Date: Fri, 15 Jul 2005 01:37:24 +0000 MIME-Version: 1.0 Message-Id: <1121391444.14.0.881569340453.issue21@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.8 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] [issue21] EAP authentication for the Home Agent X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org New submission from Vijay Devarapalli : Jari Arkko wrote: o I'd prefer seeing recommendations like [8] as orthogonal to what we need for Mobile IPv6 usage of IKEv2. That is, I agree with what [8] is saying, but it seems like a general IKEv2 issue rather than something specific to Mobile IPv6. In some cases you want to point to such work and in some other cases you can leave it out; in this case I think the draft is unfortunately not moving very fast so you might want to drop the discussion about it, as eventual approval of [8] might change the contents. ---------- category: Technical draft: draft-ietf-mip6-ikev2-ipsec messages: 80 nosy: vijay priority: Must fix status: Pending title: EAP authentication for the Home Agent _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 14 21:39:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtFAR-0005go-Ke; Thu, 14 Jul 2005 21:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtFAP-0005cq-Nv for mip6@megatron.ietf.org; Thu, 14 Jul 2005 21:39:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28094 for ; Thu, 14 Jul 2005 21:39:03 -0400 (EDT) Received: from av8-1-sn3.vrr.skanova.net ([81.228.9.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtFd7-0002Qi-L4 for mip6@ietf.org; Thu, 14 Jul 2005 22:08:46 -0400 Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id C4A3437E76; Fri, 15 Jul 2005 03:38:52 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 8D87037E5D for ; Fri, 15 Jul 2005 03:38:52 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 7EE7A37E43 for ; Fri, 15 Jul 2005 03:38:52 +0200 (CEST) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=81-224-201-50-no45.tbcn.telia.com ident=www-data) by shiraz.levkowetz.com with esmtp (Exim 4.50) id 1DtFAB-00028u-BE for mip6@ietf.org; Fri, 15 Jul 2005 03:38:51 +0200 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Vijay Devarapalli Date: Fri, 15 Jul 2005 01:38:51 +0000 MIME-Version: 1.0 Message-Id: <1121391531.3.0.406316455512.issue22@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-Helo-Check-Failed: Verification failed for HELO 81-224-201-50-no45.tbcn.telia.com X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on shiraz.levkowetz.com X-Spam-Status: No, score=-103.8 required=2.5 tests=ALL_TRUSTED,AWL,BAYES_00, USER_IN_WHITELIST,X_HELO_CHECK_FAILED autolearn=ham version=3.0.4 X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Subject: [Mip6] [issue22] Manual IPsec entries X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org New submission from Vijay Devarapalli : Jari Arkko wrote: o Question: do we want to keep the manually keyed case in this document? I mean we will always have RFC 3776 when we want to do that... ---------- category: Technical draft: draft-ietf-mip6-ikev2-ipsec messages: 82 nosy: vijay priority: Must fix status: Pending title: Manual IPsec entries _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 14 21:40:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtFBk-0006FZ-Rh; Thu, 14 Jul 2005 21:40:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtFBj-0006FR-SR for mip6@megatron.ietf.org; Thu, 14 Jul 2005 21:40:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28138 for ; Thu, 14 Jul 2005 21:40:25 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtFeS-0002Sq-L1 for mip6@ietf.org; Thu, 14 Jul 2005 22:10:09 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6F18Z413916; Thu, 14 Jul 2005 18:08:35 -0700 X-mProtect: <200507150108> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141173.americas.nokia.com (172.18.141.173, claiming to be "[172.18.141.173]") by darkstar.iprg.nokia.com smtpdtw6f6S; Thu, 14 Jul 2005 18:08:34 PDT Message-ID: <42D713F2.2050902@iprg.nokia.com> Date: Thu, 14 Jul 2005 18:40:02 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mip6] review of draft-ietf-mip6-ikev2-ipsec-01 References: <42C11AFB.8060906@kolumbus.fi> In-Reply-To: <42C11AFB.8060906@kolumbus.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: Mobile IPv6 Mailing List 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 hi Jari, sorry for the late reply. thanks for reviewing the draft. > o Imho, the draft reads too much like a "diff" to RFC 3776. In > the light of eventually switching to only this, I think > we want a more self-contained document, even if it > means more text. yes. many others have expressed this concern. I plan to make the document self contained. > o Question: do we want to keep the manually keyed case in > this document? I mean we will always have RFC 3776 when > we want to do that... well, I wanted to show the manual IPsec entries that take advantage of the new MH type selector and ICMP type selector. we didnt have that in RFC 3776. > o In some places (such as section 6 and how you explain the > use of the AUTH payload) I got the feeling this repeats what > IKEv2 spec already says. Not sure what to do here, just > an observation. personally, it is kind of hard to read the IKEv2 spec. I thought it would be a good idea to write down what I understood. I have got comments from others saying that they understood better how IKEv2 can be used with MIPv6 after reading section 5.2 and 6. :) > o I'd prefer seeing recommendations like [8] as orthogonal > to what we need for Mobile IPv6 usage of IKEv2. That is, > I agree with what [8] is saying, but it seems like a general > IKEv2 issue rather than something specific to Mobile IPv6. > In some cases you want to point to such work and in some > other cases you can leave it out; in this case I think the draft > is unfortunately not moving very fast so you might want to > drop the discussion about it, as eventual approval of [8] > might change the contents. I really would like to see this implemented by folks. currently I think using EAP is only realistic way of authenticating mobile nodes in an Operator deployment. and some deployments like 3GPP2 currently cant support public key or certificate based authentication for the home agent. I re-worded the paragraph a bit to say that it is completely optional. I dont mind moving it to an appendix either so that [8] does not ever has to become a normative reference. :) The IKEv2 specification [4] requires that public key based mechanism be used to authenticate the Home Agent to the mobile node, when EAP is used. This should be used by default by the mobile node and the home agent. If the EAP method that is used, supports mutual authentication and and key generation, then the mobile node MAY use EAP itself to authenticate the Home Agent. The mobile node can request this by including the EAP_ONLY_AUTHENTICATION notification payload [8] in message 3. If the Home Agent supports the EAP_ONLY_AUTHENTICATION notification payload and agrees to use EAP, it omits the public key based AUTH and CERT payloads in message 4. If the Home Agent does not support this mechanism, it rejects it by including an AUTH payload in message 4. More details can be found in [8]. what do you think? > o Security considerations should perhaps say something about > rules regarding the allocation of home addresses, to avoid > hijacking them. I think you said something about that already somewhere > else, maybe that text could move here. okay. > > o It would also be interesting to hear more about how NAT traversal > feature of IKEv2 could be used in the connection of this new > spec for v4 compatibility, or whether you want to continue to use > the K bit or MOBIKE for moving the SAs. But perhaps these are > out of scope, I know that at least for the v4-v6 compatibility there > are other discussions and drafts. we plan to address that in the v4 traversal work. we should have something on this to report at the Paris IETF meeting. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 14 22:15:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtFev-0000qS-PU; Thu, 14 Jul 2005 22:10:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt9HE-0000VF-MD; Thu, 14 Jul 2005 15:21:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11745; Thu, 14 Jul 2005 15:21:42 -0400 (EDT) Received: from ms-smtp-02.nyroc.rr.com ([24.24.2.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dt9jr-0007RG-VF; Thu, 14 Jul 2005 15:51:22 -0400 Received: from hpn307pc2 (cpe-69-204-120-221.rochester.res.rr.com [69.204.120.221]) by ms-smtp-02.nyroc.rr.com (8.12.10/8.12.10) with SMTP id j6EJKhIU025155; Thu, 14 Jul 2005 15:20:44 -0400 (EDT) Message-ID: <008401c588a9$24a8f3f0$6401a8c0@hpn307pc2> From: "Wendi Heinzelman" To: "Wendi Heinzelman" Date: Thu, 14 Jul 2005 15:20:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 14 Jul 2005 22:10:36 -0400 Cc: Subject: [Mip6] Call for Participation MobiCom 2005 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 ******************************************************************* Call for Participation 11th International Conference on Mobile Computing and Networking August 28 - September 2, 2005 Cologne, Germany http://www.sigmobile.org/mobicom/2005/ ******************************************************************* ACM MobiCom is a highly-selective international conference on mobile computing and networking. It serves as the premier forum for presenting and discussing research results on networks, systems, algorithms, and applications supporting the symbiosis of mobile computing and wireless networking. Each year, the conference attracts about 500 researchers, practitioners, students, and executives. MobiCom 2005 will be held in beautiful Cologne, Germany. Technical Program. The program consists of a single track with 23 papers. The authors present cutting-edge results on various topics, such as new architectures, content-based and geometric routing, self-management, cross-layer optimization. The papers cover ad hoc networks, mesh networks, wireless sensor networks, WLANs, and cellular networks. A list of accepted papers can be found at http://www.sigmobile.org/mobicom/2005/program.html. Tutorials. Four tutorials will be offered: (a) Wireless sensor and actuator networks, (b) 802.11 WLAN MAC and smart antennas: issues and directions, (c) Security in sensor and ad hoc networks: perspectives and status, (d) Wide area wireless networks: 3G and beyond. Cologne is very popular, especially in August due to World Youth Day 2005 taking place there. Because Pope Benedict XVI organizes this event, he will be in town just the week before MobiCom. Thus, we ask you to make your hotel and flight reservations as early as possible. For more travel info please visit http://www.sigmobile.org/mobicom/2005/travel.html. Registration is available at http://www.regmaster.com/mobicom2005.html. There is a discounted rate until August 5, 2005. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jul 15 00:11:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtHXv-0001iZ-V7; Fri, 15 Jul 2005 00:11:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtHXt-0001iU-PI for mip6@megatron.ietf.org; Fri, 15 Jul 2005 00:11:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06923 for ; Fri, 15 Jul 2005 00:11:26 -0400 (EDT) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtI0c-0006sb-Ig for mip6@ietf.org; Fri, 15 Jul 2005 00:41:12 -0400 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IJN00E54IAPKE@mailout2.samsung.com> for mip6@ietf.org; Fri, 15 Jul 2005 13:11:13 +0900 (KST) Received: from srkrishnan ([107.108.71.58]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IJN009RWIALJ5@mmp1.samsung.com> for mip6@ietf.org; Fri, 15 Jul 2005 13:11:13 +0900 (KST) Date: Fri, 15 Jul 2005 09:37:38 +0530 From: "Radhakrishnan.S" Subject: Re: [Mip6] Draft on Securing Home Agent List To: Jari Arkko , sachind@huawei.com Message-id: <06bd01c588f2$bf4e73a0$3a476c6b@sisodomain.com> Organization: Samsung India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <000001c5886b$304a2190$c504120a@china.huawei.com> <42D6B334.6040404@kolumbus.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7BIT Cc: mip6@ietf.org, 'James Kempf' , 'COMBES Jean-Michel RD-MAPS-ISS' , deshbandhus@huawei.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Radhakrishnan.S" List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Jari, I completely agree with your suggestion. Analysing and outlining different ways of solving the problem will really make this draft worth while. The authors should consider this aspect and take it to IETF for further discussion on the problem itself. Regards Radhakrishnan >I have reviewed this draft. > > I agree that the security of the home agents list on the home > link can be a problem. Or more generally, the security between > the different home agents on the home link can be a problem. > > Thanks for writing a draft on this! > > I do have some issues with the proposed scheme, however. > Perhaps it would be worthwhile to update this draft to talk > more about the problem, as well as outline a number of > different solutions (not just one) that could be used to > mitigate the problem. > > One issue that I have with the proposed scheme is that > it seems equally easy to send a fake RA than to respond to > a NS probe generated as a part of the scheme. > > SEND and IPsec were mentioned as potential candidate > solutions in the mailing list discussion. If you look at the > problem from the 10.000 ft viewpoint, its obvious that you > can find many solutions where some additional work by > the network admin will buy better security. The simplest > scheme is perhaps configuring the home agent list in > the home agents directly, and not relying on RAs at all... > at least not for verifying the existence of another home > agent. A slightly more advanced scheme would rely on > SEND, which also requires configuration effort but if > you wanted to do that anyway its not additional effort. > Even more advanced schemes could be devised, perhaps > based on adding home agent authorization information > to SEND certificates, or some sort of a general purpose > security mechanism that secures not only the home agent > list construction but also load-balancing and failover > signaling between home agents. The main questions to > me are how important this problem is, how complicated > mechanism we need to solve it, and whether there's a > need for Mobile IPv6 specific mechanisms or if general > IPv6 mechanisms suffice. Are there other router -to- router > communications, for example? > > In conclusion I would suggest this be discussed at the > IETF, preferrably after a draft update has addressed > some of the tradeoffs and alternative solutions above -- > maybe in Vancouver if this can't be done before that. > (Assuming of course people on this list think that this > is an important enough problem to solve.) > > --Jari > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jul 15 01:47:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtJ34-000551-Sr; Fri, 15 Jul 2005 01:47:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtJ31-00053w-R0 for mip6@megatron.ietf.org; Fri, 15 Jul 2005 01:47:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12221 for ; Fri, 15 Jul 2005 01:47:42 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtJVl-0000pS-Ld for mip6@ietf.org; Fri, 15 Jul 2005 02:17:27 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5E9408980A; Fri, 15 Jul 2005 08:47:27 +0300 (EEST) Message-ID: <42D74DFB.3060509@kolumbus.fi> Date: Fri, 15 Jul 2005 08:47:39 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Draft on Securing Home Agent List References: <000001c5886b$304a2190$c504120a@china.huawei.com> <0cc101c588b1$2bc2c1e0$016115ac@dcml.docomolabsusa.com> In-Reply-To: <0cc101c588b1$2bc2c1e0$016115ac@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: a7d6aff76b15f3f56fcb94490e1052e4 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 James Kempf wrote: >>Use SEND >> >> > >SEND can be an alternate solution but MIP6 implementation should not >mandate SEND to be implemented and link to be secured > >jak>> Why not? > > This reminds me of an argument that I often see in the IETF, "implementations aren't doing RFC XXXX, so we have to develop RFC YYYY to fix that". Needless to say, its often the case that thereafter the implementations aren't doing either XXXX or YYYY :-) In some cases (perhaps with SEND too) one may wonder if a complicated piece of other functionality is needed to implement something simple. In such cases it may make some sense to develop alternative schemes. However, in this particular case it would suffice to implement a very small part of SEND, just the RA security and only on the home agents, not on all nodes. The scalability and ease of configuration of that part of SEND is probably close to what any other cryptographic solution would be able to offer, so working on other cryptographic solutions would probably not make much sense. A non-cryptographic, liveness based scheme might be OK, but they don't seem to address the threat that people wanted to fix, so unless we invent something new I don't think we want to go there. Anyway, in this discussion I think we should first focus on figuring out if a protocol mechanism is needed at all rather than arguing what it should be. (A protocol mechanism is not needed if, for instance, addition of some configuration information to the implementations would avoid the need to trust RAs. I'm not saying this solves this problem, but at least we should look at it.) --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jul 15 11:37:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtSFs-0003aS-FM; Fri, 15 Jul 2005 11:37:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtSFr-0003aI-0Q for mip6@megatron.ietf.org; Fri, 15 Jul 2005 11:37:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19569 for ; Fri, 15 Jul 2005 11:37:31 -0400 (EDT) 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.43) id 1DtSif-0006KR-Ke for mip6@ietf.org; Fri, 15 Jul 2005 12:07:23 -0400 Message-ID: <0f5d01c58953$1921bee0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" References: <000001c5886b$304a2190$c504120a@china.huawei.com> <0cc101c588b1$2bc2c1e0$016115ac@dcml.docomolabsusa.com> <42D74DFB.3060509@kolumbus.fi> Subject: Re: [Mip6] Draft on Securing Home Agent List Date: Fri, 15 Jul 2005 08:37:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 > This reminds me of an argument that I often see in the IETF, > "implementations aren't doing RFC XXXX, so we have to develop > RFC YYYY to fix that". Needless to say, its often the case that > thereafter the implementations aren't doing either XXXX or > YYYY :-) > > In some cases (perhaps with SEND too) one may wonder if > a complicated piece of other functionality is needed to implement > something simple. In such cases it may make some sense to > develop alternative schemes. However, in this particular case > it would suffice to implement a very small part of SEND, just the > RA security and only on the home agents, not on all nodes. > The scalability and ease of configuration of that part of SEND > is probably close to what any other cryptographic solution would > be able to offer, so working on other cryptographic solutions > would probably not make much sense. A non-cryptographic, liveness > based scheme might be OK, but they don't seem to address > the threat that people wanted to fix, so unless we invent something > new I don't think we want to go there. > Yes, that's true. Though the WG did have a discussion about whether or not to use IPsec on the HA to MN connection, nobody seemed to be making the case that "we shouldn't mandate using IPsec in Mobile IP" (though of course now we have the mip6-auth option). I know protocol designers like to avoid "dependencies", people are constantly trying to avoid using TCP and then they end up reinventing congestion control. My point was that if there is an existing protocol that solves the problem, then why not use it? > Anyway, in this discussion I think we should first focus on > figuring out if a protocol mechanism is needed at all > rather than arguing what it should be. (A protocol mechanism > is not needed if, for instance, addition of some configuration > information to the implementations would avoid the need to > trust RAs. I'm not saying this solves this problem, but at least > we should look at it.) > Well it is always good to have a clear and concise statement of the problem before attempting to solve it. If the problem lends itself to a configuration solution rather than a protocol solution, then so much the better. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jul 15 15:51:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWDL-0006CQ-4S; Fri, 15 Jul 2005 15:51:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWCI-0005s0-7g; Fri, 15 Jul 2005 15:50:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10910; Fri, 15 Jul 2005 15:50:07 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtWf4-0007pe-2a; Fri, 15 Jul 2005 16:19:58 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DtWCA-0001v5-Sj; Fri, 15 Jul 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 15 Jul 2005 15:50:02 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-dsmip-problem-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobility management for Dual stack mobile nodes A Problem Statement Author(s) : G. Tsirtsis, H. Soliman Filename : draft-ietf-mip6-dsmip-problem-00.txt Pages : 5 Date : 2005-7-15 This draft discusses the issues associated with mobility management for dual stack mobile nodes. Currently, two mobility management protocols are defined for IPv4 and IPv6. Deploying both in a dual stack mobile node introduces a number of inefficiencies. Deployment and operational issues motivate the use of a single mobility management protocol. This draft discusses such motivations. The draft also hints on how current MIPv4 and MIPv6 could be extended so that they can support mobility management for a dual stack node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-dsmip-problem-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-dsmip-problem-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-dsmip-problem-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-15141006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-dsmip-problem-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-dsmip-problem-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-15141006.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Sun Jul 17 08:11:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du7zy-0001xy-Cw; Sun, 17 Jul 2005 08:11:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du7zw-0001xU-0F; Sun, 17 Jul 2005 08:11:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00217; Sun, 17 Jul 2005 08:11:54 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX185mnJJiF2YAAMP/phcE3qzwmHq71uYR+g=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du8T9-0002Do-5b; Sun, 17 Jul 2005 08:42:08 -0400 Received: from hsi-kbw-082-212-035-085.hsi.kabelbw.de ([82.212.35.85] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Du7zq-0005BR-9T; Sun, 17 Jul 2005 14:11:53 +0200 Message-ID: <42DA4B04.4010209@tm.uka.de> Date: Sun, 17 Jul 2005 14:11:48 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Gerardo Giaretta References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -1.7 (-) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: 748ed3980abc7d4bd6a14905626ff64e Cc: mip6@ietf.org, Rajeev Koodli , Jari Arkko , mobopts@irtf.org Subject: [Mip6] Re: Review of draft-irtf-mobopts-ro-enhancements-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: , Content-Type: multipart/mixed; boundary="===============0791756552==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0791756552== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigFB871CA55EA4344CDA1D3D13" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFB871CA55EA4344CDA1D3D13 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Gerardo, you had one more comment concerning the section on processing improvements: > Not necessarily. However, even without any reference, some more > details can be useful. As you mention RR was designed with low > computational complexity in mind. If you state that it can be too > expensive, you should at least provide some examples, scenarios or > data. Thinking more about this, I tend to conclude that the complexity of the return-routability procedure is already very low. One may further reduce processing requirements through easier ways to compute the Home and Care-of Keygen Tokens, or the KBM. But that's probably not so urgent. Here is the new text: 5.17 Processing Improvements One goal for designing the return-routability procedure was to limit its computational complexity to a minimum. The processing overhead for route optimization should thus be acceptable in general. However, some alternatives to the return-routability procedure use stronger cryptographic algorithms, such as public-key cryptography. This can be more taxing on processing resources, especially for low- provisioned handheld devices. Here, it may help to replace RSA algorithms with ECC techniques. Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Gerardo Giaretta wrote: > Hi Christian, > > thanks for your replay. Some comments below... > > >> Hi Gerardo, >> >> thanks again for reviewing the doc. Some responses below. You can >> check the new version at >> >> http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-0 >> 1-pre.txt >> >> - Christian >> >> ++++ >> >> >>> General comment: I think the draft is very well-written and >> >> provide a >> >>> complete analysis of the topic. The unique general issue I found >>> is that it is very long. I agree with James' comment that the >>> draft could be shortened removing some sections that are not >>> completely in the scope of the draft (e.g. section 5.13 and 5.14, >>> more about these sections below). >> >> Ok, will do that. >> >> >>> More detailed comments: >>> >>> - section 1, paragraph 4 "In the opposite direction, the mobile >>> node may tunnel packets to the home agent". I think this sentence >>> is not completely correct, or at least a bit misleading. If route >>> optimization is not used, the MN MUST tunnel packets to the HA. >>> Is "MAY" used in this sentence to highlight that the MN can >>> choose to use bidirectional tunneling or route optimization? >> >> You are right, the text is misleading. The idea was that RO is the >> alternative, and the MN may choose (provided the CN supports RO). >> But, again, this is confusing, so I changed it. >> >> >>> - section 1, paragraph 10 "This can lead to handover delay >>> unacceptable for many real-time or interactive applications like >>> Voice over IP (VoIP) and audio or video streaming". I'd suggest >>> to remove audio/video streaming here. Streaming applications are >>> not real-time nor interactive: they usually buffer few seconds of >>> the movie/sound and thus are usually not affected by MIPv6 >>> handover latency. At least this is what we have experimented in >>> our labs. >> >> Would you say that rapid handovers and small buffers in >> less-provisioned devices can be an issue with streaming? >> > > > Yes, it can be an issue. But this depends on the device capabilities > and not on strong application requirements. Usually, in most > streaming applications, buffer size is configurable and has a default > value of few seconds. > > >> Anyway, I changed the text. >> > > > Good. > > >>> - section 3.1, paragraph 7 "The mobile node must compute a >>> message-authentication code keyed with the Home and Care-of >>> Keygen Token". Actually the MAC is keyed with the Kbm, that is a >>> 20 octets SHA-1 hash of the concatenation of Home and Care-of >>> Keygen Token >> >> Right, this was imprecise. Corrected it. >> >> >>> - section 4.1, paragraph 1: I would mention explicitly that the >>> handoff latency for a route-optimized communication is longer >>> than for a bi-directional tunneled communication. >> >> Yes, it's added. >> >> >>> - section 4.1, paragraph 2: since the CN is not always required >>> to send the BA, I wonder why the MN should by default wait for >>> the BA. Or are you suggesting the MN asks the CN an ack? If so, I >>> think the sentence should be rephrased. >> >> Right. >> >> >>> - section 4.1, paragraph 3 "But more generally, mobile >> >> nodes wait for >> >>> the home registration to be completed and acknowledged before >>> initiating the correspondent registration". Are you >> >> referring to some >> >>> specific implementations? I'm asking this because the open source >>> implementation we use in our labs does not wait the BA. >> >> Kame-Shisa does it. We added the optimization not to wait for the >> BA from the HA. >> >> Actually, not waiting for the BA is not standard-conform. RFC 3775 >> says that the lifetime of correspondent registrations must not >> exceed that of the home registration. And the latter becomes known >> to the MN only with the BA. >> >> I don't think this requirement is critical, though. After all, >> it's up to the MN to request the CN lifetime anyway. It could just >> ignore the home-registration lifetime. >> > > > I tend to agree on this. This implementation choice can improve > performance. > > > >>> - section 4.4, paragraph 2: I would add references to >>> draft-koodli-mip6-location-privacy-00 and to >>> draft-koodli-mip6-location-privacy-solutions-00 >> >> Definitely a good idea. >> >> >>> - section 5.2, paragraph 1: What do you mean by "close to >> >> the mobile >> >>> node"? Shouldn't it be "on the path between MN and HA"? >> >> The critical link on the patch between the MN and the HA is a >> wireless first hop. >> >> Anyway, the text is unclear. Rewrote that sentence. >> >> >>> - section 5.3, paragraph 2: the sentence is not clear to >> >> me. The last >> >>> BA is referred to BA from CN, I suppose. If so, I think it >> >> should be >> >>> mentioned explicitly. >> >> Done. >> >> >>> - section 5.13: as mentioned before I think this section is not >>> really in the scope of the draft. If you think it is, I'd suggest >>> to include some more text explaining how HMIPv6 influences RO >> >> operations >> >>> (e.g. reduction of signaling overhead). The same applies to >>> section 5.14. I think that FMIPv6 has even less impact on RO than >>> HMIPv6. So I suggest you include some more text to explain how >>> these protocols are tied to RO. >> >> It seems there is pretty much agreement in that FMIPv6 and HMIPv6 >> should be removed from this particular document. >> >> >>> - section 5.16, last sentence: are there simulations that prove >>> that RR can be too expensive? A reference could be helpful. >> >> I don't have such a reference. Is your suggestion to remove the >> section in this case? >> > > > Not necessarily. However, even without any reference, some more > details can be useful. As you mention RR was designed with low > computational complexity in mind. If you state that it can be too > expensive, you should at least provide some examples, scenarios or > data. > > --Gerardo > > >>> - section 6.2.1, last paragraph: HMIPv6 causes always a tunneling >>> overhead that is not present in plain MIPv6. Therefore, some >>> localized mobility protocols always cause overhead and not only >>> "in some situations". >> >> That's right. But I have already removed that sub-section. >> >> >>> - section 6.2.2, paragraph 1 "On the other hand, nodes that do >>> share a common secret should be allowed to omit the home-address >>> test". Isn't required that the common secret is tied to the Home >>> Address used in order to remove the home address test? >> >> You are right. Added that. >> >> >>> Editorial comments: >>> >>> - section 4.1, last paragraph: Section 6.3.1 should be in >> >> brackets or >> >>> similar >> >> Oops, it's done. >> >> >>> - section 5.1, paragraph 2: s/IP-ddress/IP-address >> >> Ok. >> >> >>> - section 5.7, paragraph 5: s/its is the data/it is the data >> >> Ok. >> >> >>> - section 5.8, paragraph 2: s/it in general/it is in general >> >> Ok. >> >> >>> Hope this helps. >> >> It did. ;) >> >> Thanks, - Christian >> >> -- Christian Vogt, Institute of Telematics, University of Karlsruhe >> www.tm.uka.de/~chvogt/pubkey/ >> >> >> >> Gerardo Giaretta wrote: >> >>> Hi Christian and Jari, >>> >>> Raj requested me to review draft-irtf-mobopts-ro-enhancements-00. >>> Here are some comments and question. >>> >>> General comment: I think the draft is very well-written and >> >> provide a >> >>> complete analysis of the topic. The unique general issue I found >>> is that it is very long. I agree with James' comment that the >>> draft could be shortened removing some sections that are not >>> completely in the scope of the draft (e.g. section 5.13 and 5.14, >>> more about these sections below). >>> >>> More detailed comments: >>> >>> - section 1, paragraph 4 "In the opposite direction, the mobile >>> node may tunnel packets to the home agent". I think this sentence >>> is not completely correct, or at least a bit misleading. If route >>> optimization is not used, the MN MUST tunnel packets to the HA. >>> Is "MAY" used in this sentence to highlight that the MN can >>> choose to use bidirectional tunneling or route optimization? >>> >>> - section 1, paragraph 10 "This can lead to handover delay >>> unacceptable for many real-time or interactive applications like >>> Voice over IP (VoIP) and audio or video streaming". I'd suggest >>> to remove audio/video streaming here. Streaming applications are >>> not real-time nor interactive: they usually buffer few seconds of >>> the movie/sound and thus are usually not affected by MIPv6 >>> handover latency. At least this is what we have experimented in >>> our labs. >>> >>> - section 3.1, paragraph 7 "The mobile node must compute a >>> message-authentication code keyed with the Home and Care-of >>> Keygen Token". Actually the MAC is keyed with the Kbm, that is a >>> 20 octets SHA-1 hash of the concatenation of Home and Care-of >>> Keygen Token >>> >>> - section 4.1, paragraph 1: I would mention explicitly that the >>> handoff latency for a route-optimized communication is longer >>> than for a bi-directional tunneled communication. >>> >>> - section 4.1, paragraph 2: since the CN is not always required >>> to send the BA, I wonder why the MN should by default wait for >>> the BA. Or are you suggesting the MN asks the CN an ack? If so, I >>> think the sentence should be rephrased. >>> >>> - section 4.1, paragraph 3 "But more generally, mobile >> >> nodes wait for >> >>> the home registration to be completed and acknowledged before >>> initiating the correspondent registration". Are you >> >> referring to some >> >>> specific implementations? I'm asking this because the open source >>> implementation we use in our labs does not wait the BA. >>> >>> - section 4.4, paragraph 2: I would add references to >>> draft-koodli-mip6-location-privacy-00 and to >>> draft-koodli-mip6-location-privacy-solutions-00 >>> >>> - section 5.2, paragraph 1: What do you mean by "close to >> >> the mobile >> >>> node"? Shouldn't it be "on the path between MN and HA"? >>> >>> - section 5.3, paragraph 2: the sentence is not clear to >> >> me. The last >> >>> BA is referred to BA from CN, I suppose. If so, I think it >> >> should be >> >>> mentioned explicitly. >>> >>> - section 5.13: as mentioned before I think this section is not >>> really in the scope of the draft. If you think it is, I'd suggest >>> to include some more text explaining how HMIPv6 influences RO >> >> operations >> >>> (e.g. reduction of signaling overhead). The same applies to >>> section 5.14. I think that FMIPv6 has even less impact on RO than >>> HMIPv6. So I suggest you include some more text to explain how >>> these protocols are tied to RO. >>> >>> - section 5.16, last sentence: are there simulations that prove >>> that RR can be too expensive? A reference could be helpful. >>> >>> - section 6.2.1, last paragraph: HMIPv6 causes always a tunneling >>> overhead that is not present in plain MIPv6. Therefore, some >>> localized mobility protocols always cause overhead and not only >>> "in some situations". >>> >>> - section 6.2.2, paragraph 1 "On the other hand, nodes that do >>> share a common secret should be allowed to omit the home-address >>> test". Isn't required that the common secret is tied to the Home >>> Address used in order to remove the home address test? >>> >>> >>> Editorial comments: >>> >>> - section 4.1, last paragraph: Section 6.3.1 should be in >> >> brackets or >> >>> similar >>> >>> - section 5.1, paragraph 2: s/IP-ddress/IP-address >>> >>> - section 5.7, paragraph 5: s/its is the data/it is the data >>> >>> - section 5.8, paragraph 2: s/it in general/it is in general >>> >>> >>> Hope this helps. >>> >>> Regards, --Gerardo >>> >>> >>> >>> >>> >>> >>> Gruppo Telecom Italia - Direzione e coordinamento di Telecom >>> Italia S.p.A. >>> >>> >> >> ==================================================================== >> >> >>> 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 >>> ==================================================================== >>> >> >> > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > S.p.A. > > ==================================================================== > 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 > ==================================================================== --------------enigFB871CA55EA4344CDA1D3D13 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.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC2ksEwstEk8gl2rURAohTAKCbO0qjt1MEJTyH/tdfOyBtAXz8KQCgs0Aa avvJ5W6DgoVkfMtAwaA0ErM= =0X09 -----END PGP SIGNATURE----- --------------enigFB871CA55EA4344CDA1D3D13-- --===============0791756552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0791756552==-- From mip6-bounces@ietf.org Sun Jul 17 08:14:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du82Z-0002Gh-L7; Sun, 17 Jul 2005 08:14:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du82W-0002GA-U2; Sun, 17 Jul 2005 08:14:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00372; Sun, 17 Jul 2005 08:14:35 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX18Zmv9OAngwWJFvG3NA9bamlRg8IlKgiGY=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du8Vk-0002OV-0h; Sun, 17 Jul 2005 08:44:48 -0400 Received: from hsi-kbw-082-212-035-085.hsi.kabelbw.de ([82.212.35.85] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Du82O-0005Ga-AQ; Sun, 17 Jul 2005 14:14:34 +0200 Message-ID: <42DA4BA2.6040205@tm.uka.de> Date: Sun, 17 Jul 2005 14:14:26 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Review of draft-irtf-mobopts-ro-enhancements-00.txt References: <0abd01c56246$fe2927f0$016115ac@dcml.docomolabsusa.com> <42A7CF48.2040807@tm.uka.de> <00b101c56d0a$aefca2a0$016115ac@dcml.docomolabsusa.com> In-Reply-To: <00b101c56d0a$aefca2a0$016115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -1.2 (-) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: f560cc438c8be83d0aa5c816c29b481c Cc: MIP6 , Jari Arkko , Rajeev Koodli , MOBOPTS 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="===============1241107039==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1241107039== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig177D579897C75D1A967D63CC" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig177D579897C75D1A967D63CC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi James, thanks for your additional comments. My responses are inline. >>> Section 4.2, 3rd & 4th para: I've never been convinced that a >>> mobile node would want to keep optimized routes hot while it was >>> in dormant mode, and this example doesn't convince me either. >>> Route optimization helps with RTT latency, and such latency is an >>> issue primarily in real time traffic. The example given here, a >>> messaging server (presumably IM), is a store and forward system >>> that will derive little benefit from keeping routes hot during >>> optimization. Even for real time traffic, like VoIP, the CN still >>> has to do SIP signaling to initiate the connection, and while >>> there is some amount of urgency to the signaling above a store >>> and forward application, it still is not going to suffer if the >>> traffic is routed through the home agent. The latency involved in >>> initiating the IP connection with the dormant mode mobile node >>> through paging is likely to exceed any benefit from keeping >>> optimized routes hot. >> >> Should we remove the example and say instead that it be worthwhile >> to save the wireless bandwidth? > > Yes, I think that should be enough. Ok, this is done. >>> Section 5, para 1: Are the tradeoffs between universal >>> applicablity v.s. efficiency discussed in this paper anywhere? >>> This would be the ideal paper to have the discussion. >> >> It's mentioned where pre-configuration is discussed, for instance. > > Might be good to give it a more prominant place, perhaps up front. It > is a good architectural point, that should not get lost in the > details of the various techniques. Yes, that's true. I added the following section to the Introduction section: ++++ This paper describes, classifies, and evaluates strategies that can enhance or optimize Mobile IPv6 route optimization. These optimizations have different objectives: Some of them tackle signaling latency or overhead, while others focus on security improvements. Again others seek to increase protocol robustness or to add to the functionality of base Mobile IPv6. When it comes to evaluating a particular optimization, it is important to not only regard its relative improvement over standard Mobile IPv6, but to also consider the optimization's costs in terms of hardware upgrades, software modifications, and manual configuration, as well as its applicability to different scenarios and ease of deployment. E.g., end-to-end techniques like Mobile IPv6 route optimization itself have a natural lower bound with respect to signaling latency of one round- trip time. (It takes the first one-way time to signal a new care-of address to a peer; the second one-way time is needed by the first packet to arrive at the new care-of address.) To reduce the latency below one round-trip time, some optimizations make use of network infrastructure. While the benefit of such infrastructure can be enormous, the associated acquisition and maintenance costs are a disadvantage that needs to be kept in mind. Also, infrastructure- based optimizations are ineffective when the infrastructure is unavailable. (This may, e.g., be the case when a mobile node switches to a different administrative domain.) Though end-to-end optimizations are slower, they are usually cheaper and easier to deploy, and they are operable without network support. ++++ >>> Section 5.5, para 2: Later in the paper, you discuss this, but >>> the statistical uniqueness properties of CGAs suggest that the >>> care-of test might not be needed since the probability of another >>> node having exactly the same interface identifier is fairly low. >>> I think you should state that here. It is the same tradeoff that >>> optimistic DAD makes. The argument you advance later in the paper >>> that the attacker can still mount an attack on the subnet is >>> irrelevent. An attacker can do that without using route >>> optimization, by creating a zombie and programming it to iterate >>> through non-existant addresses in the victim subnet. >> >> I think there is still an issue with CGAs and RO of which one needs >> to be aware: >> >> An attacker could use any interface identifier in order to bomb a >> certain network. The only thing that matters in such a case is the >> network prefix. >> >> Route optimization does not create the issue with flooding, but it >> can aggravate it. You get amplification without programming a >> zombie and distributing viral software. And if you choose to >> program a zombie nonetheless, the zombie can misuse route >> optimization for you. (In the latter case, the zombie would contact >> a large set of powerful correspondent nodes, download large files, >> and redirect those files to the target network. This is "more >> efficient" compared to when the zombie alone sends packets.) >> > > > OK, so it sounds as if RO using CGA w.o. an RR test will provide > additional leverage to an attacker, right? Perhaps you could explain > this a little more in the draft? I added the following two paragraphs to section "Mobility-Related Security Threats :: Flooding Attacks": ++++ Note that a redirection-based flooding attack can be combined with the conventional strategy where the attacker infects and takes over control of zombies. The attacker could infect multiple zombies, and each of those could in turn persuade multiple correspondent nodes to send packets to a common victim. The base of correspondent nodes that could be misused would be substantial, because support for Mobile IPv6 route optimization is recommended to all IPv6 nodes [14]. This is why RFC 3775 prevents redirection-based flooding attacks through care-of-address test. Cryptographically Bound Identifiers (CBIDs, cf. Section 5.9) may be used to partly mitigate the risk of flooding, because a correspondent node can verify whether the interface identifier of a mobile node's (or the attacker's) care-of address is correct. However, CBIDs do not guarantee the correctness of the address prefix. A malicous node could therefore still bomb a certain network even though it may not be able to target a particular node within that network. ++++ >>> Section 5.7: I think it might be worthwhile to include a >>> paragragh describing how the mobile node's credit is measured. I >>> recently attempted to construct a bandwidth measuring algorithm >>> and found it not so simple. There are probably very simple ways >>> to do it, but I think they may not be obvious to the casual >>> reader. >> >> The basic mode for CBA is just packet counting, or rather byte >> counting. Paragraph 3 explains this already, I think. > > Hmm, so things like bursts and such are not accounted for? It seems > like a MN wanting to game the system or even an attacker could simply > bombard the CN with traffic, build up a huge account, then use that > to mount an attack. I guess I need to read the CBA draft again, it's > been a while since I read it. See my response at http://www1.ietf.org/mail-archive/web/mobopts/current/msg00439.html >> Perhaps, what you are having in mind is how the CN comes up with a >> rate limit? CBA has a loose data-rate limit in that the credit >> ages over time. So a MN cannot acquire credit slowly and use it up >> all at once. But that's said in the text as well. > > Does the CN also use an algorithm where it reduces the credit if it > thinks that the MN is gaming or it is being bombarded in order to > build up enough credit to launch an attack? IKE does something like > this, it reduces the timeout on cookies during IKE_INIT if it thinks > it is under DoS attack. Again, see http://www1.ietf.org/mail-archive/web/mobopts/current/msg00439.html >> Bandwidth and throughput measurements are not so simple. Care-of >> Address Spot Checks can be used to find approximations, which are >> good enough for the purpose of CBA. Maybe, this is what was >> unclear to you? > > Yes, perhaps a little more detail would be useful, but I guess > ultimately people need to read the CBA draft. I replaced quite a bit of text in section "Credit-Based Authorization". It should be much more understandable now. >>> Section 5.7, para 5.7: I wonder if the Spot Check tokens aren't a >>> potential state depletion threat. Since they are essentially per >>> flow state, an attacker could iterate creating a bunch of flows >>> until the victim's Spot Check token storage was exhausted. >> >> No, the tokens for spot checks can be derived similar to how the CN >> creates Home and Care-of Keygen Tokens. Do you think this should >> be explained in the text? I think it may lead too far. > > OK, I think people can go back to the original source if they want > the detail. I agree. >>> Section 6.2.4: Can CBA somehow get rid of the need to >>> re-authorize every 7 minutes? If the MN is building credit, then >>> perhaps it doesn't need to re-authorize because its ability to >>> attack is limited by the credit. Of course, the issue of the home >>> address test would have to be addressed too, but I think it >>> worthwhile to explore this, since the signaling overhead of RR is >>> onerous. >> >> It can. We wrote that down in > > http://www.watersprings.org/pub/id/draft-arkko-mipv6-binding-lifetime-extension-00.txt > > > Good. Ok. >> But why would CGA and CBA have a problem with this? Both CGA and >> CBA have a very large applicability; CGA with respect to >> home-address authentication/authorization and CBA with respect to >> moving the care-of-address test out of the "critical phase" (which >> we now have defined ;) ). >> >> Foremost, the independence of CGA from infrastructure (you don't >> need the certification authorities) is very attractive. And CBA >> applies to basically every IP-mobility protocol. > > Yes, that is exactly my point. These two approaches have the right > kind of properties for a next-gen solution that should be of wide > appeal, the others so far don't. :-) Alright, that's it. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ James Kempf wrote: > Hi Christian, > > Thanx for the response. Below, a couple of follow-ups. > > jak > > -------------------------------------------------------- > > >>> Section 4.2, 3rd & 4th para: I've never been convinced that a >>> mobile node would want to keep optimized routes hot while it was >>> in dormant mode, and this example doesn't convince me either. >>> Route optimization helps with RTT latency, and such latency is an >>> issue primarily in real time traffic. The example given here, a >>> messaging server (presumably IM), is a store and forward system >>> that will derive little benefit from keeping routes hot during >>> optimization. Even for real time traffic, like VoIP, the CN still >>> has to do SIP signaling to initiate the connection, and while >>> there is some amount of urgency to the signaling above a store >>> and forward application, it still is not going to suffer if the >>> traffic is routed through the home agent. The latency involved in >>> initiating the IP connection with the dormant mode mobile node >>> through paging is likely to exceed any benefit from keeping >>> optimized routes hot. >> >> Should we remove the example and say instead that it be worthwhile >> to save the wireless bandwidth? >> > > > Yes, I think that should be enough. > > >>> Section 5, para 1: Are the tradeoffs between universal >>> applicablity v.s. efficiency discussed in this paper anywhere? >>> This would be the ideal paper to have the discussion. >> >> It's mentioned where pre-configuration is discussed, for instance. >> > > > Might be good to give it a more prominant place, perhaps up front. It > is a good architectural point, that should not get lost in the > details of the various techniques. > > >>> Section 5.5, para 2: Later in the paper, you discuss this, but >>> the statistical uniqueness properties of CGAs suggest that the >>> care-of test might not be needed since the probability of another >>> node having exactly the same interface identifier is fairly low. >>> I think you should state that here. It is the same tradeoff that >>> optimistic DAD makes. The argument you advance later in the paper >>> that the attacker can still mount an attack on the subnet is >>> irrelevent. An attacker can do that without using route >>> optimization, by creating a zombie and programming it to iterate >>> through non-existant addresses in the victim subnet. >> >> I think there is still an issue with CGAs and RO of which one needs >> to be aware: >> >> An attacker could use any interface identifier in order to bomb a >> certain network. The only thing that matters in such a case is the >> network prefix. >> >> Route optimization does not create the issue with flooding, but it >> can aggravate it. You get amplification without programming a >> zombie and distributing viral software. And if you choose to >> program a zombie nonetheless, the zombie can misuse route >> optimization for you. (In the latter case, the zombie would contact >> a large set of powerful correspondent nodes, download large files, >> and redirect those files to the target network. This is "more >> efficient" compared to when the zombie alone sends packets.) >> > > > OK, so it sounds as if RO using CGA w.o. an RR test will provide additional > leverage to an attacker, right? Perhaps you could explain this a little more > in the draft? > > > >>> Section 5.7: I think it might be worthwhile to include a >>> paragragh describing how the mobile node's credit is measured. I >>> recently attempted to construct a bandwidth measuring algorithm >>> and found it not so simple. There are probably very simple ways >>> to do it, but I think they may not be obvious to the casual >>> reader. >> >> The basic mode for CBA is just packet counting, or rather byte >> counting. Paragraph 3 explains this already, I think. >> > > > Hmm, so things like bursts and such are not accounted for? It seems > like a MN wanting to game the system or even an attacker could simply > bombard the CN with traffic, build up a huge account, then use that > to mount an attack. > I guess I need to read the CBA draft again, it's been a while since I > read it. > > >> Perhaps, what you are having in mind is how the CN comes up with a >> rate limit? CBA has a loose data-rate limit in that the credit >> ages over time. So a MN cannot acquire credit slowly and use it up >> all at once. But that's said in the text as well. >> > > > Does the CN also use an algorithm where it reduces the credit if it > thinks that the MN is gaming or it is being bombarded in order to > build up enough credit to launch an attack? IKE does something like > this, it reduces the timeout on cookies during IKE_INIT if it thinks > it is under DoS attack. > > >> Bandwidth and throughput measurements are not so simple. Care-of >> Address Spot Checks can be used to find approximations, which are >> good enough for the purpose of CBA. Maybe, this is what was >> unclear to you? >> > > > Yes, perhaps a little more detail would be useful, but I guess > ultimately people need to read the CBA draft. > > >>> Section 5.7, para 5.7: I wonder if the Spot Check tokens aren't a >>> potential state depletion threat. Since they are essentially per >>> flow state, an attacker could iterate creating a bunch of flows >>> until the victim's Spot Check token storage was exhausted. >> >> No, the tokens for spot checks can be derived similar to how the CN >> creates Home and Care-of Keygen Tokens. Do you think this should >> be explained in the text? I think it may lead too far. >> > > > > OK, I think people can go back to the original source if they want > the detail. > > >>> Section 6.2.4: Can CBA somehow get rid of the need to >>> re-authorize every 7 minutes? If the MN is building credit, then >>> perhaps it doesn't need to re-authorize because its ability to >>> attack is limited by the credit. Of course, the issue of the home >>> address test would have to be addressed too, but I think it >>> worthwhile to explore this, since the signaling overhead of RR is >>> onerous. >> >> It can. We wrote that down in >> > > http://www.watersprings.org/pub/id/draft-arkko-mipv6-binding-lifetime-extension-00.txt > > > Good. > > >> But why would CGA and CBA have a problem with this? Both CGA and >> CBA have a very large applicability; CGA with respect to >> home-address authentication/authorization and CBA with respect to >> moving the care-of-address test out of the "critical phase" (which >> we now have defined ;) ). >> >> Foremost, the independence of CGA from infrastructure (you don't >> need the certification authorities) is very attractive. And CBA >> applies to basically every IP-mobility protocol. >> > > > Yes, that is exactly my point. These two approaches have the right > kind of properties for a next-gen solution that should be of wide > appeal, the others > so far don't. > > jak --------------enig177D579897C75D1A967D63CC 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.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC2kuiwstEk8gl2rURAu3cAJ9LstAhekHhw8zSGerYRMH8qtp84gCfeNfU HjSSW4WaI5aF92yjdRqDmng= =gbtB -----END PGP SIGNATURE----- --------------enig177D579897C75D1A967D63CC-- --===============1241107039== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1241107039==-- From mip6-bounces@ietf.org Sun Jul 17 08:21:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du89Z-0003re-EY; Sun, 17 Jul 2005 08:21:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Du89X-0003r7-RT; Sun, 17 Jul 2005 08:21:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00743; Sun, 17 Jul 2005 08:21:50 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1/cIZwOh6RhbVDZA5CryscnIu8RJHp4tLE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Du8cl-0002kJ-L5; Sun, 17 Jul 2005 08:52:03 -0400 Received: from hsi-kbw-082-212-035-085.hsi.kabelbw.de ([82.212.35.85] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1Du89T-0005RF-NK; Sun, 17 Jul 2005 14:21:50 +0200 Message-ID: <42DA4D5A.7070601@tm.uka.de> Date: Sun, 17 Jul 2005 14:21:46 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: MOBOPTS , MIP6 X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -1.6 (-) X-Spam-Status: No X-Spam-Score: 2.4 (++) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Jari Arkko , Rajeev Koodli Subject: [Mip6] Draft-irtf-mobopts-ro-enhancements-00.txt Revised 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="===============0808089593==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0808089593== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7C2BBC1EE440D50CB445A24E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7C2BBC1EE440D50CB445A24E Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi everybody, draft-irtf-mobopts-ro-enhancements-00.txt has been thoroughly reviewed by Samita Chakrabarti, Francis Dupont, Thierry Ernst, Gerardo Giaretta, James Kempf, Rajeev Koodli, Gabriel Montenegro, and Vidya Narayanan (in alphabetical order). Thanks to all of them. I incorporated most of the suggestions from these folks. The new version is now available at http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-01-pre.txt and I will submit it tomorrow at 6:00 am ET. BTW, the draft has a dedicated Acknowledgements section, right after the Introduction, referring to the many reviews that we got. Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ --------------enig7C2BBC1EE440D50CB445A24E 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.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC2k1awstEk8gl2rURArBEAKCiSpzpywFAkGdSmjYukZ/tGTFf2wCfXhBO et5unllqp8xLfTqQvDYF06A= =19Cx -----END PGP SIGNATURE----- --------------enig7C2BBC1EE440D50CB445A24E-- --===============0808089593== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0808089593==-- From mip6-bounces@ietf.org Sun Jul 17 13:33:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuD1Z-0003ea-Tf; Sun, 17 Jul 2005 13:33:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtYv2-00038l-I8; Fri, 15 Jul 2005 18:44:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02158; Fri, 15 Jul 2005 18:44:29 -0400 (EDT) Received: from mailn.site.uottawa.ca ([137.122.89.142] helo=mail.site.uottawa.ca ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtZNw-000178-BA; Fri, 15 Jul 2005 19:14:24 -0400 Received: from paradise0.site.uottawa.ca (paradise0.site.uottawa.ca [137.122.93.16]) by mail.site.uottawa.ca (8.9.3/8.9.3) with ESMTP id XAA67336 for ; Thu, 14 Jul 2005 23:34:02 -0400 (EDT) Received: from paradise0.site.uottawa.ca (localhost.localdomain [127.0.0.1]) by paradise0.site.uottawa.ca (8.13.4/8.13.4) with ESMTP id j6F3cT2j030558 for ; Thu, 14 Jul 2005 23:38:29 -0400 Received: (from call-for-papers@localhost) by paradise0.site.uottawa.ca (8.13.4/8.13.4/Submit) id j6F3cTKZ030557 for cfp-list@site.uottawa.ca; Thu, 14 Jul 2005 23:38:29 -0400 Date: Thu, 14 Jul 2005 23:38:29 -0400 From: Call For Papers Message-Id: <200507150338.j6F3cTKZ030557@paradise0.site.uottawa.ca> To: undisclosed-recipients:; X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 X-Mailman-Approved-At: Sun, 17 Jul 2005 13:33:57 -0400 Subject: [Mip6] Extension: 2nd ACM Workshop on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiquitous Networks 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 Due to numerous requests, the Submission deadline is extended to: July 22nd (Firm Deadline) [Please accept our apologies if you receive multiple copies of this CFP] ----------------------------------------------------------------------- Please email us on rshaikh@site.uottawa.ca with the word "UNSUBSCRIBE" if you would like to be removed from this mailing-list. ----------------------------------------------------------------------- CALL FOR PAPERS 2nd ACM Workshop on Performance Evaluation of Wireless Ad Hoc, Sensor, and Ubiquitous Networks (PE-WASUN' 2005) http://www.dcs.gla.ac.uk/~mohamed/wasun05/pe-wasun05.html To be held in conjunction with ACM/IEEE MSWiM'2005 http://www.cs.unibo.it/mswim2005/ Montreal, Qc. Canada, October 10-13, 2005 ------------------------------------------------------------------------- Submission deadline: July 22nd, 2005 SCOPE: Wireless ad hoc, sensor, along with ubiquitous networks have recently witnessed their fastest growth period ever in history, and this trend is likely to continue for the foreseeable future. However, as such networks become increasingly complex, performance modelling and evaluation will play a crucial part in their design process to ensure their successful deployment and exploitation in practice. This workshop will bring together scientists, engineers, and practitioners to share and exchange their experiences, discuss challenges, and report state-of-the-art and in-progress research on all aspects of wireless ad hoc, sensor, and ubiquitous networks with a specific emphasis on their performance evaluation and analysis. Topics of interest include, but are not limited to: * Predictive performance models of ad hoc, sensor, and ubiquitous networks * Performance measurement and monitoring tools * Tracing and trace analysis * Simulation * Analytical modeling * Software tools for network performance and evaluation * Automatic performance analysis * Performance comparison * Performance of wireless and sensor devices * RF channel capacity modeling and analysis * Mobility modeling and management * Traffic models for ad hoc, sensor networks * Probabilistic models for ad hoc, sensor, and ubiquitous networks * Improvement in network performance through optimization and tuning * Evaluation of multimedia over wireless ad hoc networks. * Evaluation of QoS provisioning in ad hoc and sensor networks * Evaluation of pervasive and ubiquitous computing * Performance tools for ad hoc, sensor and ubiquitous networks. * Performance and security issues in ad hoc, sensor, and ubiquitous networks * Performance and power management control * Case studies demonstrating the role of performance evaluation in the design of ad hoc, sensor, and ubiquitous networks WORKSHOP CO-CHAIRS: Mohamed Ould-Khaoua University of Glasgow UK Mineo Takai University of California, Los Angeles USA PROGRAM COMMITTEE (IN PROGRESSS): K. Al-Begain, Univ. of Glamorgan (UK) I. Awan, Univ. of Bradford (UK) R. Battiti, Univ. of Trento (Italy) P. Bellavista, Universita' di Bologna (Italy) L. Bononi, Univ. of Bologna (Italy) A. Boukerche, Univ. of Ottawa (Canada) T. Calamoneri, Univ. of Rome "La Sapienza" (Italy) C.-C. Shen, Univeristy of Delaware (USA) M. Colajanni, Univ. of Modena (Italy) G. Cugola, Politecnico di Milano (Italy) V. Gianuzzi, Univ. of Genova (Italy) I. Guerin-Lassous, INRIA (France) H. Karatza, Aristotle University of Thessaloniki (Greece) S. V. Krishnamurthy, University of California, Riverside (USA) Z. Liu, IBM T. J. Watson Research Center (USA) K. Mase, Niigata University (Japan) G. Min, Univ. of Bradford (UK) J. Misic, Univ. Manitoba (Canada) M. Naimi, University of Cergy-Pontoise (France) S. Nikoletseas, Computer Technology Institute (Greece) I. Nikolaidis, Univ. of Alberta (Canada) M. S. M. Annoni Notare, Barddal Univ. (Brazil) S. Olariu, Old Dominion Univ. (USA) Y. Pan, Georgia State Univ. (USA) A. Passarella, Univ. of Cambridge (UK) R. Wakikawa, Keio University (Japan) V. R. Syrotiuk, Arizona State University (USA) N. Thomas, Univ if Newcastle (UK) C.K. Toh, Queen Mary University of London (UK) Y. Yang, State University of New York, Stony Brook (USA) J. Wu, Florida Atlantic Univ. (USA) K. Wu, Univ. of Victoria (Canada) S. Yoshida, Kyoto University (Japan) F. Zambonelli, University of Modena and Reggio Emilia (Italy) A. Zomaya, Univ. of Sydney (Australia) PUBLICITY CHAIR Mirela Sechi Moretti Annoni Notare Barddal University Florianopolis, SC Brazil PAPER SUBMISSION: Authors are invited to submit manuscripts reporting original unpublished research and recent developments in the topics related to the workshop. The length of the papers should not exceed 10 single-spaced pages (in two-column format) including figures and references on 8.5 by 11 inch paper using at least 11 point font. Papers should be submitted electronically in PDF format (or postscript) by sending it as an e-mail attachment to mohamed@dcs.gla.ac.uk or mineo@cs.ucla.edu. All papers will be peer reviewed and the comments will be provided to the authors. Accepted papers will appear in the workshop proceedings and a special issue will be planned in a scholarly journal to include selected high-quality papers from the workshop. IMPRTANT DATES: * Submission Deadline: 22nd, July, 2005 * Author Notification: 20 August, 2005 * Final Manuscript Due: 30 August, 2005 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jul 17 13:33:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuD1a-0003ez-BP; Sun, 17 Jul 2005 13:33:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtZlJ-00033x-EL; Fri, 15 Jul 2005 19:38:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07303; Fri, 15 Jul 2005 19:38:29 -0400 (EDT) Received: from mailn.site.uottawa.ca ([137.122.89.142] helo=mail.site.uottawa.ca ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DtaEB-0003Hs-PJ; Fri, 15 Jul 2005 20:08:26 -0400 Received: from paradise0.site.uottawa.ca (paradise0.site.uottawa.ca [137.122.93.16]) by mail.site.uottawa.ca (8.9.3/8.9.3) with ESMTP id WAA64576 for ; Thu, 14 Jul 2005 22:54:24 -0400 (EDT) Received: from paradise0.site.uottawa.ca (localhost.localdomain [127.0.0.1]) by paradise0.site.uottawa.ca (8.13.4/8.13.4) with ESMTP id j6F2wp9u030159 for ; Thu, 14 Jul 2005 22:58:51 -0400 Received: (from call-for-papers@localhost) by paradise0.site.uottawa.ca (8.13.4/8.13.4/Submit) id j6F2wp9F030158 for cfp-list@site.uottawa.ca; Thu, 14 Jul 2005 22:58:51 -0400 Date: Thu, 14 Jul 2005 22:58:51 -0400 From: Call For Papers Message-Id: <200507150258.j6F2wp9F030158@paradise0.site.uottawa.ca> To: undisclosed-recipients:; X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 X-Mailman-Approved-At: Sun, 17 Jul 2005 13:33:57 -0400 Subject: [Mip6] Reminder: ACM -Wireless Multimedia Networking and Performancec Modeling 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 [Please accept our apologies if you receive multiple copies of this CFP] ----------------------------------------------------------------------- Please email us on rshaikh@site.uottawa.ca with the word "UNSUBSCRIBE" if you would like to be removed from this mailing-list. =========================================================================== CALL FOR PAPERS 1st ACM Workshop on Wireless Multimedia Networking and Performance Modeling (WMuNeP '05) Thursday, October 13th, 2005 Montreal, Quebec, Canada http://www2.dcc.ufmg.br/~loureiro/wmunep05.html =========================================================================== To be held in conjunction with ACM MSWiM'05 Best papers will be selected for the Journal of Pervasive Computing and Communications. Sponsored by: ACM In cooperation with: IEEE Computer Society Supported by: UFMG, Brazil ============================================================================= Submision deadline: July 20th, 2005 ============================================================================= The demand for wireless multimedia communications thrives in today's consumer and corporate market. The need to evolve multimedia applications and services, and their associated protocols for emerging networks is at a critical point given the proliferation and integration of wireless systems to intelligent and broadband networks, mobility of people, data/voice convergence and the integration of computing and communication in mobile devices. This workshop is devoted to cover different aspects of wireless multimedia networking and performance modeling for WLANs, WPANs, WMANs, WWANs, MANETs and sensor networks such as wireless video and wireless streaming, systematic design methodologies, algorithms, synchronization, analysis and performance modeling. The workshop will provide a forum for researchers and practitioners to present their contributions related to the above high-level aspects. Topics of interest include (but are not limited to): * Wireless multimedia network management * Wireless multimedia traffic modeling * Middleware and reflective systems support for wireless multimedia * Proxy-based systems for video transcoding and content distribution * Performance modeling, monitoring and evaluation of wireless multimedia networks and systems * Multipoint, multicast wireless multimedia services * Deployment of wireless multimedia applications, services and networks * Protocols for wireless multimedia networks * QoS in wireless multimedia networks * Integration of wireless multimedia networks to broadband networks * End-to-end IP multimedia wireless communications * Coding and transmission for wireless multimedia networks * Distributed wireless multimedia services * Content-based wireless multimedia information retrieval tools * Video, streaming, real-time wireless multimedia communications and applications * Security in wireless multimedia networks * Wireless multimedia right protection and watermarking * Pricing mechanisms for wireless multimedia networks * E-Commerce and related applications for wireless multimedia networks * Multimedia evaluation and processing for wireless networks * Cross layer design for wireless multimedia networks * Analytical modeling of wireless multimedia networks * Software tools for system performance and evaluation of wireless multimedia networks * Performance comparison of wireless multimedia networks * Case studies showing the role of evaluation in the design of systems Important Dates: Submission deadline: July 20th, 2005 Notification of acceptance: August 20th, 2005 Camera ready papers: September 30th, 2005 Paper Submission Instructions: Authors are invited to submit research contributions representing original, previously unpublished work. Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. All papers will be refereed by at least three members of the program committee. Please direct any questions about the paper submission process to the Program Co-Chairs. Paper length should be no more than 20 pages, single column, double spaced, including tables and figures, and no less than 11pt fonts single or double side. No paper templates are provided in this phase. All paper submissions should be sent one of the Program Co-Chairs (loureiro AT dcc.ufmg.br, wzhuang AT bbcr.uwaterloo.ca). Authors should prepare a PostScript or Portable Document Format (PDF) version of their paper. Accepted papers will be published by ACM Press, as proceedings of the WMuNeP. At least one listed author on the final paper must register for and attend the workshop to present his/her paper. Venue: The 2005 ACM Workhop on Wireless Multimedia Networking and Performance Modeling (WMuNeP '05) will take place in Montreal, October 13, 2005, co-located with ACM MSWiM '05 . For more information see for instance http://www.montreal.com/tourism/general.html Workshop Co-Chairs: Antonio A.F. Loureiro, Federal University of Minas Gerais, Brazil Email: loureiro AT dcc.ufmg.br Weihua Zhuang, University of Waterloo, Canada wzhuang AT bbcr.uwaterloo.ca Program Committee: * Rossana Andrade, Federal University of Ceara, Brazil * Regina Araujo, Federal University of Sao Carlos, Brazil * Nazim Agoulmine, University of Evry, France * Raffaele Bruno, CNR, Italy * Hsiao-Hwa Chen, National Sun Yat-Sen Univ., Taiwan * Zihua Guo, Lenovo Corporate R&D, China * Hossam Hassanein, Queens University, Canada * Ekram Hossain, University of Manitoba, Canada * Hai Jiang, University of Waterloo, Canada * Tho Le-Ngoc, McGill University, Canada * Victor Leung, University of British Columbia, Canada * Wei Li, University of Toledo, USA * Jiangchuan Liu, Simon Fraser University, Canada * Pascal Lorenz, University of Haute Alsace, France * Brian Mark, George Mason University, USA * Jelena Misic, University of Manitoba, Canada * Mirela Sechi Moretti Annoni Notare, Barddal University, Brazil * Linnyer Ruiz, Federal University of Minas Gerais, Brazil * Jianping Pan, NTT MCL, USA * Yu-Chee Tseng, National Chiao Tung Univ., Taiwan * Murat Uysal, University of Waterloo, Canada * Guoliang (Larry) Xue, Arizona State University, USA * Yang Yang, University College London, UK * Junshan Zhang, Arizona State University, USA Further Information: For any further questions or inquiries please contact: Antonio A.F. Loureiro Department of Computer Science Federal University of Minas Gerais Belo Horizonte, Minas Gerais, Brazil E-mail: loureiro AT dcc.ufmg.br Tel: +55-31-3499-5860 Fax: +55-31-3499-5858 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 18 03:01:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuPd9-0003Zk-1Q; Mon, 18 Jul 2005 03:01:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuPd7-0003Zc-Ln for mip6@megatron.ietf.org; Mon, 18 Jul 2005 03:01:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15529 for ; Mon, 18 Jul 2005 03:01:32 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuQ6T-0007W8-2G for mip6@ietf.org; Mon, 18 Jul 2005 03:31:55 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6I71L1J023694; Mon, 18 Jul 2005 10:01:23 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 10:01:22 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 10:01:21 +0300 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] Draft on Securing Home Agent List Date: Mon, 18 Jul 2005 10:01:20 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CE94B@esebe100.NOE.Nokia.com> Thread-Topic: [Mip6] Draft on Securing Home Agent List Thread-Index: AcWJVJQhNnNuoQUGRrCbdFe/+NlFTQCEIvag To: , X-OriginalArrivalTime: 18 Jul 2005 07:01:21.0868 (UTC) FILETIME=[8117E8C0:01C58B66] X-Spam-Score: 0.3 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 James, > > This reminds me of an argument that I often see in the IETF, > > "implementations aren't doing RFC XXXX, so we have to develop > > RFC YYYY to fix that". Needless to say, its often the case that > > thereafter the implementations aren't doing either XXXX or > > YYYY :-) > > > > In some cases (perhaps with SEND too) one may wonder if > > a complicated piece of other functionality is needed to implement > > something simple. In such cases it may make some sense to > > develop alternative schemes. However, in this particular case > > it would suffice to implement a very small part of SEND, just the > > RA security and only on the home agents, not on all nodes. > > The scalability and ease of configuration of that part of SEND > > is probably close to what any other cryptographic solution would > > be able to offer, so working on other cryptographic solutions > > would probably not make much sense. A non-cryptographic, liveness > > based scheme might be OK, but they don't seem to address > > the threat that people wanted to fix, so unless we invent something > > new I don't think we want to go there. > > >=20 > Yes, that's true. >=20 > Though the WG did have a discussion about whether or not to use IPsec = on the > HA to MN connection, nobody seemed to be making the case that "we = shouldn't > mandate using IPsec in Mobile IP" (though of course now we have the > mip6-auth option).=20 My feeling is that the WG had no choice in this matter - I doubt that = MIP would have gotten through a security review without it. > I know protocol designers like to avoid "dependencies", > people are constantly trying to avoid using TCP and then they end up > reinventing congestion control. >=20 > My point was that if there is an existing protocol that solves the = problem, > then why not use it? I'm not sure that I buy this argument. Basically, TCP is available in = almost all (if not all) OSes, so its other considerations that make people = forgo TCP, usually based on performance reasons (including local OS = performance issues like wanted to do everything inside kernal space). I'm not sure that's why Jari was discussing about. > > Anyway, in this discussion I think we should first focus on > > figuring out if a protocol mechanism is needed at all > > rather than arguing what it should be. (A protocol mechanism > > is not needed if, for instance, addition of some configuration > > information to the implementations would avoid the need to > > trust RAs. I'm not saying this solves this problem, but at least > > we should look at it.) > > >=20 > Well it is always good to have a clear and concise statement of the = problem > before attempting to solve it. If the problem lends itself to a > configuration solution rather than a protocol solution, then so much = the > better. My feeling is that if SEND is available, using it to solve this problem is a good idea; however also stating that if SEND is not available, then some configuration mechanisms probably will solve this issue. I think this is relevant information to the problem - for example even if you have SEND implemented and use it to Secure the Home Agent list - what happens when you roam to a network without SEND? A hostile network = probably wouldn't deploy SEND in the first place, so the mobile node would not have the ability to secure its home agent list. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 18 05:11:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuRf1-00074e-SC; Mon, 18 Jul 2005 05:11:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuRew-00073c-FM for mip6@megatron.ietf.org; Mon, 18 Jul 2005 05:11:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24394 for ; Mon, 18 Jul 2005 05:11:32 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuS8J-00008X-Nj for mip6@ietf.org; Mon, 18 Jul 2005 05:41:57 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8E846898A1; Mon, 18 Jul 2005 12:11:19 +0300 (EEST) Message-ID: <42DB7240.4040109@kolumbus.fi> Date: Mon, 18 Jul 2005 12:11:28 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: john.loughney@nokia.com Subject: Re: [Mip6] Draft on Securing Home Agent List References: <1AA39B75171A7144A73216AED1D7478D6CE94B@esebe100.NOE.Nokia.com> In-Reply-To: <1AA39B75171A7144A73216AED1D7478D6CE94B@esebe100.NOE.Nokia.com> 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, Kempf@docomolabs-usa.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 Hi John, >>Well it is always good to have a clear and concise statement of the problem >>before attempting to solve it. If the problem lends itself to a >>configuration solution rather than a protocol solution, then so much the >>better. >> >> > >My feeling is that if SEND is available, using it to solve this problem >is a good idea; however also stating that if SEND is not available, then >some configuration mechanisms probably will solve this issue. I think > > To me, SEND is the right choice, if people think the configuration scheme is insufficient as a solution. But I think it would be helpful for the IETF to decide what level of a solution they want and recommend that, rather than providing a number of different solutions. >this is relevant information to the problem - for example even if you >have SEND implemented and use it to Secure the Home Agent list - what >happens when you roam to a network without SEND? A hostile network probably >wouldn't deploy SEND in the first place, so the mobile node would not >have the ability to secure its home agent list. > > The intent of this draft was to secure the process where the home agents on the home link discover each others' presence. As a result, its only the home network admins who get to decide how to do it; the availability of various tools in the visited networks is not an issue. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 18 05:19:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuRm9-0000DV-HT; Mon, 18 Jul 2005 05:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuRm7-0000DD-Vr for mip6@megatron.ietf.org; Mon, 18 Jul 2005 05:19:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24733 for ; Mon, 18 Jul 2005 05:18:57 -0400 (EDT) From: john.loughney@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuSFT-0000aK-Qr for mip6@ietf.org; Mon, 18 Jul 2005 05:49:23 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6I9DNYp007894; Mon, 18 Jul 2005 12:13:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 12:18:50 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 12:18:50 +0300 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] Draft on Securing Home Agent List Date: Mon, 18 Jul 2005 12:18:50 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D6CE955@esebe100.NOE.Nokia.com> Thread-Topic: [Mip6] Draft on Securing Home Agent List Thread-Index: AcWLeNvDbvznK6BbTBiZvbeMaq1lkgAAHc5Q To: X-OriginalArrivalTime: 18 Jul 2005 09:18:50.0808 (UTC) FILETIME=[B5D84380:01C58B79] X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Kempf@docomolabs-usa.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 Hi Jari, > >My feeling is that if SEND is available, using it to solve this = problem > >is a good idea; however also stating that if SEND is not available, = then > >some configuration mechanisms probably will solve this issue. I = think > > =20 > To me, SEND is the right choice, if people think the configuration > scheme is insufficient as a solution. But I think it would be > helpful for the IETF to decide what level of a solution they want > and recommend that, rather than providing a number of > different solutions. Re-reading the draft, I agree that SEND seems to be a good tool to solve this problem. =20 > >this is relevant information to the problem - for example even if you > >have SEND implemented and use it to Secure the Home Agent list - what > >happens when you roam to a network without SEND? A hostile network = probably > >wouldn't deploy SEND in the first place, so the mobile node would not > >have the ability to secure its home agent list. > > =20 > The intent of this draft was to secure the process where > the home agents on the home link discover each others' > presence. As a result, its only the home network admins who > get to decide how to do it; the availability of various tools > in the visited networks is not an issue. Ack. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 18 05:44:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuSAW-0006D7-ET; Mon, 18 Jul 2005 05:44:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuSAS-0006Cl-SW for mip6@megatron.ietf.org; Mon, 18 Jul 2005 05:44:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26325 for ; Mon, 18 Jul 2005 05:44:06 -0400 (EDT) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuSdl-0002Pv-Qv for mip6@ietf.org; Mon, 18 Jul 2005 06:14:32 -0400 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IJT0093LH2FFB@dns2.cselt.it> for mip6@ietf.org; Mon, 18 Jul 2005 11:30:15 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 18 Jul 2005 11:42:12 +0200 Date: Mon, 18 Jul 2005 11:43:47 +0200 From: Gerardo Giaretta Subject: RE: [Mip6] Re: Review of draft-irtf-mobopts-ro-enhancements-00 To: Christian Vogt Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Re: Review of draft-irtf-mobopts-ro-enhancements-00 thread-index: AcWLbwCTdkEXI55HRFOeIaVXkbXZfQADhiCQ Content-Class: urn:content-classes:message X-OriginalArrivalTime: 18 Jul 2005 09:42:12.0843 (UTC) FILETIME=[F985D3B0:01C58B7C] X-Spam-Score: 2.4 (++) X-Scan-Signature: 57b3d456dc4730784e7070d5c6b7d14f Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Rajeev Koodli , Jari Arkko , mobopts@irtf.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 Hi Christian, the text sounds good to me. Thanks, --Gerardo > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On=20 > Behalf Of Christian Vogt > Sent: domenica 17 luglio 2005 14.12 > To: Gerardo Giaretta > Cc: mip6@ietf.org; Rajeev Koodli; Jari Arkko; mobopts@irtf.org > Subject: [Mip6] Re: Review of draft-irtf-mobopts-ro-enhancements-00 >=20 > Hi Gerardo, >=20 > you had one more comment concerning the section on processing=20 > improvements: >=20 > > Not necessarily. However, even without any reference, some more > > details can be useful. As you mention RR was designed with low > > computational complexity in mind. If you state that it can be too > > expensive, you should at least provide some examples, scenarios or > > data. >=20 > Thinking more about this, I tend to conclude that the=20 > complexity of the > return-routability procedure is already very low. One may further > reduce processing requirements through easier ways to compute the Home > and Care-of Keygen Tokens, or the KBM. But that's probably=20 > not so urgent. >=20 > Here is the new text: >=20 > 5.17 Processing Improvements >=20 > One goal for designing the return-routability procedure=20 > was to limit > its computational complexity to a minimum. The=20 > processing overhead > for route optimization should thus be acceptable in general. > However, some alternatives to the return-routability procedure use > stronger cryptographic algorithms, such as public-key=20 > cryptography. > This can be more taxing on processing resources,=20 > especially for low- > provisioned handheld devices. Here, it may help to replace RSA > algorithms with ECC techniques. >=20 > Regards, >=20 > - Christian >=20 > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ >=20 >=20 >=20 > Gerardo Giaretta wrote: > > Hi Christian, > > > > thanks for your replay. Some comments below... > > > > > >> Hi Gerardo, > >> > >> thanks again for reviewing the doc. Some responses below. You can > >> check the new version at > >> > >> http://doc.tm.uka.de/2005/draft-irtf-mobopts-ro-enhancements-0 > >> 1-pre.txt > >> > >> - Christian > >> > >> ++++ > >> > >> > >>> General comment: I think the draft is very well-written and > >> > >> provide a > >> > >>> complete analysis of the topic. The unique general issue I found > >>> is that it is very long. I agree with James' comment that the > >>> draft could be shortened removing some sections that are not > >>> completely in the scope of the draft (e.g. section 5.13 and 5.14, > >>> more about these sections below). > >> > >> Ok, will do that. > >> > >> > >>> More detailed comments: > >>> > >>> - section 1, paragraph 4 "In the opposite direction, the mobile > >>> node may tunnel packets to the home agent". I think this sentence > >>> is not completely correct, or at least a bit misleading. If route > >>> optimization is not used, the MN MUST tunnel packets to the HA. > >>> Is "MAY" used in this sentence to highlight that the MN can > >>> choose to use bidirectional tunneling or route optimization? > >> > >> You are right, the text is misleading. The idea was that RO is the > >> alternative, and the MN may choose (provided the CN supports RO). > >> But, again, this is confusing, so I changed it. > >> > >> > >>> - section 1, paragraph 10 "This can lead to handover delay > >>> unacceptable for many real-time or interactive applications like > >>> Voice over IP (VoIP) and audio or video streaming". I'd suggest > >>> to remove audio/video streaming here. Streaming applications are > >>> not real-time nor interactive: they usually buffer few seconds of > >>> the movie/sound and thus are usually not affected by MIPv6 > >>> handover latency. At least this is what we have experimented in > >>> our labs. > >> > >> Would you say that rapid handovers and small buffers in > >> less-provisioned devices can be an issue with streaming? > >> > > > > > > Yes, it can be an issue. But this depends on the device capabilities > > and not on strong application requirements. Usually, in most > > streaming applications, buffer size is configurable and has=20 > a default > > value of few seconds. > > > > > >> Anyway, I changed the text. > >> > > > > > > Good. > > > > > >>> - section 3.1, paragraph 7 "The mobile node must compute a > >>> message-authentication code keyed with the Home and Care-of > >>> Keygen Token". Actually the MAC is keyed with the Kbm, that is a > >>> 20 octets SHA-1 hash of the concatenation of Home and Care-of > >>> Keygen Token > >> > >> Right, this was imprecise. Corrected it. > >> > >> > >>> - section 4.1, paragraph 1: I would mention explicitly that the > >>> handoff latency for a route-optimized communication is longer > >>> than for a bi-directional tunneled communication. > >> > >> Yes, it's added. > >> > >> > >>> - section 4.1, paragraph 2: since the CN is not always required > >>> to send the BA, I wonder why the MN should by default wait for > >>> the BA. Or are you suggesting the MN asks the CN an ack? If so, I > >>> think the sentence should be rephrased. > >> > >> Right. > >> > >> > >>> - section 4.1, paragraph 3 "But more generally, mobile > >> > >> nodes wait for > >> > >>> the home registration to be completed and acknowledged before > >>> initiating the correspondent registration". Are you > >> > >> referring to some > >> > >>> specific implementations? I'm asking this because the open source > >>> implementation we use in our labs does not wait the BA. > >> > >> Kame-Shisa does it. We added the optimization not to wait for the > >> BA from the HA. > >> > >> Actually, not waiting for the BA is not standard-conform. RFC 3775 > >> says that the lifetime of correspondent registrations must not > >> exceed that of the home registration. And the latter becomes known > >> to the MN only with the BA. > >> > >> I don't think this requirement is critical, though. After all, > >> it's up to the MN to request the CN lifetime anyway. It could just > >> ignore the home-registration lifetime. > >> > > > > > > I tend to agree on this. This implementation choice can improve > > performance. > > > > > > > >>> - section 4.4, paragraph 2: I would add references to > >>> draft-koodli-mip6-location-privacy-00 and to > >>> draft-koodli-mip6-location-privacy-solutions-00 > >> > >> Definitely a good idea. > >> > >> > >>> - section 5.2, paragraph 1: What do you mean by "close to > >> > >> the mobile > >> > >>> node"? Shouldn't it be "on the path between MN and HA"? > >> > >> The critical link on the patch between the MN and the HA is a > >> wireless first hop. > >> > >> Anyway, the text is unclear. Rewrote that sentence. > >> > >> > >>> - section 5.3, paragraph 2: the sentence is not clear to > >> > >> me. The last > >> > >>> BA is referred to BA from CN, I suppose. If so, I think it > >> > >> should be > >> > >>> mentioned explicitly. > >> > >> Done. > >> > >> > >>> - section 5.13: as mentioned before I think this section is not > >>> really in the scope of the draft. If you think it is, I'd suggest > >>> to include some more text explaining how HMIPv6 influences RO > >> > >> operations > >> > >>> (e.g. reduction of signaling overhead). The same applies to > >>> section 5.14. I think that FMIPv6 has even less impact on RO than > >>> HMIPv6. So I suggest you include some more text to explain how > >>> these protocols are tied to RO. > >> > >> It seems there is pretty much agreement in that FMIPv6 and HMIPv6 > >> should be removed from this particular document. > >> > >> > >>> - section 5.16, last sentence: are there simulations that prove > >>> that RR can be too expensive? A reference could be helpful. > >> > >> I don't have such a reference. Is your suggestion to remove the > >> section in this case? > >> > > > > > > Not necessarily. However, even without any reference, some more > > details can be useful. As you mention RR was designed with low > > computational complexity in mind. If you state that it can be too > > expensive, you should at least provide some examples, scenarios or > > data. > > > > --Gerardo > > > > > >>> - section 6.2.1, last paragraph: HMIPv6 causes always a tunneling > >>> overhead that is not present in plain MIPv6. Therefore, some > >>> localized mobility protocols always cause overhead and not only > >>> "in some situations". > >> > >> That's right. But I have already removed that sub-section. > >> > >> > >>> - section 6.2.2, paragraph 1 "On the other hand, nodes that do > >>> share a common secret should be allowed to omit the home-address > >>> test". Isn't required that the common secret is tied to the Home > >>> Address used in order to remove the home address test? > >> > >> You are right. Added that. > >> > >> > >>> Editorial comments: > >>> > >>> - section 4.1, last paragraph: Section 6.3.1 should be in > >> > >> brackets or > >> > >>> similar > >> > >> Oops, it's done. > >> > >> > >>> - section 5.1, paragraph 2: s/IP-ddress/IP-address > >> > >> Ok. > >> > >> > >>> - section 5.7, paragraph 5: s/its is the data/it is the data > >> > >> Ok. > >> > >> > >>> - section 5.8, paragraph 2: s/it in general/it is in general > >> > >> Ok. > >> > >> > >>> Hope this helps. > >> > >> It did. ;) > >> > >> Thanks, - Christian > >> > >> -- Christian Vogt, Institute of Telematics, University of Karlsruhe > >> www.tm.uka.de/~chvogt/pubkey/ > >> > >> > >> > >> Gerardo Giaretta wrote: > >> > >>> Hi Christian and Jari, > >>> > >>> Raj requested me to review draft-irtf-mobopts-ro-enhancements-00. > >>> Here are some comments and question. > >>> > >>> General comment: I think the draft is very well-written and > >> > >> provide a > >> > >>> complete analysis of the topic. The unique general issue I found > >>> is that it is very long. I agree with James' comment that the > >>> draft could be shortened removing some sections that are not > >>> completely in the scope of the draft (e.g. section 5.13 and 5.14, > >>> more about these sections below). > >>> > >>> More detailed comments: > >>> > >>> - section 1, paragraph 4 "In the opposite direction, the mobile > >>> node may tunnel packets to the home agent". I think this sentence > >>> is not completely correct, or at least a bit misleading. If route > >>> optimization is not used, the MN MUST tunnel packets to the HA. > >>> Is "MAY" used in this sentence to highlight that the MN can > >>> choose to use bidirectional tunneling or route optimization? > >>> > >>> - section 1, paragraph 10 "This can lead to handover delay > >>> unacceptable for many real-time or interactive applications like > >>> Voice over IP (VoIP) and audio or video streaming". I'd suggest > >>> to remove audio/video streaming here. Streaming applications are > >>> not real-time nor interactive: they usually buffer few seconds of > >>> the movie/sound and thus are usually not affected by MIPv6 > >>> handover latency. At least this is what we have experimented in > >>> our labs. > >>> > >>> - section 3.1, paragraph 7 "The mobile node must compute a > >>> message-authentication code keyed with the Home and Care-of > >>> Keygen Token". Actually the MAC is keyed with the Kbm, that is a > >>> 20 octets SHA-1 hash of the concatenation of Home and Care-of > >>> Keygen Token > >>> > >>> - section 4.1, paragraph 1: I would mention explicitly that the > >>> handoff latency for a route-optimized communication is longer > >>> than for a bi-directional tunneled communication. > >>> > >>> - section 4.1, paragraph 2: since the CN is not always required > >>> to send the BA, I wonder why the MN should by default wait for > >>> the BA. Or are you suggesting the MN asks the CN an ack? If so, I > >>> think the sentence should be rephrased. > >>> > >>> - section 4.1, paragraph 3 "But more generally, mobile > >> > >> nodes wait for > >> > >>> the home registration to be completed and acknowledged before > >>> initiating the correspondent registration". Are you > >> > >> referring to some > >> > >>> specific implementations? I'm asking this because the open source > >>> implementation we use in our labs does not wait the BA. > >>> > >>> - section 4.4, paragraph 2: I would add references to > >>> draft-koodli-mip6-location-privacy-00 and to > >>> draft-koodli-mip6-location-privacy-solutions-00 > >>> > >>> - section 5.2, paragraph 1: What do you mean by "close to > >> > >> the mobile > >> > >>> node"? Shouldn't it be "on the path between MN and HA"? > >>> > >>> - section 5.3, paragraph 2: the sentence is not clear to > >> > >> me. The last > >> > >>> BA is referred to BA from CN, I suppose. If so, I think it > >> > >> should be > >> > >>> mentioned explicitly. > >>> > >>> - section 5.13: as mentioned before I think this section is not > >>> really in the scope of the draft. If you think it is, I'd suggest > >>> to include some more text explaining how HMIPv6 influences RO > >> > >> operations > >> > >>> (e.g. reduction of signaling overhead). The same applies to > >>> section 5.14. I think that FMIPv6 has even less impact on RO than > >>> HMIPv6. So I suggest you include some more text to explain how > >>> these protocols are tied to RO. > >>> > >>> - section 5.16, last sentence: are there simulations that prove > >>> that RR can be too expensive? A reference could be helpful. > >>> > >>> - section 6.2.1, last paragraph: HMIPv6 causes always a tunneling > >>> overhead that is not present in plain MIPv6. Therefore, some > >>> localized mobility protocols always cause overhead and not only > >>> "in some situations". > >>> > >>> - section 6.2.2, paragraph 1 "On the other hand, nodes that do > >>> share a common secret should be allowed to omit the home-address > >>> test". Isn't required that the common secret is tied to the Home > >>> Address used in order to remove the home address test? > >>> > >>> > >>> Editorial comments: > >>> > >>> - section 4.1, last paragraph: Section 6.3.1 should be in > >> > >> brackets or > >> > >>> similar > >>> > >>> - section 5.1, paragraph 2: s/IP-ddress/IP-address > >>> > >>> - section 5.7, paragraph 5: s/its is the data/it is the data > >>> > >>> - section 5.8, paragraph 2: s/it in general/it is in general > >>> > >>> > >>> Hope this helps. > >>> > >>> Regards, --Gerardo > >>> > >>> > >>> > >>> > >>> > >>> > >>> Gruppo Telecom Italia - Direzione e coordinamento di Telecom > >>> Italia S.p.A. > >>> > >>> > >> > >>=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=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 > >>>=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=3D=3D=3D=3D > >>> > >> > >> > > > > > > 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=20 > addressed > > solely to the persons above and may contain confidential=20 > 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 >=20 >=20 >=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 Mon Jul 18 12:19:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuYL5-0007aP-Ra; Mon, 18 Jul 2005 12:19:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuYL3-0007aG-Vt for mip6@megatron.ietf.org; Mon, 18 Jul 2005 12:19:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25575 for ; Mon, 18 Jul 2005 12:19:27 -0400 (EDT) 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.43) id 1DuYoV-0004Ky-7S for mip6@ietf.org; Mon, 18 Jul 2005 12:49:56 -0400 Message-ID: <01da01c58bb4$70679d60$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: <1AA39B75171A7144A73216AED1D7478D6CE94B@esebe100.NOE.Nokia.com> Subject: Re: [Mip6] Draft on Securing Home Agent List Date: Mon, 18 Jul 2005 09:19:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 > I know protocol designers like to avoid "dependencies", > people are constantly trying to avoid using TCP and then they end up > reinventing congestion control. > > My point was that if there is an existing protocol that solves the problem, > then why not use it? I'm not sure that I buy this argument. Basically, TCP is available in almost all (if not all) OSes, so its other considerations that make people forgo TCP, usually based on performance reasons (including local OS performance issues like wanted to do everything inside kernal space). I'm not sure that's why Jari was discussing about. jak>> Sometimes these arguments are valid, other times they are just because engineers like inventing things and therefore want to do a congestion control algorithm or they mistrust TCP and SCTP or are misinformed about how TCP and SCTP work (or, at least, I've seen a couple cases where I would judge that this was the motivation). The IESG is often quite good at seeing through this kind of motivation, but it does tend to delay the approval of drafts. > Well it is always good to have a clear and concise statement of the problem > before attempting to solve it. If the problem lends itself to a > configuration solution rather than a protocol solution, then so much the > better. My feeling is that if SEND is available, using it to solve this problem is a good idea; however also stating that if SEND is not available, then some configuration mechanisms probably will solve this issue. I think this is relevant information to the problem - for example even if you have SEND implemented and use it to Secure the Home Agent list - what happens when you roam to a network without SEND? A hostile network probably wouldn't deploy SEND in the first place, so the mobile node would not have the ability to secure its home agent list. jak>> As I understand the problem, there is no issue except on the home link? So only the home link need deploy SEND (and of course the MN), which is why I think the analogy with IPsec is pretty close. jak>> Again, a good problem statement should help to clarify the issue. If the problem can be solved by configuration, as Jari mentioned, that is an even better solution. jak>> The metapoint I was trying to make is that saying "we should not have a dependency between our protocol and others" should not be an acceptable argument for ignoring a standards-track, RFC-ed protocol that solves the problem. This point goes beyond SEND, and beyond this particular problem. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 18 14:53:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duak4-0001oq-8P; Mon, 18 Jul 2005 14:53:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duak1-0001nF-BO for mip6@megatron.ietf.org; Mon, 18 Jul 2005 14:53:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05274 for ; Mon, 18 Jul 2005 14:53:24 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DubDQ-0004LZ-W1 for mip6@ietf.org; Mon, 18 Jul 2005 15:23:53 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6IILOY04706 for ; Mon, 18 Jul 2005 11:21:24 -0700 X-mProtect: <200507181821> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdKkjp88; Mon, 18 Jul 2005 11:21:22 PDT Message-ID: <42DBFA8A.7050200@iprg.nokia.com> Date: Mon, 18 Jul 2005 11:52:58 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird (X11/20050322) 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: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Subject: [Mip6] Version 02 of the MIP6-IKEv2 draft 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 hi folks, I just updated the MIP6 - IKEv2 draft. you can find version 02 at http://people.nokia.net/vijayd/mip6/mip6_ikev2.txt main changes are 1. the draft is now more self-contained with respect to the requirements section. you dont have to refer to RFC 3776 to lookup the requirements. this addresses concerns raised by Gerardo, Jari and Jim (section 4). 2. added some text in the security considerations section regarding home address configuration and the use of EAP to authenticate the HA to the MN. 3. added some text on what the SPD entries on the HA should contain when the MN's home address is not known yet (section 6.1.1) 4. added some text to say that the MN could use a range of selectors to use the same SA for multiple messages, for e.g., BU and BAck, instead of creating pairs of IPsec SA per mobility message type (section 6.2) 5. clarified the use of PKI and verification of identities presented by the mobility node (section 6.2) 6. added some text related to the use of 'K' bit and IKEv2 (section 6.3). 7. added some text related to the use of EAP_ONLY_AUTHENTICATION payload in section 7. you can see a diff from the previous version at http://people.nokia.net/vijayd/mip6/1to2_diff.html there is one major issue remaining. this was raised by Francis. it is related to mandating the use of MH type as a selector. I will send a separate mail on this. I hope to resolve this by the Paris IETF meeting. comments are welcome. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 18 20:30:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dug0U-0007vz-4V; Mon, 18 Jul 2005 20:30:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dug0S-0007u6-57 for mip6@megatron.ietf.org; Mon, 18 Jul 2005 20:30:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04350 for ; Mon, 18 Jul 2005 20:30:41 -0400 (EDT) Received: from mx2.buaa.edu.cn ([219.239.227.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DugTo-0002vm-Kb for mip6@ietf.org; Mon, 18 Jul 2005 21:01:13 -0400 Received: from mx1.buaa.edu.cn (mx1.buaa.edu.cn [192.168.128.5]) by mx2.buaa.edu.cn (Postfix) with ESMTP id AFB5937F6F for ; Tue, 19 Jul 2005 08:29:50 +0800 (CST) Received: from [210.76.115.36] by 10.0.0.130 with StormMail ESMTP id 53198.5679896285; Tue, 19 Jul 2005 08:59:56 +0800 (CST) Message-ID: <42DC496C.6080402@cse.buaa.edu.cn> Date: Tue, 19 Jul 2005 08:29:32 +0800 From: Li Qin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko , mip6@ietf.org Subject: Re: [Mip6] Draft on Securing Home Agent List References: <000001c5886b$304a2190$c504120a@china.huawei.com> <42D6B334.6040404@kolumbus.fi> In-Reply-To: <42D6B334.6040404@kolumbus.fi> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: 'James Kempf' , deshbandhus@huawei.com, 'COMBES Jean-Michel RD-MAPS-ISS' 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 Jari Arkko wrote: > I have reviewed this draft. > > I agree that the security of the home agents list on the home > link can be a problem. Or more generally, the security between > the different home agents on the home link can be a problem. Do you think that multiple home agents issue should be considered recently in the working group? -Qin _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 19 00:45:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DujzD-0006LP-Il; Tue, 19 Jul 2005 00:45:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DujzA-0006KU-Pd for mip6@megatron.ietf.org; Tue, 19 Jul 2005 00:45:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16647 for ; Tue, 19 Jul 2005 00:45:34 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DukSY-0002we-Em for mip6@ietf.org; Tue, 19 Jul 2005 01:16:10 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJU00A5BYN5KY@szxga01-in.huawei.com> for mip6@ietf.org; Tue, 19 Jul 2005 12:47:29 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJU00ACYYN5WM@szxga01-in.huawei.com> for mip6@ietf.org; Tue, 19 Jul 2005 12:47:29 +0800 (CST) Received: from sachin1734 ([10.18.4.197]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJU003D5YP7JT@szxml02-in.huawei.com>; Tue, 19 Jul 2005 12:48:44 +0800 (CST) Date: Mon, 18 Jul 2005 21:43:06 -0700 From: Sachin Dutta Subject: RE: [Mip6] Draft on Securing Home Agent List In-reply-to: <01da01c58bb4$70679d60$016115ac@dcml.docomolabsusa.com> To: "'James Kempf'" , john.loughney@nokia.com, jari.arkko@kolumbus.fi Message-id: <000701c58c1c$5c183370$c504120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7BIT Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sachind@huawei.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 > jak>> The metapoint I was trying to make is that saying "we should not > jak>> have > a dependency between our protocol and others" should not be an acceptable > argument for ignoring a standards-track, RFC-ed protocol that solves the > > problem. This point goes beyond SEND, and beyond this particular problem. Sachin >>> Jak I agree by you that standard tracks should not be ignored at the same time as Jari also put forward I believe Complexity of the problem vs Complexity of solution should be measured. It is upto WG to decide the complexity of the issue but I personally feel in this case that MIP6 protocol can come up with some parallel solution to address this issue rather then implementing complete SEND ~Sachin -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of James Kempf Sent: Monday, July 18, 2005 09:19 To: john.loughney@nokia.com; jari.arkko@kolumbus.fi Cc: mip6@ietf.org Subject: Re: [Mip6] Draft on Securing Home Agent List > I know protocol designers like to avoid "dependencies", > people are constantly trying to avoid using TCP and then they end up > reinventing congestion control. > > My point was that if there is an existing protocol that solves the problem, > then why not use it? I'm not sure that I buy this argument. Basically, TCP is available in almost all (if not all) OSes, so its other considerations that make people forgo TCP, usually based on performance reasons (including local OS performance issues like wanted to do everything inside kernal space). I'm not sure that's why Jari was discussing about. jak>> Sometimes these arguments are valid, other times they are just because engineers like inventing things and therefore want to do a congestion control algorithm or they mistrust TCP and SCTP or are misinformed about how TCP and SCTP work (or, at least, I've seen a couple cases where I would judge that this was the motivation). The IESG is often quite good at seeing through this kind of motivation, but it does tend to delay the approval of drafts. > Well it is always good to have a clear and concise statement of the problem > before attempting to solve it. If the problem lends itself to a > configuration solution rather than a protocol solution, then so much the > better. My feeling is that if SEND is available, using it to solve this problem is a good idea; however also stating that if SEND is not available, then some configuration mechanisms probably will solve this issue. I think this is relevant information to the problem - for example even if you have SEND implemented and use it to Secure the Home Agent list - what happens when you roam to a network without SEND? A hostile network probably wouldn't deploy SEND in the first place, so the mobile node would not have the ability to secure its home agent list. jak>> As I understand the problem, there is no issue except on the home link? So only the home link need deploy SEND (and of course the MN), which is why I think the analogy with IPsec is pretty close. jak>> Again, a good problem statement should help to clarify the issue. If the problem can be solved by configuration, as Jari mentioned, that is an even better solution. jak>> The metapoint I was trying to make is that saying "we should not have a dependency between our protocol and others" should not be an acceptable argument for ignoring a standards-track, RFC-ed protocol that solves the problem. This point goes beyond SEND, and beyond this particular problem. 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 Jul 19 15:53:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuyA1-0003q2-PF; Tue, 19 Jul 2005 15:53:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duy6h-0002hF-JI; Tue, 19 Jul 2005 15:50:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28141; Tue, 19 Jul 2005 15:50:21 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Duya9-0001c7-6Y; Tue, 19 Jul 2005 16:20:53 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1Duy6O-0002Rb-Ia; Tue, 19 Jul 2005 15:50:04 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 19 Jul 2005 15:50:04 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-ikev2-ipsec-02.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture Author(s) : V. Devarapalli Filename : draft-ietf-mip6-ikev2-ipsec-02.txt Pages : 24 Date : 2005-7-19 This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-ikev2-ipsec-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-ikev2-ipsec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-19140439.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-ikev2-ipsec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-ikev2-ipsec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-19140439.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Tue Jul 19 20:44:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv2hU-0006AE-Fr; Tue, 19 Jul 2005 20:44:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv2hR-0006A9-Vk for mip6@megatron.ietf.org; Tue, 19 Jul 2005 20:44:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20482 for ; Tue, 19 Jul 2005 20:44:33 -0400 (EDT) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dv3B1-0007X2-3J for mip6@ietf.org; Tue, 19 Jul 2005 21:15:19 -0400 Received: (qmail 23341 invoked from network); 20 Jul 2005 00:44:06 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;c96e7cfff9a9e2232a9d372d256e7611; Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 20 Jul 2005 00:44:05 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Wed, 20 Jul 2005 08:42:42 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Mip6] Draft on Securing Home Agent List Date: Wed, 20 Jul 2005 08:42:39 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA3859136D@hcbjdc2> Thread-Topic: [Mip6] Draft on Securing Home Agent List Thread-Index: AcWIpJi2w6VlQwYjTPilkny5WjxqrQEi78rA From: "DENG, HUI -HCHBJ" To: "Jari Arkko" , X-OriginalArrivalTime: 20 Jul 2005 00:42:43.0046 (UTC) FILETIME=[F0724860:01C58CC3] X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1121820245.864-23336-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.03/0.88 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, James Kempf , deshbandhus@huawei.com, COMBES Jean-Michel RD-MAPS-ISS 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 > Are there other router -to- router communications, for example?=20 >--Jari I will not say whether there are dangerous existed in the home network. Regarding router redundancy, VRRP historically consider security issue. but finally they just use only one hop judgement for security issue. Secondly, issues of multiple home agents have not been considered mostly=20 in the working group, I guess that bootstrap also not consider scenario of multiple home agents. -Hui _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 20 01:47:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7QB-0005XZ-5U; Wed, 20 Jul 2005 01:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv7Q9-0005XU-CJ for mip6@megatron.ietf.org; Wed, 20 Jul 2005 01:47:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25914 for ; Wed, 20 Jul 2005 01:47:04 -0400 (EDT) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dv7tu-0006qE-0p for mip6@ietf.org; Wed, 20 Jul 2005 02:17:51 -0400 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJW008UXW1Q1X@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 20 Jul 2005 13:46:38 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJW004PAW1QO9@szxga03-in.huawei.com> for mip6@ietf.org; Wed, 20 Jul 2005 13:46:38 +0800 (CST) Received: from rajesh1649 ([10.18.4.152]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJW00EJ1WC2C5@szxml01-in.huawei.com> for mip6@ietf.org; Wed, 20 Jul 2005 13:52:51 +0800 (CST) Date: Wed, 20 Jul 2005 11:14:06 +0530 From: Rajesh Shetty Subject: Re: [Mip6] Draft on Securing Home Agent List To: sachind@huawei.com Message-id: <001201c58cee$0bdcec20$9804120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <834B54D356AA8F46B9B233DD88BEAA3859136D@hcbjdc2> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7BIT Cc: mip6@ietf.org, deshbandhus@huawei.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 Hi Sachin, Please find my concerns, about the mentioned solution If entry is not present in Home Agent List then o Add the entry in Home Agent list and make the state of that entry as STALE (same as ND, when entry is added in Neighbor cache through RA, it is added in STALE state). o After adding the entry start the neighbor reachability detection as per RFC-2461 [2] for that link local address Its better to give a Random Delay before starting a neighbour reachability detection, Since more than one recieving Home Agent might start reachability detection at the same time. Rajesh ----- Original Message ----- From: "DENG, HUI -HCHBJ" To: "Jari Arkko" ; Cc: ; "James Kempf" ; ; "COMBES Jean-Michel RD-MAPS-ISS" Sent: Wednesday, July 20, 2005 6:12 AM Subject: RE: [Mip6] Draft on Securing Home Agent List > Are there other router -to- router communications, for example? >--Jari I will not say whether there are dangerous existed in the home network. Regarding router redundancy, VRRP historically consider security issue. but finally they just use only one hop judgement for security issue. Secondly, issues of multiple home agents have not been considered mostly in the working group, I guess that bootstrap also not consider scenario of multiple home agents. -Hui _______________________________________________ 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 Jul 20 04:17:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv9gl-0007wl-Mf; Wed, 20 Jul 2005 04:12:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dv9gf-0007ue-Lw for mip6@megatron.ietf.org; Wed, 20 Jul 2005 04:12:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16240 for ; Wed, 20 Jul 2005 04:12:15 -0400 (EDT) Received: from mx2.buaa.edu.cn ([219.239.227.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvAAD-0006Tn-16 for mip6@ietf.org; Wed, 20 Jul 2005 04:43:04 -0400 Received: from mx1.buaa.edu.cn (unknown [192.168.128.6]) by mx2.buaa.edu.cn (Postfix) with ESMTP id 6CA8537F5F for ; Wed, 20 Jul 2005 16:11:12 +0800 (CST) Received: from [210.76.115.36] by 10.0.0.131 with StormMail ESMTP id 41176.1378338358; Wed, 20 Jul 2005 16:46:40 +0800 (CST) Message-ID: <42DE0749.9000400@cse.buaa.edu.cn> Date: Wed, 20 Jul 2005 16:11:53 +0800 From: Li Qin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] Bootstrapping DT solution draft References: In-Reply-To: X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 I guess that multiple home agents related issues, such as dynamic home agent assignment, have not been considered in this draft. if so , can you tell us the reason? Gerardo Giaretta wrote: > Dear WG, > > the bootstrapping DT has submitted a solution draft. The document > defines how a Mobile Node can bootstrap MIPv6 operations from > non-topological information and pre-configured security credentials. The > solution solves the boostrapping problem when the Mobile Node's mobility > service is authorized by a different service provider than basic network > access (i.e. split scenario). > > The draft can be found at > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- > 00.txt. > > The DT is currently working on optimized solutions for integrated > scenario (i.e. mobility service and basic network access are authorized > by the same entity). > > Please read the document and provide comments. > > Thanks and regards, > > --Gerardo (DT editor) > > > > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > > ==================================================================== > 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 > ==================================================================== > > _______________________________________________ > 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 Jul 20 05:19:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvAjp-0000VF-7W; Wed, 20 Jul 2005 05:19:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvAjn-0000V6-OZ for mip6@megatron.ietf.org; Wed, 20 Jul 2005 05:19:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24026 for ; Wed, 20 Jul 2005 05:19:33 -0400 (EDT) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvBDZ-0002IU-WF for mip6@ietf.org; Wed, 20 Jul 2005 05:50:23 -0400 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJX00MX85W9DF@szxga02-in.huawei.com> for mip6@ietf.org; Wed, 20 Jul 2005 17:19:22 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJX002IP5W9E9@szxga02-in.huawei.com> for mip6@ietf.org; Wed, 20 Jul 2005 17:19:21 +0800 (CST) Received: from rajesh1649 ([10.18.4.152]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJX00ITZ5W2CF@szxml02-in.huawei.com>; Wed, 20 Jul 2005 17:19:15 +0800 (CST) Date: Wed, 20 Jul 2005 14:42:06 +0530 From: Rajesh Shetty To: mip6@ietf.org, john.loughney@nokia.com, jari.arkko@kolumbus.fi, Kempf@docomolabs-usa.com Message-id: <012d01c58d0b$50395b20$9804120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.8 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [Mip6] Clarification needed 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="===============1818348154==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1818348154== Content-type: multipart/alternative; boundary="Boundary_(ID_76oHC1ZIVHak9VHlm5KpNg)" This is a multi-part message in MIME format. --Boundary_(ID_76oHC1ZIVHak9VHlm5KpNg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi all, This is Regarding RFC 3775 section 10.3.1. Primary Care-of Address Registration Quoted From the section mentioned Above : Regardless of the setting of the Acknowledge (A) bit in the Binding Update, the home agent MUST return a Binding Acknowledgement to the mobile node constructed as follows: The Status field MUST be set to a value indicating success. The value 1 (accepted but prefix discovery necessary) MUST be used if the subnet prefix of the specified home address is deprecated or becomes deprecated during the lifetime of the binding, or becomes invalid at the end of the lifetime. There is a small confusion here As per my knowledge subnet prefix has to become deprecated before going to invalid state. If the above holds good than we can change the mentioned statement in RFC to The Status field MUST be set to a value indicating success. The value 1 (accepted but prefix discovery necessary) MUST be used if the subnet prefix of the specified home address is deprecated or becomes deprecated during the lifetime of the binding or becomes deprecated at the end of the lifetime. Rajesh --Boundary_(ID_76oHC1ZIVHak9VHlm5KpNg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi all,
 
      This is Regarding RFC 3775 section 10.3.1.  Primary Care-of Address Registration
 
Quoted From the section mentioned Above :
 
Regardless of the setting of the Acknowledge (A) bit in the Binding
   Update, the home agent MUST return a Binding Acknowledgement to the
   mobile node constructed as follows:
 
      The Status field MUST be set to a value indicating success.  The
      value 1 (accepted but prefix discovery necessary) MUST be used if
      the subnet prefix of the specified home address is deprecated or
      becomes deprecated during the lifetime of the binding, or becomes
      invalid at the end of the lifetime. 
 

 
There is a small confusion here 

       As per my knowledge subnet prefix has to become deprecated before going to
            invalid state.
 
      If the above holds good than we can change the mentioned statement in RFC to
 
      The Status field MUST be set to a value indicating success.  The
      value 1 (accepted but prefix discovery necessary) MUST be used if
      the subnet prefix of the specified home address is deprecated or
      becomes deprecated during the lifetime of the binding or becomes
      deprecated at the end of the lifetime.
 

Rajesh
--Boundary_(ID_76oHC1ZIVHak9VHlm5KpNg)-- --===============1818348154== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1818348154==-- From mip6-bounces@ietf.org Wed Jul 20 07:28:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCk7-0007al-60; Wed, 20 Jul 2005 07:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvCk2-0007aX-O4 for mip6@megatron.ietf.org; Wed, 20 Jul 2005 07:28:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06453 for ; Wed, 20 Jul 2005 07:27:53 -0400 (EDT) Received: from mail.riverstonenet.com ([63.113.148.10] helo=riverstonenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvDDk-0002mx-Ex for mip6@ietf.org; Wed, 20 Jul 2005 07:58:44 -0400 Received: from gondor.rs.riverstonenet.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id EAA00473; Wed, 20 Jul 2005 04:27:19 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Clarification needed Date: Wed, 20 Jul 2005 16:57:17 +0530 Message-ID: Thread-Topic: [Mip6] Clarification needed Thread-Index: AcWNDfgHv4M945PYS3qd1wz2fY7AZQAD5tAg From: "Srinivasa, Arun" To: "Rajesh Shetty" , , , , X-Spam-Score: 0.1 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d Cc: 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="===============1812749600==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1812749600== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C58D1D.FCCA7528" This is a multi-part message in MIME format. ------_=_NextPart_001_01C58D1D.FCCA7528 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 I agree with Rajesh suggestion. It looks like it is mandatory to change Invalid to "deprecated". =20 Arun =20 ________________________________ From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of Rajesh Shetty Sent: Wednesday, July 20, 2005 2:42 PM To: mip6@ietf.org; john.loughney@nokia.com; jari.arkko@kolumbus.fi; Kempf@docomolabs-usa.com Subject: [Mip6] Clarification needed =20 Hi all, =20 This is Regarding RFC 3775 section 10.3.1. Primary Care-of Address Registration =20 Quoted From the section mentioned Above : =20 Regardless of the setting of the Acknowledge (A) bit in the Binding Update, the home agent MUST return a Binding Acknowledgement to the mobile node constructed as follows: =20 The Status field MUST be set to a value indicating success. The value 1 (accepted but prefix discovery necessary) MUST be used if the subnet prefix of the specified home address is deprecated or becomes deprecated during the lifetime of the binding, or becomes invalid at the end of the lifetime. =20 =20 =20 There is a small confusion here=20 As per my knowledge subnet prefix has to become deprecated before going to=20 invalid state. =20 If the above holds good than we can change the mentioned statement in RFC to=20 =20 The Status field MUST be set to a value indicating success. The value 1 (accepted but prefix discovery necessary) MUST be used if the subnet prefix of the specified home address is deprecated or becomes deprecated during the lifetime of the binding or becomes=20 deprecated at the end of the lifetime.=20 =20 Rajesh ------_=_NextPart_001_01C58D1D.FCCA7528 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

I agree with Rajesh suggestion. It looks like it is mandatory to change Invalid to “deprecated”.

 

Arun

 

From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of Rajesh Shetty
Sent: Wednesday, July 20, = 2005 2:42 PM
To: mip6@ietf.org; john.loughney@nokia.com; jari.arkko@kolumbus.fi; = Kempf@docomolabs-usa.com
Subject: [Mip6] = Clarification needed

 

Hi all,

 

      This is Regarding RFC = 3775 section 10.3.1.  Primary Care-of Address = Registration

 

Quoted From the section mentioned Above = :

 

Regardless of the setting of the Acknowledge (A) bit = in the Binding
   Update, the home agent MUST return a Binding = Acknowledgement to the
   mobile node constructed as = follows:

 

      The Status field MUST = be set to a value indicating success.  The
      value 1 (accepted but prefix discovery necessary) MUST be used if
      the subnet prefix of the specified home = address is deprecated or
      becomes deprecated during the lifetime of = the binding, or becomes
      invalid at the = end of the lifetime. 

 


 
There is a small confusion here 


       As per my knowledge subnet prefix = has to become deprecated before going to
            = invalid state.

 

      If the above holds = good than we can change the mentioned statement in RFC to =

 

      The Status field MUST = be set to a value indicating success.  The
      value 1 (accepted but prefix discovery necessary) MUST be used if
      the subnet prefix of the specified home = address is deprecated or
      becomes deprecated during the lifetime of = the binding or becomes
      deprecated at the = end of the lifetime.

 


Rajesh

------_=_NextPart_001_01C58D1D.FCCA7528-- --===============1812749600== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1812749600==-- From mip6-bounces@ietf.org Wed Jul 20 12:24:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvHNF-0005Wn-SD; Wed, 20 Jul 2005 12:24:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvHNE-0005Wi-TZ for mip6@megatron.ietf.org; Wed, 20 Jul 2005 12:24:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06687 for ; Wed, 20 Jul 2005 12:24:42 -0400 (EDT) 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.43) id 1DvHr6-0007hN-FH for mip6@ietf.org; Wed, 20 Jul 2005 12:55:37 -0400 Message-ID: <00d201c58d47$8163e850$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Li Qin" , "Gerardo Giaretta" References: <42DE0749.9000400@cse.buaa.edu.cn> Subject: Re: [Mip6] Bootstrapping DT solution draft Date: Wed, 20 Jul 2005 09:24:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 The home DNS server can contain multiple HA addresses in the SRV record. jak ----- Original Message ----- From: "Li Qin" To: "Gerardo Giaretta" Cc: Sent: Wednesday, July 20, 2005 1:11 AM Subject: Re: [Mip6] Bootstrapping DT solution draft > I guess that multiple home agents related issues, such as dynamic home > agent assignment, have not been considered in this draft. > > if so , can you tell us the reason? > > Gerardo Giaretta wrote: > > Dear WG, > > > > the bootstrapping DT has submitted a solution draft. The document > > defines how a Mobile Node can bootstrap MIPv6 operations from > > non-topological information and pre-configured security credentials. The > > solution solves the boostrapping problem when the Mobile Node's mobility > > service is authorized by a different service provider than basic network > > access (i.e. split scenario). > > > > The draft can be found at > > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- > > 00.txt. > > > > The DT is currently working on optimized solutions for integrated > > scenario (i.e. mobility service and basic network access are authorized > > by the same entity). > > > > Please read the document and provide comments. > > > > Thanks and regards, > > > > --Gerardo (DT editor) > > > > > > > > > > > > > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > > > > ==================================================================== > > 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 > > ==================================================================== > > > > _______________________________________________ > > 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 Jul 20 13:57:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvIp4-0008FZ-Ch; Wed, 20 Jul 2005 13:57:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvIp1-0008FO-LZ for mip6@megatron.ietf.org; Wed, 20 Jul 2005 13:57:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15988 for ; Wed, 20 Jul 2005 13:57:30 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvJIt-00067x-1z for mip6@ietf.org; Wed, 20 Jul 2005 14:28:24 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6KHOWr25332; Wed, 20 Jul 2005 10:24:32 -0700 X-mProtect: <200507201724> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdORCVz7; Wed, 20 Jul 2005 10:24:30 PDT Message-ID: <42DE903C.5080809@iprg.nokia.com> Date: Wed, 20 Jul 2005 10:56:12 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rajesh Shetty Subject: Re: [Mip6] Clarification needed References: <012d01c58d0b$50395b20$9804120a@china.huawei.com> In-Reply-To: <012d01c58d0b$50395b20$9804120a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Rajesh Shetty wrote: > Hi all, > > This is Regarding RFC 3775 section 10.3.1. Primary Care-of > Address Registration > > Quoted From the section mentioned Above : > > Regardless of the setting of the Acknowledge (A) bit in the Binding > Update, the home agent MUST return a Binding Acknowledgement to the > mobile node constructed as follows: > > The Status field MUST be set to a value indicating success. The > value 1 (accepted but prefix discovery necessary) MUST be used if > the subnet prefix of the specified home address is deprecated or > becomes deprecated during the lifetime of the binding, or becomes > *invalid* at the end of the lifetime. > > > > There is a small confusion here > > As per my knowledge subnet prefix has to become deprecated before > going to > invalid state. > > If the above holds good than we can change the mentioned statement > in RFC to > > The Status field MUST be set to a value indicating success. The > value 1 (accepted but prefix discovery necessary) MUST be used if > the subnet prefix of the specified home address is deprecated or > becomes deprecated during the lifetime of the binding or becomes > *deprecated* at the end of the lifetime. not really. if the prefix is going to be deprecated only at end of the period indicated by the lifetime in the BU, there is no need to set the status to 1 yet in the Binding Ack. can be done for the next BU sent by the MN. anyway, the text in RFC 3775 cant be changed right now. it can be done only when it is revised. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 20 14:00:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvIsK-0001b9-By; Wed, 20 Jul 2005 14:00:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvIsI-0001YB-OF for mip6@megatron.ietf.org; Wed, 20 Jul 2005 14:00:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16161 for ; Wed, 20 Jul 2005 14:00:53 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvJMB-0006Qe-7i for mip6@ietf.org; Wed, 20 Jul 2005 14:31:47 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6KHSf029775; Wed, 20 Jul 2005 10:28:41 -0700 X-mProtect: <200507201728> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdROEkez; Wed, 20 Jul 2005 10:28:40 PDT Message-ID: <42DE9135.2020701@iprg.nokia.com> Date: Wed, 20 Jul 2005 11:00:21 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Li Qin Subject: Re: [Mip6] Bootstrapping DT solution draft References: <42DE0749.9000400@cse.buaa.edu.cn> In-Reply-To: <42DE0749.9000400@cse.buaa.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , 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 once the mobile node knows the home prefix, it can still do DHAAD if it wants to. Vijay Li Qin wrote: > I guess that multiple home agents related issues, such as dynamic home > agent assignment, have not been considered in this draft. > > if so , can you tell us the reason? > > Gerardo Giaretta wrote: > >>Dear WG, >> >>the bootstrapping DT has submitted a solution draft. The document >>defines how a Mobile Node can bootstrap MIPv6 operations from >>non-topological information and pre-configured security credentials. The >>solution solves the boostrapping problem when the Mobile Node's mobility >>service is authorized by a different service provider than basic network >>access (i.e. split scenario). >> >>The draft can be found at >>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- >>00.txt. >> >>The DT is currently working on optimized solutions for integrated >>scenario (i.e. mobility service and basic network access are authorized >>by the same entity). >> >>Please read the document and provide comments. >> >>Thanks and regards, >> >>--Gerardo (DT editor) >> >> >> >> >> >> >> >> >>Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. >> >>==================================================================== >>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 >>==================================================================== >> >>_______________________________________________ >>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 Jul 20 15:40:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKQb-0000Ib-89; Wed, 20 Jul 2005 15:40:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKQZ-0000IE-Ff for mip6@megatron.ietf.org; Wed, 20 Jul 2005 15:40:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24671 for ; Wed, 20 Jul 2005 15:40:21 -0400 (EDT) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX1+HQzpATSWsTvalzUm+yddKkPpj7qvUuuE=]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvKuQ-0003n1-Ne for mip6@ietf.org; Wed, 20 Jul 2005 16:11:17 -0400 Received: from hsi-kbw-082-212-035-085.hsi.kabelbw.de ([82.212.35.85] helo=[192.168.123.123]) by iramx2.ira.uni-karlsruhe.de with esmtpsa id 1DvKQK-0000Uc-2Y; Wed, 20 Jul 2005 21:40:12 +0200 Message-ID: <42DEA893.3000804@tm.uka.de> Date: Wed, 20 Jul 2005 21:40:03 +0200 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.2.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] Bootstrapping DT solution draft References: In-Reply-To: X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: -2.5 (--) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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: , Content-Type: multipart/mixed; boundary="===============1045226183==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1045226183== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig869272B7665156E68B0BF2FE" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig869272B7665156E68B0BF2FE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Gerardo, hi DT members, thanks for the bootstrapping I-D; you did a very good job! Some comments (and questions) from my side: (1) The DT draft doesn't yet specify the backend AAA protocol, e.g., a Diameter application. Is this your next step? (IMO, considering a split scenario makes sense only when you specify the AAA protocol, too, because that AAA protocol---neither the DNS lookup nor the MN-HA IKEv2 exchange---is affected by the split.) (2) Draft-ietf-mip6-ikev2-ipsec-01.txt already defines how to dynamically assign a HoA during the IKEv2 handshake. Why do you use different Configuration Payloads? (3) In order to contact DNS, the MN needs IP connectivity. Is your assumption that the visited network (ASP/ASA) authorizes the MN for IP connectivity first, and the MN bootstraps Mobile IPv6 thereafter? (This would preclude an all-in-one solution like, e.g., the one described in draft-le-aaa-diameter-mobileipv6-04.txt.) (4) Are you assuming that the DNS server belongs to the MSA? If not, the MN probably won't have an SA with the DNS server, so DNS requests are unauthenticated and DNS responses are not encrypted. (Note that I am NOT talking about DNS updates here.) As a consequence, information about the home topology is accessible to anybody. Is this an issue? (5) The DNS server can store multiple HA addresses, so dynamic HA assignment is possible in principle. Do you assume that the DNS server is in charge of load balancing or that it can assign a HA topologically close to the MN? (Fault tolerance could be handled by DHAAD.) Allright then. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Gerardo Giaretta wrote: > Dear WG, > > the bootstrapping DT has submitted a solution draft. The document > defines how a Mobile Node can bootstrap MIPv6 operations from > non-topological information and pre-configured security credentials. The > solution solves the boostrapping problem when the Mobile Node's mobility > service is authorized by a different service provider than basic network > access (i.e. split scenario). > > The draft can be found at > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- > 00.txt. > > The DT is currently working on optimized solutions for integrated > scenario (i.e. mobility service and basic network access are authorized > by the same entity). > > Please read the document and provide comments. > > Thanks and regards, > > --Gerardo (DT editor) --------------enig869272B7665156E68B0BF2FE 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.4.0 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC3qiWwstEk8gl2rURArkoAKC6gM29gYACUWCLqgecY63XIJKyAQCg2RFd jeTkGFuYAyDNpMw+XceCGWQ= =Jpxj -----END PGP SIGNATURE----- --------------enig869272B7665156E68B0BF2FE-- --===============1045226183== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1045226183==-- From mip6-bounces@ietf.org Wed Jul 20 21:11:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvPb4-0005jX-OE; Wed, 20 Jul 2005 21:11:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvPb2-0005j0-C2; Wed, 20 Jul 2005 21:11:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21782; Wed, 20 Jul 2005 21:11:30 -0400 (EDT) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvQ4y-0003H3-8o; Wed, 20 Jul 2005 21:42:28 -0400 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 4008E800088; Thu, 21 Jul 2005 04:11:19 +0300 (EEST) Date: Thu, 21 Jul 2005 04:11:19 +0300 (EEST) From: Wassim Haddad To: mipshop@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Score: 2.4 (++) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: mip6@ietf.org, mobopts@irtf.org Subject: [Mip6] I-D ACTION:draft-haddad-mipshop-omm-01.txt (fwd) 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 Hi, FYI, A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Optimizing Micromobility Management for Active and Dormant Mobile Nodes Author(s) : W. Haddad, et al. Filename : draft-haddad-mipshop-omm-01.txt Pages : 28 Date : 2005-7-20 Micromobility protocols address mobile nodes (MN) movements within a particular IP network domain. This document introduces a new protocol "Optimized Micromobility Management" (OMM), to manage Micromobility for active and dormant mobile nodes. The suggested solution is based on the Hierarchical Mobile IPv6 (HMIPv6) proposal and aims to increase the mobility performance by reducing the handover latency and the packet loss. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haddad-mipshop-omm-01.txt Comments appreciated. Regards, Wassim H. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 21 00:46:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvSxG-0000uy-SP; Thu, 21 Jul 2005 00:46:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvSxE-0000q3-5I for mip6@megatron.ietf.org; Thu, 21 Jul 2005 00:46:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06929 for ; Thu, 21 Jul 2005 00:46:36 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvTRA-0008Ro-Jd for mip6@ietf.org; Thu, 21 Jul 2005 01:17:38 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJY00ESZO5JLW@szxga01-in.huawei.com> for mip6@ietf.org; Thu, 21 Jul 2005 12:51:19 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJY002SSO5JQR@szxga01-in.huawei.com> for mip6@ietf.org; Thu, 21 Jul 2005 12:51:19 +0800 (CST) Received: from rajesh1649 ([10.18.4.152]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJY00MGWO7KUW@szxml02-in.huawei.com>; Thu, 21 Jul 2005 12:52:32 +0800 (CST) Date: Thu, 21 Jul 2005 10:16:53 +0530 From: Rajesh Shetty Subject: Re: [Mip6] Clarification needed To: Vijay Devarapalli Message-id: <005d01c58daf$37f42eb0$9804120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <012d01c58d0b$50395b20$9804120a@china.huawei.com> <42DE903C.5080809@iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Hi Vijay, I Fully agree with you. To avoid confusion its Better to change RFC when revised. As per me it must be changed to /*******************************************************************/ Regardless of the setting of the Acknowledge (A) bit in the Binding Update, the home agent MUST return a Binding Acknowledgement to the mobile node constructed as follows: The Status field MUST be set to a value indicating success. The value 1 (accepted but prefix discovery necessary) MUST be used if the subnet prefix of the specified home address is deprecated or becomes deprecated during the lifetime of the binding. /**********************************************************************/ Its not necessary to mention becomes invalid at the end of the lifetime. Rajesh ----- Original Message ----- From: "Vijay Devarapalli" To: "Rajesh Shetty" Cc: Sent: Wednesday, July 20, 2005 11:26 PM Subject: Re: [Mip6] Clarification needed > Rajesh Shetty wrote: > > Hi all, > > > > This is Regarding RFC 3775 section 10.3.1. Primary Care-of > > Address Registration > > > > Quoted From the section mentioned Above : > > > > Regardless of the setting of the Acknowledge (A) bit in the Binding > > Update, the home agent MUST return a Binding Acknowledgement to the > > mobile node constructed as follows: > > > > The Status field MUST be set to a value indicating success. The > > value 1 (accepted but prefix discovery necessary) MUST be used if > > the subnet prefix of the specified home address is deprecated or > > becomes deprecated during the lifetime of the binding, or becomes > > *invalid* at the end of the lifetime. > > > > > > > > There is a small confusion here > > > > As per my knowledge subnet prefix has to become deprecated before > > going to > > invalid state. > > > > If the above holds good than we can change the mentioned statement > > in RFC to > > > > The Status field MUST be set to a value indicating success. The > > value 1 (accepted but prefix discovery necessary) MUST be used if > > the subnet prefix of the specified home address is deprecated or > > becomes deprecated during the lifetime of the binding or becomes > > *deprecated* at the end of the lifetime. > > not really. if the prefix is going to be deprecated only at > end of the period indicated by the lifetime in the BU, there > is no need to set the status to 1 yet in the Binding Ack. > can be done for the next BU sent by the MN. > > anyway, the text in RFC 3775 cant be changed right now. it > can be done only when it is revised. > > Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 21 00:49:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvT0M-00027X-9P; Thu, 21 Jul 2005 00:49:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvT0K-00027S-Lq for mip6@megatron.ietf.org; Thu, 21 Jul 2005 00:49:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07154 for ; Thu, 21 Jul 2005 00:49:49 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvTUI-0000Bl-HX for mip6@ietf.org; Thu, 21 Jul 2005 01:20:51 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJY00EDSOB5LW@szxga01-in.huawei.com> for mip6@ietf.org; Thu, 21 Jul 2005 12:54:41 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IJY00MN9OB5RC@szxga01-in.huawei.com> for mip6@ietf.org; Thu, 21 Jul 2005 12:54:41 +0800 (CST) Received: from rajesh1649 ([10.18.4.152]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IJY00M2VOD6UW@szxml02-in.huawei.com>; Thu, 21 Jul 2005 12:55:55 +0800 (CST) Date: Thu, 21 Jul 2005 10:20:15 +0530 From: Rajesh Shetty Subject: Re: [Mip6] Clarification needed To: Vijay Devarapalli Message-id: <007c01c58daf$b066fda0$9804120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook Express 6.00.2800.1106 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <012d01c58d0b$50395b20$9804120a@china.huawei.com> <42DE903C.5080809@iprg.nokia.com> 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 List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Hi Vijay, I Fully agree with you. To avoid confusion its Better to change RFC when revised. As per me it must be changed to /*******************************************************************/ Regardless of the setting of the Acknowledge (A) bit in the Binding Update, the home agent MUST return a Binding Acknowledgement to the mobile node constructed as follows: The Status field MUST be set to a value indicating success.The value 1 (accepted but prefix discovery necessary) MUST be used if the subnet prefix of the specified home address is deprecated or becomes deprecated during the lifetime of the binding. /**********************************************************************/ Its not necessary to mention becomes invalid at the end of the lifetime. Rajesh ----- Original Message ----- From: "Vijay Devarapalli" To: "Rajesh Shetty" Cc: Sent: Wednesday, July 20, 2005 11:26 PM Subject: Re: [Mip6] Clarification needed > Rajesh Shetty wrote: > > Hi all, > > > > This is Regarding RFC 3775 section 10.3.1. Primary Care-of > > Address Registration > > > > Quoted From the section mentioned Above : > > > > Regardless of the setting of the Acknowledge (A) bit in the Binding > > Update, the home agent MUST return a Binding Acknowledgement to the > > mobile node constructed as follows: > > > > The Status field MUST be set to a value indicating success. The > > value 1 (accepted but prefix discovery necessary) MUST be used if > > the subnet prefix of the specified home address is deprecated or > > becomes deprecated during the lifetime of the binding, or becomes > > *invalid* at the end of the lifetime. > > > > > > > > There is a small confusion here > > > > As per my knowledge subnet prefix has to become deprecated before > > going to > > invalid state. > > > > If the above holds good than we can change the mentioned statement > > in RFC to > > > > The Status field MUST be set to a value indicating success. The > > value 1 (accepted but prefix discovery necessary) MUST be used if > > the subnet prefix of the specified home address is deprecated or > > becomes deprecated during the lifetime of the binding or becomes > > *deprecated* at the end of the lifetime. > > not really. if the prefix is going to be deprecated only at > end of the period indicated by the lifetime in the BU, there > is no need to set the status to 1 yet in the Binding Ack. > can be done for the next BU sent by the MN. > > anyway, the text in RFC 3775 cant be changed right now. it > can be done only when it is revised. > > Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 21 06:31:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvYKw-0003tM-Qc; Thu, 21 Jul 2005 06:31:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvYKv-0003tE-6e for mip6@megatron.ietf.org; Thu, 21 Jul 2005 06:31:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17823 for ; Thu, 21 Jul 2005 06:31:26 -0400 (EDT) Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvYot-00055W-8F for mip6@ietf.org; Thu, 21 Jul 2005 07:02:30 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 2C9ADD91 for ; Thu, 21 Jul 2005 12:31:24 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 12:31:23 +0200 Received: from esealmw115.eemea.ericsson.se ([153.88.200.6]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 12:31:22 +0200 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="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jul 2005 12:31:22 +0200 Message-ID: <24521B9781EAC745A4BE65966F69C9BE212BDE@esealmw115.eemea.ericsson.se> Thread-Topic: Simultaneous Bindings in MIP6 Thread-Index: AcWN31ZtH/SXX67jRcel9JJYxcEfcg== From: "Karim El-Malki (AL/EAB)" To: X-OriginalArrivalTime: 21 Jul 2005 10:31:22.0919 (UTC) FILETIME=[5724F370:01C58DDF] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Simultaneous Bindings in MIP6 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 Hi Since I got a email about it I have resubmitted an old draft that introduces simultaneous bindings functionality in MIP6 so that an MN can register using multiple COAs contemporarily: http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-bicasting-v6-0= 6.txt I'm sending this out to see if anyone thinks it is useful and wants to work on it. BR Karim _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 21 09:14:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvasC-0002gK-T1; Thu, 21 Jul 2005 09:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvasA-0002ey-SF for mip6@megatron.ietf.org; Thu, 21 Jul 2005 09:13:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28222 for ; Thu, 21 Jul 2005 09:13:55 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvbM9-0006ud-VM for mip6@ietf.org; Thu, 21 Jul 2005 09:44:59 -0400 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j6LDDfdN023883; Thu, 21 Jul 2005 15:13:41 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j6LDDfIe027509; Thu, 21 Jul 2005 15:13:41 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 21 Jul 2005 15:13:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [Mip6] Bootstrapping DT solution draft Date: Thu, 21 Jul 2005 15:13:38 +0200 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [Mip6] Bootstrapping DT solution draft Thread-Index: AcWNZFVOeXBybTeCQUaStoCEAix51wAkPTLg From: "Tschofenig, Hannes" To: "Christian Vogt" , "Gerardo Giaretta" X-OriginalArrivalTime: 21 Jul 2005 13:13:40.0258 (UTC) FILETIME=[030CF820:01C58DF6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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: , Content-Type: multipart/mixed; boundary="===============1243121427==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --===============1243121427== Content-class: urn:content-classes:message Content-Type: application/pkcs7-mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQMxCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg28Q29u dGVudC1UcmFuc2Zlci1FbmNvZGluZzogcXVvdGVkLXByaW50YWJsZQ0KQ29udGVudC1UeXBlOiB0 ZXh0L3BsYWluOw0KCWNoYXJzZXQ9Imlzby04ODU5LTEiDQoNCmhpIGNocmlzdGlhbiw9MjANCg0K dGhhbmtzIGZvciB5b3VyIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUgYWFhIHdvcmsuPTIwDQp3ZSBo YXZlIHN0YXJ0ZWQgdG8gd29yayBvbiB0aGlzIGlzc3VlLiB5b3UgY2FuIGZpbmQgdGhlIGRvY3Vt ZW49DQp0IGNhbiBiZSBmb3VuZCBhdDo9MjANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LXRzY2hvZmVuaWctbWlwNi1hYWEtaD0NCmEtZGlhbWV0ZXItMDAudHh0DQoN CmNpYW8NCmhhbm5lcw0KDQo+IC0tLS0tVXJzcHI9RkNuZ2xpY2hlIE5hY2hyaWNodC0tLS0tDQo+ IFZvbjogbWlwNi1ib3VuY2VzPTQwaWV0Zi5vcmcgPTVCbWFpbHRvOm1pcDYtYm91bmNlcz00MGll dGYub3I9DQpnPTVEIEltPTIwDQo+IEF1ZnRyYWcgdm9uIENocmlzdGlhbiBWb2d0DQo+IEdlc2Vu ZGV0OiBNaXR0d29jaCwgMjAuIEp1bGkgMjAwNSAyMTo0MA0KPiBBbjogR2VyYXJkbyBHaWFyZXR0 YQ0KPiBDYzogbWlwNj00MGlldGYub3JnDQo+IEJldHJlZmY6IFJlOiA9NUJNaXA2PTVEIEJvb3Rz dHJhcHBpbmcgRFQgc29sdXRpb24gZHJhZnQNCj49MjANCj49MjANCj4gSGkgR2VyYXJkbywgaGkg RFQgbWVtYmVycywNCj49MjANCj4gdGhhbmtzIGZvciB0aGUgYm9vdHN0cmFwcGluZyBJLUQ7IHlv dSBkaWQgYSB2ZXJ5IGdvb2Qgam9iPTIxDQo+PTIwDQo+IFNvbWUgY29tbWVudHMgKGFuZCBxdWVz dGlvbnMpIGZyb20gbXkgc2lkZToNCj49MjANCj4gKDEpICBUaGUgRFQgZHJhZnQgZG9lc24ndCB5 ZXQgc3BlY2lmeSB0aGUgYmFja2VuZCBBQUE9MjANCj4gcHJvdG9jb2wsIGUuZy4sIGENCj4gRGlh bWV0ZXIgYXBwbGljYXRpb24uICBJcyB0aGlzIHlvdXIgbmV4dCBzdGVwPyAgKElNTywgY29uc2lk ZT0NCnJpbmcgYQ0KPiBzcGxpdCBzY2VuYXJpbyBtYWtlcyBzZW5zZSBvbmx5IHdoZW4geW91IHNw ZWNpZnkgdGhlIEFBQT0yMA0KPiBwcm90b2NvbCwgdG9vLA0KPiBiZWNhdXNlIHRoYXQgQUFBIHBy b3RvY29sLS0tbmVpdGhlciB0aGUgRE5TIGxvb2t1cCBub3IgdGhlIE1OPQ0KLUhBIElLRXYyDQo+ IGV4Y2hhbmdlLS0taXMgYWZmZWN0ZWQgYnkgdGhlIHNwbGl0LikNCj49MjANCj4gKDIpICBEcmFm dC1pZXRmLW1pcDYtaWtldjItaXBzZWMtMDEudHh0IGFscmVhZHkgZGVmaW5lcyBob3cgdD0NCm8N Cj4gZHluYW1pY2FsbHkgYXNzaWduIGEgSG9BIGR1cmluZyB0aGUgSUtFdjIgaGFuZHNoYWtlLiAg V2h5IGRvPQ0KIHlvdSB1c2UNCj4gZGlmZmVyZW50IENvbmZpZ3VyYXRpb24gUGF5bG9hZHM/DQo+ PTIwDQo+ICgzKSBJbiBvcmRlciB0byBjb250YWN0IEROUywgdGhlIE1OIG5lZWRzIElQIGNvbm5l Y3Rpdml0eS4gIEk9DQpzIHlvdXINCj4gYXNzdW1wdGlvbiB0aGF0IHRoZSB2aXNpdGVkIG5ldHdv cmsgKEFTUC9BU0EpIGF1dGhvcml6ZXMgdGhlPQ0KIE1OIGZvciBJUA0KPiBjb25uZWN0aXZpdHkg Zmlyc3QsIGFuZCB0aGUgTU4gYm9vdHN0cmFwcyBNb2JpbGUgSVB2Nj0yMA0KPiB0aGVyZWFmdGVy PyAgKFRoaXMNCj4gd291bGQgcHJlY2x1ZGUgYW4gYWxsLWluLW9uZSBzb2x1dGlvbiBsaWtlLCBl LmcuLCB0aGUgb25lIGRlcz0NCmNyaWJlZCBpbg0KPiBkcmFmdC1sZS1hYWEtZGlhbWV0ZXItbW9i aWxlaXB2Ni0wNC50eHQuKQ0KPj0yMA0KPiAoNCkgQXJlIHlvdSBhc3N1bWluZyB0aGF0IHRoZSBE TlMgc2VydmVyIGJlbG9uZ3MgdG8gdGhlIE1TQT89DQogIElmIG5vdCwNCj4gdGhlIE1OIHByb2Jh Ymx5IHdvbid0IGhhdmUgYW4gU0Egd2l0aCB0aGUgRE5TIHNlcnZlciwgc28gRE5TPQ0KIHJlcXVl c3RzDQo+IGFyZSB1bmF1dGhlbnRpY2F0ZWQgYW5kIEROUyByZXNwb25zZXMgYXJlIG5vdCBlbmNy eXB0ZWQuICAoTm89DQp0ZSB0aGF0IEkNCj4gYW0gTk9UIHRhbGtpbmcgYWJvdXQgRE5TIHVwZGF0 ZXMgaGVyZS4pICBBcyBhIGNvbnNlcXVlbmNlLCBpbj0NCmZvcm1hdGlvbg0KPiBhYm91dCB0aGUg aG9tZSB0b3BvbG9neSBpcyBhY2Nlc3NpYmxlIHRvIGFueWJvZHkuICBJcyB0aGlzIGFuPQ0KIGlz c3VlPw0KPj0yMA0KPiAoNSkgIFRoZSBETlMgc2VydmVyIGNhbiBzdG9yZSBtdWx0aXBsZSBIQSBh ZGRyZXNzZXMsIHNvIGR5bmFtPQ0KaWMgSEENCj4gYXNzaWdubWVudCBpcyBwb3NzaWJsZSBpbiBw cmluY2lwbGUuICBEbyB5b3UgYXNzdW1lIHRoYXQgdGhlPQ0KPTIwDQo+IEROUyBzZXJ2ZXINCj4g aXMgaW4gY2hhcmdlIG9mIGxvYWQgYmFsYW5jaW5nIG9yIHRoYXQgaXQgY2FuIGFzc2lnbiBhIEhB PTIwDQo+IHRvcG9sb2dpY2FsbHkNCj4gY2xvc2UgdG8gdGhlIE1OPyAgKEZhdWx0IHRvbGVyYW5j ZSBjb3VsZCBiZSBoYW5kbGVkIGJ5IERIQUFELj0NCikNCj49MjANCj4gQWxscmlnaHQgdGhlbi4N Cj49MjANCj4gLSBDaHJpc3RpYW4NCj49MjANCj4gLS0NCj4gQ2hyaXN0aWFuIFZvZ3QsIEluc3Rp dHV0ZSBvZiBUZWxlbWF0aWNzLCBVbml2ZXJzaXR5IG9mIEthcmxzcj0NCnVoZQ0KPiB3d3cudG0u dWthLmRlLz03RWNodm9ndC9wdWJrZXkvDQo+PTIwDQo+PTIwDQo+PTIwDQo+IEdlcmFyZG8gR2lh cmV0dGEgd3JvdGU6DQo+ID4gRGVhciBXRywNCj4gPg0KPiA+IHRoZSBib290c3RyYXBwaW5nIERU IGhhcyBzdWJtaXR0ZWQgYSBzb2x1dGlvbiBkcmFmdC4gVGhlIGRvPQ0KY3VtZW50DQo+ID4gZGVm aW5lcyBob3cgYSBNb2JpbGUgTm9kZSBjYW4gYm9vdHN0cmFwIE1JUHY2IG9wZXJhdGlvbnMgZnI9 DQpvbQ0KPiA+IG5vbi10b3BvbG9naWNhbCBpbmZvcm1hdGlvbiBhbmQgcHJlLWNvbmZpZ3VyZWQg c2VjdXJpdHk9MjANCj4gY3JlZGVudGlhbHMuIFRoZQ0KPiA+IHNvbHV0aW9uIHNvbHZlcyB0aGUg Ym9vc3RyYXBwaW5nIHByb2JsZW0gd2hlbiB0aGUgTW9iaWxlPTIwDQo+IE5vZGUncyBtb2JpbGl0 eQ0KPiA+IHNlcnZpY2UgaXMgYXV0aG9yaXplZCBieSBhIGRpZmZlcmVudCBzZXJ2aWNlIHByb3Zp ZGVyIHRoYW49DQo9MjANCj4gYmFzaWMgbmV0d29yaw0KPiA+IGFjY2VzcyAoaS5lLiBzcGxpdCBz Y2VuYXJpbykuDQo+ID4NCj4gPiBUaGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0DQo+ID49MjANCj4g aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1taXA2LWJvb3Rz dHJhcD0NCnANCmluZy1zcGxpdC0NCj4gMDAudHh0Lg0KPg0KPiBUaGUgRFQgaXMgY3VycmVudGx5 IHdvcmtpbmcgb24gb3B0aW1pemVkIHNvbHV0aW9ucyBmb3IgaW50ZWdyPQ0KYXRlZA0KPiBzY2Vu YXJpbyAoaS5lLiBtb2JpbGl0eSBzZXJ2aWNlIGFuZCBiYXNpYyBuZXR3b3JrIGFjY2VzcyBhcmU9 DQogYXV0aG9yaXplZA0KPiBieSB0aGUgc2FtZSBlbnRpdHkpLg0KPg0KPiBQbGVhc2UgcmVhZCB0 aGUgZG9jdW1lbnQgYW5kIHByb3ZpZGUgY29tbWVudHMuDQo+DQo+IFRoYW5rcyBhbmQgcmVnYXJk cywNCj4NCj4gLS1HZXJhcmRvIChEVCBlZGl0b3IpDQoNCg0KAAAAAAAAoIIQ0zCCBXcwggRfoAMC AQICBFR7HgkwDQYJKoZIhvcNAQEFBQAwWDELMAkGA1UEBhMCREUxEDAOBgNVBAoMB1NpZW1lbnMx ETAPBgNVBAUTCFpaWlpaMEVFMSQwIgYDVQQDDBtTaWVtZW5zIElzc3VpbmcgQ0EgQ2xhc3MgRUUw HhcNMDUwMTMxMDkyMjA5WhcNMDgwMTMxMDkyMjA5WjBnMREwDwYDVQQFEwhaMDAwQ1lITzEPMA0G A1UEKgwGSGFubmVzMRMwEQYDVQQEDApUc2Nob2ZlbmlnMRAwDgYDVQQKDAdTSUVNRU5TMRowGAYD VQQDDBFUc2Nob2ZlbmlnIEhhbm5lczCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs/mAWuNG X78I+5dHGGEg1mMiyCT4i+v6pj7tQmOUIO2Tgig9m7KZwoZg8gooZVaLIMP7K4qAqpHiLfHAl5A6 nKMudWt0oW94wsBUm6nX/gGizGchJ33f/GHG+6IF5IiwTfP/wAzHIjLeRpskENCRDGAC4QQIZz0F j/rhqMA/GNECAwEAAaOCArwwggK4MIHSBggrBgEFBQcBAQSBxTCBwjBBBggrBgEFBQcwAoY1bGRh cDovL2FsLnNpZW1lbnMubmV0L0NOPVpaWlpaMEVFLEw9UEtJP2NBQ2VydGlmaWNhdGUwMgYIKwYB BQUHMAKGJmh0dHA6Ly9haC5zaWVtZW5zLmNvbS9wa2k/WlpaWlowRUUuY3J0MEkGCCsGAQUFBzAC hj1sZGFwOi8vYWwuc2llbWVucy5jb20vQ049WlpaWlowRUUsbz1UcnVzdGNlbnRlcj9jQUNlcnRp ZmljYXRlMB8GA1UdIwQYMBaAFDxzC8K2tRZ+3u1EuGyB/pvCz95cMAwGA1UdEwEB/wQCMAAwGAYD VR0gBBEwDzANBgsrBgEEAaFpBwICAzCBygYDVR0fBIHCMIG/MIG8oIG5oIG2hkFsZGFwOi8vY2wu c2llbWVucy5uZXQvQ049WlpaWlowRUUsTD1QS0k/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdIYm aHR0cDovL2NoLnNpZW1lbnMuY29tL3BraT9aWlpaWjBFRS5jcmyGSWxkYXA6Ly9jbC5zaWVtZW5z LmNvbS9DTj1aWlpaWjBFRSxvPVRydXN0Y2VudGVyP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Qw QwYDVR0lBDwwOgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBAYIKwYBBQUIAgIGCisGAQQB gjcUAgIGBFUdJQAwDgYDVR0PAQH/BAQDAgeAMFcGA1UdEQRQME6gLQYKKwYBBAGCNxQCA6AfDB1o YW5uZXMudHNjaG9mZW5pZ0BzaWVtZW5zLmNvbYEdaGFubmVzLnRzY2hvZmVuaWdAc2llbWVucy5j b20wHQYDVR0OBBYEFLkSxAq1Y3mPPMdHztq0RmspqZReMA0GCSqGSIb3DQEBBQUAA4IBAQAHG1do kQvx76yYy8wzVSEcAW5uvDcKOqbKmDnOTlNqs3ImWxNwIwQ5Oa5IFhNF0zyMByWswTbEPQU0gEbH 97z+uiR7v6srHJDPh0vVGl2EAG4FDrnx1L05goEUuzIvH5jWPMMBgZR2EWhX5lkdf6tbxkUynaik d+0tc/zlmRROhI8Tzk3QsrUsNkyQXW8XUii1OPr0Qx+AyBB12f12A0EJ3cgJjS4UJbezoYT1Tsxp eXvdcTGWL7EyE6UEeD/6jtwZ6P88LkXUy/zjrIUAdCy1k79nvRSAQPG+1v22XwP/EfedBg9rXBiV goUlxl5TfkOtws/dn7GxCbhBrhJqCcgVMIIFnjCCBIagAwIBAgIEPPXVozANBgkqhkiG9w0BAQUF ADCBqjELMAkGA1UEBhMCREUxEDAOBgNVBAoMB1NpZW1lbnMxSTBHBgNVBAsMQENvcHlyaWdodCAo QykgU2llbWVucyBCdXNpbmVzcyBTZXJ2aWNlcyAyMDAzIEFsbCBSaWdodHMgUmVzZXJ2ZWQxPjA8 BgNVBAMMNVNpZW1lbnMgQnVzaW5lc3MgU2VydmljZXMgVHJ1c3QgQ2VudGVyIFJvb3QtQ0EgVjEu MS4xMB4XDTAzMDcxMDEwNTIyOVoXDTA5MDcxMDEwNTIyOVowWDELMAkGA1UEBhMCREUxEDAOBgNV BAoMB1NpZW1lbnMxETAPBgNVBAUTCFpaWlpaMEVFMSQwIgYDVQQDDBtTaWVtZW5zIElzc3Vpbmcg Q0EgQ2xhc3MgRUUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC9aW6L4VZwXuvuzAAo o+kBv6hA0qWmsT+ER4wNhtP9pR+f+ORAl1Lyo5xi5DUXJOGzVvFkqdzTZ3KwowW+tFeq6PszQJaJ noB9q0MafoGyWS6X52Jg5ylXLDL+PA0SYsRRSPyPduVINC8Lo8+HbeYmvCyplN26rMJH+zLmbd1B NIBZhkpIDBYtLivbOkzXWZus6D7gSOMQAZSH86Gu2SPaFg0FvdkQRXMz4XTob0vH1F6K2rIDQ4x7 BmrWbmR4VtSpCnwd6N5vzGCI8i0C+THcWn6FpXW+glJCTc4K6GyvTE79FN7av2zV/fK7PopQ1pv4 A3l9gBG2cekliK4L/kT/AgMBAAGjggIbMIICFzCB0wYIKwYBBQUHAQEEgcYwgcMwQQYIKwYBBQUH MAKGNWxkYXA6Ly9hbC5zaWVtZW5zLm5ldC9DTj1aWlpaWjAwMCxMPVBLST9jQUNlcnRpZmljYXRl MDIGCCsGAQUFBzAChiZodHRwOi8vYWguc2llbWVucy5jb20vcGtpP1paWlpaMDAwLmNydDBKBggr BgEFBQcwAoY+bGRhcDovL2FsLnNpZW1lbnMuY29tL3VpZD1aWlpaWjAwMCxvPVRydXN0Y2VudGVy P2NBQ2VydGlmaWNhdGUwHwYDVR0jBBgwFoAUqF2Ax+Na+hi9uatsqLLVaVgxfhUwEgYDVR0TAQH/ BAgwBgEB/wIBADARBgNVHSAECjAIMAYGBFUdIAAwgccGA1UdHwSBvzCBvDCBuaCBtqCBs4Y/bGRh cDovL2NsLnNpZW1lbnMubmV0L0NOPVpaWlpaMDAwLEw9UEtJP2F1dGhvcml0eVJldm9jYXRpb25M aXN0hiZodHRwOi8vY2guc2llbWVucy5jb20vcGtpP1paWlpaMDAwLmNybIZIbGRhcDovL2NsLnNp ZW1lbnMuY29tL3VpZD1aWlpaWjAwMCxvPVRydXN0Y2VudGVyP2F1dGhvcml0eVJldm9jYXRpb25M aXN0MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUPHMLwra1Fn7e7US4bIH+m8LP3lwwDQYJKoZI hvcNAQEFBQADggEBAA5IpBoRckYSqQY0ltx2uq1WvSDvAh+HRjLwYeq35kdkr5vHQMrYuUcokeXy 55QARV2ZTO18tosCATpfDd3bocgHLZKsZ9lq9i7ei88o3ZMUNV8W8ikrMXkgav9ibBu+Jl5kyf6u y6OF3IK/zPTOmaTazn+BvYciO8RIdLbqdpPerrJj/JZHAzSGOHV19NC5FflF9pwgluxp00Bd4Q1w gvJZhbgt6FsDe2A3oH2ciH5PaS4wcUQ8NgT40bTO434JLPvnQwNq6WSwX9Xd39RbVWYZ3anWB6T1 dWZN+1jGEY1Dbydnu6HiIl7lM2z1kLWX+LfTb3xL5hSiXotjL8G1CIwwggWyMIIEmqADAgECAgQ8 A3XQMA0GCSqGSIb3DQEBBQUAMIGqMQswCQYDVQQGEwJERTEQMA4GA1UECgwHU2llbWVuczFJMEcG A1UECwxAQ29weXJpZ2h0IChDKSBTaWVtZW5zIEJ1c2luZXNzIFNlcnZpY2VzIDIwMDMgQWxsIFJp Z2h0cyBSZXNlcnZlZDE+MDwGA1UEAww1U2llbWVucyBCdXNpbmVzcyBTZXJ2aWNlcyBUcnVzdCBD ZW50ZXIgUm9vdC1DQSBWMS4xLjEwHhcNMDMwNjE3MTE1NTEwWhcNMTUwNjE3MTE1NTEwWjCBqjEL MAkGA1UEBhMCREUxEDAOBgNVBAoMB1NpZW1lbnMxSTBHBgNVBAsMQENvcHlyaWdodCAoQykgU2ll bWVucyBCdXNpbmVzcyBTZXJ2aWNlcyAyMDAzIEFsbCBSaWdodHMgUmVzZXJ2ZWQxPjA8BgNVBAMM NVNpZW1lbnMgQnVzaW5lc3MgU2VydmljZXMgVHJ1c3QgQ2VudGVyIFJvb3QtQ0EgVjEuMS4xMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnyR6BvnlIQWwg6N9crVEYhuomwGEHXieLrNQ 0gJxhDp8G6C3e/JXdHHp7GXBgPsf7QizyxZ0gUfWFYsZoISuTVmjp64cbRX9bkAGr9PohcuxXu4O tHY7iYzujTH/d+yr+EMAK7vG8fBidHHtuVtynFALtKNlmp+jo8rtmWueQGnPP4ugRprBIoebR4Gf UYDtjqjUo6mgQrOrp2D93Sbb9UCl3rqoeIm58QMhuveq8U64mIvCvLS/GITYqaU9GR0+PoeYEQQC nV+Q9COUE8HFtB9ZsKFcZJibMTjJ8+L1x67CgpNzmyNtrlPjXK041dJgoUxMp8TzYsP5qjO2a12O VwIDAQABo4IB3DCCAdgwQQYIKwYBBQUHAQEENTAzMDEGCCsGAQUFBzABhiVodHRwOi8vb2NzcC5w a2ktc2VydmljZXMuc2llbWVucy5jb20vMB8GA1UdIwQYMBaAFKhdgMfjWvoYvbmrbKiy1WlYMX4V MA8GA1UdEwEB/wQFMAMBAf8wVQYDVR0gBE4wTDBKBgRVHSAAMEIwQAYIKwYBBQUHAgEWNGh0dHA6 Ly93d3cuc2llbWVucy5jb20vcGtpLXNlcnZpY2VzL3BraS9jcHMtMS0wLmh0bWwwgaoGA1UdHwSB ojCBnzCBnKCBmaCBloZabGRhcDovL2NkcGxkYXAucGtpLXNlcnZpY2VzLnNpZW1lbnMuY29tL3Vp ZD1aWlpaWjAwMCxvPVRydXN0Y2VudGVyP2F1dGhvcml0eVJldm9jYXRpb25MaXN0hjhodHRwOi8v Y2RwaHR0cC5wa2ktc2VydmljZXMuc2llbWVucy5jb20vcGtpL1paWlpaMDAwLmNybDAOBgNVHQ8B Af8EBAMCAQYwLgYDVR0RBCcwJaAjBggrBgEFBQcIA6AXMBUMCFpaWlpaMDAwBgkrBgEEAaFpBwEw HQYDVR0OBBYEFKhdgMfjWvoYvbmrbKiy1WlYMX4VMA0GCSqGSIb3DQEBBQUAA4IBAQB+r3C+rYQx CutCEhAiGDmknSmz+5KL9fjBUqF4CsSiZr23BgRn5xUiHnz21uSlZeBgr+FBGgiW4tx7ojsV26PM w1Uj0J0mEfnNrSklOixMP3ndCSXwBYVJEjuNFYia3HlvI9Sj2vsx33RIEnb6xIha6eEqZMjZ6V5y wqObzvqdUUoi5dsNasJCgPiDoVioFuaEegYoIH5M/HFnYBWK37BU62eZS76aXk1bpTIufgptdXcJ AsfaQLTpLlMq3isSLv8qk17YPPU3oL0byWR8+sb8kfKp3FiG7swcbWR1CyYkz8bs/7PaoqIRAAPN q6CTpJzDhPNj70gl8uuO7uHsDETuMYIBRzCCAUMCAQEwYDBYMQswCQYDVQQGEwJERTEQMA4GA1UE CgwHU2llbWVuczERMA8GA1UEBRMIWlpaWlowRUUxJDAiBgNVBAMMG1NpZW1lbnMgSXNzdWluZyBD QSBDbGFzcyBFRQIEVHseCTAJBgUrDgMCGgUAoD8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAj BgkqhkiG9w0BCQQxFgQUntcMCHb8EBkqjZudoY9iNm4lpHwwDQYJKoZIhvcNAQEBBQAEgYCCeJDa 5s2dF0WB20fnbsK/jiB4ku7Ws/CIpaFRW2TbYMhNyWa69uIrvMdowYFKoGG2Nigsm55s9DxhuG8K GcQpXa7dh+MwUiXIYnB5wo5YBd0UQwG97ME0ksEy2L6PbQ2yVPCwASda6sjiNFKwwWGolgsFWCHa m5eJ9hBd3xrWsgAAAAAAAA== --===============1243121427== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1243121427==-- From mip6-bounces@ietf.org Thu Jul 21 09:29:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvb6v-0001fX-KC; Thu, 21 Jul 2005 09:29:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvb6u-0001f9-Iw for mip6@megatron.ietf.org; Thu, 21 Jul 2005 09:29:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29291 for ; Thu, 21 Jul 2005 09:29:10 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvbaw-0007sX-Fs for mip6@ietf.org; Thu, 21 Jul 2005 10:00:15 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IJZ00H8VBZC3Z@dns1.cselt.it> for mip6@ietf.org; Thu, 21 Jul 2005 15:26:00 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 15:32:24 +0200 Date: Thu, 21 Jul 2005 15:28:55 +0200 From: Gerardo Giaretta Subject: RE: [Mip6] Bootstrapping DT solution draft To: Christian Vogt Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Bootstrapping DT solution draft thread-index: AcWNYudyFuboJdqvTAGUqbzwyWEJKgAjigQA Content-Class: urn:content-classes:message X-OriginalArrivalTime: 21 Jul 2005 13:32:24.0937 (UTC) FILETIME=[A1695D90:01C58DF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 Hi Christian, thanks for your comments. Please see inline..=20 >=20 > Hi Gerardo, hi DT members, >=20 > thanks for the bootstrapping I-D; you did a very good job! >=20 > Some comments (and questions) from my side: >=20 > (1) The DT draft doesn't yet specify the backend AAA=20 > protocol, e.g., a > Diameter application. Is this your next step? (IMO, considering a > split scenario makes sense only when you specify the AAA=20 > protocol, too, > because that AAA protocol---neither the DNS lookup nor the MN-HA IKEv2 > exchange---is affected by the split.) >=20 Actually the AAA backend is out of the scope of the DT. There is a WG item (draft-ietf-mip6-aaa-ha-goals) that described the goals for the AAA backend interface. A new version of this document will be released based on draft-ietf-mip6-bootstrap-split-00 and based on the solution for integrated scenario we are working on. Then I guess that definition of the AAA protocol should be done by AAA and RADEXT working groups.=20 > (2) Draft-ietf-mip6-ikev2-ipsec-01.txt already defines how to > dynamically assign a HoA during the IKEv2 handshake. Why do you use > different Configuration Payloads? >=20 We use the same attribute for HoA assignment by the HA (i.e. INTERNAL_IP6_ADDRESS attribute). We use a different attribute for HoA auto-configuration (i.e. MIP6_HOME_PREFIX): this is because the MN needs to be provided by a network prefix and its length. This is not the purpose of INTERNAL_IP6_ADDRESS that provides an IPv6 address to the peer. > (3) In order to contact DNS, the MN needs IP connectivity. Is your > assumption that the visited network (ASP/ASA) authorizes the MN for IP > connectivity first, and the MN bootstraps Mobile IPv6=20 > thereafter? (This > would preclude an all-in-one solution like, e.g., the one described in > draft-le-aaa-diameter-mobileipv6-04.txt.) >=20 In split scenario network access authentication and authentication for mobility service are performed indipendently. That is ASA and MSA are different entities. The DT is currently working on an integrated solution for the scenario you mention. > (4) Are you assuming that the DNS server belongs to the MSA? If not, > the MN probably won't have an SA with the DNS server, so DNS requests > are unauthenticated and DNS responses are not encrypted. (Note that I > am NOT talking about DNS updates here.) As a consequence, information > about the home topology is accessible to anybody. Is this an issue? >=20 We believe this is not an issue, even if there has been discussion in the DT about that.=20 The HA address can be recovered by other means anyway. If you are referring to possible DoS attacks, I think that not revealing the HA address during the HA Address discovery is not a viable solution. IKEv2 has mechanisms built in to discourage DoS. Moreover, the Home Agents, like any other server in the network, should be protected against DoS attacks, e.g. by overprovision. > (5) The DNS server can store multiple HA addresses, so dynamic HA > assignment is possible in principle. Do you assume that the=20 > DNS server > is in charge of load balancing or that it can assign a HA=20 > topologically > close to the MN? (Fault tolerance could be handled by DHAAD.) >=20 I think both are possible. Do you think we need more text about this in the draft? --Gerardo > Allright then. >=20 > - Christian >=20 > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ >=20 >=20 >=20 > Gerardo Giaretta wrote: > > Dear WG, > > > > the bootstrapping DT has submitted a solution draft. The document > > defines how a Mobile Node can bootstrap MIPv6 operations from > > non-topological information and pre-configured security=20 > credentials. The > > solution solves the boostrapping problem when the Mobile=20 > Node's mobility > > service is authorized by a different service provider than=20 > basic network > > access (i.e. split scenario). > > > > The draft can be found at > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp ing-split- > > 00.txt. > > > > The DT is currently working on optimized solutions for integrated > > scenario (i.e. mobility service and basic network access=20 > are authorized > > by the same entity). > > > > Please read the document and provide comments. > > > > Thanks and regards, > > > > --Gerardo (DT editor) >=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=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 Thu Jul 21 11:33:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvd3R-0007Aw-PX; Thu, 21 Jul 2005 11:33:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvd3Q-0007Ap-1V for mip6@megatron.ietf.org; Thu, 21 Jul 2005 11:33:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10190 for ; Thu, 21 Jul 2005 11:33:41 -0400 (EDT) Received: from mx2.buaa.edu.cn ([219.239.227.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvdXL-0007m2-8t for mip6@ietf.org; Thu, 21 Jul 2005 12:04:47 -0400 Received: from mx1.buaa.edu.cn (unknown [192.168.128.6]) by mx2.buaa.edu.cn (Postfix) with ESMTP id 6DAD537F64 for ; Thu, 21 Jul 2005 23:32:55 +0800 (CST) Received: from [210.76.115.36] by 10.0.0.131 with StormMail ESMTP id 41176.3495355641; Fri, 22 Jul 2005 00:08:38 +0800 (CST) Message-ID: <42DFC05B.8050605@cse.buaa.edu.cn> Date: Thu, 21 Jul 2005 23:33:47 +0800 From: Li Qin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Bootstrapping DT solution draft References: <42DE0749.9000400@cse.buaa.edu.cn> <00d201c58d47$8163e850$016115ac@dcml.docomolabsusa.com> In-Reply-To: <00d201c58d47$8163e850$016115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , 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 In my opinion I think its more like a HA discovery than HA assignment. If multiple HAs are deployed in home network, is it possible to assign a HA according to the user's profile, or according to current load of the HAs in this solution? James Kempf wrote: > The home DNS server can contain multiple HA addresses in the SRV record. > > jak > > > > ----- Original Message ----- > From: "Li Qin" > To: "Gerardo Giaretta" > Cc: > Sent: Wednesday, July 20, 2005 1:11 AM > Subject: Re: [Mip6] Bootstrapping DT solution draft > > > >>I guess that multiple home agents related issues, such as dynamic home >>agent assignment, have not been considered in this draft. >> >>if so , can you tell us the reason? >> >>Gerardo Giaretta wrote: >> >>>Dear WG, >>> >>>the bootstrapping DT has submitted a solution draft. The document >>>defines how a Mobile Node can bootstrap MIPv6 operations from >>>non-topological information and pre-configured security credentials. The >>>solution solves the boostrapping problem when the Mobile Node's mobility >>>service is authorized by a different service provider than basic network >>>access (i.e. split scenario). >>> >>>The draft can be found at >>>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- >>>00.txt. >>> >>>The DT is currently working on optimized solutions for integrated >>>scenario (i.e. mobility service and basic network access are authorized >>>by the same entity). >>> >>>Please read the document and provide comments. >>> >>>Thanks and regards, >>> >>>--Gerardo (DT editor) >>> >>> >>> >>> >>> >>> >>> >>> >>>Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > > S.p.A. > >>>==================================================================== >>>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 >>>==================================================================== >>> >>>_______________________________________________ >>>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 Jul 21 12:49:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DveF7-0002DC-Pv; Thu, 21 Jul 2005 12:49:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DveF6-0002D4-1B for mip6@megatron.ietf.org; Thu, 21 Jul 2005 12:49:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17542 for ; Thu, 21 Jul 2005 12:49:48 -0400 (EDT) Received: from mx2.buaa.edu.cn ([219.239.227.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dveiz-0004i8-2X for mip6@ietf.org; Thu, 21 Jul 2005 13:20:56 -0400 Received: from mx1.buaa.edu.cn (unknown [192.168.128.6]) by mx2.buaa.edu.cn (Postfix) with ESMTP id D7D1D37F67 for ; Fri, 22 Jul 2005 00:49:10 +0800 (CST) Received: from [210.76.115.36] by 10.0.0.131 with StormMail ESMTP id 41176.1574426920; Fri, 22 Jul 2005 01:24:54 +0800 (CST) Message-ID: <42DFD243.1060406@cse.buaa.edu.cn> Date: Fri, 22 Jul 2005 00:50:11 +0800 From: Li Qin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] Bootstrapping DT solution draft References: <42DE0749.9000400@cse.buaa.edu.cn> <42DE9135.2020701@iprg.nokia.com> In-Reply-To: <42DE9135.2020701@iprg.nokia.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , 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 There are many issues discussed in WG related to DHAAD. For example: security issue and anycast address issue. Also, I think we cannot actually _assign_ an HA using DHAAD, right? In DHAAD, HA address is discoverd and selected by MN, not be assigned by MSP. Vijay Devarapalli wrote: > once the mobile node knows the home prefix, it can still do > DHAAD if it wants to. > > Vijay > > Li Qin wrote: > >> I guess that multiple home agents related issues, such as dynamic home >> agent assignment, have not been considered in this draft. >> >> if so , can you tell us the reason? >> >> Gerardo Giaretta wrote: >> >>> Dear WG, >>> >>> the bootstrapping DT has submitted a solution draft. The document >>> defines how a Mobile Node can bootstrap MIPv6 operations from >>> non-topological information and pre-configured security credentials. The >>> solution solves the boostrapping problem when the Mobile Node's mobility >>> service is authorized by a different service provider than basic network >>> access (i.e. split scenario). >>> >>> The draft can be found at >>> http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- >>> 00.txt. >>> >>> The DT is currently working on optimized solutions for integrated >>> scenario (i.e. mobility service and basic network access are authorized >>> by the same entity). >>> >>> Please read the document and provide comments. >>> >>> Thanks and regards, >>> >>> --Gerardo (DT editor) >>> >>> >>> >>> >>> >>> >>> >>> >>> Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia >>> S.p.A. >>> >>> ==================================================================== >>> 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 >>> ==================================================================== >>> >>> _______________________________________________ >>> 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 Jul 21 16:03:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvhG2-0006nb-TO; Thu, 21 Jul 2005 16:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvTxk-0001wu-LS for mip6@megatron.ietf.org; Thu, 21 Jul 2005 01:51:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10486 for ; Thu, 21 Jul 2005 01:51:15 -0400 (EDT) Received: from webmail.chinamobile.com ([211.136.27.4] helo=cmccmta) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvURV-0003nJ-Ff for mip6@ietf.org; Thu, 21 Jul 2005 02:22:03 -0400 Received: from carcar ([10.1.5.252]) by mail.chinamobile.com (Lotus Domino Release 5.0.12) with SMTP id 2005072113461092:5883 ; Thu, 21 Jul 2005 13:46:10 +0900 From: "Duan Xiaodong" To: Date: Thu, 21 Jul 2005 13:45:48 +0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWNt3HUMaB68NmCQOKbIp1h681jUQ== X-MIMETrack: Itemize by SMTP Server on jtgsml01/servers/cmcc(Release 5.0.12 |February 13, 2003) at 2005-07-21 01:46:11 PM, Serialize by Router on cmccmta/servers/cmcc(Release 5.0.6a |January 17, 2001) at 2005-07-21 01:46:05 PM, Serialize complete at 2005-07-21 01:46:05 PM Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 X-Mailman-Approved-At: Thu, 21 Jul 2005 16:03:00 -0400 Cc: hdeng@hitachi.cn, 'Duan Xiaodong' Subject: [Mip6] about draft-deng-mip6-vrrp-homeagent-reliability-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: , Content-Type: multipart/mixed; boundary="===============1237431490==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1237431490== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01C58DFA.805FF580" This is a multi-part message in MIME format. ------=_NextPart_000_001A_01C58DFA.805FF580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit hi folks, we just submit a internet draft here: http://www.ietf.org/internet-drafts/draft-deng-mip6-vrrp-homeagent-reliabili ty-00.txt It already has been discussed in VRRP working group before http://www1.ietf.org/mail-archive/web/vrrp/current/msg00582.html We hope to discuss this in mip6 WG by the Paris IETF meeting. comments are welcome. -Hui Deng & Xiaodong ------=_NextPart_000_001A_01C58DFA.805FF580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

hi<= /span> folks,

 

we<= /span> just submit a internet draft = here:

htt= p://www.ietf.org/internet-drafts/draft-deng-mip6-vrrp-homeagent-reliabili= ty-00.txt

 

It already has been discussed in VRRP working group before

 

htt= p://www1.ietf.org/mail-archive/web/vrrp/current/msg00582.html

 

We hope to discuss = this in mip6 WG by the Paris IETF meeting.

 

com= ments are welcome.

 

-Hui Deng & Xiaodong

 

 

------=_NextPart_000_001A_01C58DFA.805FF580-- --===============1237431490== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1237431490==-- From mip6-bounces@ietf.org Thu Jul 21 16:03:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvhG3-0006oK-VX; Thu, 21 Jul 2005 16:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvfrP-0007si-8S; Thu, 21 Jul 2005 14:33:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25076; Thu, 21 Jul 2005 14:33:30 -0400 (EDT) Received: from orion.lrg.ufsc.br ([150.162.63.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvgLT-0003Y4-Jo; Thu, 21 Jul 2005 15:04:37 -0400 Received: by orion.lrg.ufsc.br (Postfix, from userid 3002) id 693F6A2B1; Thu, 21 Jul 2005 16:34:59 -0400 (WST) Received: from localhost (localhost [127.0.0.1]) by orion.lrg.ufsc.br (Postfix) with ESMTP id 31DF8DD6D; Thu, 21 Jul 2005 16:34:59 -0400 (WST) Date: Thu, 21 Jul 2005 16:34:58 -0400 (WST) From: Carlos Becker Westphall To: mip6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; REPORT-TYPE=delivery-status; BOUNDARY="=_mh.ndn.632f.42dfe767_=" Content-ID: X-Spam-Score: 1.6 (+) X-Scan-Signature: fec852dbea6d068499ed3250edf328e2 X-Mailman-Approved-At: Thu, 21 Jul 2005 16:03:00 -0400 Cc: Postmaster@stkitts.grc.nasa.gov, mip4@ietf.org, Carlos Becker Westphall Subject: [Mip6] CFP - NOMS 2006 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --=_mh.ndn.632f.42dfe767_= Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: --=_mh.ndn.632f.42dfe767_= Content-Type: MESSAGE/RFC822; CHARSET=US-ASCII Content-ID: Content-Description: Received: from lombok-fi.grc.nasa.gov by stkitts.grc.nasa.gov with ESMTP for pilc@grc.nasa.gov; Thu, 21 Jul 2005 14:20:23 -0400 Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j6LIJhGT019426 for ; Thu, 21 Jul 2005 14:19:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j6LIJhQ5008330 for ; Thu, 21 Jul 2005 14:19:43 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.n asa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 03692-15 for

;Thu, 21 Jul 2005 14:19:39 -0400 (EDT) Received: from mx1.grc.nasa.gov (mx1.grc.nasa.gov [128.156.11.68])by apataki .grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j6LIJYVI008179for ; Thu, 21 Jul 2005 14:19:34 -0400 (EDT) Received: by mx1.grc.nasa.gov (Postfix, from userid 54322)id 013ACC3A6; Thu, 21 Jul 2005 14:19:33 -0400 (EDT) Received: from orion.lrg.ufsc.br (orion.lrg.ufsc.br [150.162.63.1])by mx1.gr c.nasa.gov (Postfix) with ESMTP id DA2C6C31Dfor ; Thu, 2 1 Jul 2005 14:19:26 -0400 (EDT) Received: by orion.lrg.ufsc.br (Postfix, from userid 3002)id EDF95A2A3; Thu, 21 Jul 2005 16:20:44 -0400 (WST) Received: from localhost (localhost [127.0.0.1])by orion.lrg.ufsc.br (Postfi x) with ESMTPid 8EBFCDD6D; Thu, 21 Jul 2005 16:20:44 -0400 (WST) Date: Thu, 21 Jul 2005 16:20:44 -0400 (WST) From: Carlos Becker Westphall To: ejiri@otrs.ts.fujitsu.co.jp, wagner@cs.ubc.ca, westphal@lrg.ufsc.br, stiller@tik.ee.ethz.ch, hellers@us.ibm.com, rboutaba@bbcr.uwaterloo.ca Cc: liste_cfip@info.uqam.ca, tccc@comsoc.org, itc@comsoc.org, rmt@lbl.gov, mboned@network-services.uoregon.edu, avt@ietf.org, nanog@merit.edu, news-announce-conferences@uunet.uu.net, amlist@takilab.k.dendai.ac.jp, disman@dorothy.bmc.com, aaa-wg@merit.edu, rmonmib@ietf.org, policy@ietf.org, snmpv3@lists.tislabs.com, sming@ops.ietf.org, mpls@uu.net, mobile-ip@sunroof.eng.sun.com, gsmp@ietf.org, diffserv@ietf.org, sip@ietf.org, mmusic@ietf.org, manet@ietf.org, cfp@mmlab.snu.ac.kr, conf@colmar.uha.fr, multicomm@research.panasonic.com, nemo@nal.motlabs.com, seamoby@ietf.org, TCPC.Mail@rome.ece.cornell.edu, dares-announcement@enst-bretagne.fr, dnac_2002@yahoo.fr, Georg Carle , all@inf.ethz.ch, all_ifi@ifi.unizh.ch, arl@arl.wustl.edu, cnom@lrg.ufsc.br, commsoft@ieee.org, comswtc@ieee.org, confs-conferencesa@comsoc.org, cost263@fokus.gmd.de, cost264@lip6.fr, disman@dorothy.bmc.com, enternet@bbn.com, gi-fb3@fokus.gmd.de, giga@tele.pitt.edu, ifip_nm@bbcr.uwaterloo.ca, ifip-tc6@informatik.rwth-aachen.de, int-serv@ISI.EDU, issll@mercury.lcs.mit.edu, itc@i-teletraffic.org, itc@ieee.org, kom-meeting@KOM.th-darmstadt.de, KUVS-L@listserv.uni-heidelberg.de, kuvs-elg@fokus.gmd.de, lacomsoc@lrg.ufsc.br, mmb@ira.uka.de, multicomm@comsoc.org, members@ngni.org, netnomics@listserver.tue.nl, nichains@BXL.DG13.cec.eu.int, pilc@grc.nasa.gov, reres@laas.fr, RHDM@lip6.fr, rm@openmash.org, sigmetrics-bb@haven.epm.ornl.gov, spects02@comp.leeds.ac.uk, tcgn@ieee.org, tcgn@majordomo.ieee.org, tcpp-announce@eece.unm.edu, tik@tik.ee.ethz.ch, wiss-mitarb@ee.ethz.ch, xtp-relay@cs.concordia.ca Subject: CFP - NOMS 2006 - 10th IEEE/IFIP Network Operations and ManagementS ymposium (NOMS 2006) In-Reply-To: Message-Id: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 X-Sanitizer: NASA GRC mail filter X-imss-version: 2.25 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:2 S:2 R:2 (0.0100 0.0100) Content-Transfer-Encoding: QUOTED-PRINTABLE We apologize if you receive multiple copies of this CFP. 10th IEEE/IFIP Network Operations and Management Symposium (NOMS 2006) http://www.noms2006.org Call for Papers "Management of Integrated End-to-end Communications and Services" The 10th IEEE/IFIP Network Operations and Management Symposium (NOMS 2006) will be held 3-7 April 2006 in the Vancouver Convention and Exhibition Center, Vancouver, Canada. Held in even-numbered years since 1988, NOMS 2006 will follow the 18 year tradition of NOMS and IM as the primary forum for technical exchange of the research, standards, development, systems integration, service provider, and user communities. NOMS 2006 will present up-to-date approaches and technical solutions for integrated systems and services including communication networks, host systems, enterprise applications, service oriented architectures, and delivery of management services. The conference provides a peer-reviewed program of technical sessions, application sessions, tutorials, posters, application sessions, and panels as well as vendor exhibits. Integrated systems and services require considerations for today's multi-service and multi-domain environment of heterogeneous technologies, service offerings, management strategies, and business models. NOMS 2006 focuses on integrated management that encompasses provisioning, operation, and maintenance. This broad scope also calls for an integrated approach to dependability, resilience, quality-of-service, mobility management, and services billing. In particular, these considerations include the combination of wireless and wired networks and the integration of all-IP communication systems. NOMS 2006 will offer five types of sessions: technical, application, poster, panel, and BoF. Technical sessions present high-quality papers on the latest research results in the network operations and management area. Application sessions present papers focusing on the experience of IT and telecommunications industries, such as service providers, OSS vendors, and equipment manufacturers. The scope here includes customer requirements, management system implementations, and business practices. Poster sessions provide an insight into work-in-progress. Panel sessions focus on business implications, market trends, and emerging applications with panelists who are technology and business leaders. Authors are invited to submit complete unpublished papers that are not under review in any other conference or journal in the following, or related topic areas: Management Paradigms, Models and Architectures * Self-managing networks (self-healing, self-optimizing, self-protecting and self-configuring) * Integrated control and management * Distributed and scalable management * Policy and role based management * Programmable, active, and adaptive mgmt * Resilience and survivability * "Plug-n-Play" component-based management * Customer controlled and managed networks * Proactive and reactive management Operation and Management Functions * Security management * Mobility management * End-to-end measurements * Network and systems monitoring * Alarm correlation and filtering * Customer care and workforce management * Process engineering for operators' service and network management * Performance and fault management * Configuration and accounting management * Integration and testing of commercial off-the-shelf products * Content hosting and delivery * Path Protection and Restoration * Internet service pricing, bandwidth trading, Service engineering, and Operational challenges * Next generation operation support systems * Service design and quality assurance * Resource inventory, planning, and allocation * Service discovery and service negotiation * SLAs and business process management * Quality-of-Service management * Service portability/mobility (VHE) * Transaction-oriented services and supply chain=20 management * "Soft" networks (Soft-switch, Parlay, 3GPP OSA, JAIN) and service switching * Dynamic service requirements analysis * Charging and accounting of integrated systems and services Theories, Models, and Enabling Management Technologies * Theory (control, optimization, economic, games, chaos, graph) for management * Grid, middleware and peer-to-peer technologies * Information models and Internet technologies (Web, XML, DEN, CIM) * AI techniques (knowledge-based, intelligent agents, machine learning, neural networks,) * Data warehousing, ontology, mining and statistical methods in management * User interfaces and virtual reality in management * Management of Emerging Networks and Services * Converged networks and services * Peer-to-peer and community networks * Grids, grid services, and grid applications * Ad hoc and self-configurable networks * Multi-sensor and self-organizing networks * Overlay networks, virtual topologies and VPN services * Wireless broadband networks (2G, 2.5G, 3G, and beyond) * High speed access, Wireless Local (WLANs) and Personal Area Networks (PANs) * Optical networks (metropolitan, all optical, WDM, DWDM, optical IP) * Video and broadband cable networks * VoIP, VoD, FTTX networks, services, and protocols (IPv4, IPv6, H.323, SIP, RTP, RTCP, RTSP, MGCP, and QoS) * Storage Area Networks (SAN) and ASPs server farms * Web services and content delivery networks * Smart homes and networked haptics * Satellite and interplanetary networks * e-World (e-health,e-commerce, e-business, and e-government) Important Dates: * Deadline for Technical Session Papers: 1 August 2005 * Deadline for Application Session Papers: 15 September 2005 * Deadline for Tutorials, Panels and Posters: 15 September 2005 * Notification of Acceptance: 12 November 2005 * Final Camera Ready Papers Due: 1 February 2006 For more information on NOMS 2006, please contact one of the two Program Co-chairs: Joseph L. Hellerstein , IBM, U.S.A. Burkhard Stiller , University of Z=FCrich and ETH Z=FCrich, Switzerland NOMS 2006 Poster Sessions ------------------------- In addition to regular papers presented in technical sessions, NOMS 2006 also offers poster sessions for more informal interactions and presenting work in progress. Short papers (4 pages long) can be submitted for consideration as poster presentations. Posters will be selected from these short papers and regular papers. You can submit your work selecting "Poster session" in the NOMS 2006 submission system (JEMS) at https://submissoes.sbc.org.br/noms2006. Further questions related to posters must be addressed to the poster co-chairs: Lisandro Zambenedetti Granville , Federal University of Rio Grande do Sul Nikos Anerousis , IBM, U.S.A. Kyung-Hyu Lee , ETRI, Korea NOMS 2006 Application Sessions ------------------------------ The NOMS2006 Application Session submissions aim to encourage discussions concerning experience, lessons-learned, business cases, implementation examples, new applications, innovative enterprises, and organizational impacts, in any of the detailed topics found at http://www.noms2006.org. Papers for the Application Sessions should be written in English. The paper format should have a visual in the upper half of a page and the explanatory text in the lower half (annotated visuals). Paper submissions should consist of no more than 15 annotated visuals in PDF only. Detailed author instructions are available on the author information page on the conference web site. Further questions related to the application session should be addressed to the application sessions co-chairs: Joseph Betser , The Aerospace Corporation, U.S.A. Prosper Chemouil , France Telecom, France Yoshiaki Kiriha , NEC, Japan NOMS 2006 Workshops ------------------- Workshops on specialized topics will be held on the days before and after the NOMS technical program. Contributions to these workshops will be solicited and reviewed separately from those for NOMS. A proposal to organize a half-day or full-day workshop should contain the following information * A draft of the CFP (includes Title, description, topics and dates) * Why is the topic area important? * Likely contributors and target audience * Organizing committee * Plan for workshop advertising and publicity * Biography of the main organizer (100-200 words) Deadline for submission is September 15, 2005. For a point of reference, see the workshops held in conjunction with IM 2005 at http://www.ieee-im.org/workshops.html. Workshop proposals should be sent to one of the tutorial co-chairs: Ehab Al-Shaer , De Paul University, U.S.A. Rolf Stadler , KTH, Sweden NOMS 2006 Tutorials ------------------- NOMS 2006 will feature state-of-the-art tutorials from top experts in their fields on the days before (April 3, 2006) and after (April 7, 2006) the technical program. Topics cover every level from introductory skills to highly advanced and address highly important and relevant subject areas of Systems, Network, and Service Management. =20 To provide the best possible tutorial offerings, NOMS 2006 solicits proposals and ideas for half-day (3.5 hours) and full-day (7 hours) tutorials. Proposals will be evaluated by the NOMS 2006 Technical Program Committee. Tutorial presenters will receive a honorarium. If you are interested in presenting a tutorial at this conference or have an idea for a tutorial you would like to see offered please contact the Tutorial Chair: Alexander Keller , IBM, USA Deadline for submitting Tutorial Proposals: 15 September 2005. A proposal to present a tutorial should contain the following information: * Tutorial Title * Full Name(s) and Affiliation(s) of the Instructor(s) * Outline and Extended Abstract (500-1000 words) detailing the importance of the subject and its relevance and benefits to NOMS 2006 attendees * Potential attendee profile * Biography of the Instructor (100-200 words) If the tutorial or its earlier version has been given before, please indicate the events, dates and contents. -------------------------------------------------------------- --=_mh.ndn.632f.42dfe767_= Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --=_mh.ndn.632f.42dfe767_=-- From mip6-bounces@ietf.org Thu Jul 21 22:46:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvnY2-0007Fr-Od; Thu, 21 Jul 2005 22:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvnY2-0007Fm-37 for mip6@megatron.ietf.org; Thu, 21 Jul 2005 22:46:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12731 for ; Thu, 21 Jul 2005 22:46:00 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dvo2B-0003Pd-TB for mip6@ietf.org; Thu, 21 Jul 2005 23:17:12 -0400 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id E266B4CD87 for ; Fri, 22 Jul 2005 11:44:28 +0900 (JST) Date: Fri, 22 Jul 2005 11:45:52 +0900 From: Thierry Ernst To: mip6@ietf.org Subject: Re: [Mip6] about draft-deng-mip6-vrrp-homeagent-reliability-00.txt Message-Id: <20050722114552.60429c88.ernst@sfc.wide.ad.jp> In-Reply-To: References: Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Hi, Are you only consireding the case where all HAs are on the same link, or do you also cover the case where HAs are on disctinct links (the MN would thus have a different HoA). In addition to this, do you consider the case where both HAs could be used simultaneously by a given MN ? Thanks, Thierry On Thu, 21 Jul 2005 13:45:48 +0800 "Duan Xiaodong" wrote: > > hi folks, > > we just submit a internet draft here: > http://www.ietf.org/internet-drafts/draft-deng-mip6-vrrp-homeagent-reliabili > ty-00.txt > > It already has been discussed in VRRP working group before > > http://www1.ietf.org/mail-archive/web/vrrp/current/msg00582.html > > We hope to discuss this in mip6 WG by the Paris IETF meeting. > > comments are welcome. > > -Hui Deng & Xiaodong > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jul 22 10:52:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvysm-0001aZ-Dr; Fri, 22 Jul 2005 10:52:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvysl-0001aQ-0h for mip6@megatron.ietf.org; Fri, 22 Jul 2005 10:52:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21794 for ; Fri, 22 Jul 2005 10:52:08 -0400 (EDT) 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.43) id 1DvzMz-0000Jd-Tu for mip6@ietf.org; Fri, 22 Jul 2005 11:23:27 -0400 Message-ID: <01cf01c58ecc$e84fe5b0$596015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Li Qin" References: <42DE0749.9000400@cse.buaa.edu.cn> <00d201c58d47$8163e850$016115ac@dcml.docomolabsusa.com> <42DFC05B.8050605@cse.buaa.edu.cn> Subject: Re: [Mip6] Bootstrapping DT solution draft Date: Fri, 22 Jul 2005 07:51:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , 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 The SRV record contains information that the operator can use to establish a preference ordering on the servers for clients. That said, I don't believe it is intended to provide fast, real time information about preferences, say on the order of seconds., but more over longer periods, since dynamic DNS updates require some time to propagate, and it would also not be such a good idea to burden the DNS server with having to handle such frequent updates. Its also possible for the HAs themselves to refuse new IKEv2 connections if they are loaded. Since the MN will have a list of HAs, it will just roll over to trying the next one. The HAs could co-operate somehow (maybe using a protocol like HAHA?) to establish which HA should be taking new connections. This could be used to perform finer grained load balancing. Make sense? jak ----- Original Message ----- From: "Li Qin" To: "James Kempf" Cc: "Li Qin" ; "Gerardo Giaretta" ; Sent: Thursday, July 21, 2005 8:33 AM Subject: Re: [Mip6] Bootstrapping DT solution draft > In my opinion I think its more like a HA discovery than HA assignment. > > If multiple HAs are deployed in home network, is it possible to assign a > HA according to the user's profile, or according to current load of the > HAs in this solution? > > James Kempf wrote: > > The home DNS server can contain multiple HA addresses in the SRV record. > > > > jak > > > > > > > > ----- Original Message ----- > > From: "Li Qin" > > To: "Gerardo Giaretta" > > Cc: > > Sent: Wednesday, July 20, 2005 1:11 AM > > Subject: Re: [Mip6] Bootstrapping DT solution draft > > > > > > > >>I guess that multiple home agents related issues, such as dynamic home > >>agent assignment, have not been considered in this draft. > >> > >>if so , can you tell us the reason? > >> > >>Gerardo Giaretta wrote: > >> > >>>Dear WG, > >>> > >>>the bootstrapping DT has submitted a solution draft. The document > >>>defines how a Mobile Node can bootstrap MIPv6 operations from > >>>non-topological information and pre-configured security credentials. The > >>>solution solves the boostrapping problem when the Mobile Node's mobility > >>>service is authorized by a different service provider than basic network > >>>access (i.e. split scenario). > >>> > >>>The draft can be found at > >>>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- > >>>00.txt. > >>> > >>>The DT is currently working on optimized solutions for integrated > >>>scenario (i.e. mobility service and basic network access are authorized > >>>by the same entity). > >>> > >>>Please read the document and provide comments. > >>> > >>>Thanks and regards, > >>> > >>>--Gerardo (DT editor) > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > > > > S.p.A. > > > >>>==================================================================== > >>>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 > >>>==================================================================== > >>> > >>>_______________________________________________ > >>>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 Fri Jul 22 14:18:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw26V-00074U-Kx; Fri, 22 Jul 2005 14:18:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw26U-00073E-1y for mip6@megatron.ietf.org; Fri, 22 Jul 2005 14:18:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07493 for ; Fri, 22 Jul 2005 14:18:32 -0400 (EDT) Received: from smtp.um.es ([155.54.212.105] helo=mail.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw2ak-0008N1-Jl for mip6@ietf.org; Fri, 22 Jul 2005 14:49:52 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 18B4F23C159; Fri, 22 Jul 2005 20:18:22 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23678-01-45; Fri, 22 Jul 2005 20:18:21 +0200 (CEST) Received: from [155.54.194.41] (dibulibu.um.es [155.54.1.250]) by mail.um.es (Postfix) with ESMTP id 393DA23C0B9; Fri, 22 Jul 2005 20:18:21 +0200 (CEST) Message-ID: <42E13870.2010107@dif.um.es> Date: Fri, 22 Jul 2005 20:18:24 +0200 From: Rafa Marin Lopez Organization: University of Murcia User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] Bootstrapping DT solution draft References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 2696b5382f263e6d2b082a0a0572f4b8 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 Hi Gerardo Sorry for my delayed answer. Please see my comments inline: >>$Rafa> I was wondering what is the role of MSP AAA server in >>the roaming >>scenario. For example considering following example: >> >>MN <---------IKEv2(EAP)------------>HA<------Diameter(EAP) -------> >>MSA's AAA server >> >>HA can request a redirect agent to contact directly with MSA's AAA >>server (at least this policy is being followed with network >>access service >>as far as I know). So what is the role of MSP's AAA server?? only AAA >>routing?? >> >> >> >AAA server is involved in AAA routing. But, as you mention below, it >should have an active role also in the authorization step, since the >usage of the HA in the MSP may need to be explicetly authorized by the >MSP itself. > > <$Rafa> Then maybe it should be reflected in the I-D > > >>Another related question is about authorization. Under my >>point of view >>, MSP's AAA server is the entity that finally takes decision about if >>the mobility service is authorized or not. MSA's AAA server could send >>to MSP's AAA some kind of evidences or attributes related with >>authenticated user.Following these attributes and internal policies >>MSP's AAA server takes a final decision. >> >> >> > >I tend to agree. This is the reason why AAA server of the MSP should be >involved. I think that these issues should be covered by >draft-mip6-aaa-ha-goals. > <$rafa> Well... in the MIP6 bootstrapping draft , you mention that MSA is giving authorization. However if you agree that MSP can be involved in the authorization , I don't see why it should explained in draft-mip6-aaa-ha-goals. > As you know, in this DT draft, we have not >spcified the backend communitcation between HA and AAA infrastructure >since we consider it out of the scope of the DT. > > <$Rafa> Yes I know > > >>In particular , I was thinking a similar model than it is shown in >>Diameter EAP application I-D (Scenario 3: Direct EAP, >>authorization via >>agents). >> >>Note this dicussion could be also valid for other services >>(i.e. network >>access service). >> >> >> > >I tend to agree also here. The MSP might need to add some authorization >AVPs. > <$Rafa> I agree that AVPs or specific information could be placed on draf-ietf-aaa-ha-goals but to say if MSP is involved in authorization or not could be said in bootstrapping solution I-D. >But, again, I think this is out of the scope of this draft. These >issues will be considered when we'll discuss the AAA backend protocol >specification. > > > > >>>Therefore, in the split scenario, two different cases can be >>>identified depending on the relationship between the entity that >>>provides the mobility service (i.e. Mobility Service Provider, MSP) >>>and the entity that authenticates and authorizes the user (i.e. >>>Mobility Service Authorizer, MSA). >>>Figure 1 depicts the split scenario when the MSP and the >>> >>> >>MSA are the >> >> >>>same entity. This means that the network operator that provides the >>>Home Agent authenticates and authorizes the user for >>> >>> >>mobility service. >> >> >>$Rafa> During text, you also consider PKI as backend infrastructure. >>Maybe it should appear in the figure 1 not only AAA. >> >> >> > >Yes, you are right. I'll add it as a possible choice. > > <$rafa> Ok > > >>>Mobility Service Provider and Authorizer >>>+-------------------------------------------+ | | | +-------------+ >>>+--+ | | | MSA/MSP AAA | <-------------> |HA| | | | server | AAA >>>protocol +--+ | | +-------------+ | | | >>>+-------------------------------------------+ +--+ |MN| >>> >>> >>+--+ Figure 1 >> >> >>>- Split Scenario (MSA == MSP) G. Giaretta, Ed. Expires December 22, >>>2005 [Page 6] >>> >>> >>> >>> >>> >>> >> >> >> >> >>>4. Components of the solution >>>The bootstrapping problem is composed of different >>> >>> >>sub-problems that >> >> >>>can be solved independently in a modular way. The components >>>identified and a brief overview of their solution follow. >>>o HA address discovery. The Mobile Node needs to discover >>> >>> >>the address >> >> >>>of its Home Agent. The main objective of a bootstrapping >>> >>> >>solution is >> >> >>>to minimize the data pre-configured on the Mobile Node. For this >>>reason, the DHAAD defined in [2] may not be applicable in real >>>deployments since it is required that the Mobile Node is >>>pre-configured with the home network prefix and it does not >>> >>> >>allow an >> >> >>>operator to load balance by having Mobile Nodes dynamically >>> >>> >>assigned >> >> >>>to Home Agents located in different subnets. This document >>> >>> >>defines a >> >> >>>solution for Home Agent address discovery that is based on >>> >>> >>Domain Name >> >> >>>Service (DNS), introducing a new DNS SRV record [5]. >>> >>>The unique information that needs to be pre- >>>configured on the Mobile Node is the domain name of the MSP. >>> >>> >>> >> >> >> >> >>>o IPsec Security Associations setup. MIPv6 requires that a >>> >>> >>Mobile Node >> >> >>>and its Home Agent share an IPsec SA in order to protect binding >>>updates and other MIPv6 signaling. This document provides a >>> >>> >>solution >> >> >>>that is based on IKEv2 and follows what is specified in >>> >>> >>[6]. The IKEv2 >> >> >>>peer authentication can be performed both using >>> >>> >>certificates and using >> >> >>>EAP, depending on the network operator's deployment model. >>>o HoA assignment. The Mobile Node needs to know its Home Address in >>>order to bootstrap Mobile IPv6 operation. The Home Address >>> >>> >>is assigned >> >> >>>by the Home Agent during the IKEv2 exchange (as described >>> >>> >>in [6]). The >> >> >>>solution defined in this draft also allows the Mobile Node to >>>auto-configure its Home Address based on stateless auto- >>>configuration ([20]), Cryptographically Generated Addresses >>> >>> >>([9]) or >> >> >>>privacy addresses ([10]). >>>o Authentication and Authorization with MSA. The user must be >>>authenticated in order for the MSA to grant the service. >>> >>> >><$Rafa> Here appears "MSA to grant the service" and in page >>10 section >>5.1.1 >>"MSP granting the mobility service". Would it not be in the first case >>"MSP to grant the service" too? >> >> >> > >Yes. What about the following text? > >" >Authentication and Authorization with MSA. The user must be >authenticated in order for the MSP to grant the service. Since the user >credentials can be verified only by the MSA, this authorization step is >performed by the MSA. Moreover, the mobility service must be explicitly >authorized by the MSA based on the user's profile. These operations are >performed in different ways depending on the credentials used by the >Mobile Node during the IKEv2 peer authentication and on the backend >infrastructure (PKI or AAA). > > >" > > <$Rafa> As you can see, this text still state MSA is explicitly doing the authorization and MSP is not involved. So I understand from this that MSP's AAA server is only doing routing. > > > >> >> >> >> >>>5. Protocol Operations >>>This section describes in detail the procedures needed to perform >>>Mobile IPv6 bootstrapping based on the components identified in the >>>previous section. >>> >>>5.1. Home Agent Address Discovery >>>Once a Mobile Node has obtained network access, it can >>> >>> >>perform Mobile >> >> >>>IPv6 bootstrapping. For this purpose, the Mobile Node >>> >>> >>queries the DNS >> >> >>>server to request information on Home Agent service. As mentioned >>>before in the document, the only information that needs to be auto- >>>configured >>> >>> >><$Rafa> autoconfigured---> pre-configured?? >> >> >> > >fixed. > > <$rafa> ok. > > >>>on the Mobile Node is the domain name of the Mobility >>> >>> >>Service Provider. >> >> >>>The Mobile Node needs to obtain the IP address of the DNS server >>>before it can send a DNS request. This can be pre-configured on the >>>Mobile Node or obtained through DHCPv6 from the visited >>> >>> >>link [11]. In >> >> >>>any case, it is assumed that there is some kind of >>> >>> >>mechanism by which >> >> >>>the Mobile Node is configured with a DNS server since a DNS >>> >>> >>server is >> >> >>>needed for many other reasons. >>>Two options for DNS lookup for a Home Agent address are >>> >>> >>identified in >> >> >>>this document: DNS lookup by Home Agent Name and DNS lookup >>> >>> >>by service >> >> >>>name. >>>While this document specifies a Home Agent Address >>> >>> >>Discovery solution >> >> >>>based on DNS, when the ASP and the MSP are the same entity >>> >>> >>DHCP may be >> >> >>>used. See [15] for details. >>> >>> >>> >> >> >> >> >>>5.4. Authorization and Authentication with MSA >>>In a scenario where the Home Agent is discovered dynamically by the >>>Mobile Node, it is very likely that the Home Agent is not able to >>>verify by its own the credentials provided by the Mobile >>> >>> >>Node during >> >> >>>the IKEv2 exchange. Moreover, the mobility service needs to be >>>explicitly authorized based on the user's profile. >>> >>> >> >> >> >>>As an example, the Home Agent might not be aware if the mobility >>>service can be granted at a particular time of the day or if the >>>credit of the Mobile Node is going to expire. >>> >>> >>> >><$Rafa> In the example, could MSA know that mobility service can be or >>cannot be granted at a particular time depending on internal >>policies in >>the MSP? I guess this example considers that user's profile says that >>this user cannot use the service during a particular time of the >>day.However it does not consider that user has no restricction about >>this time but MSP decides that mobility service cannot be >>granted during >>a particular time of the day. Home Agent should be aware of this too. >> >> >> > >Yes. The text refers to policies that the MSA might send to the MSP >based on the user's profile. However, as you mention, some policies can >be also forced by the MSP. Do you think we need some text about that in >the draft? > > <$rafa> As I mentioned previosly, i think some text about MSP and MSP's AAA server role should be included. Although I don't know what others think. However I recognize the same text could be applied for other services not only MIP6 > > >>>Due to all these reasons, the Home Agent may need to >>> >>> >>contact the MSA >> >> >>>in order to authenticate >>> >>>the Mobile Node and authorize mobility G. Giaretta, Ed. Expires >>>December 22, 2005 [Page 14] >>> >>> >>> >>> >>> >>> >>>Internet-Draft MIPv6 bootstrapping in split scenario June 2005 >>>service. This can be accomplished based on a Public Key >>> >>> >>Infrastructure >> >> >>>if certificates are used and a PKI >>> >>> >>> >><$Rafa> For authorization ... are you considering attributes >>certificates when >>PKI is used...?? >> >> >> > >How to use PKI for authorization purposes is actually a general open >issue, not only in this draft. We mentioned this in the draft but I >think this is more in the scoper of AAA-HA interface solution. Maybe >Hannes could be more precise about that since he had some ideas during >DT discussion. > > <%Rafa> waiting for Hannes' answer. > > >>>is deployed by the MSP and MSA. On the other hand, if the >>> >>> >>Mobile Node >> >> >>>is provided with other types of credentials, the AAA infrastructure >>>must be used. >>>The definition of this backend communication is out of the scope of >>>this document. In [12] a list of goals for such a communication is >>>provided. >>> >>> >>>6. Home Address registration in the DNS >>>In order that the Mobile Node is reachable through its dynamically >>>assigned Home Address, the DNS needs to be updated with the >>> >>> >>new Home >> >> >>>Address. Since applications make use of DNS lookups on FQDN >>> >>> >>to find a >> >> >>>node, the DNS update is essential for providing IP >>> >>> >>reachability to the >> >> >>>Mobile Node, which is the main purpose of the Mobile IPv6 protocol. >>>The need of DNS update is not discussed in RFC 3775 since >>> >>> >>it assumes >> >> >>>that the Mobile Node is provisioned with a static home address. >>>However, when a dynamic Home Address is assigned to the >>> >>> >>Mobile Node, >> >> >>>any existing DNS entry becomes invalid and the Mobile Node becomes >>>unreachable unless a DNS update is performed. >>>Since the DNS update must be performed securely in order to prevent >>>attacks or modifications from malicious nodes, the node performing >>>this update must share a security association with the DNS server. >>>Having all possible Mobile Nodes sharing a security >>> >>> >>association with >> >> >>>the DNS servers of the MSP might be cumbersome from an >>> >>> >>administrative >> >> >>>perspective. Moreover, even if a Mobile Node has a security >>>association with a DNS server of its MSP, an address authorization >>>issue comes into the picture. A detailed analysis of >>> >>> >>possible threats >> >> >>>against DNS update is provided in section 9.5. >>>Therefore, due to security and administrative reasons, it is >>>RECOMMENDED that the Home Agent perform DNS entry update for the >>>Mobile Node. For this purpose the Mobile Node MAY include a new >>>mobility option, the DNS Update option, with the flag R not >>> >>> >>set in the >> >> >>>Binding Update. This option is defined in section 8 and >>> >>> >>includes the >> >> >>>FQDN that needs to be updated. After receiving the Binding >>> >>> >>Update, the >> >> >>>Home Agent MUST update the DNS entry with the identifier >>> >>> >>provided by >> >> >>>the Mobile Node and the Home Address included in the Home Address >>>Option. The procedure for sending a dynamic DNS update message is >>>specified in [14]. The dynamic DNS update SHOULD be performed in a >>>secure way; for this reason, the usage of TKEY and TSEC or >>> >>> >>DNSSEC is >> >> >>>recommended (see section 9.5 for details). As soon as the >>> >>> >>Home Agent >> >> >>>has updated the DNS, it MUST send a Binding Acknowledgement >>> >>> >>message to >> >> >>>the Mobile Node including the DNS Update mobility option with the >>>correct value in the Status field (see section 8.1). >>>This procedure can be performed directly by the Home Agent >>> >>> >>if the Home >> >> >>>Agent has a security association with the domain specified in the >>>Mobile Node's FQDN. >>> >>> >>> >>> >><$Rafa> Why don't MSP's AAA server could do DNS update >>instead of MSA's >>AAA server?? >> >> >> > >It could. But I don't see a reason for that. Do you see any issue with >the current solution? > > <%Rafa> if MSP provides the Home Agent , and Home Agent gives a Home Address... would not be more coherent that MSP's AAA server did this task? > > >>>On the other hand, if the Mobile Node wants to be reachable >>> >>> >>through a >> >> >>>FQDN that belongs to the MSA, the Home Agent and the DNS >>> >>> >>server that >> >> >>>must be updated belong to different administrative domain. >>> >>> >>In this G. >> >> >>>Giaretta, Ed. Expires December 22, 2005 [Page 16] >>> >>> >>> >>> >>> >>> >>>Internet-Draft MIPv6 bootstrapping in split scenario June 2005 >>>case the Home Agent may not share a security association >>> >>> >>with the DNS >> >> >>>server and the DNS entry update can be performed by the AAA >>> >>> >>server of >> >> >>>the MSA. In order to accomplish this, the Home Agent sends >>> >>> >>to the AAA >> >> >>>server the FQDN-HoA pair through the AAA protocol. This message is >>>proxied by the AAA infrastructure of the MSP and is received by the >>>AAA server of the MSA. The AAA server of the MSA perform the DNS >>>update based on [14]. The detailed description of the communication >>>between Home Agent and AAA is out of the scope of this draft. More >>>details are provided in [12]. >>> >>> >>> >>> >> >> >> >> >>>9. Security Considerations >>>9.1. HA Address Discovery >>>Use of DNS for address discovery carries certain security >>> >>> >>risks. DNS >> >> >>>transactions in the Internet are typically done without any >>>authentication of the DNS server by the client or of the >>> >>> >>client by the >> >> >>>server. There are two risks involved: >>>1) A legitimate client obtains a bogus Home Agent address >>> >>> >>from a bogus >> >> >>>DNS server. This is sometimes called a "pharming" attack, >>>2) An attacking client obtains a legitimate Home Agent >>> >>> >>address from a >> >> >>>legitimate server. >>> >>> >>> >><$Rafa>I have a comment regarding this case 1): I think any >>user already >>authenticated and authorized to use mobility service could launch >>this attack becuase user already owns a valid certificate and >>therefore >>a legitimate client could verify this certificate. The issue is this >>user is NOT AUTHORIZED to be a Home Agent. what do you think?? >> >> >> > >I don't get your point. Which scenario are you referring to? Are you >assuming only certificates is used or also AAA? > > <$Rafa> I am assuming only certificates. > > >>>The risk in Case 1 is mitigated because the Mobile Node is >>> >>> >>required to >> >> >>>conduct an IKE transaction with the Home Agent prior to >>> >>> >>performing a >> >> >>>Binding Update to establish Mobile IPv6 service. According to the >>>IKEv2 specification [7], the responder must present the >>> >>> >>initiator with >> >> >>>a valid certificate containing the responder's public key, and the >>>responder to initiator IKE_AUTH message must be protected with an >>>authenticator calculated using the public key in the certificate. >>>Thus, an attacker would have to set up both a bogus DNS >>> >>> >>server and a >> >> >>>bogus Home Agent, and provision the Home Agent with a >>> >>> >>certificate that >> >> >>>a victim Mobile Node could verify. If the Mobile Node can >>> >>> >>detect that >> >> >>>the certificate is not trustworthy, the attack will be >>> >>> >>foiled when the >> >> >>>Mobile Node attempts to set up the IKE SA. >>> >>> >>> >>> >> >> >> >> >>>9.5. Dynamic DNS Update >>>Mobile IPv6 bootstrapping recommends the Home Agent to update the >>>Mobile Node's FQDN with a dynamically assigned home address rather >>>than have the Mobile Node itself do it (see Section 6 above). This >>>choice was motivated by a concern for preventing redirection-based >>>flooding attacks (see draft-ietf-mip6-ro-sec [19] for more >>> >>> >>information >> >> >>>about redirection-based flooding attacks and the role >>> >>> >>preventing them >> >> >>>played in the design of Mobile IPv6 route optimization security). >>>Exactly as for route optimization, it is possible for a >>> >>> >>node that is >> >> >>>the legitimate owner of a DNS FQDN - in the sense that it has a >>>security association with the DNS server allowing it to perform >>>dynamic DNS update of its FQDN - to bind its FQDN to the >>> >>> >>address of a >> >> >>>victim, then redirect large volumes of traffic at the victim. The >>>attack may be propagated without the owner's knowledge, for >>> >>> >>example, >> >> >>>if the node is compromised by malware, or it may be >>> >>> >>intentional if the >> >> >>>node itself is the attacker. >>>While it is possible to prevent redirection attacks through ingress >>>filtering on access routers, ISPs have little or no incentive to >>>deploy ingress filtering. In some cases, if an attack could >>> >>> >>result in >> >> >>>substantial financial gain, it is even possible that a >>> >>> >>corrupt ISP may >> >> >>>have an incentive not to deploy ingress filters such as has >>> >>> >>been the >> >> >>>case for spam. Consequently, the security for dynamic >>> >>> >>Mobile Node FQDN >> >> >>>update has been assigned to the Home Agent, where active network >>>administration and vigilant defense measures are more >>> >>> >>likely to (but >> >> >>>G. Giaretta, Ed. Expires December 22, 2005 [Page 25] >>> >>> >>> >>> >>> >>> >>>Internet-Draft MIPv6 bootstrapping in split scenario June 2005 >>>are not assured of) mitigating problems, and the owner of >>> >>> >>the Mobile >> >> >>>Node is more likely to detect a problem if it occurs. >>>If a Home Agent performs dynamic DNS update on behalf of the Mobile >>>Node directly with the DNS server, the Home Agent MUST have >>> >>> >>a security >> >> >>>association of some type with the DNS server. The security >>> >>> >>association >> >> >>>MAY be established either using DNSSEC [16] or TSIG/TKEY >>> >>> >>[17][18]. A >> >> >>>security association is required even if the DNS server is >>> >>> >>in the same >> >> >>>administrative domain as the Home Agent. The security association >>>SHOULD be separate from the security associations used for other >>>purposes, such as AAA. >>>In the case where the Mobility Service Provider is >>> >>> >>different from the >> >> >>>Mobility Service Authorizer, the network administrators may want to >>>limit the number of cross-administrative domain security >>> >>> >>associations. >> >> >>>If the Mobile Node's FQDN is in the Mobility Service Authorizer's >>>domain, since a security association for AAA signaling involved in >>>mobility service authorization is required in any case, the >>> >>> >>Home Agent >> >> >>>can send the Mobile Node's FQDN to the AAA server under the HA-AAA >>>server security association, >>> >>> >>$Rafa> MSA's AAA Server?? or MSP's AAA server?? >> >> >> > >To the MSA's AAA server through the MSP's AAA server. The MSA's AAA >server updates the MSA's DNS server. > > > >>So far, these are my comments. >> >> >> > >Thanks again, > >--Gerardo > > > >>Regards. >> >>-- >>------------------------------------------------------ >>Rafael Marin Lopez >>Faculty of Computer Science-University of Murcia >>30071 Murcia - Spain >>Telf: +34968367645 e-mail: rafa@dif.um.es >>------------------------------------------------------ >> >> >> >> >> >> >> >> >>Gerardo Giaretta wrote: >> >> >> >>>Dear WG, >>> >>>the bootstrapping DT has submitted a solution draft. The document >>>defines how a Mobile Node can bootstrap MIPv6 operations from >>>non-topological information and pre-configured security >>> >>> >>credentials. The >> >> >>>solution solves the boostrapping problem when the Mobile >>> >>> >>Node's mobility >> >> >>>service is authorized by a different service provider than >>> >>> >>basic network >> >> >>>access (i.e. split scenario). >>> >>>The draft can be found at >>> >>> >>> >>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp >>ing-split- >> >> >>>00.txt. >>> >>>The DT is currently working on optimized solutions for integrated >>>scenario (i.e. mobility service and basic network access >>> >>> >>are authorized >> >> >>>by the same entity). >>> >>>Please read the document and provide comments. >>> >>>Thanks and regards, >>> >>>--Gerardo (DT editor) >>> >>> >>> >>> >>> >>> >>> >>> >>>Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia >>>S.p.A. >>> >>>==================================================================== >>>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 >>>==================================================================== >>> >>>_______________________________________________ >>>Mip6 mailing list >>>Mip6@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> >>> >>> >>> >>> >> >> >>Gerardo Giaretta wrote: >> >> >> >>>Dear WG, >>> >>>the bootstrapping DT has submitted a solution draft. The document >>>defines how a Mobile Node can bootstrap MIPv6 operations from >>>non-topological information and pre-configured security >>> >>> >>credentials. The >> >> >>>solution solves the boostrapping problem when the Mobile >>> >>> >>Node's mobility >> >> >>>service is authorized by a different service provider than >>> >>> >>basic network >> >> >>>access (i.e. split scenario). >>> >>>The draft can be found at >>>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap >>> >>> >>ping-split- >> >> >>>00.txt. >>> >>>The DT is currently working on optimized solutions for integrated >>>scenario (i.e. mobility service and basic network access are >>> >>> >>authorized >> >> >>>by the same entity). >>> >>>Please read the document and provide comments. >>> >>>Thanks and regards, >>> >>>--Gerardo (DT editor) >>> >>> >>> >>> >>> >>> >>> >>> >>>Gruppo Telecom Italia - Direzione e coordinamento di Telecom >>> >>> >>Italia S.p.A. >> >> >>>==================================================================== >>>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 >>>==================================================================== >>> >>>_______________________________________________ >>>Mip6 mailing list >>>Mip6@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> >>> >>> >>> >>-- >>------------------------------------------------------ >>Rafael Marin Lopez >>Faculty of Computer Science-University of Murcia >>30071 Murcia - Spain >>Telf: +34968367645 e-mail: rafa@dif.um.es >>------------------------------------------------------ >> >> >> >> > > >Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > >==================================================================== >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 >==================================================================== > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jul 22 14:53:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2eT-0004P6-5o; Fri, 22 Jul 2005 14:53:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dw2eQ-0004P1-4J for mip6@megatron.ietf.org; Fri, 22 Jul 2005 14:53:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10034 for ; Fri, 22 Jul 2005 14:53:36 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dw38e-0001Ew-8r for mip6@ietf.org; Fri, 22 Jul 2005 15:24:56 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6MIHR301244; Fri, 22 Jul 2005 11:17:27 -0700 X-mProtect: <200507221817> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdPvi7uK; Fri, 22 Jul 2005 11:17:25 PDT Message-ID: <42E13FA7.8010209@iprg.nokia.com> Date: Fri, 22 Jul 2005 11:49:11 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird (X11/20050322) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Li Qin Subject: Re: [Mip6] Bootstrapping DT solution draft References: <42DE0749.9000400@cse.buaa.edu.cn> <42DE9135.2020701@iprg.nokia.com> <42DFD243.1060406@cse.buaa.edu.cn> In-Reply-To: <42DFD243.1060406@cse.buaa.edu.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , 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 Li Qin wrote: > There are many issues discussed in WG related to DHAAD. For example: > security issue and anycast address issue. > > Also, I think we cannot actually _assign_ an HA using DHAAD, right? > In DHAAD, HA address is discoverd and selected by MN, not be assigned > by MSP. actually you can, by adjusting the HA preference value. the list of HAs in a DHAAD reply is ordered based on the HA's preference value. but I understand what you are getting at. one option is to use http://www.ietf.org/internet-drafts/draft-haley-mip6-ha-switch-00.txt to switch the mobile node to another HA. we dont have any other solution currently. the current bootstrap solution is for the split scenario. the bootstrap design team just started working on the integrated scenario. in the integrated scenario the HA can be assigned by the AAAH during network access authentication. Vijay > > Vijay Devarapalli wrote: > >>once the mobile node knows the home prefix, it can still do >>DHAAD if it wants to. >> >>Vijay >> >>Li Qin wrote: >> >> >>>I guess that multiple home agents related issues, such as dynamic home >>>agent assignment, have not been considered in this draft. >>> >>>if so , can you tell us the reason? >>> >>>Gerardo Giaretta wrote: >>> >>> >>>>Dear WG, >>>> >>>>the bootstrapping DT has submitted a solution draft. The document >>>>defines how a Mobile Node can bootstrap MIPv6 operations from >>>>non-topological information and pre-configured security credentials. The >>>>solution solves the boostrapping problem when the Mobile Node's mobility >>>>service is authorized by a different service provider than basic network >>>>access (i.e. split scenario). >>>> >>>>The draft can be found at >>>>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-split- >>>>00.txt. >>>> >>>>The DT is currently working on optimized solutions for integrated >>>>scenario (i.e. mobility service and basic network access are authorized >>>>by the same entity). >>>> >>>>Please read the document and provide comments. >>>> >>>>Thanks and regards, >>>> >>>>--Gerardo (DT editor) >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia >>>>S.p.A. >>>> >>>>==================================================================== >>>>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 >>>>==================================================================== >>>> >>>>_______________________________________________ >>>>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 Jul 24 11:14:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwiBK-0003e4-Em; Sun, 24 Jul 2005 11:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwiBH-0003dw-TS; Sun, 24 Jul 2005 11:14:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03714; Sun, 24 Jul 2005 11:14:16 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwifw-0005Ls-99; Sun, 24 Jul 2005 11:46:00 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK500F3317T53@szxga01-in.huawei.com>; Sun, 24 Jul 2005 23:19:05 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK5000WE17SSE@szxga01-in.huawei.com>; Sun, 24 Jul 2005 23:19:05 +0800 (CST) Received: from sachin1734 ([10.18.4.197]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IK500FHC19W3O@szxml02-in.huawei.com>; Sun, 24 Jul 2005 23:20:21 +0800 (CST) Date: Sun, 24 Jul 2005 08:14:36 -0700 From: Sachin Dutta Subject: RE: [Mip6] about draft-deng-mip6-vrrp-homeagent-reliability-00.txt In-reply-to: To: "'Duan Xiaodong'" , mip6@ietf.org Message-id: <001201c59062$68170120$c504120a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.3416 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7BIT Cc: hdeng@hitachi.cn, vrrp@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sachind@huawei.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 Hi Hui Deng & Xiaodong, Here are few of my comments on this draft >From MIP6 Protocol Perspective 1 No method for synchronizing deletes requests has been consider ( Binding Option Format can be enhancement for this ) 2 Details can be added for scenario when slave becomes master and L bit FLAG is set 3 What about the case when HA is acting as a Home agent on multiple interfaces and Binding cache has entries corresponding to different interfaces? 4 In Section 4.3.3 should it be Lifetime or Remaining Lifetime ( As Backup can come up after Main ) 5 What about the scenario where Backup HA is also having a CN entry corresponding to MN so when Backup becomes Master both entries will co-exist ??? 6 IPv6 addresses can come in single message so no issue for basic VRRP but binding cache can quite big , What about Link MTU and Why limit the count to 8 bits in VRRP_BC_UPDATE message , so maximum data that can be sent in the packet is 255* Binding option size , approx 10200 bytes , what about the links that can support Link MTU much larger then this and number of Binding Cache entries sent are much larger then 255( Considerations regarding the fragmentation ?? ) 7 what about the security aspects of new VRRP messages defined ??? In basic IPv6 VRRP it is ok as only current IPv6 addresses on link are being shared but sharing the complete binding cache information (Location of each MN ) in clear text messages on a link may not be a good idea. 8 What about the attacks, like some node first sending Priority 0 on behalf of Master Router and then itself becoming the master ( May be base VRRP issue ) But this can affect the complete mobility of the network 9 For load balancing (deng-mip6-ha-loadbalance) security aspects should be considered (Because of basic vulnerability of underline RA message used) Regards Sachin Dutta -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of Duan Xiaodong Sent: Wednesday, July 20, 2005 22:46 To: mip6@ietf.org Cc: hdeng@hitachi.cn; 'Duan Xiaodong' Subject: [Mip6] about draft-deng-mip6-vrrp-homeagent-reliability-00.txt hi folks, we just submit a internet draft here: http://www.ietf.org/internet-drafts/draft-deng-mip6-vrrp-homeagent-relia bility-00.txt It already has been discussed in VRRP working group before http://www1.ietf.org/mail-archive/web/vrrp/current/msg00582.html We hope to discuss this in mip6 WG by the Paris IETF meeting. comments are welcome. -Hui Deng & Xiaodong _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jul 24 12:13:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwj6Q-0005FE-CY; Sun, 24 Jul 2005 12:13:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwj6O-0005Ex-5h for mip6@megatron.ietf.org; Sun, 24 Jul 2005 12:13:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06610 for ; Sun, 24 Jul 2005 12:13:17 -0400 (EDT) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dwjax-0006rz-FX for mip6@ietf.org; Sun, 24 Jul 2005 12:45:02 -0400 Received: (qmail 2796 invoked from network); 24 Jul 2005 16:12:49 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;9c03fa06b51ee007ba27fbd8803bcb5c; Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 24 Jul 2005 16:12:48 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Jul 2005 00:09:18 +0800 MIME-Version: 1.0 Subject: RE: [Mip6] Bootstrapping DT solution draft Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 25 Jul 2005 00:09:16 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38591372@hcbjdc2> Thread-Topic: [Mip6] Bootstrapping DT solution draft Thread-Index: AcWOzOZBpPWwByfGRWqSYsVSMLHdXAB/yxmA From: "DENG, HUI -HCHBJ" To: "James Kempf" , "Li Qin" X-OriginalArrivalTime: 24 Jul 2005 16:09:18.0281 (UTC) FILETIME=[0B70EB90:01C5906A] X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1122221568.779-2792-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.02/0.20 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: quoted-printable Cc: Gerardo Giaretta , 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 The SRV record contains information that the operator can use to establish a preference ordering on the servers for clients. That said, I don't believe it is intended to provide fast, real time information about preferences, say on the order of seconds., but more over longer periods, since dynamic DNS updates require some time to propagate, and it would also not be such a good idea to burden the DNS server with having to handle such frequent updates.=20 =3D=3D> Do you mean that DNS is not suitable for dynamical home agent assignment in this bootstrap solution? Its also possible for the HAs themselves to refuse new IKEv2 connections if they are loaded.=20 =3D=3D> We guess here need more discussion. Since the MN will have a list of HAs, it will just roll over to trying the next one. =20 =3D=3D> Do you think this way is very efficient? The HAs could co-operate somehow (maybe using a protocol like HAHA?) to establish which HA should be taking new connections. This could be used to perform finer grained load balancing.=20 =3D=3D> Do you mean that home agent assignment should be in another document, out of bootstrap? -Hui ----- Original Message ----- From: "Li Qin" To: "James Kempf" Cc: "Li Qin" ; "Gerardo Giaretta" ; Sent: Thursday, July 21, 2005 8:33 AM Subject: Re: [Mip6] Bootstrapping DT solution draft > In my opinion I think its more like a HA discovery than HA assignment. > > If multiple HAs are deployed in home network, is it possible to assign > a HA according to the user's profile, or according to current load of=20 > the HAs in this solution? > > James Kempf wrote: > > The home DNS server can contain multiple HA addresses in the SRV > > record. > > > > jak > > > > > > > > ----- Original Message ----- > > From: "Li Qin" > > To: "Gerardo Giaretta" > > Cc: > > Sent: Wednesday, July 20, 2005 1:11 AM > > Subject: Re: [Mip6] Bootstrapping DT solution draft > > > > > > > >>I guess that multiple home agents related issues, such as dynamic > >>home agent assignment, have not been considered in this draft. > >> > >>if so , can you tell us the reason? > >> > >>Gerardo Giaretta wrote: > >> > >>>Dear WG, > >>> > >>>the bootstrapping DT has submitted a solution draft. The document > >>>defines how a Mobile Node can bootstrap MIPv6 operations from=20 > >>>non-topological information and pre-configured security=20 > >>>credentials. The > >>>solution solves the boostrapping problem when the Mobile Node's mobility > >>>service is authorized by a different service provider than basic network > >>>access (i.e. split scenario). > >>> > >>>The draft can be found at > >>>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-spl >>>it- > >>>00.txt. > >>> > >>>The DT is currently working on optimized solutions for integrated > >>>scenario (i.e. mobility service and basic network access are=20 > >>>authorized by the same entity). > >>> > >>>Please read the document and provide comments. > >>> > >>>Thanks and regards, > >>> > >>>--Gerardo (DT editor) > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>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=20 > >>>persons above and may contain confidential information. If you have > >>>received the message in error, be informed that any use of the=20 > >>>content hereof is prohibited. Please return it immediately to the=20 > >>>sender and delete the message. Should you have any questions,=20 > >>>please send an e_mail to MailAdmin@tilab.com. Thank you=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=3D=3D=3D > >>>=3D > >>> > >>>_______________________________________________ > >>>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 Sun Jul 24 12:14:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwj7F-0005Lm-L3; Sun, 24 Jul 2005 12:14:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwj7D-0005Lf-EN for mip6@megatron.ietf.org; Sun, 24 Jul 2005 12:14:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06630 for ; Sun, 24 Jul 2005 12:14:08 -0400 (EDT) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dwjbt-0006tM-72 for mip6@ietf.org; Sun, 24 Jul 2005 12:45:54 -0400 Received: (qmail 3081 invoked from network); 24 Jul 2005 16:14:00 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;26851fb6263aa53c4e4b7701b7b832a1; Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 24 Jul 2005 16:14:00 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Jul 2005 00:12:35 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] about draft-deng-mip6-vrrp-homeagent-reliability-00.txt content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 25 Jul 2005 00:12:33 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38591373@hcbjdc2> Thread-Topic: [Mip6] about draft-deng-mip6-vrrp-homeagent-reliability-00.txt Thread-Index: AcWOZ7QHpFP6UOl2SGm3lb6IsPS5/wCYfEVQ From: "DENG, HUI -HCHBJ" To: "Thierry Ernst" , X-OriginalArrivalTime: 24 Jul 2005 16:12:35.0046 (UTC) FILETIME=[80B8E060:01C5906A] X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1122221640.763-3078-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.06 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: 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 Thierry, >Are you only consireding the case where all HAs are on the same link, or do you also cover the case where HAs are on disctinct links Are you talking about distinct links but has L2-connectivity? > (the MN would thus have a different HoA). If you talk about different HoA, then I guess that you are not talking about L2-connectivity. then, is there any scenario existed need this mechanism? >In addition to this, do you consider the case where both HAs could be used simultaneously by a given MN ? is there any scenario need such mechanism, but not bringing into more complex to the network? -Hui On Thu, 21 Jul 2005 13:45:48 +0800 "Duan Xiaodong" wrote: > =20 > hi folks, > =20 > we just submit a internet draft here:=20 > http://www.ietf.org/internet-drafts/draft-deng-mip6-vrrp-homeagent-rel > iabili > ty-00.txt > =20 > It already has been discussed in VRRP working group before > =20 > http://www1.ietf.org/mail-archive/web/vrrp/current/msg00582.html > =20 > We hope to discuss this in mip6 WG by the Paris IETF meeting. > =20 > comments are welcome. > =20 > -Hui Deng & Xiaodong > =20 _______________________________________________ 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 Jul 24 15:35:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwmFv-0000xY-JG; Sun, 24 Jul 2005 15:35:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwLJG-000248-6V; Sat, 23 Jul 2005 10:49:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00422; Sat, 23 Jul 2005 10:48:58 -0400 (EDT) Received: from smtp11.singnet.com.sg ([165.21.6.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwLng-0007bF-Hp; Sat, 23 Jul 2005 11:20:29 -0400 Received: from bearty1 (qtas0852.singnet.com.sg [165.21.57.242]) by smtp11.singnet.com.sg (8.13.4/8.13.4) with SMTP id j6NEiCfb007762; Sat, 23 Jul 2005 22:44:16 +0800 Message-ID: <000501c58f95$04589360$f23915a5@bearty1> From: "Boon Sain Yeo" To: Date: Sat, 23 Jul 2005 22:03:35 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.7 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 X-Mailman-Approved-At: Sun, 24 Jul 2005 15:35:21 -0400 Cc: Subject: [Mip6] Call for Participation ---ISWCS 2005, Siena, Italy, 5 - 7 September 2005 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="===============0425918633==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0425918633== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01C58FD2.5F4097E0" This is a multi-part message in MIME format. ------=_NextPart_000_001F_01C58FD2.5F4097E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (My apologies if you receive multiple copies of this message) =20 Dear Colleagues, =20 Please find the call for participation for ISWCS 2005, 5 - 7 September = 2005, Siena, Italy below. =20 On behalf we look forward to receiving you at ISWCS 2005. =20 Many thanks Best regards, Boon =20 General Co-chair =20 *************** CALL FOR PARTICIPATION ********************** =20 ISWCS 2005 2nd International Symposium on Wireless Communication Systems http://www.iswcs.org/iswcs2005 5 - 7 September 2005, Siena, Italy =20 *************** CALL FOR PARTICIPATION ********************** =20 The Technical Program includes 100 full papers and 33 poster papers. Out = of 252 submissions, the Technical Program Committee worked very = diligently and professionally in the selection of the final papers, with = at least three reviews for each submitted contribution. The Program is = structured in three parallel tracks and 5 sessions per track, with a = total of 15 sessions. The three tracks represent key areas in wireless = communications, namely: wireless network layer; radio channel modulation = and coding, and; wireless network applications. The session topics (and = the paper contributions) are very indicative of current research = interests in the wireless field. Please find more information with = regards to the technical program at the following URL: = http://www.iswcs.org/iswcs2005/plan_technical_sessions_ISWCS_2005.pdf =20 Posters represent work in progress and have been given a very visible = role (and an important slot) in the program. In fact, the poster = presentations will follow immediately the Plenary Session on the morning = of Sept 7. We expect active discussion around posters and interaction = with authors. The panel will precede the social dinner on Sept 6 - it = will be addressing the very timely and, in many aspects still = controversial topic, entitled "Towards a wireless and ubiquitous = information society". The panelists comprise of researchers from IBM, = Harris Corporation, Alcatel, KDDI R&D Lab, among others. =20 We have been very lucky to secure two well known and esteemed = researchers in the wireless community - Dr Victor Bahl, Microsoft = Research and Prof Dharma P. Agrawal, University of Cincinnati - as = keynote and plenary speakers respectively. Dr Bahl talk "Bridging the = Information Divide: Challenges & Opportunities" will touch a very = critical problem created by the Internet today and will describe how = wireless technologies will enable ubiquitous connectivity and services = connecting rural villages in remote areas using a programmable mobile = platform. Prof Agrawal talk, entitled "Why use Aggregate Logical Sensor = Units for large Sensor Networks?", will address a critical area of = sensor networks - tight energy constraints. Dr Agrawal will show that = such constraints can be relaxed by aggregating off the shelf sensors = into logical units that support the desired functions. =20 =20 ------=_NextPart_000_001F_01C58FD2.5F4097E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

(My apologies=20 if you receive multiple copies of this message)

 

Dear Colleagues,

 

Please find the call for participation for ISWCS 2005, 5 - 7 = September=20 2005, Siena,=20 Italy = below.

 

On behalf we look forward to receiving you at ISWCS = 2005.

 

Many thanks

Best regards,

Boon

 

General Co-chair

 

*************** CALL FOR PARTICIPATION = **********************

 

ISWCS 2005

2nd International Symposium on Wireless Communication = Systems

http://www.iswcs.org/iswcs2005

5 - 7 September=20 2005, Siena,=20 Italy<= /P>

 

*************** CALL FOR PARTICIPATION = **********************

 

The Technical Program includes 100 full papers and 33 poster = papers. Out=20 of 252 submissions, the Technical Program Committee worked very = diligently and=20 professionally in the selection of the final papers, with at least three = reviews=20 for each submitted contribution. The Program is structured in three = parallel=20 tracks and 5 sessions per track, with a total of 15 sessions. The three = tracks=20 represent key areas in wireless communications, namely: wireless network = layer;=20 radio channel modulation and coding, and; wireless network applications. = The=20 session topics (and the paper contributions) are very indicative of = current=20 research interests in the wireless field. =20 Please find more information with regards to the technical = program at the=20 following URL: http://www.iswcs.org/iswcs2005/plan_technical_sessions_ISWCS_200= 5.pdf

 

Posters represent work in progress and have been given a very = visible=20 role (and an important slot) in the program. In fact, the poster = presentations=20 will follow immediately the Plenary Session on the morning of Sept 7. We = expect=20 active discussion around posters and interaction with authors. The panel = will=20 precede the social dinner on Sept 6 =96 it will be addressing the very = timely and,=20 in many aspects still controversial topic, entitled "Towards a wireless = and=20 ubiquitous information society". The panelists comprise of researchers = from IBM,=20 Harris Corporation, Alcatel, KDDI R&D Lab, among others.

 

We have been very lucky to secure two well known and esteemed = researchers=20 in the wireless community =96 Dr Victor Bahl, Microsoft Research  and Prof Dharma P. Agrawal,=20 University of=20 Cincinnati - as keynote and = plenary=20 speakers respectively.  Dr = Bahl talk=20 =93Bridging the Information Divide: Challenges & Opportunities=94 = will touch a=20 very critical problem created by the Internet today and will describe = how=20 wireless technologies will enable ubiquitous connectivity and services=20 connecting rural villages in remote areas using a programmable mobile=20 platform.  Prof Agrawal = talk,=20 entitled =93Why use Aggregate Logical Sensor Units for large Sensor = Networks?=94,=20 will address a critical area of sensor networks =96 tight energy = constraints. Dr=20 Agrawal will show that such constraints can be relaxed by aggregating = off the=20 shelf sensors into logical units that support the desired = functions.

 

 

------=_NextPart_000_001F_01C58FD2.5F4097E0-- --===============0425918633== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0425918633==-- From mip6-bounces@ietf.org Sun Jul 24 15:35:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwmFw-0000xx-3K; Sun, 24 Jul 2005 15:35:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwSiO-0006mr-Sx for mip6@megatron.ietf.org; Sat, 23 Jul 2005 18:43:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25327 for ; Sat, 23 Jul 2005 18:43:20 -0400 (EDT) Received: from rea.cti.gr ([150.140.1.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DwTCp-0002oq-Ie for mip6@ietf.org; Sat, 23 Jul 2005 19:14:57 -0400 Received: (qmail 35114 invoked from network); 23 Jul 2005 22:45:46 -0000 Received: from hermes.cti.gr (150.140.1.34) by rea.cti.gr with SMTP; 23 Jul 2005 22:45:46 -0000 Received: (qmail 7116 invoked by uid 41021); 23 Jul 2005 22:43:18 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 Jul 2005 22:43:18 -0000 Date: Sun, 24 Jul 2005 01:43:18 +0300 (EEST) From: Ioannis Chatzigiannakis To: Ioannis Chatzigiannakis Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc X-Mailman-Approved-At: Sun, 24 Jul 2005 15:35:21 -0400 Cc: Subject: [Mip6] IPDPS 2006: 1st 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 ================================== ================================== IPDPS 2006 CALL FOR PAPERS APRIL 25-29, 2006 RHODES ISLAND, GREECE SPONSORED BY IEEE COMPUTER SOCIETY ================================== ================================== 20th IEEE International Parallel & Distributed Processing Symposium Tuesday, 25 April -- Saturday, 29 April 2006 Rodos Palace Resort Hotel & Convention Center Rhodes Island, Greece Sponsored by: IEEE Computer Society Technical Committee on Parallel Processing In cooperation with: ACM SIGARCH, IEEE Computer Society Technical Committee on Computer Architecture, and IEEE Computer Society Technical Committee on Distributed Processing Hosted by: Research Academic Computer Technology Institute (CTI, Greece) IPDPS 2006 CALL FOR PARTICIPATION IPDPS serves as a forum for engineers and scientists from around the world to present their latest research findings in the fields of parallel processing and distributed computing. The five-day program will follow the usual format of contributed papers, invited speakers, panels, and commercial participation mid week, framed by workshops held on the first and last days; this year in Greece that will be Tuesday and Saturday. Visit this Web site for regular updates, including the advance program, registration, and accommodations. Send general email inquiries to info@ipdps.org. ================================== ================================== IMPORTANT DATES FOR IPDPS 2006 October 7, 2005 Final Deadline for Manuscripts December 9, 2005 Review Decisions Mailed January 21, 2006 Camera-Ready Papers Due GENERAL CO-CHAIRS Paul Spirakis, CTI & University of Patras, Greece H.J. Siegel, Colorado State University, USA GENERAL VICE-CHAIRS Sotiris Nikoletseas, CTI & University of Patras, Greece Charles Weems, University of Massachusetts Amherst, USA PROGRAM CHAIR Arnold L. Rosenberg, University of Massachusetts Amherst, USA ================================== ================================== IPDPS 2006 CALL FOR PAPERS Authors are invited to submit manuscripts that present original unpublished research in all areas of parallel and distributed processing, including the development of experimental or commercial systems. Work focusing on emerging technologies is especially welcome. Topics of interest include, but are not limited to: --Parallel and distributed algorithms, focusing on issues such as: stability, scalability, and fault tolerance of distributed systems, communication and synchronization protocols, network algorithms, and scheduling and load balancing. --Applications of parallel and distributed computing, including web applications, peer-to-peer computing, grid computing, scientific applications, and mobile computing. --Parallel and distributed architectures, including shared memory, distributed memory (including petascale system designs, and architectures with instruction-level and thread-level parallelism), special-purpose models (including signal and image processors, network processors, other special purpose processors), nontraditional processor technologies, network and interconnect architecture, parallel I/O and storage systems, system design issues for low power, design for high reliability, and performance modeling and evaluation. --Parallel and distributed software, including parallel programming languages and compilers, runtime systems, operating systems, resource management, middleware, libraries, data mining, and programming environments and tools. -------------------- BEST PAPER AWARDS Awards will be given for one best paper in each of the four conference technical tracks: algorithms, applications, architectures, and software. The selected papers also will be considered for possible publication in a special issue of the Journal of Parallel and Distributed Computing. -------------------- WHAT/WHERE TO SUBMIT Submitted manuscripts may not exceed 15 single-spaced pages using 12-point size font on 8.5x11 inch pages, including figures, tables, and references. Authors may submit additional material as an appendix to their submission, but there is no guarantee that this material will influence the review process. Files should be submitted in PDF format. Authors must ensure that electronically submitted files are formatted for 8.5x11 inch paper. --Submission procedures will be available via web access at www.ipdps.org sometime after August 1, 2005. Return here after that date for instructions. --Authors who have e-mail access, but not web access, should send an e-mail message to cfp@ipdps.org for an automatic reply that will contain detailed instructions for submission of manuscripts. They should also contact the Program Chair at: ipdps06@ipdps.org. --Authors who have no electronic access (e-mail or web) should contact the Program Chair at: Department of Computer Science; University of Massachusetts Amherst; Amherst, MA 01003, USA. --------------------- REVIEW OF MANUSCRIPTS All submitted manuscripts will be reviewed. Submissions will be judged on correctness, originality, technical strength, significance, quality of presentation, and interest and relevance to the conference scope. Submitted papers may NOT have appeared in, nor be under consideration for, another conference or workshop, nor for a journal. Manuscripts must be received by October 7, 2005, by 5 p.m. U.S. Eastern Daylight Time. This is a final, hard deadline; to ensure fairness, no extensions will be given. Notification of review decisions will be mailed by December 9, 2005 (typically electronically). Camera-ready papers will be due January 21, 2006. ------------- PROGRAM CHAIR Arnold L. Rosenberg, University of Massachusetts Amherst, USA PROGRAM VICE-CHAIRS --ALGORITHMS Mikhail J. Atallah, Purdue University, USA --APPLICATIONS David A. Bader, Georgia Institute of Technology, USA --ARCHITECTURES Allan Gottlieb, New York University, USA --SOFTWARE Laxmikant Kale, University of Illinois, Urbana-Champaign, USA ----------------- PROGRAM COMMITTEE Gagan AGRAWAL (Ohio State) USA Ishfaq AHMAD (U. Texas/Arlington) USA Shoukat ALI (U. Missouri/Rolla) USA Nancy AMATO (Texas A&M) USA Hagit ATTIYA (The Technion) Israel Eduard AYGUAD. (U. Polit.cnica de Catalunya) Spain Olivier BEAUMONT (U. Bordeaux) France Pete BECKMAN (Argonne National Lab.) USA Michael BENDER (SUNY/Stony Brook) USA Azzedine BOUKERCHE (U. Ottawa) Canada David BROOKS (Harvard) USA Doug BURGER (U. Texas/Austin) USA Rajkumar BUYYA (U. Melbourne) Australia Franck CAPPELLO (INRIA) France Nikos CHRISOCHOIDES (Coll. of William & Mary) USA Guojing CONG (IBM TJ Watson Research Center) USA Toni CORTES (U. Polit.cnica de Catalunya) Spain Karen DEVINE (Sandia National Lab.) USA Guy EVEN (Tel-Aviv U.) Israel Rainer FELDMANN (U. Paderborn) Germany Wu-chun FENG (Los Alamos National Lab.) USA John FEO (Cray Inc.) USA Alfredo FERRO (U. Catania) Italy Pierre FRAIGNIAUD (U. Paris-Sud) France Mark A. FRANKLIN (Washington U.) USA Efstratios GALLOPOULOS (U. Patras) Greece Guang GAO (U. Delaware) USA John GAROFALAKIS (U. Patras & CTI) Greece James R. GOODMAN (U. Auckland) NZ Ananth GRAMA (Purdue) USA Manish GUPTA (IBM) USA Attila GURSOY (Koc U.) Turkey Kei HIRAKI (U. Tokyo) Japan Hiroshi IMAI (U. Tokyo) Japan Mary Jane IRWIN (Penn State) USA Christos KAKLAMANIS (U. Patras) Greece Vijay KARAMCHETI (NYU) USA George KARYPIS (U. Minnesota) USA Bradley C. KUSZMAUL (MIT) USA Konrad LAI (Intel Labs) USA Hyunyoung LEE (U. Denver) USA Kai LI (Princeton) USA Keqin LI (SUNY/New Paltz) USA David LOWENTHAL (U. Georgia) USA Paul LU (U. Alberta) Canada Andrew LUMSDAINE (Indiana U.) USA Xiaosong MA (North Carolina State & ORNL) USA Grzegorz MALEWICZ (U. Alabama) USA Allen D. MALONY (U. Oregon) USA Bernard MANS (Macquarie Univ.) Australia Satoshi MATSUOKA (Tokyo Inst. of Technology) Japan Tim MATTSON (Intel) USA Sally A. MCKEE (Cornell) USA Celso MENDES (U. Illinois) USA Ulrich MEYER (Max Planck Inst.) Germany Russ MILLER (SUNY/Buffalo) USA Michael O'BOYLE (U. Edinburgh) UK Kunle OLUKOTUN (Stanford) USA Marios PAPAEFTHYMIOU (U. Michigan) USA Manish PARASHAR (Rutgers) USA Kunsoo PARK (Seoul National U.) Korea Yale N. PATT (U. Texas/Austin) USA Fabrizio PETRINI (Los Alamos National Lab.) USA Cynthia A. PHILLIPS (Sandia National Lab.) USA Beth PLALE (Indiana U.) USA C. Greg PLAXTON (U. Texas/Austin) USA Sushil K. PRASAD (Georgia State) USA Geppino PUCCI (U. Padova) Italy Patrice QUINTON (U. Rennes) France Sanguthevar RAJASEKARAN (U. Connecticut) USA Partha RANGANATHAN (HP Labs) USA Sanjay RANKA (U. Florida) USA Lawrence RAUCHWERGER (Texas A&M) USA Alexander REINEFELD (Zuse Inst.) Germany Adi ROS.N (The Technion) Israel Larry RUDOLPH (MIT) USA P. SADAYAPPAN (Ohio State) USA Subhash SAINI (NASA Ames) USA Pascal SAINRAT (U. Paul Sabatier) France Christian SCHEIDELER (Johns Hopkins) USA Christian SCHINDELHAUER (U. Paderborn) Germany Karsten SCHWAN (Georgia Inst. Technology) USA Peter SLOOT (U. Amsterdam) The Netherlands Per STENSTROM (U. Chalmers) Sweden Quentin F. STOUT (U. Michigan) USA Michela TAUFER (U. Texas/El Paso) USA Patricia J. TELLER (U. Texas/El Paso) USA Denis TRYSTRAM (U. Grenoble) France Dean TULLSEN (U. California/San Diego) USA Mateo VALERO (U. Polit.cnica de Catalunya) Spain Jeffrey VETTER (Oak Ridge National Lab.) USA Uzi VISHKIN (U. Maryland) USA Charles WEEMS (U. Massachusetts) USA Uri WEISER (Intel) Israel Li XIAO (Michigan State) USA Zhiwei XU (Chinese Academy of Sciences) China Yuanyuan YANG (SUNY/Stony Brook) USA Albert Y. ZOMAYA (U. Sydney) Australia ================================== ================================== IPDPS 2006 LOCATION The 20th IEEE International Parallel & Distributed Processing Symposium, hosted by the Research Academic Computer Technology Institute (CTI, Greece), will be held on the Isle of Rhodes in Greece at the Rodos Palace Resort Hotel & Convention Center. Considered a premier European conference site, the hotel tower provides spectacular views of gardens and the blue Aegean Sea alongside its modern conference facilities. Situated on the Mediterranean Sea at the crossroads of two continents, Rodos combines the worldliness of Europe with the mystery of the Orient in an atmosphere that allows visitors to discover ancient Greek cities, a medieval town with its own castle, charming small villages, and sun drenched beaches. Rodos is also one of the most developed islands in the Mediterranean, providing every holiday amenity, including a yachting harbor, entertaining night life, and casino and sports facilities. The Rodos airport has direct flights to major international cities and other Aegean islands as well as many daily flights from Athens International Airport. With 300 sunny days per year, the island holds the Greek record for sunshine, and its remarkably rich legacy in archaeological treasures and developed tourism infrastructure make Rodos a very special place to gather for IPDPS 2006. Plan to arrive early and stay late! WORKSHOPS COMMITTEE Chair: Alan Sussman, University of Maryland, USA Vice-Chair: Yuanyuan Yang, State University of New York, Stony Brook, USA COMMERCIAL PRESENTATIONS & EXHIBITS CO-CHAIRS John K. Antonio, University of Oklahoma, USA Theodoros Komninos, Computer Technology Institute, Greece PROCEEDINGS CHAIR Shoukat Ali, University of Missouri-Rolla, USA FINANCE CHAIR Bill Pitts, Toshiba America Information Systems, Inc., USA LOCAL ARRANGEMENTS CO-CHAIRS Susamma Barua, California State University, Fullerton, USA Rozina Efstathiadou, Computer Technology Institute, Greece Lena Gourdoupi, Computer Technology Institute, Greece PRODUCTION CHAIR Sally Jelinek, Electronic Design Associates, Inc., USA PUBLICITY COORDINATORS --AMERICAS Bo Hong, Drexel University, USA --ASIA/PACIFIC RIM Cho-Li Wang, University of Hong Kong, China --EUROPE/AFRICA Ioannis Chatzigiannakis, Computer Technology Institute, Greece STEERING COMMITTEE David A. Bader, Georgia Institute of Technology, USA Luc Boug., ENS Cachan & IRISA, Rennes, France K. Mani Chandy, California Institute of Technology, USA Jean-Luc Gaudiot, University of California, Irvine, USA Ali R. Hurson, Pennsylvania State University, USA Joseph JaJa, University of Maryland, USA F. Tom Leighton, MIT, USA Sotiris E. Nikoletseas, CTI & University of Patras, Greece Co-Chair: Viktor K. Prasanna, University of Southern California, USA Jos. D.P. Rolim, University of Geneva, Switzerland Arnold L. Rosenberg, University of Massachusetts Amherst, USA Sartaj Sahni, University of Florida, USA Behrooz Shirazi, University of Texas at Arlington, USA H. J. Siegel, Colorado State University, USA Paul Spirakis, CTI & University of Patras, Greece Hal Sudborough, University of Texas at Dallas, USA Charles Weems, University of Massachusetts Amherst, USA Co-Chair: George B. Westrom, Future Scientists & Engineers of America, USA IPDPS 2006 WORKSHOPS Workshops at IPDPS are held on the first and last day of the symposium. Next year in Greece that will be Tuesday, April 25th and Saturday, April 29th. Workshops are an opportunity to explore special topics, and running a workshop in association with IPDPS offers many advantages. For more information on organizing a workshop, contact Workshops Chair Alan Sussman (als@cs.umd.edu). Workshops already planned for 2006 are listed on the IPDPS Web at www.ipdps.org. IPDPS 2006 COMMERCIAL PARTICIPATION There are three exciting forums available for commercial participants to showcase their technologies at IPDPS 2006: (1) Give a presentation in a special Commercial Track, which includes publication of a technical article in the proceedings of the symposium. (2) Offer an evening Commercial Tutorial to provide orientation and training to symposium participants interested in using and/or learning more about your technology. (3) Participate in three days of Commercial Exhibits by having a booth where your company can promote awareness about its recent technological advances in a "walk-up-and-talk" setting with a diverse audience. Participants in one or more of the above events will be designated as Commercial Sponsors and will have their company logo linked on the IPDPS home page. For more detailed information and to reserve your spot, contact one of the Commercial Co-chairs - John K. Antonio (antonio@ou.edu) or Theodoros Komninos (komninos@cti.gr) - as early as possible but no later than January 1, 2006. IPDPS BIRDS-OF-A-FEATHER These are informal sessions in which a group of researchers can gather for discussions on a topic of mutual interest. BOF space will be available early in the evening and a typical BOF session will last one to two hours. We'll provide the space, you provide the topic and gather the people. Please reserve space in advance by contacting the General Vice Chair Charles Weems (weems@cs.umass.edu). Reservations should be made by January 16, 2006. BOF sessions will be advertised in advance of the meeting on the IPDPS web site and can be linked to a BOF announcement web page. The goal of the BOF sessions is to encourage new collaborations and research directions, to inspire educational initiatives, and to nurture the development of new workshop proposals and other initiatives and interactions within our community. ================================== ================================== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jul 24 17:40:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwoCr-0005rU-R9; Sun, 24 Jul 2005 17:40:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwoCq-0005rO-OV for mip6@megatron.ietf.org; Sun, 24 Jul 2005 17:40:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26947; Sun, 24 Jul 2005 17:40:18 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwohX-00076g-La; Sun, 24 Jul 2005 18:12:06 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6OLeC4m018414; Mon, 25 Jul 2005 00:40:16 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jul 2005 00:40:14 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 24 Jul 2005 16:40:10 -0500 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 24 Jul 2005 16:36:38 -0500 Message-ID: <456943D540CFC14A8D7138E64843F853014F87CB@daebe101.NOE.Nokia.com> Thread-Topic: Agenda of Mobility for IPv6 (mip6) WG meeting at IETF63 Thread-Index: AcWQl8Yt9iC1gmCJQHOKhZZP7qDzww== To: X-OriginalArrivalTime: 24 Jul 2005 21:40:10.0219 (UTC) FILETIME=[441E43B0:01C59098] X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org Subject: [Mip6] Agenda of Mobility for IPv6 (mip6) WG meeting at IETF63 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 Agenda of Mobility for IPv6 (mip6) WG meeting at IETF63 Tuesday August 2nd, 2006 1630-1800 Afternoon Session II and 1815-1945 Afternoon Session III (180 Mins) Chair(s): Basavaraj Patil Gopal Dommety ------------------------------------------ 1. Agenda, Bluesheets, Note-takers and Jabber scribes 5 Mins 2. WG documents status update Chairs 15 Mins I-Ds and TAHI test suite update =20 3. Mobile IPv6 bootstrapping in split and integrated scenarios=20 draft-ietf-mip6-bootstrapping-split-00 Gerardo Giaretta 20 Mins 4. Home Agent Initiated Bootstrap for Mobile IPv6 draft-li-mip6-ha-init-bootstrap-00 Q. Li 10 Mins =20 5. Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture draft-ietf-mip6-ikev2-ipsec-02 Vijay Devarapalli 15 Mins 6. Mobility management for Dual stack mobile nodes; Problem Statement draft-ietf-mip6-dsmip-problem-00 Hesham Soliman 15 Mins 7. MIP6 operation when attached to v4 access networks =20 Slides to be made available before meeting Design team 20 Mins 8. IP Address Location Privacy and IP Mobility draft-koodli-mip6-location-privacy-00 Rajeev Koodli 10 Mins 9. Review summary of I-D draft-irtf-mobopts-ro-enhancements-01 Christian Vogt 10 Mins 10. Care-of Address Test for MIPv6 using a State Cookie draft-dupont-mipv6-rrcookie-01 Francis Dupont 5 Mins 11. Securing Home Agent List in MIP6 draft-dutta-mip6-ra-00 Sachin Dutta 10 Mins 12. Reliability and Load Balance among multiple Home Agents draft-deng-mip6-vrrp-homeagent-reliability-00.txt Hui Deng 10 Mins 13. Next steps Chairs 10 Mins _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jul 24 22:52:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwt4f-0003M6-9p; Sun, 24 Jul 2005 22:52:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwt4d-0003M1-MA for mip6@megatron.ietf.org; Sun, 24 Jul 2005 22:52:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15809 for ; Sun, 24 Jul 2005 22:52:09 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwtZO-0006sf-Dx for mip6@ietf.org; Sun, 24 Jul 2005 23:23:59 -0400 Received: from iseran.local (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 251924CCBB for ; Mon, 25 Jul 2005 11:50:34 +0900 (JST) Date: Mon, 25 Jul 2005 11:52:02 +0900 From: Thierry Ernst To: mip6@ietf.org Subject: Re: [Mip6] about draft-deng-mip6-vrrp-homeagent-reliability-00.txt Message-Id: <20050725115202.4c573975.ernst@sfc.wide.ad.jp> In-Reply-To: <834B54D356AA8F46B9B233DD88BEAA38591373@hcbjdc2> References: <834B54D356AA8F46B9B233DD88BEAA38591373@hcbjdc2> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Dear Hui, I'm afraid you didn't answer the question ... > >Are you only consireding the case where all HAs are on the same link, > or do you also cover the case where HAs are on disctinct links > Are you talking about distinct links but has L2-connectivity? > > > (the MN would thus have a different HoA). > If you talk about different HoA, then I guess that you are not talking > about L2-connectivity. Yes, I surely speak about L3 links, with different prefixes. > then, is there any scenario existed need this mechanism? > > >In addition to this, do you consider the case where both HAs could be > used simultaneously by a given MN ? > is there any scenario need such mechanism, but not bringing into more > complex to the network? Yes, they are. In same cases the HA must be synchronized, in some other they don't have to. My concern is for the cases where do have to do so. Thierry. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jul 24 23:51:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtzk-0002ng-Sl; Sun, 24 Jul 2005 23:51:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwtzc-0002nQ-Tc for mip6@megatron.ietf.org; Sun, 24 Jul 2005 23:51:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19607 for ; Sun, 24 Jul 2005 23:51:01 -0400 (EDT) Received: from usaga01-in.huawei.com ([63.250.163.245] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwuUH-0000DC-8N for mip6@ietf.org; Mon, 25 Jul 2005 00:22:53 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK50026AZURC4@usaga01-in.huawei.com> for mip6@ietf.org; Sun, 24 Jul 2005 20:47:15 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK500IZ2ZUPAB@usaga01-in.huawei.com> for mip6@ietf.org; Sun, 24 Jul 2005 20:47:15 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [172.19.1.206]) by szxmc02-in.huawei.com (mshttpd); Mon, 25 Jul 2005 11:51:30 +0800 Date: Mon, 25 Jul 2005 11:51:30 +0800 From: SurajShetty 70535 Subject: Re: [Mip6] about draft-deng-mip6-vrrp-homeagent-reliability-00.txt To: Duan Xiaodong Message-id: <4cf7d482af.482af4cf7d@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_vaS/dSqgrlv5K+EHoNzgzw)" Content-language: en X-Accept-Language: en Priority: normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: mip6@ietf.org, hdeng@hitachi.cn, 'Duan Xiaodong' 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 This is a multi-part message in MIME format. --Boundary_(ID_vaS/dSqgrlv5K+EHoNzgzw) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-Transfer-Encoding: 7BIT HI Hui Deng & Xiaodong, One more thing you missed out is that it is not enough to just synchronize information that are available in the Binding Cache. This information is initial, lots of dynamic information like Mobile Prefix Advertisements Status (number of retries, etc), Binding Refresh Request status, Binding Cache status in Intermediate state (say it is still not verified and the backup takes over) and the lifetimes that are constantly decreasing in real time, need to be synchronized. This could be a lot of information in real-time. Neccessary assumptions need to be clearly put for these OR proper mechanisms defined to Sync data real-time. Also Home Agent list updation needs to be properly considered, during the time the backup takes over from the main. Time may be needed for the reconstruction of the Home Agent list, unless and otherwise the time is always assumed to be too small and can be safely ignored. regards, Suraj. ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! **************************************************************************************** --Boundary_(ID_vaS/dSqgrlv5K+EHoNzgzw) Content-type: multipart/alternative; boundary="Boundary_(ID_vg1UAULD9Ef3ljEh/ZH7tQ)" --Boundary_(ID_vg1UAULD9Ef3ljEh/ZH7tQ) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT hi folks, we just submit a internet draft here: http://www.ietf.org/internet-drafts/draft-deng-mip6-vrrp-homeagent-reliabili ty-00.txt It already has been discussed in VRRP working group before http://www1.ietf.org/mail-archive/web/vrrp/current/msg00582.html We hope to discuss this in mip6 WG by the Paris IETF meeting. comments are welcome. -Hui Deng & Xiaodong --Boundary_(ID_vg1UAULD9Ef3ljEh/ZH7tQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

 

hi folks,

 

we just submit a internet draft here:

http://www.ietf.org/internet-drafts/draft-deng-mip6-vrrp-homeagent-reliability-00.txt

 

It already has been discussed in VRRP working group before

 

http://www1.ietf.org/mail-archive/web/vrrp/current/msg00582.html

 

We hope to discuss this in mip6 WG by the Paris IETF meeting.

 

comments are welcome.

 

-Hui Deng & Xiaodong

 

 

--Boundary_(ID_vg1UAULD9Ef3ljEh/ZH7tQ)-- --Boundary_(ID_vaS/dSqgrlv5K+EHoNzgzw) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline Content-Transfer-Encoding: 7BIT _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --Boundary_(ID_vaS/dSqgrlv5K+EHoNzgzw) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --Boundary_(ID_vaS/dSqgrlv5K+EHoNzgzw)-- From mip6-bounces@ietf.org Mon Jul 25 02:35:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwwZ0-0007kJ-A3; Mon, 25 Jul 2005 02:35:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwwYn-0007i3-Ek for mip6@megatron.ietf.org; Mon, 25 Jul 2005 02:35:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20612 for ; Mon, 25 Jul 2005 02:35:32 -0400 (EDT) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwx3Y-0004em-Gu for mip6@ietf.org; Mon, 25 Jul 2005 03:07:23 -0400 Received: from FLY ([129.254.12.66]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Mon, 25 Jul 2005 15:36:39 +0900 From: "Junghoon Jee" To: "'DENG, HUI -HCHBJ'" , "'James Kempf'" , "'Li Qin'" Subject: RE: [Mip6] Bootstrapping DT solution draft Date: Mon, 25 Jul 2005 15:35:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcWOzOZBpPWwByfGRWqSYsVSMLHdXAB/yxmAAAVyfiA= In-Reply-To: <834B54D356AA8F46B9B233DD88BEAA38591372@hcbjdc2> Message-ID: X-OriginalArrivalTime: 25 Jul 2005 06:36:39.0816 (UTC) FILETIME=[369CF880:01C590E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 7bit Cc: 'Gerardo Giaretta' , 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 Hi Hui, > The SRV record contains information that the operator can use > to establish a preference ordering on the servers for > clients. That said, I don't believe it is intended to provide > fast, real time information about preferences, say on the > order of seconds., but more over longer periods, since > dynamic DNS updates require some time to propagate, and it > would also not be such a good idea to burden the DNS server > with having to handle such frequent updates. > ==> Do you mean that DNS is not suitable for dynamical home > agent assignment in this bootstrap solution? Nope, definitely not. James is talking about the rationale why DNS update does not need to happen so frequently. > Its also possible for the HAs themselves to refuse new IKEv2 > connections if they are loaded. > ==> We guess here need more discussion. It would be helpful if you can share your thoughts more specifically. Then, let's start discussion. > Since the MN will have a list of HAs, it will just roll over > to trying the next one. > ==> Do you think this way is very efficient? Do you see any problem from the James' thought ? > The HAs could co-operate somehow (maybe using a protocol like > HAHA?) to establish which HA should be taking new > connections. This could be used to perform finer grained load > balancing. > ==> Do you mean that home agent assignment should be in > another document, out of bootstrap? I can not quite understand what you said. More clarification would be helpful. Regards, Junghoon > -Hui > > ----- Original Message ----- > From: "Li Qin" > To: "James Kempf" > Cc: "Li Qin" ; "Gerardo Giaretta" > ; > Sent: Thursday, July 21, 2005 8:33 AM > Subject: Re: [Mip6] Bootstrapping DT solution draft > > > > In my opinion I think its more like a HA discovery than HA > assignment. > > > > If multiple HAs are deployed in home network, is it > possible to assign > > a HA according to the user's profile, or according to > current load of > > the HAs in this solution? > > > > James Kempf wrote: > > > The home DNS server can contain multiple HA addresses in the SRV > > > record. > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > From: "Li Qin" > > > To: "Gerardo Giaretta" > > > Cc: > > > Sent: Wednesday, July 20, 2005 1:11 AM > > > Subject: Re: [Mip6] Bootstrapping DT solution draft > > > > > > > > > > > >>I guess that multiple home agents related issues, such as dynamic > > >>home agent assignment, have not been considered in this draft. > > >> > > >>if so , can you tell us the reason? > > >> > > >>Gerardo Giaretta wrote: > > >> > > >>>Dear WG, > > >>> > > >>>the bootstrapping DT has submitted a solution draft. The > document > > >>>defines how a Mobile Node can bootstrap MIPv6 operations from > > >>>non-topological information and pre-configured security > > >>>credentials. > The > > >>>solution solves the boostrapping problem when the Mobile Node's > mobility > > >>>service is authorized by a different service provider than basic > network > > >>>access (i.e. split scenario). > > >>> > > >>>The draft can be found at > > > >>>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstr > apping-spl > >>>it- > > >>>00.txt. > > >>> > > >>>The DT is currently working on optimized solutions for > integrated > > >>>scenario (i.e. mobility service and basic network access are > > >>>authorized by the same entity). > > >>> > > >>>Please read the document and provide comments. > > >>> > > >>>Thanks and regards, > > >>> > > >>>--Gerardo (DT editor) > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>>Gruppo Telecom Italia - Direzione e coordinamento di > Telecom Italia > > > > > > S.p.A. > > > > > > >>>=================================================================== > > >>>= > > >>>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 > > > >>>=================================================================== > > >>>= > > >>> > > >>>_______________________________________________ > > >>>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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 25 03:38:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwxXc-0007dM-Rg; Mon, 25 Jul 2005 03:38:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwxXa-0007d7-IM for mip6@megatron.ietf.org; Mon, 25 Jul 2005 03:38:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24071 for ; Mon, 25 Jul 2005 03:38:21 -0400 (EDT) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dwy2I-0006xN-D3 for mip6@ietf.org; Mon, 25 Jul 2005 04:10:12 -0400 Received: (qmail 20990 invoked from network); 25 Jul 2005 07:37:53 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;2aceee9e23e593b43376cdfc3c87b1ea; Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 25 Jul 2005 07:37:33 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Jul 2005 13:27:12 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 25 Jul 2005 13:19:33 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38BC6895@hcbjdc2> Thread-Topic: +AFs-Mip6+AF0- Bootstrapping DT solution draft Thread-Index: AcWO7uqpb1WRSPo0QISfg5a+5sgWcgB6L72Q From: "+ACI-DENG, HUI -HCHBJ+ACI-" To: "Vijay Devarapalli" , "Li Qin" X-OriginalArrivalTime: 25 Jul 2005 05:27:12.0296 (UTC) FILETIME=[8293E280:01C590D9] X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1122277053.795-20908-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.03/0.27 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Spam-Score: 0.3 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , mip6@ietf.org Subject: [Mip6] RE: +AFs-Mip6+AF0- Bootstrapping DT solution draft 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 actually you can, by adjusting the HA preference value. the list of HAs in a DHAAD reply is ordered based on the HA's preference value. but I understand what you are getting at. one option is to use http://www.ietf.org/internet-drafts/draft-haley-mip6-ha-switch-00.txt to switch the mobile node to another HA. +AD0APQA+- This should be a good idea we dont have any other solution currently. the current bootstrap solution is for the split scenario. the bootstrap design team just started working on the integrated scenario. in the integrated scenario the HA can be assigned by the AAAH during network access authentication. +AD0APQA+- I understand that MN need to discover a HA before initiate bootstrap with the HA in split scenario, but this HA is not necessarily to be the HA serving MN in the future. +AD4- +AD4- Vijay Devarapalli wrote: +AD4- +AD4APg-once the mobile node knows the home prefix, it can still do DHAAD if +AD4APg-it wants to. +AD4APg- +AD4APg-Vijay +AD4APg- +AD4APg-Li Qin wrote: +AD4APg- +AD4APg- +AD4APgA+-I guess that multiple home agents related issues, such as dynamic +AD4APgA+-home agent assignment, have not been considered in this draft. +AD4APgA+- +AD4APgA+-if so , can you tell us the reason? +AD4APgA+- +AD4APgA+-Gerardo Giaretta wrote: +AD4APgA+- +AD4APgA+- +AD4APgA+AD4-Dear WG, +AD4APgA+AD4- +AD4APgA+AD4-the bootstrapping DT has submitted a solution draft. The document +AD4APgA+AD4-defines how a Mobile Node can bootstrap MIPv6 operations from +AD4APgA+AD4-non-topological information and pre-configured security credentials. +AD4APgA+AD4-The solution solves the boostrapping problem when the Mobile Node's +AD4APgA+AD4-mobility service is authorized by a different service provider than +AD4APgA+AD4-basic network access (i.e. split scenario). +AD4APgA+AD4- +AD4APgA+AD4-The draft can be found at +AD4APgA+AD4-http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-sp +AD4APgA+AD4-lit- +AD4APgA+AD4-00.txt. +AD4APgA+AD4- +AD4APgA+AD4-The DT is currently working on optimized solutions for integrated +AD4APgA+AD4-scenario (i.e. mobility service and basic network access are +AD4APgA+AD4-authorized by the same entity). +AD4APgA+AD4- +AD4APgA+AD4-Please read the document and provide comments. +AD4APgA+AD4- +AD4APgA+AD4-Thanks and regards, +AD4APgA+AD4- +AD4APgA+AD4---Gerardo (DT editor) +AD4APgA+AD4- +AD4APgA+AD4- +AD4APgA+AD4- +AD4APgA+AD4- +AD4APgA+AD4- +AD4APgA+AD4- +AD4APgA+AD4- +AD4APgA+AD4- +AD4APgA+AD4-Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia +AD4APgA+AD4-S.p.A. +AD4APgA+AD4- +AD4APgA+AD4APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9- +AD4APgA+AD4-CONFIDENTIALITY NOTICE +AD4APgA+AD4-This message and its attachments are addressed solely to the persons +AD4APgA+AD4-above and may contain confidential information. If you have received +AD4APgA+AD4-the message in error, be informed that any use of the content hereof +AD4APgA+AD4-is prohibited. Please return it immediately to the sender and delete +AD4APgA+AD4-the message. Should you have any questions, please send an e+AF8-mail to +AD4APgA+AD4-MailAdmin+AEA-tilab.com. Thank you +AD4APgA+AD4APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9- +AD4APgA+AD4- +AD4APgA+AD4AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBf-+AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBf- +AD4APgA+AD4-Mip6 mailing list +AD4APgA+AD4-Mip6+AEA-ietf.org +AD4APgA+AD4-https://www1.ietf.org/mailman/listinfo/mip6 +AD4APgA+- +AD4APgA+- +AD4APgA+- +AD4APgA+AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- +AD4APgA+-Mip6 mailing list +AD4APgA+-Mip6+AEA-ietf.org +AD4APgA+-https://www1.ietf.org/mailman/listinfo/mip6 +AD4APg- +AD4APg- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- Mip6 mailing list Mip6+AEA-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 Jul 25 06:17:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwzyY-0000YP-Tm; Mon, 25 Jul 2005 06:14:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwzyX-0000YF-9E for mip6@megatron.ietf.org; Mon, 25 Jul 2005 06:14:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03508 for ; Mon, 25 Jul 2005 06:14:19 -0400 (EDT) Received: from usaga01-in.huawei.com ([63.250.163.245] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx0TL-0003Wn-8H for mip6@ietf.org; Mon, 25 Jul 2005 06:46:13 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK600AU0HM2CA@usaga01-in.huawei.com> for mip6@ietf.org; Mon, 25 Jul 2005 03:10:50 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK6002XMHM0QZ@usaga01-in.huawei.com> for mip6@ietf.org; Mon, 25 Jul 2005 03:10:50 -0700 (PDT) Received: from [172.24.1.6] (Forwarded-For: [172.19.1.206]) by szxmc02-in.huawei.com (mshttpd); Mon, 25 Jul 2005 18:15:05 +0800 Date: Mon, 25 Jul 2005 18:15:05 +0800 From: SurajShetty 70535 Subject: Re: [Mip6] about draft-deng-mip6-vrrp-homeagent-reliability-00.txt To: Duan Xiaodong Message-id: <8578e82a74.82a748578e@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: multipart/mixed; boundary="Boundary_(ID_xHp6L1ObGN61Zt+aay6kxw)" Content-language: en X-Accept-Language: en Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: mip6@ietf.org, 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 This is a multi-part message in MIME format. --Boundary_(ID_xHp6L1ObGN61Zt+aay6kxw) Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-Transfer-Encoding: 7BIT HI Hui Deng & Xiaodong, One more thing you missed out is that it is not enough to just synchronize information that are available in the Binding Cache. This information is initial, lots of dynamic information like Mobile Prefix Advertisements Status (number of retries, etc), Binding Refresh Request status, Binding Cache status in Intermediate state (say it is still not verified and the backup takes over) and the lifetimes that are constantly decreasing in real time, need to be synchronized. This could be a lot of information in real-time. Neccessary assumptions need to be clearly put for these OR proper mechanisms defined to Sync data real-time. Also Home Agent list updation needs to be properly considered, during the time the backup takes over from the main. Time may be needed for the reconstruction of the Home Agent list, unless and otherwise the time is always assumed to be too small and can be safely ignored. regards, Suraj. ****************************************************************************************** This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! **************************************************************************************** --Boundary_(ID_xHp6L1ObGN61Zt+aay6kxw) MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline Content-Transfer-Encoding: 7BIT _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --Boundary_(ID_xHp6L1ObGN61Zt+aay6kxw) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --Boundary_(ID_xHp6L1ObGN61Zt+aay6kxw)-- From mip6-bounces@ietf.org Mon Jul 25 10:18:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx3hy-0004Aj-Ex; Mon, 25 Jul 2005 10:13:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx3hw-00043N-7S for mip6@megatron.ietf.org; Mon, 25 Jul 2005 10:13:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22955 for ; Mon, 25 Jul 2005 10:13:26 -0400 (EDT) Message-Id: <200507251413.KAA22955@ietf.org> Received: from csnet1.cs.tsinghua.edu.cn ([166.111.68.226]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dx4Cm-0003sc-H2 for mip6@ietf.org; Mon, 25 Jul 2005 10:45:22 -0400 Received: (qmail 14709 invoked by uid 0); 25 Jul 2005 14:34:56 -0000 Received: from th024174.ip.tsinghua.edu.cn (HELO cy) (yong@59.66.24.174) by csnet1.cs.tsinghua.edu.cn with SMTP; 25 Jul 2005 14:34:56 -0000 Date: Mon, 25 Jul 2005 22:12:47 +0800 From: "Yong" To: "Vijay Devarapalli" , "Li Qin" Subject: Re: Re: [Mip6] Bootstrapping DT solution draft X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , "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 Hi, Vijay Devarapalli, >the current bootstrap solution is for the split scenario. the >bootstrap design team just started working on the integrated >scenario. in the integrated scenario the HA can be assigned >by the AAAH during network access authentication. > >Vijay > I cannot agree that AAA in MSP are not responsible for assignment home agent in bootstrap split scenario from the mip6 deployment point of view. Best regards, 22:08:32 2005-07-25 ******************************************************** * Yong Cui * * Ph.D, Department of Computer Science & Technology * * Tsinghua University, Beijing, P.R.China(100084) * * Tel: (8610)-62795818-6859 * * Email: yong@csnet1.cs.tsinghua.edu.cn * ******************************************************** _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 25 11:24:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx4p3-0003rX-Od; Mon, 25 Jul 2005 11:24:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx4p2-0003rR-N0 for mip6@megatron.ietf.org; Mon, 25 Jul 2005 11:24:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00014 for ; Mon, 25 Jul 2005 11:24:50 -0400 (EDT) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dx5Jo-0006Xo-60 for mip6@ietf.org; Mon, 25 Jul 2005 11:56:47 -0400 Received: (qmail 30861 invoked from network); 25 Jul 2005 15:24:26 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;b9e70b6614820054d749fe90367d2ae4; Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 25 Jul 2005 15:24:26 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Mon, 25 Jul 2005 23:22:59 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 25 Jul 2005 23:22:57 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38BC6896@hcbjdc2> Thread-Topic: +AFs-Mip6+AF0- about draft-deng-mip6-vrrp-homeagent-reliability-00.txt Thread-Index: AcWQxFm6uZUFbXj5Ra6T4K4JcwR30AAZpw9Q From: "+ACI-DENG, HUI -HCHBJ+ACI-" To: "Thierry Ernst" , X-OriginalArrivalTime: 25 Jul 2005 15:22:59.0656 (UTC) FILETIME=[BDAA2480:01C5912C] X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1122305066.64-30855-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.09 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: Subject: [Mip6] RE: +AFs-Mip6+AF0- about draft-deng-mip6-vrrp-homeagent-reliability-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 Dear Thierry +AD4- Yes, I surely speak about L3 links, with different prefixes. Honestly speaking, we have not yet consider such scenario, What I can say right now is NO. Can you elaborate more? +AD4- +AD4APg-In addition to this, do you consider the case where both HAs could be +AD4APg- +AD4-used simultaneously by a given MN ? +AD4- +AD4-is there any scenario need such mechanism, but not bringing into more +AD4- +AD4-complex to the network? +AD4-Yes, they are. In same cases the HA must be synchronized, +AD4-in some other they don't have to. +AD4-My concern is for the cases where do have to do so. In the case of IPsec supporting, we feel to realize this is pretty hard. Here list functionality of HA as the following 1) HA response MN related MIP6 signaling 2) HA deliver packet from CN to MN 3) HA deliver packet from MN to CN. then, I would like to know which cases is your concern -Hui _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 25 13:09:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx6SJ-0002jM-6W; Mon, 25 Jul 2005 13:09:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx6SF-0002eE-QC for mip6@megatron.ietf.org; Mon, 25 Jul 2005 13:09:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07914 for ; Mon, 25 Jul 2005 13:09:24 -0400 (EDT) Received: from mx2.buaa.edu.cn ([219.239.227.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx6wq-0001Xy-PP for mip6@ietf.org; Mon, 25 Jul 2005 13:41:22 -0400 Received: from mx1.buaa.edu.cn (mx1.buaa.edu.cn [192.168.128.5]) by mx2.buaa.edu.cn (Postfix) with ESMTP id 5D61B37F5A; Tue, 26 Jul 2005 01:08:31 +0800 (CST) Received: from [210.76.115.36] by 10.0.0.130 with StormMail ESMTP id 53198.6739287058; Tue, 26 Jul 2005 01:39:43 +0800 (CST) Message-ID: <42E51CDE.5030501@cse.buaa.edu.cn> Date: Tue, 26 Jul 2005 01:09:50 +0800 From: Li Qin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sachind@huawei.com Subject: Re: [Mip6] about draft-deng-mip6-vrrp-homeagent-reliability-00.txt References: <001201c59062$68170120$c504120a@china.huawei.com> In-Reply-To: <001201c59062$68170120$c504120a@china.huawei.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, hdeng@hitachi.cn, 'Duan Xiaodong' , vrrp@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 Sachin Dutta wrote: > Hi Hui Deng & Xiaodong, > > Here are few of my comments on this draft > >>From MIP6 Protocol Perspective > > 1 No method for synchronizing deletes requests has been consider ( > Binding Option Format can be enhancement for this ) We will define this in next version, based on Binding Option extension or 0 Lifetime. > > 2 Details can be added for scenario when slave becomes master and Yes, thank you. > L bit FLAG is set Which L bit? > > 3 What about the case when HA is acting as a Home agent on multiple > interfaces and Binding cache has entries corresponding to different > interfaces? As defined in basic MIPv6, a separate Binding Cache SHOULD be maintained for each unicast addresses. VRRP HA rely in the same link with each other, which means only those BC associated with the address of same home link prefix is considered in our solution. > > 4 In Section 4.3.3 should it be Lifetime or Remaining Lifetime ( As > Backup can come up after Main ) It means remaining lifetime, but we store it in Lifetime field. > > 5 What about the scenario where Backup HA is also having a CN entry > corresponding to MN so when Backup becomes Master both entries will > co-exist ??? Yes, is there any problem? > > 6 IPv6 addresses can come in single message so no issue for basic VRRP > but binding cache can quite big , What about Link MTU and > Why limit the count to 8 bits in VRRP_BC_UPDATE message , so maximum > data that can be sent in the packet is 255* Binding option size , approx > 10200 bytes , what about the links that can support Link MTU much larger > then this and number of Binding Cache entries sent are much larger then > 255( Considerations regarding the fragmentation ?? ) We designed 8 bits in count field because we believed it is not necessary for HA to send VRRP_BC_UPDATE once with more than 255 entries. For example, implementation could limit to no more than one VRRP_BC_UPDATE per second for HA, then the UPDATE message need only include those Binding renewed by MN with a second. Also, a VRRP_BC_UPDATE message MUST not exceed MTU limit even it's less than 255 Bindings. Bindings will be divided into separate VRRP_BC_UPDATE messages to satisfy MTU. This will be added in the next version. > > 7 what about the security aspects of new VRRP messages defined ??? > In basic IPv6 VRRP it is ok as only current IPv6 addresses on link are > being shared but sharing the complete binding cache information > (Location of each MN ) in clear text messages on a link may not be a > good idea. > > 8 What about the attacks, like some node first sending Priority 0 on > behalf of Master Router and then itself becoming the master ( May be > base VRRP issue ) > But this can affect the complete mobility of the network > > 9 For load balancing (deng-mip6-ha-loadbalance) security aspects should > be considered (Because of basic vulnerability of underline RA message > used) I think 7,8,9, could all be seen as the home link security problem, we think one hop judgement is enough for operators. -Qin _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 25 17:19:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxALw-0004CP-86; Mon, 25 Jul 2005 17:19:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxALt-00048K-I3 for mip6@megatron.ietf.org; Mon, 25 Jul 2005 17:19:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24348 for ; Mon, 25 Jul 2005 17:18:43 -0400 (EDT) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxAqQ-0000Wy-Pg for mip6@ietf.org; Mon, 25 Jul 2005 17:50:43 -0400 Received: from MINDLAP2 (mindlap2.cs.umd.edu [172.16.0.37]) (authenticated bits=0) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j6PLIVfL015644 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 25 Jul 2005 17:18:36 -0400 (EDT) Message-Id: <200507252118.j6PLIVfL015644@carrierpigeon.cs.umd.edu> From: "Moustafa Youssef" To: Date: Mon, 25 Jul 2005 17:18:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Subject: [Mip6] 1st CFP: Journal of Computer Communications Special Issue on "Sensor-Actuator Networks (SANETs)" 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 (Our apologies if you receive multiple copies of this CFP) ------------------------------------------------------------- Call for Papers Journal of Computer Communications (http://www.elsevier.com/locate/comcom) Special Issue on "Sensor-Actuator Networks (SANETs)" Sensor-Actuator NETworks (SANETs) are comprised of networked sensor and actuator nodes that communicate among each other using wireless links to perform distributed sensing and actuation tasks. The recent few years have witnessed an increasing interest in the potential use of SANETs in many applications ranging from healthcare to warfare. In these applications, sensors are engaged in gathering information about the physical environment, while actuators are involved in taking decisions and then performing appropriate actions in the area of interest. This enables SANETs to provide remote sensing and actuation services to their users. SANETs are heterogeneous networks having widely differing sensor and actuator node characteristics; while sensor nodes are small, inexpensive, usually static devices with limited computation, communication and energy resources, actuator nodes are resource-rich and usually mobile. Also, the number of sensor nodes deployed may be in the order of hundreds or thousands. In contrast, actuator nodes are smaller in number due to the different coverage requirements and physical interaction methods of actuation. Typically, a deployed SANET is expected to operate autonomously in unattended environments. Operational requirements of SANETs may vary according to a network=92s mission defined over a multi-dimensional context, such as field of deployment (e.g., hostile versus friendly), type of application (e.g., monitoring, tracking, intrusion detection and mitigation), mode of operation (e.g., normal, exception, post-event recovery), and time. In SANETs, depending on the application, there may be a need to rapidly respond to sensor input. Moreover, so as to provide right actions, sensor data must still be valid at the time of acting. Consequently, the issues of real-time communication and coordination are vital in SANETs. Finally, to realize their potential, dependable, secure, application-aware design and operation of SANETs have to be ensured. Apparently, research is needed to resolve the many complicating issues that may impede wide-scale SANET adoption. This special issue of the Journal of Computer Communications will be designated for reporting on recent research results on SANETs. It is expected that non-conventional techniques more suited to the characteristics of SANETs need to be employed. Also, in many cases trade-off would be necessary in order to ensure practicality by dynamically setting bounds on aspects such as dependability, security, and QoS. Papers presenting original and unpublished work are being solicited. Topics of interest include, although not limited to, the following: - Sensor-actuator coordination and communication - Architectural and operational models - Robust routing and MAC protocols - Fault and attack resilience middleware - Models, metrics and measurements - Self-aware and autonomous networks - Localization and mobility - Energy-efficient cross-layer protocols - Security, dependability, privacy and QoS issues - Network management - Formal representation and verification - Network inference (tomography, etc.) - Testbeds, simulation and visualization - Novel applications of sensor and actuator networks ** Submission deadline: February 15 , 2006 ** Decision notification: May 15, 2006 ** Final manuscript due: July 31, 2006 ** Publication date: 1st Quarter 2007 ** Submission instructions: Prospective authors should submit their paper and inquiries electronically to toweissy@vt.edu. The manuscript should not exceed 30 double-space pages in PDF. The manuscript should be in a single column font size 11 or larger format. The first page should include title, authors=92 contact information, an abstract and five keywords. Authors should include the paper abstract in their message. ** Guest Editors: Mohamed Eltoweissy: The Bradley Dept. of Electrical & Computer Eng., Virginia Tech, USA, toweissy@vt.edu Silvia Giordano: Dept. of Informatics & Electronics, Univ. of Applied Sci., Switzerland, silvia.giordano@supsi.ch Stephan Olariu: Dept. of Computer Science, Old Dominion University, USA, olariu@cs.odu.edu David Simplot-Ryl: IRCICA/LIFL, University of Lille 1, INRIA Futurs, France, David.Simplot@lifl.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 25 19:11:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxC6c-0006FJ-0W; Mon, 25 Jul 2005 19:11:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxC6Z-00068e-Rr for mip6@megatron.ietf.org; Mon, 25 Jul 2005 19:11:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05677 for ; Mon, 25 Jul 2005 19:11:25 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxCbV-0004wL-9e for mip6@ietf.org; Mon, 25 Jul 2005 19:43:26 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6PMeBf05757 for ; Mon, 25 Jul 2005 15:40:11 -0700 X-mProtect: <200507252240> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdIEpcm6; Mon, 25 Jul 2005 13:40:04 PDT Message-ID: <42E55563.1040804@iprg.nokia.com> Date: Mon, 25 Jul 2005 14:10:59 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird (X11/20050322) 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: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Mip6] HAHA and HA reliability 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 hi folks, since we are on the topic of HA reliability, we recently revised and submitted a draft on HA reliability based on the HAHA protocol. you can find it at http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-nemo-local-haha-00.txt It has been completely re-written. it also has a section on using VRRPv6 with HAHA. comments are welcome. HAHA in general supports placing HAs in geographically separate locations while still serving the same home prefix. this is described in http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-global-haha-00.txt the HAHA messages are defined in http://www.mobilenetworks.org/nemo/drafts/draft-wakikawa-mip6-nemo-haha-spec-00.txt Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 25 19:42:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxCaJ-000321-8Z; Mon, 25 Jul 2005 19:42:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxCaI-00031w-E1 for mip6@megatron.ietf.org; Mon, 25 Jul 2005 19:42:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06996; Mon, 25 Jul 2005 19:42:07 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxD5E-0005gW-Vc; Mon, 25 Jul 2005 20:14:09 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6PNaKXG020523; Tue, 26 Jul 2005 02:36:20 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Jul 2005 02:42:03 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jul 2005 18:42:01 -0500 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jul 2005 18:41:59 -0500 Message-ID: <456943D540CFC14A8D7138E64843F853014F8BB4@daebe101.NOE.Nokia.com> Thread-Topic: IETF63: Agenda of Mobility for IPv6 (mip6) WG meeting Thread-Index: AcWQl8Yt9iC1gmCJQHOKhZZP7qDzww== To: X-OriginalArrivalTime: 25 Jul 2005 23:42:01.0038 (UTC) FILETIME=[741E76E0:01C59172] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org Subject: [Mip6] IETF63: Agenda of Mobility for IPv6 (mip6) WG meeting 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 Please post the revised agenda of the MIP6 WG. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Agenda of Mobility for IPv6 (mip6) WG meeting at IETF63 Tuesday August 2nd, 2006 1630-1800 Afternoon Session II and 1815-1945 Afternoon Session III (180 Mins) Chair(s): Basavaraj Patil Gopal Dommety ------------------------------------------ 1. Agenda, Bluesheets, Note-takers and Jabber scribes 5 Mins 2. WG documents status update Chairs 15 Mins I-Ds and TAHI test suite update =20 3. Mobile IPv6 bootstrapping in split and integrated scenarios=20 draft-ietf-mip6-bootstrapping-split-00 Gerardo Giaretta 20 Mins 4. Home Agent Initiated Bootstrap for Mobile IPv6 draft-li-mip6-ha-init-bootstrap-00 Q. Li 10 Mins =20 5. Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture draft-ietf-mip6-ikev2-ipsec-02 Vijay Devarapalli 15 Mins 6. Mobility management for Dual stack mobile nodes; Problem Statement draft-ietf-mip6-dsmip-problem-00 Hesham Soliman 15 Mins 7. MIP6 operation when attached to v4 access networks =20 Slides to be made available before meeting Design team 20 Mins 8. IP Address Location Privacy and IP Mobility draft-koodli-mip6-location-privacy-00 Rajeev Koodli 10 Mins 9. Review summary of I-D draft-irtf-mobopts-ro-enhancements-01 Christian Vogt 10 Mins 10. Care-of Address Test for MIPv6 using a State Cookie draft-dupont-mipv6-rrcookie-01 Francis Dupont 5 Mins 11. Securing Home Agent List in MIP6 draft-dutta-mip6-ra-00 Sachin Dutta 10 Mins 12. Reliability and Load Balance among multiple Home Agents draft-deng-mip6-vrrp-homeagent-reliability-00.txt Hui Deng 10 Mins 13. Next steps Chairs 10 Mins _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 25 20:57:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxDks-0000mn-6D; Mon, 25 Jul 2005 20:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxDkr-0000mf-3f for mip6@megatron.ietf.org; Mon, 25 Jul 2005 20:57:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11151; Mon, 25 Jul 2005 20:57:07 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxEFl-0007fn-Di; Mon, 25 Jul 2005 21:29:08 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6Q0Pnc06304; Mon, 25 Jul 2005 17:25:49 -0700 X-mProtect: <200507260025> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14169.americas.nokia.com (172.18.141.69, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdWTNFGj; Mon, 25 Jul 2005 17:25:47 PDT Message-ID: <42E58A4B.80007@iprg.nokia.com> Date: Mon, 25 Jul 2005 17:56:43 -0700 From: Rajeev Koodli 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] Agenda of Mobility for IPv6 (mip6) WG meeting at IETF63 References: <456943D540CFC14A8D7138E64843F853014F87CB@daebe101.NOE.Nokia.com> In-Reply-To: <456943D540CFC14A8D7138E64843F853014F87CB@daebe101.NOE.Nokia.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, agenda@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 Basavaraj.Patil@nokia.com wrote: > 8. IP Address Location Privacy and IP Mobility > draft-koodli-mip6-location-privacy-00 Rajeev Koodli 10 Mins This should be draft-irtf-mobopts-location-privacy-ps-00.txt -Rajeev _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 25 23:12:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFsD-0006zF-HN; Mon, 25 Jul 2005 23:12:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxFsB-0006z7-S0; Mon, 25 Jul 2005 23:12:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17476; Mon, 25 Jul 2005 23:12:49 -0400 (EDT) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxGN9-0002Pu-9M; Mon, 25 Jul 2005 23:44:52 -0400 Received: from iseran.local (unknown [IPv6:2001:200:0:8410:20a:95ff:fed0:2c78]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 09D574D454; Tue, 26 Jul 2005 12:12:18 +0900 (JST) Date: Tue, 26 Jul 2005 12:12:16 +0900 From: Thierry Ernst To: mip6@ietf.org, ml-monami6 Subject: Re: [Mip6] HAHA and HA reliability Message-Id: <20050726121216.2d8da257.ernst@sfc.wide.ad.jp> In-Reply-To: <42E55563.1040804@iprg.nokia.com> References: <42E55563.1040804@iprg.nokia.com> Organization: Keio University X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: 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 Hi, On Mon, 25 Jul 2005 14:10:59 -0700 Vijay Devarapalli wrote: > hi folks, > > since we are on the topic of HA reliability, we recently revised > and submitted a draft on HA reliability based on the HAHA > protocol. you can find it at > http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-nemo-local-haha-00.txt > It has been completely re-written. it also has a section on using > VRRPv6 with HAHA. comments are welcome. > > HAHA in general supports placing HAs in geographically separate > locations while still serving the same home prefix. this is > described in > http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-global-haha-00.txt > > the HAHA messages are defined in > http://www.mobilenetworks.org/nemo/drafts/draft-wakikawa-mip6-nemo-haha-spec-00.txt In the case where HA are placed in geographically separate locations, this is indeed a multihoming configuration as defined in draft-montavont-mobileip-multihoming-pb-statement (for host mobility) and draft-ietf-nemo-multihoming-issues (for network mobility). As such, and since it covers for MIP6 and NEMO, I think it falls into the scope of the Monami6 BOF (http://www.nautilus6.org/ietf). However, we have not yet initiated the discussion on this topic on the Monami6 ML and it may be too much discussion for the BOF. If Monami6 can become a WG, I think it should be added in our charter as a Monami6 WG item. Thierry _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Jul 25 23:58:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxGa9-0006rh-RX; Mon, 25 Jul 2005 23:58:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxGa7-0006rT-MG for mip6@megatron.ietf.org; Mon, 25 Jul 2005 23:58:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20438 for ; Mon, 25 Jul 2005 23:58:13 -0400 (EDT) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DxH4z-0003ol-Rq for mip6@ietf.org; Tue, 26 Jul 2005 00:30:16 -0400 Received: (qmail 25997 invoked from network); 26 Jul 2005 03:57:40 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;e114460001f34566d009e90b02f7e727; Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 26 Jul 2005 03:57:22 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Tue, 26 Jul 2005 11:42:32 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 26 Jul 2005 11:42:29 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA3859138A@hcbjdc2> Thread-Topic: +AFs-Mip6+AF0- Simultaneous Bindings in MIP6 Thread-Index: AcWN31ZtH/SXX67jRcel9JJYxcEfcgDtJrWw From: "+ACI-DENG, HUI -HCHBJ+ACI-" To: "Karim El-Malki (AL/EAB)" , X-OriginalArrivalTime: 26 Jul 2005 03:42:32.0531 (UTC) FILETIME=[0DF58A30:01C59194] X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1122350242.103-25897-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.02/0.13 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Subject: [Mip6] RE: +AFs-Mip6+AF0- Simultaneous Bindings in MIP6 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 Hi, Karim I feel that bicasting is useful for mobopts. and some proposal adopted this mechanism. -Hui -----Original Message----- From: Karim El-Malki (AL/EAB) +AFs-mailto:karim.el-malki+AEA-ericsson.com+AF0- Sent: 2005+XnQ-7+Zwg-21+ZeU- 18:31 To: mip6+AEA-ietf.org Subject: +AFs-Mip6+AF0- Simultaneous Bindings in MIP6 Hi Since I got a email about it I have resubmitted an old draft that introduces simultaneous bindings functionality in MIP6 so that an MN can register using multiple COAs contemporarily: http://www.ietf.org/internet-drafts/draft-elmalki-mobileip-bicasting-v6-06.txt I'm sending this out to see if anyone thinks it is useful and wants to work on it. BR Karim +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- Mip6 mailing list Mip6+AEA-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 Jul 26 01:46:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxIGU-0002fe-03; Tue, 26 Jul 2005 01:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxIGS-0002f7-9W; Tue, 26 Jul 2005 01:46:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26533; Tue, 26 Jul 2005 01:46:03 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxIlQ-0006V9-Q7; Tue, 26 Jul 2005 02:18:06 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK8008VO02NOU@szxga01-in.huawei.com>; Tue, 26 Jul 2005 13:47:11 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK8008KM02M7V@szxga01-in.huawei.com>; Tue, 26 Jul 2005 13:47:11 +0800 (CST) Received: from keshavaak ([10.18.4.181]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IK800MSM09RJI@szxml01-in.huawei.com>; Tue, 26 Jul 2005 13:51:35 +0800 (CST) Date: Tue, 26 Jul 2005 11:12:30 +0530 From: Keshava Ayanur To: mip4@ietf.org, mip6@ietf.org Message-id: <000601c591a4$d6e19820$b504120a@china.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: Subject: [Mip6] implementation section .. X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: keshavaak@huawei.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0856354674==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0856354674== Content-type: multipart/alternative; boundary="Boundary_(ID_8m7dBH0yk88NIfiF3ngtjA)" This is a multi-part message in MIME format. --Boundary_(ID_8m7dBH0yk88NIfiF3ngtjA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Dear all, Can I know who is maintaining the MIP4 and MIP6 implementation sections? (http://www.mip4.org/2004/implementations/) Sorry for the inconvenience. Thanks & regards, Keshava --Boundary_(ID_8m7dBH0yk88NIfiF3ngtjA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Dear all,

            Can I know who is maintaining the MIP4 and MIP6 implementation sections?

            (http://www.mip4.org/2004/implementations/)

           

            Sorry for the inconvenience.

 

Thanks & regards,

Keshava

--Boundary_(ID_8m7dBH0yk88NIfiF3ngtjA)-- --===============0856354674== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0856354674==-- From mip6-bounces@ietf.org Tue Jul 26 03:13:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxJca-0003Wu-QJ; Tue, 26 Jul 2005 03:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxJcZ-0003Wm-5a; Tue, 26 Jul 2005 03:12:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22766; Tue, 26 Jul 2005 03:12:57 -0400 (EDT) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxK7Z-0000De-12; Tue, 26 Jul 2005 03:45:02 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IK8005EX49POP@szxga01-in.huawei.com>; Tue, 26 Jul 2005 15:17:50 +0800 (CST) Received: from m22421 ([10.78.230.55]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IK800M8K49PD3@szxga01-in.huawei.com>; Tue, 26 Jul 2005 15:17:49 +0800 (CST) Date: Tue, 26 Jul 2005 15:10:41 +0800 From: mao shanxiang Subject: Re: [Mip6] implementation section .. To: keshavaak@huawei.com, mip4@ietf.org, mip6@ietf.org Message-id: <001801c591b1$2423ebe0$37e64e0a@huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-Priority: 3 X-MSMail-priority: Normal References: <000601c591a4$d6e19820$b504120a@china.huawei.com> X-Spam-Score: 0.4 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: 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="===============0725558776==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0725558776== Content-type: multipart/alternative; boundary="Boundary_(ID_mPYoJ7r/vsThGlTDzlthGA)" This is a multi-part message in MIME format. --Boundary_(ID_mPYoJ7r/vsThGlTDzlthGA) Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT it is mentioned in the web site how to update it. there is a mail link there, i think you can directly ask there. ***************************************************************** This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! ***************************************************************** ----- Original Message ----- From: Keshava Ayanur To: mip4@ietf.org ; mip6@ietf.org Sent: Tuesday, July 26, 2005 1:42 PM Subject: [Mip6] implementation section .. Dear all, Can I know who is maintaining the MIP4 and MIP6 implementation sections? (http://www.mip4.org/2004/implementations/) Sorry for the inconvenience. Thanks & regards, Keshava ------------------------------------------------------------------------------ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --Boundary_(ID_mPYoJ7r/vsThGlTDzlthGA) Content-type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7BIT
it is mentioned in the web site how to update it. there is a mail link there, i think you can directly ask there.
*****************************************************************
This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
*****************************************************************
----- Original Message -----
Sent: Tuesday, July 26, 2005 1:42 PM
Subject: [Mip6] implementation section ..

Dear all,

            Can I know who is maintaining the MIP4 and MIP6 implementation sections?

            (http://www.mip4.org/2004/implementations/)

           

            Sorry for the inconvenience.

 

Thanks & regards,

Keshava

_______________________________________________
Mip6 mailing list
Mip6@ietf.org
https://www1.ietf.org/mailman/listinfo/mip6
--Boundary_(ID_mPYoJ7r/vsThGlTDzlthGA)-- --===============0725558776== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0725558776==-- From mip6-bounces@ietf.org Tue Jul 26 04:57:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLFN-0001qZ-W2; Tue, 26 Jul 2005 04:57:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLFL-0001q0-TP; Tue, 26 Jul 2005 04:57:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29418; Tue, 26 Jul 2005 04:57:05 -0400 (EDT) Received: from av8-2-sn3.vrr.skanova.net ([81.228.9.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxLkM-0003hq-Cx; Tue, 26 Jul 2005 05:29:11 -0400 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 5DE3137E7A; Tue, 26 Jul 2005 10:56:52 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3235F37E62; Tue, 26 Jul 2005 10:56:51 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 110BC37E45; Tue, 26 Jul 2005 10:56:40 +0200 (CEST) Received: from localhost ([127.0.0.1] ident=henrik) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1DxLEt-0000X6-PP; Tue, 26 Jul 2005 10:56:39 +0200 Message-ID: <42E5FAC1.7070200@levkowetz.com> Date: Tue, 26 Jul 2005 10:56:33 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: keshavaak@huawei.com References: <000601c591a4$d6e19820$b504120a@china.huawei.com> In-Reply-To: <000601c591a4$d6e19820$b504120a@china.huawei.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: mip6@ietf.org, mip4@ietf.org Subject: [Mip6] Re: [Mip4] implementation section .. 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="===============1404176295==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1404176295== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9266BECD935D047C7EF15077" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9266BECD935D047C7EF15077 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit on 2005-07-26 07:42 Keshava Ayanur said the following: > Dear all, > > Can I know who is maintaining the MIP4 and MIP6 implementation > sections? > > (http://www.mip4.org/2004/implementations/) I am, but I don't actively look for new implementations; however I'm happy to add any new information people supply. Do you know some implementation which is missing? Henrik --------------enig9266BECD935D047C7EF15077 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFC5frHeVhrtTJkXCMRAm3HAJ9q2gGiVf5ICVG+0+Qe9qooJ9n4UgCfQBrS E75B3maqnwwrrUV7SKVDMJ4= =0XII -----END PGP SIGNATURE----- --------------enig9266BECD935D047C7EF15077-- --===============1404176295== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1404176295==-- From mip6-bounces@ietf.org Tue Jul 26 05:06:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLOR-0003ig-GH; Tue, 26 Jul 2005 05:06:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLOO-0003fv-MM for mip6@megatron.ietf.org; Tue, 26 Jul 2005 05:06:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00107 for ; Tue, 26 Jul 2005 05:06:26 -0400 (EDT) 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.43) id 1DxLtP-0003z4-OT for mip6@ietf.org; Tue, 26 Jul 2005 05:38:32 -0400 Message-ID: <013501c591c1$4b74f940$626015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "DENG, HUI -HCHBJ" , "Li Qin" References: <834B54D356AA8F46B9B233DD88BEAA38591372@hcbjdc2> Subject: Re: [Mip6] Bootstrapping DT solution draft Date: Tue, 26 Jul 2005 02:06:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , 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 What I mean is that the operater can use the SRV record preference field for long term load balancing, and connection refusal for short term load balancing, due to flash crowds and such. Since such short term loads tend to be rare in a properly provisioned network, I see no problem with connection refusal requiring more time on the part of the MN, since it should not happen often (if it does, the operater has a provisioning problem, and better buy a couple more HAs). I believe that the DNS is perfectly fine for bootstrapping. Every other service on the Internet uses it, there's no reason why Mobile IP can't use it too. I think the solution outlined in the bootstrapping draft is just fine, and aligns mobility service discovery consistently with the general Internet service architecture model, for the split scenerio case. For the integrated scenerio case, other solutions may be somewhat more optimal on a couple of metrics. The DT is looking at that case right now. jak ----- Original Message ----- From: "DENG, HUI -HCHBJ" To: "James Kempf" ; "Li Qin" Cc: "Gerardo Giaretta" ; Sent: Sunday, July 24, 2005 9:09 AM Subject: RE: [Mip6] Bootstrapping DT solution draft The SRV record contains information that the operator can use to establish a preference ordering on the servers for clients. That said, I don't believe it is intended to provide fast, real time information about preferences, say on the order of seconds., but more over longer periods, since dynamic DNS updates require some time to propagate, and it would also not be such a good idea to burden the DNS server with having to handle such frequent updates. ==> Do you mean that DNS is not suitable for dynamical home agent assignment in this bootstrap solution? Its also possible for the HAs themselves to refuse new IKEv2 connections if they are loaded. ==> We guess here need more discussion. Since the MN will have a list of HAs, it will just roll over to trying the next one. ==> Do you think this way is very efficient? The HAs could co-operate somehow (maybe using a protocol like HAHA?) to establish which HA should be taking new connections. This could be used to perform finer grained load balancing. ==> Do you mean that home agent assignment should be in another document, out of bootstrap? -Hui ----- Original Message ----- From: "Li Qin" To: "James Kempf" Cc: "Li Qin" ; "Gerardo Giaretta" ; Sent: Thursday, July 21, 2005 8:33 AM Subject: Re: [Mip6] Bootstrapping DT solution draft > In my opinion I think its more like a HA discovery than HA assignment. > > If multiple HAs are deployed in home network, is it possible to assign > a HA according to the user's profile, or according to current load of > the HAs in this solution? > > James Kempf wrote: > > The home DNS server can contain multiple HA addresses in the SRV > > record. > > > > jak > > > > > > > > ----- Original Message ----- > > From: "Li Qin" > > To: "Gerardo Giaretta" > > Cc: > > Sent: Wednesday, July 20, 2005 1:11 AM > > Subject: Re: [Mip6] Bootstrapping DT solution draft > > > > > > > >>I guess that multiple home agents related issues, such as dynamic > >>home agent assignment, have not been considered in this draft. > >> > >>if so , can you tell us the reason? > >> > >>Gerardo Giaretta wrote: > >> > >>>Dear WG, > >>> > >>>the bootstrapping DT has submitted a solution draft. The document > >>>defines how a Mobile Node can bootstrap MIPv6 operations from > >>>non-topological information and pre-configured security > >>>credentials. The > >>>solution solves the boostrapping problem when the Mobile Node's mobility > >>>service is authorized by a different service provider than basic network > >>>access (i.e. split scenario). > >>> > >>>The draft can be found at > >>>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-spl >>>it- > >>>00.txt. > >>> > >>>The DT is currently working on optimized solutions for integrated > >>>scenario (i.e. mobility service and basic network access are > >>>authorized by the same entity). > >>> > >>>Please read the document and provide comments. > >>> > >>>Thanks and regards, > >>> > >>>--Gerardo (DT editor) > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > > > > S.p.A. > > > >>>=================================================================== > >>>= > >>>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 > >>>=================================================================== > >>>= > >>> > >>>_______________________________________________ > >>>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 Tue Jul 26 05:41:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLvq-0002zC-Tq; Tue, 26 Jul 2005 05:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxLvq-0002xK-4r for mip6@megatron.ietf.org; Tue, 26 Jul 2005 05:41:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02089 for ; Tue, 26 Jul 2005 05:40:59 -0400 (EDT) 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.43) id 1DxMQq-00052X-U4 for mip6@ietf.org; Tue, 26 Jul 2005 06:13:06 -0400 Message-ID: <02cd01c591c6$1c870510$626015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Yong" , "Vijay Devarapalli" , "Li Qin" References: <200507251413.KAA22955@ietf.org> Subject: Re: Re: [Mip6] Bootstrapping DT solution draft Date: Tue, 26 Jul 2005 02:40:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , 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 Can you say why? If the MSP != MSA, then it is the MSA's AAA server that is authorizing the mobility service, and the AAA_MSA is in a separate domain. Thus, the AAA_MSA has no knowledge of the MSP's toplogy. jak ----- Original Message ----- From: "Yong" To: "Vijay Devarapalli" ; "Li Qin" Cc: "Gerardo Giaretta" ; Sent: Monday, July 25, 2005 7:12 AM Subject: Re: Re: [Mip6] Bootstrapping DT solution draft > Hi, Vijay Devarapalli, > > >the current bootstrap solution is for the split scenario. the > >bootstrap design team just started working on the integrated > >scenario. in the integrated scenario the HA can be assigned > >by the AAAH during network access authentication. > > > >Vijay > > > > I cannot agree that AAA in MSP are not responsible for assignment > home agent in bootstrap split scenario from the mip6 deployment > point of view. > > Best regards, > 22:08:32 2005-07-25 > ******************************************************** > * Yong Cui * > * Ph.D, Department of Computer Science & Technology * > * Tsinghua University, Beijing, P.R.China(100084) * > * Tel: (8610)-62795818-6859 * > * Email: yong@csnet1.cs.tsinghua.edu.cn * > ******************************************************** > > > _______________________________________________ > 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 Jul 26 08:30:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOZd-0006jv-TT; Tue, 26 Jul 2005 08:30:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dx3zX-0005wr-1u for mip6@megatron.ietf.org; Mon, 25 Jul 2005 10:31:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25118 for ; Mon, 25 Jul 2005 10:31:36 -0400 (EDT) Received: from mx1.iit.cnr.it ([146.48.98.40] helo=mx.iit.cnr.it) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dx4UN-0004e8-FZ for mip6@ietf.org; Mon, 25 Jul 2005 11:03:32 -0400 Received: from localhost (mx.iit.cnr.it [127.0.0.1]) by mx.iit.cnr.it (Postfix) with ESMTP id 7B3562EE13; Mon, 25 Jul 2005 16:31:08 +0200 (CEST) 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 13025-03; Mon, 25 Jul 2005 16:31:03 +0200 (CEST) Received: from [146.48.99.112] (dhcp49.iit.cnr.it [146.48.99.112]) by mx.iit.cnr.it (Postfix) with ESMTP id 2F0062EE17; Mon, 25 Jul 2005 16:31:03 +0200 (CEST) Mime-Version: 1.0 X-Sender: marco.conti@iit.cnr.it@mx.iit.cnr.it Message-Id: Date: Mon, 25 Jul 2005 16:33:07 +0200 To: sw-ubicomp-interest@yahoogroups.com, ubiquitous-computing@listserv.uni-augsburg.de, dbjapan@dbsj.org, mip6@ietf.org From: Marco Conti X-Virus-Scanned: by Content Checker at iit.cnr.it X-Spam-Score: 0.7 (/) X-Scan-Signature: 32a65c0bf5eb4ec26489239c7cdd0636 X-Mailman-Approved-At: Tue, 26 Jul 2005 08:30:15 -0400 Cc: Subject: [Mip6] IEEE PerCom'06: CFP (Deadline: September 5, 2005) 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="===============1833965301==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --===============1833965301== Content-Type: multipart/alternative; boundary="============_-1089820506==_ma============" --============_-1089820506==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" We apologize in advance if you receive multiple copies of this CFP. ---------------------------------------------------------------------- CALL FOR PAPERS Fourth IEEE International Conference on Pervasive Computing and Communications (PerCom 2006) Pisa, March 13-17, 2006 http://www.percom.org/ **** Submission Deadline --- September 5, 2005 **** ---------------------------------------------------------------------- IEEE PerCom 2006 will be the fourth annual conference on the emerging area of pervasive computing and communications aimed at providing an exciting platform and paradigm for all the time, everywhere services. This emergence is a natural outcome of the tremendous advances in wireless networks, mobile computing, sensor networks, distributed computing, and agent technologies. PerCom 2006 will provide a high profile, leading edge forum for researchers and engineers alike to present their latest research in the field of pervasive computing and communications. Topics: Contributions are solicited in all areas of pervasive computing research and applications. Topics include, but not limited to: - Pervasive computing and communication architectures - Intelligent environments - Wearable computers - Smart devices and smart spaces - Middleware services and agent technologies - Wireless Sensor networks and RFID technologies - Positioning and tracking technologies - Virtual immersive communications - Enabling technologies (e.g. wireless BAN, PAN) - Mobile/Wireless computing systems and services - Context aware computing - Autonomic computing and communications - Programming paradigms for pervasive systems - User interfaces and interaction models - Wireless/mobile service management and delivery - Ad hoc networking protocols - Resource management in pervasive systems - Trust, security and privacy issues in pervasive systems ------------------------------------------------------------------------------ Submission Guidelines: ------------------------------------------------------------------------------ Submitted papers must be unpublished and not considered elsewhere for publication. Only electronic submissions (PS or PDF) will be considered. Page limit is 12 pages (single column, 11 pt fonts and 1.5 line spaced, excluding references, figures and tables). Detailed procedure is available at http://www.percom.org. All submitted papers will undergo a rigorous review process managed by the technical program committee. IEEE Press will publish the conference proceedings. The best paper will receive the prestigious Mark Weiser best paper award. Papers of particular merit will be considered for a special issue of Pervasive and Mobile Computing Journal. ---------------------------------------------------------------------- IMPORTANT DEADLINES: Paper Submission: September 5, 2005 Workshop Proposal: May 1, 2005 Demonstration Proposal: October 31, 2005 Acceptance Notification: November 22, 2005 Camera Ready Manuscripts: December 19, 2005 Conference Dates: March 13-17, 2006 ------------------------------------------------------------------------ Program Chair: Marco Conti, Istituto di Informatica e Telematica, Pisa, Italy Vice Program Chairs: Chatschik Bisdikian, IBM Research, USA Jadwiga Indulska, University of Queensland, Australia Franco Zambonelli, University of Modena and Reggio Emilia, Italy Technical Program Committee (TBD) General Chair: Enrico Gregori, Istituto di Informatica e Telematica, Pisa, Italy General Vice Chair: Ali Hurson, Pennsylvania State University, USA Steering Committee Chair: Behrooz Shirazi, University of Texas at Arlington, USA Workshop Chairs: Giuseppe Anastasi, University of Pisa, Italy Gopal Pingali, IBM T.J. Watson Research Center, Hawthorne, USA Work-in-progress Session chairs: Christian Becker, University of Stuttgart, Germany Gergely Zaruba, University of Texas at Arlington, USA Publicity Chairs: Ben Lee, Oregon State University. USA Ichiro Satoh, National Institute of Informatics, Tokyo, Japan Paolo Bellavista, University of Bologna, Italy Demo Chairs: Luciano Bononi, University of Bologna, Italy Vipul Gupta, Sun Microsystems Inc., USA Registration Chair: Gergely Zaruba, University of Texas at Arlington, USA Web Designer: Patrizia Andronico, Istituto di Informatica e Telematica, Pisa, Italy Local Arrangements: Raffaella Casarosa, - Istituto di Informatica e Telematica, Pisa, Italy -- ============================================== Marco Conti Pervasive Computing & Networking Lab. (PerLab) http://www.perlab.it Institute for Informatics and Telematics (IIT) National Research Council (CNR) Via G. Moruzzi, 1 56124 Pisa,Italy tel.: + 39 050 315 3062 (direct) mobile: +39 348 3966807 fax.: +39 050 3152593 --============_-1089820506==_ma============ Content-Type: text/html; charset="us-ascii" IEEE PerCom'06: CFP (Deadline: September 5, 2005)
We apologize in advance if you receive multiple copies of this CFP.
----------------------------------------------------------------------

CALL FOR PAPERS

Fourth IEEE International Conference on
Pervasive Computing and Communications (PerCom 2006)
Pisa, March 13-17, 2006

**** Submission Deadline --- September 5, 2005 ****
                
----------------------------------------------------------------------

IEEE PerCom 2006 will be the fourth annual conference on the emerging area of pervasive computing and communications aimed at providing an exciting platform and paradigm for all the time, everywhere services. This emergence is a natural outcome of the tremendous advances in wireless networks, mobile computing, sensor networks, distributed computing, and agent technologies. PerCom 2006 will provide a high profile, leading edge forum for researchers and engineers alike to present their latest research in the field of pervasive computing and communications.
Topics:
Contributions are solicited in all areas of pervasive computing research and applications.  Topics include, but not limited to:

- Pervasive computing and communication architectures
- Intelligent environments
- Wearable computers
- Smart devices and smart spaces
- Middleware services and agent technologies
- Wireless Sensor networks and RFID technologies
- Positioning and tracking technologies
- Virtual immersive communications
- Enabling technologies (e.g. wireless BAN, PAN)
- Mobile/Wireless computing systems and services
- Context aware computing
- Autonomic computing and communications
- Programming paradigms for pervasive systems
- User interfaces and interaction models
- Wireless/mobile service management and delivery
- Ad hoc networking protocols
- Resource management in pervasive systems
- Trust, security and privacy issues in pervasive systems
 
------------------------------------------------------------------------------
Submission Guidelines:
------------------------------------------------------------------------------

Submitted papers must be unpublished and not considered elsewhere for publication. Only electronic submissions (PS or PDF) will be considered.
Page limit is 12 pages (single column, 11 pt fonts and 1.5 line spaced, excluding references, figures and tables). Detailed procedure is available at http://www.percom.org. All submitted papers will undergo a rigorous review process managed by the technical program committee. IEEE Press will publish the conference proceedings. The best paper will receive the prestigious Mark Weiser best paper award. Papers of particular merit will be considered for a special issue of Pervasive and Mobile Computing Journal.
----------------------------------------------------------------------
IMPORTANT DEADLINES:

Paper Submission:                       September 5, 2005
Workshop Proposal:                         May 1, 2005
Demonstration Proposal:                      October 31, 2005
Acceptance Notification:                November 22, 2005
Camera Ready Manuscripts:              December 19, 2005
Conference Dates:                       March 13-17, 2006
------------------------------------------------------------------------

Program Chair:
Marco Conti, Istituto di Informatica e Telematica, Pisa, Italy

Vice Program Chairs:
Chatschik Bisdikian, IBM Research, USA
Jadwiga Indulska, University of Queensland, Australia
Franco Zambonelli, University of Modena and Reggio Emilia, Italy

Technical Program Committee (TBD)

General Chair:
Enrico Gregori, Istituto di Informatica e Telematica, Pisa, Italy

General Vice Chair:
Ali Hurson, Pennsylvania State University, USA

Steering Committee Chair:
Behrooz Shirazi, University of Texas at Arlington, USA

Workshop Chairs:
Giuseppe Anastasi, University of Pisa, Italy
Gopal Pingali, IBM T.J. Watson Research Center, Hawthorne, USA

Work-in-progress Session chairs:
Christian Becker, University of Stuttgart, Germany
Gergely Zaruba, University of Texas at Arlington, USA

Publicity Chairs:
Ben Lee, Oregon State University. USA
Ichiro Satoh, National Institute of Informatics, Tokyo, Japan
Paolo Bellavista, University of Bologna, Italy

Demo Chairs:
Luciano Bononi, University of Bologna, Italy
Vipul Gupta, Sun Microsystems Inc., USA

Registration Chair:
Gergely Zaruba, University of Texas at Arlington, USA

Web Designer:
Patrizia Andronico, Istituto di Informatica e Telematica, Pisa, Italy

Local Arrangements:
Raffaella Casarosa, - Istituto di Informatica e Telematica, Pisa, Italy

--
==============================================
Marco Conti
Pervasive Computing & Networking Lab. (PerLab)
http://www.perlab.it

Institute for Informatics and Telematics (IIT)
National Research Council (CNR)
Via G. Moruzzi, 1
56124 Pisa,Italy
tel.: + 39 050 315 3062 (direct)
mobile: +39 348 3966807
fax.: +39 050 3152593



--============_-1089820506==_ma============-- --===============1833965301== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1833965301==-- From mip6-bounces@ietf.org Tue Jul 26 08:30:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxOZe-0006l2-Cn; Tue, 26 Jul 2005 08:30:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxEpy-0003j5-99; Mon, 25 Jul 2005 22:06:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14135; Mon, 25 Jul 2005 22:06:27 -0400 (EDT) Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxFKs-0000rj-5l; Mon, 25 Jul 2005 22:38:29 -0400 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j6Q265HU019309; Tue, 26 Jul 2005 10:06:05 +0800 (SGT) Received: from newmailhost.i2r.a-star.edu.sg ([192.122.134.76])by rodin.i2r. a-star.edu.sg (8.13.1/8.13.1) with ESMTP id j6Q261ej019234; Tue, 26 Jul 2005 10:06:02 +0800 (SGT) Received: from Athena ([192.168.136.189])by mailhost.lit.org.sg (Sun Java Sy stem Messaging Server 6.1 HotFix 0.06(built Nov 11 2004)) with SMTP id <0IK 7001N3PU58240@mailhost.lit.org.sg>; Tue,26 Jul 2005 10:06:05 +0800 (SGT) Date: Tue, 26 Jul 2005 10:05:06 +0800 From: Yeo Boon Sain To: Message-id: <002d01c59186$716f1e40$bd88a8c0@Athena> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.0 X-imss-result: Passed X-imss-scores: Clean:33.86113 C:17 M:1 S:5 R:5 X-imss-settings: Baseline:5 C:4 M:4 S:4 R:4 (1.5000 6.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Tue, 26 Jul 2005 08:30:15 -0400 Cc: Subject: [Mip6] CFP - Internationl Symposium on Wireless Pervasive Computing 2006, P huket, Thailand 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 We sincerely apologize if you receive this CFP more than once. -------------------------------------------------------- 1st International Symposium on Wireless Pervasive Computing 2006 16 - 18 January 2006, Phuket, Thailand Technically Sponsored by IEEE Communications Society Hosted by Suranaree University of Technology, Thailand IMPORTANT DATES Last date for submitting of papers, proposals for tutorials and panel sessions: August 1, 2005 Notification of Acceptance: September 15, 2005 Last date for submission of camera-ready versions of accepted papers: November 15, 2005 Wireless pervasive computing is a rapidly growing area increasingly attracting attention due to its potential impact on the quality of lifestyles of individuals. This can only be made possible by integrating technologies from the fields of communications , signal processing , computing and numerous other fields. This symposium aims to provide a platform for researchers in the collective area of wireless pervasive computing or any of the related areas to showcase their results, launch new ideas, as well as to interact with colleagues from this area. The scope of the symposium covers concepts and all enabling technologies of wireless pervasive computing. This includes a huge variety of topics ranging from wireless communications and networking to services and applications of pervasive computing . A series of panel and tutorials will also seek to inform and invoke interaction among researchers which are interested in this area. Topics of interest include but are NOT LIMITED to the following: . PCS, GPRS, EDGE, 3GPP, UMTS, GSM and B3G systems . Bluetooth technologies . Air interfaces (e.g. CDMA, OFDM, TDMA) . Dynamic spectrum management . Signal processing . Wireless access techniques . Multirate and multicarrier communications . Detection and estimation . Signal separation and interference rejection . Power control . Interference avoidance . Wireless systems design . Propagation and channel characterization . Diversity techniques & equalization . UWB . Multi-user Detection . MIMO systems . WiMAX . Cooperative coding and algorithms . WLANs and WPANs . RF systems . Coding and modulation techniques . Location management techniques . Localization and tracking techniques . Wireless multimedia . Switching and routing techniques . Wireless multicasting . Wireless network architecture . Ad hoc networks . Wireless sensor networks . Speech and video processing . Wireless security . Security applications . Wearable devices . Middleware . Multimedia systems . Resource management and interference management . Healthcare applications PAPER SUBMISSION GUIDELINES Acceptance will be based on an extended abstract of about 1500 words (two pages in the standard IEEE conference format). The extended abstract should include diagrams, initial results, and details required for the reviewers to assess the contribution of your work. A short summary of approximately 150 words is also required at the time of submission of the extended abstract. Extended abstracts must be submitted electronically by August 1, 2005, via EDAS (http://edas.info). PANEL SESSIONS & TUTORIALS Proposals for Tutorial and Panel Sessions are also being solicited. Tutorials (half-day or full-day sessions) are intended to provide in-depth learning on a specific topic of interest to the participants. Panel sessions are 60 minutes long. They present leaders in a particular area discussing a topic of interest within the scope of the symposium. Proposals for Tutorials and Panel sessions should consist of 1000 words summary, a 150 word abstract, and a cover page listing the details of the author(s). The pdf version of the cfp can be found at http://www.iswpc.org/2006/cfp.pdf _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 26 10:39:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQaS-0008C8-1g; Tue, 26 Jul 2005 10:39:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQaQ-0008Av-Fi; Tue, 26 Jul 2005 10:39:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24135; Tue, 26 Jul 2005 10:39:12 -0400 (EDT) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxR5V-0006ai-1C; Tue, 26 Jul 2005 11:11:21 -0400 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 26 Jul 2005 16:39:05 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j6QEcCEK021313; Tue, 26 Jul 2005 16:39:02 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 26 Jul 2005 16:39:00 +0200 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Monami6] Re: [Mip6] HAHA and HA reliability Date: Tue, 26 Jul 2005 16:38:43 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC011DD0E0@xmb-ams-337.emea.cisco.com> Thread-Topic: [Monami6] Re: [Mip6] HAHA and HA reliability Thread-Index: AcWRkEii/Zi3QR/cTHe2yf2AOICslAAXsVMw From: "Pascal Thubert \(pthubert\)" To: "Monami6 BOF proposal" , , "ml-monami6" X-OriginalArrivalTime: 26 Jul 2005 14:39:00.0054 (UTC) FILETIME=[C2C09760:01C591EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: 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 Well... These arguments are valid. OTOH, HAHA is about getting rid of the home link, placing MIP/NEMO at L3. The objectives are mostly route optimization and load balancing. In that, it seems a bit far from MONAMI. But there's no NEMO RO WG/BOF ;) I think it's a matter of having the right people discuss the subject. If we can raise interest in MONAMI, then MONAMI is the right place. Pascal >-----Original Message----- >From: monami6-bounces@lists.ietf.org [mailto:monami6-bounces@lists.ietf.org] On Behalf Of Thierry >Ernst >Sent: Tuesday, July 26, 2005 5:12 AM >To: mip6@ietf.org; ml-monami6 >Subject: [Monami6] Re: [Mip6] HAHA and HA reliability > > >Hi, > >On Mon, 25 Jul 2005 14:10:59 -0700 >Vijay Devarapalli wrote: > >> hi folks, >> >> since we are on the topic of HA reliability, we recently revised >> and submitted a draft on HA reliability based on the HAHA >> protocol. you can find it at >> http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-nemo-local-ha ha-00.txt >> It has been completely re-written. it also has a section on using >> VRRPv6 with HAHA. comments are welcome. >> >> HAHA in general supports placing HAs in geographically separate >> locations while still serving the same home prefix. this is >> described in >> http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-global-haha -00.txt >> >> the HAHA messages are defined in >> http://www.mobilenetworks.org/nemo/drafts/draft-wakikawa-mip6-nemo-haha- spec-00.txt > >In the case where HA are placed in geographically separate locations, >this is indeed a multihoming configuration as defined in >draft-montavont-mobileip-multihoming-pb-statement (for host mobility) >and draft-ietf-nemo-multihoming-issues (for network mobility). > >As such, and since it covers for MIP6 and NEMO, I think it falls into >the scope of the Monami6 BOF (http://www.nautilus6.org/ietf). However, >we have not yet initiated the discussion on this topic on the Monami6 ML >and it may be too much discussion for the BOF. If Monami6 can >become a WG, I think it should be added in our charter as a Monami6 WG >item. > >Thierry > >_______________________________________________ >Monami6 mailing list >Monami6@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/monami6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 26 10:49:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQjw-0002AR-4T; Tue, 26 Jul 2005 10:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQju-0002AJ-1s; Tue, 26 Jul 2005 10:49:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24859; Tue, 26 Jul 2005 10:49:00 -0400 (EDT) Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxREv-0006ut-CT; Tue, 26 Jul 2005 11:21:09 -0400 Received: from ryuji-no-powerbook-g4-15.local.sfc.wide.ad.jp (sphinx.lix.polytechnique.fr [129.104.11.1]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id j6QEmi64013817; Tue, 26 Jul 2005 23:48:45 +0900 Date: Tue, 26 Jul 2005 23:48:37 +0900 Message-ID: From: Ryuji Wakikawa To: "Pascal Thubert (pthubert)" Subject: Re: [Monami6] Re: [Mip6] HAHA and HA reliability In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC011DD0E0@xmb-ams-337.emea.cisco.com> References: <7892795E1A87F04CADFCCF41FADD00FC011DD0E0@xmb-ams-337.emea.cisco.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (powerpc-apple-darwin8.1.0) MULE/5.0 (SAKAKI) Organization: Keio University/WIDE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: mip6@ietf.org, Monami6 BOF proposal 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 Hi Pascal and Thierry I basically agree with Pascal. HAHA supports many features which is not all related to multihoming. Since some people in MIP6/NEMO WG is interested in HAHA, we should keep working this at these WGs. We can decide whether we move HAHA to Monami after approvals of monami WG. regards, ryuji At Tue, 26 Jul 2005 16:38:43 +0200, Pascal Thubert (pthubert) wrote: > > Well... These arguments are valid. > > OTOH, HAHA is about getting rid of the home link, placing MIP/NEMO at > L3. > The objectives are mostly route optimization and load balancing. In > that, it seems a bit far from MONAMI. But there's no NEMO RO WG/BOF ;) > > I think it's a matter of having the right people discuss the subject. If > we can raise interest in MONAMI, then MONAMI is the right place. > > Pascal > >-----Original Message----- > >From: monami6-bounces@lists.ietf.org > [mailto:monami6-bounces@lists.ietf.org] On Behalf Of Thierry > >Ernst > >Sent: Tuesday, July 26, 2005 5:12 AM > >To: mip6@ietf.org; ml-monami6 > >Subject: [Monami6] Re: [Mip6] HAHA and HA reliability > > > > > >Hi, > > > >On Mon, 25 Jul 2005 14:10:59 -0700 > >Vijay Devarapalli wrote: > > > >> hi folks, > >> > >> since we are on the topic of HA reliability, we recently revised > >> and submitted a draft on HA reliability based on the HAHA > >> protocol. you can find it at > >> > http://www.ietf.org/internet-drafts/draft-devarapalli-mip6-nemo-local-ha > ha-00.txt > >> It has been completely re-written. it also has a section on using > >> VRRPv6 with HAHA. comments are welcome. > >> > >> HAHA in general supports placing HAs in geographically separate > >> locations while still serving the same home prefix. this is > >> described in > >> > http://www.mobilenetworks.org/nemo/drafts/draft-thubert-nemo-global-haha > -00.txt > >> > >> the HAHA messages are defined in > >> > http://www.mobilenetworks.org/nemo/drafts/draft-wakikawa-mip6-nemo-haha- > spec-00.txt > > > >In the case where HA are placed in geographically separate locations, > >this is indeed a multihoming configuration as defined in > >draft-montavont-mobileip-multihoming-pb-statement (for host mobility) > >and draft-ietf-nemo-multihoming-issues (for network mobility). > > > >As such, and since it covers for MIP6 and NEMO, I think it falls into > >the scope of the Monami6 BOF (http://www.nautilus6.org/ietf). However, > >we have not yet initiated the discussion on this topic on the Monami6 > ML > >and it may be too much discussion for the BOF. If Monami6 can > >become a WG, I think it should be added in our charter as a Monami6 WG > >item. > > > >Thierry > > > >_______________________________________________ > >Monami6 mailing list > >Monami6@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/monami6 > > _______________________________________________ > Monami6 mailing list > Monami6@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/monami6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Jul 26 20:57:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxaEf-0006T9-Is; Tue, 26 Jul 2005 20:57:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxaEd-0006Sw-Iy for mip6@megatron.ietf.org; Tue, 26 Jul 2005 20:57:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08906 for ; Tue, 26 Jul 2005 20:57:21 -0400 (EDT) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Dxajh-0008QN-G2 for mip6@ietf.org; Tue, 26 Jul 2005 21:29:35 -0400 Received: (qmail 7280 invoked from network); 27 Jul 2005 00:56:58 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;5e4ff05b74e6714b79e7b1d57af02cf9; Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 27 Jul 2005 00:56:57 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Wed, 27 Jul 2005 08:55:29 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-7" Content-Transfer-Encoding: 7bit content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 27 Jul 2005 08:55:27 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38591395@hcbjdc2> Thread-Topic: +AFs-Mip6+AF0- Bootstrapping DT solution draft Thread-Index: AcWR1DPAdeqT9xSuQK6RHQeVGen6fQAc2IjwAAB70wA= From: "+ACI-DENG, HUI -HCHBJ+ACI-" To: "+ACI-DENG, HUI -HCHBJ+ACI-" , "James Kempf" X-OriginalArrivalTime: 27 Jul 2005 00:55:29.0593 (UTC) FILETIME=[E23C5290:01C59245] X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1122425817.767-7277-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.02/0.14 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Spam-Score: 0.3 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Content-Transfer-Encoding: 7bit Cc: Gerardo.Giaretta@TILAB.COM, mip6@ietf.org Subject: [Mip6] RE: +AFs-Mip6+AF0- Bootstrapping DT solution draft 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 What I mean is that the operater can use the SRV record preference field for long term load balancing, and connection refusal for short term load balancing, due to flash crowds and such. +AD0APQA+- Here do you mean that HA will refuse all of IKE signal or MIP6 bootstrap IKE signal? Since such short term loads tend to be rare in a properly provisioned network, I see no problem with connection refusal requiring more time on the part of the MN, since it should not happen often (if it does, the operater has a provisioning problem, and better buy a couple more HAs). I believe that the DNS is perfectly fine for bootstrapping. Every other service on the Internet uses it, there's no reason why Mobile IP can't use it too. +AD0APQA+- Agree I think the solution outlined in the bootstrapping draft is just fine, and aligns mobility service discovery consistently with the general Internet service architecture model, for the split scenerio case. +AD0APQA+- We think HA assignment in the current split boostrap which you described here can not be said simple and efficient. Moreover, this procedure of HA assignment has not yet been authorized by any network entity. For the integrated scenerio case, other solutions may be somewhat more optimal on a couple of metrics. The DT is looking at that case right now. +AD0APQA+- Anyway, we will continue to write home agent initiate bootstrap also in the integrated scenario. since this scenario has not yet been considered. -Hui ----- Original Message ----- From: +ACI-DENG, HUI -HCHBJ+ACI- +ADw-hdeng+AEA-hitachi.cn+AD4- To: +ACI-James Kempf+ACI- +ADw-Kempf+AEA-docomolabs-usa.com+AD4AOw- +ACI-Li Qin+ACI- +ADw-liqin+AEA-cse.buaa.edu.cn+AD4- Cc: +ACI-Gerardo Giaretta+ACI- +ADw-Gerardo.Giaretta+AEA-TILAB.COM+AD4AOw- +ADw-mip6+AEA-ietf.org+AD4- Sent: Sunday, July 24, 2005 9:09 AM Subject: RE: +AFs-Mip6+AF0- Bootstrapping DT solution draft The SRV record contains information that the operator can use to establish a preference ordering on the servers for clients. That said, I don't believe it is intended to provide fast, real time information about preferences, say on the order of seconds., but more over longer periods, since dynamic DNS updates require some time to propagate, and it would also not be such a good idea to burden the DNS server with having to handle such frequent updates. +AD0APQA+- Do you mean that DNS is not suitable for dynamical home agent assignment in this bootstrap solution? Its also possible for the HAs themselves to refuse new IKEv2 connections if they are loaded. +AD0APQA+- We guess here need more discussion. Since the MN will have a list of HAs, it will just roll over to trying the next one. +AD0APQA+- Do you think this way is very efficient? The HAs could co-operate somehow (maybe using a protocol like HAHA?) to establish which HA should be taking new connections. This could be used to perform finer grained load balancing. +AD0APQA+- Do you mean that home agent assignment should be in another document, out of bootstrap? -Hui ----- Original Message ----- From: +ACI-Li Qin+ACI- +ADw-liqin+AEA-cse.buaa.edu.cn+AD4- To: +ACI-James Kempf+ACI- +ADw-Kempf+AEA-docomolabs-usa.com+AD4- Cc: +ACI-Li Qin+ACI- +ADw-liqin+AEA-cse.buaa.edu.cn+AD4AOw- +ACI-Gerardo Giaretta+ACI- +ADw-Gerardo.Giaretta+AEA-TILAB.COM+AD4AOw- +ADw-mip6+AEA-ietf.org+AD4- Sent: Thursday, July 21, 2005 8:33 AM Subject: Re: +AFs-Mip6+AF0- Bootstrapping DT solution draft +AD4- In my opinion I think its more like a HA discovery than HA assignment. +AD4- +AD4- If multiple HAs are deployed in home network, is it possible to assign +AD4- a HA according to the user's profile, or according to current load of +AD4- the HAs in this solution? +AD4- +AD4- James Kempf wrote: +AD4- +AD4- The home DNS server can contain multiple HA addresses in the SRV +AD4- +AD4- record. +AD4- +AD4- +AD4- +AD4- jak +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- ----- Original Message ----- +AD4- +AD4- From: +ACI-Li Qin+ACI- +ADw-liqin+AEA-cse.buaa.edu.cn+AD4- +AD4- +AD4- To: +ACI-Gerardo Giaretta+ACI- +ADw-Gerardo.Giaretta+AEA-TILAB.COM+AD4- +AD4- +AD4- Cc: +ADw-mip6+AEA-ietf.org+AD4- +AD4- +AD4- Sent: Wednesday, July 20, 2005 1:11 AM +AD4- +AD4- Subject: Re: +AFs-Mip6+AF0- Bootstrapping DT solution draft +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4APg-I guess that multiple home agents related issues, such as dynamic +AD4- +AD4APg-home agent assignment, have not been considered in this draft. +AD4- +AD4APg- +AD4- +AD4APg-if so , can you tell us the reason? +AD4- +AD4APg- +AD4- +AD4APg-Gerardo Giaretta wrote: +AD4- +AD4APg- +AD4- +AD4APgA+-Dear WG, +AD4- +AD4APgA+- +AD4- +AD4APgA+-the bootstrapping DT has submitted a solution draft. The document +AD4- +AD4APgA+-defines how a Mobile Node can bootstrap MIPv6 operations from +AD4- +AD4APgA+-non-topological information and pre-configured security +AD4- +AD4APgA+-credentials. The +AD4- +AD4APgA+-solution solves the boostrapping problem when the Mobile Node's mobility +AD4- +AD4APgA+-service is authorized by a different service provider than basic network +AD4- +AD4APgA+-access (i.e. split scenario). +AD4- +AD4APgA+- +AD4- +AD4APgA+-The draft can be found at +AD4- +AD4APgA+-http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapping-spl +AD4APgA+-it- +AD4- +AD4APgA+-00.txt. +AD4- +AD4APgA+- +AD4- +AD4APgA+-The DT is currently working on optimized solutions for integrated +AD4- +AD4APgA+-scenario (i.e. mobility service and basic network access are +AD4- +AD4APgA+-authorized by the same entity). +AD4- +AD4APgA+- +AD4- +AD4APgA+-Please read the document and provide comments. +AD4- +AD4APgA+- +AD4- +AD4APgA+-Thanks and regards, +AD4- +AD4APgA+- +AD4- +AD4APgA+---Gerardo (DT editor) +AD4- +AD4APgA+- +AD4- +AD4APgA+- +AD4- +AD4APgA+- +AD4- +AD4APgA+- +AD4- +AD4APgA+- +AD4- +AD4APgA+- +AD4- +AD4APgA+- +AD4- +AD4APgA+- +AD4- +AD4APgA+-Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia +AD4- +AD4- +AD4- +AD4- S.p.A. +AD4- +AD4- +AD4- +AD4APgA+AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0- +AD4- +AD4APgA+AD0- +AD4- +AD4APgA+-CONFIDENTIALITY NOTICE +AD4- +AD4APgA+-This message and its attachments are addressed solely to the +AD4- +AD4APgA+-persons above and may contain confidential information. If you have +AD4- +AD4APgA+-received the message in error, be informed that any use of the +AD4- +AD4APgA+-content hereof is prohibited. Please return it immediately to the +AD4- +AD4APgA+-sender and delete the message. Should you have any questions, +AD4- +AD4APgA+-please send an e+AF8-mail to MailAdmin+AEA-tilab.com. Thank you +AD4- +AD4APgA+AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0APQA9AD0- +AD4- +AD4APgA+AD0- +AD4- +AD4APgA+- +AD4- +AD4APgA+AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- +AD4- +AD4APgA+-Mip6 mailing list +AD4- +AD4APgA+-Mip6+AEA-ietf.org +AD4- +AD4APgA+-https://www1.ietf.org/mailman/listinfo/mip6 +AD4- +AD4APg- +AD4- +AD4APgBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8- +AD4- +AD4APg-Mip6 mailing list +AD4- +AD4APg-Mip6+AEA-ietf.org +AD4- +AD4APg-https://www1.ietf.org/mailman/listinfo/mip6 +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AD4- +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- Mip6 mailing list Mip6+AEA-ietf.org https://www1.ietf.org/mailman/listinfo/mip6 +AF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXwBfAF8AXw- Mip6 mailing list Mip6+AEA-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 Jul 27 05:55:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxidj-00078F-2B; Wed, 27 Jul 2005 05:55:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxidg-00078A-N8 for mip6@megatron.ietf.org; Wed, 27 Jul 2005 05:55:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11705 for ; Wed, 27 Jul 2005 05:55:45 -0400 (EDT) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxj8u-000692-FX for mip6@ietf.org; Wed, 27 Jul 2005 06:28:05 -0400 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IKA00E0G639TG@dns1.cselt.it> for mip6@ietf.org; Wed, 27 Jul 2005 11:52:21 +0200 (MEST) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Wed, 27 Jul 2005 11:58:47 +0200 Date: Wed, 27 Jul 2005 11:55:16 +0200 From: Gerardo Giaretta Subject: RE: [Mip6] Bootstrapping DT solution draft To: Rafa Marin Lopez Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Bootstrapping DT solution draft thread-index: AcWO6crwjDOswmyNTJOV2AuCRbjhqwDpRSjw Content-Class: urn:content-classes:message X-OriginalArrivalTime: 27 Jul 2005 09:58:47.0593 (UTC) FILETIME=[C8286190:01C59291] X-Spam-Score: 0.0 (/) X-Scan-Signature: edafdfdf1a7c40feead31b1909b66c9e 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 Hi Rafa,=20 >=20 > > > >>Another related question is about authorization. Under my=20 > >>point of view > >>, MSP's AAA server is the entity that finally takes=20 > decision about if > >>the mobility service is authorized or not. MSA's AAA server=20 > could send > >>to MSP's AAA some kind of evidences or attributes related with > >>authenticated user.Following these attributes and internal policies > >>MSP's AAA server takes a final decision. > >> > >> =20 > >> > > > >I tend to agree. This is the reason why AAA server of the=20 > MSP should be > >involved. I think that these issues should be covered by > >draft-mip6-aaa-ha-goals. > > > <$rafa> Well... in the MIP6 bootstrapping draft , you mention=20 > that MSA=20 > is giving authorization. > However if you agree that MSP can be involved in the=20 > authorization , I=20 > don't see why it should explained > in draft-mip6-aaa-ha-goals. >=20 MSA gives the authorization based on the user profile. This is the role of the MSA. The AAA-MSP acts as a AAA proxy and, as for network access, it can have an active role in this process. However, usually this is based on roaming agreements between the providers. > > > >>In particular , I was thinking a similar model than it is shown in > >>Diameter EAP application I-D (Scenario 3: Direct EAP,=20 > >>authorization via > >>agents). > >> > >>Note this dicussion could be also valid for other services=20 > >>(i.e. network > >>access service). > >> > >> =20 > >> > > > >I tend to agree also here. The MSP might need to add some=20 > authorization > >AVPs.=20 > > > <$Rafa> I agree that AVPs or specific information could be placed on=20 > draf-ietf-aaa-ha-goals but to say if MSP is involved in=20 > authorization or not > could be said in bootstrapping solution I-D. > We may add some text in the draft to clarify the role of the AAA-MSP. But I would keep the distinction between MSA and MSP with the MSA that authorized MIPv6 service based on the user profile.=20 > >>> =20 ~snip~ > >>> > >><$Rafa> Here appears "MSA to grant the service" and in page=20 > >>10 section=20 > >>5.1.1 > >>"MSP granting the mobility service". Would it not be in the=20 > first case > >>"MSP to grant the service" too? > >> > >> =20 > >> > > > >Yes. What about the following text? > > > >" > >Authentication and Authorization with MSA. The user must be > >authenticated in order for the MSP to grant the service.=20 > Since the user > >credentials can be verified only by the MSA, this=20 > authorization step is > >performed by the MSA. Moreover, the mobility service must be=20 > explicitly > >authorized by the MSA based on the user's profile. These=20 > operations are > >performed in different ways depending on the credentials used by the > >Mobile Node during the IKEv2 peer authentication and on the backend > >infrastructure (PKI or AAA).=20 > > =20 > > > >" > > =20 > > > <$Rafa> As you can see, this text still state MSA is explicitly doing=20 > the authorization and MSP is not involved. MSA MUST explicitly do the authorization. MSP MAY be involved depending on the scenario and the roaming agreements between the operators. Do you agree on that? > So I understand from this that MSP's AAA server is only doing routing. >=20 In my view usually it performs only AAA routing since based on roaming agreements the authorization is implicit. > > > > =20 > >> =20 > >> > >>>the Mobile Node including the DNS Update mobility option with the=20 > >>>correct value in the Status field (see section 8.1). > >>>This procedure can be performed directly by the Home Agent=20 > >>> =20 > >>> > >>if the Home=20 > >> =20 > >> > >>>Agent has a security association with the domain specified in the=20 > >>>Mobile Node's FQDN. > >>> > >>> > >>> =20 > >>> > >><$Rafa> Why don't MSP's AAA server could do DNS update=20 > >>instead of MSA's > >>AAA server?? > >> > >> =20 > >> > > > >It could. But I don't see a reason for that. Do you see any=20 > issue with > >the current solution?=20 > > =20 > > > <%Rafa> if MSP provides the Home Agent , and Home Agent gives a Home=20 > Address... would not be more coherent that MSP's AAA server=20 > did this task? >=20 It depends on the FQDN used by the MN. If the FQDN belongs to the MSA< the MSA MUST do that since the MSP AAA server may not share a SA with the DNS server of the MSA. Regards, --Gerardo > > =20 > > > >>>On the other hand, if the Mobile Node wants to be reachable=20 > >>> =20 > >>> > >>through a=20 > >> =20 > >> > >>>FQDN that belongs to the MSA, the Home Agent and the DNS=20 > >>> =20 > >>> > >>server that=20 > >> =20 > >> > >>>must be updated belong to different administrative domain.=20 > >>> =20 > >>> > >>In this G.=20 > >> =20 > >> > >>>Giaretta, Ed. Expires December 22, 2005 [Page 16] > >>> > >>> > >>> > >>> > >>> > >>> > >>>Internet-Draft MIPv6 bootstrapping in split scenario June 2005 > >>>case the Home Agent may not share a security association=20 > >>> =20 > >>> > >>with the DNS=20 > >> =20 > >> > >>>server and the DNS entry update can be performed by the AAA=20 > >>> =20 > >>> > >>server of=20 > >> =20 > >> > >>>the MSA. In order to accomplish this, the Home Agent sends=20 > >>> =20 > >>> > >>to the AAA=20 > >> =20 > >> > >>>server the FQDN-HoA pair through the AAA protocol. This message is=20 > >>>proxied by the AAA infrastructure of the MSP and is=20 > received by the=20 > >>>AAA server of the MSA. The AAA server of the MSA perform the DNS=20 > >>>update based on [14]. The detailed description of the=20 > communication=20 > >>>between Home Agent and AAA is out of the scope of this draft. More=20 > >>>details are provided in [12]. > >>> > >>> > >>> =20 > >>> > >> > >> > >> =20 > >> > >>>9. Security Considerations > >>>9.1. HA Address Discovery > >>>Use of DNS for address discovery carries certain security=20 > >>> =20 > >>> > >>risks. DNS=20 > >> =20 > >> > >>>transactions in the Internet are typically done without any=20 > >>>authentication of the DNS server by the client or of the=20 > >>> =20 > >>> > >>client by the=20 > >> =20 > >> > >>>server. There are two risks involved: > >>>1) A legitimate client obtains a bogus Home Agent address=20 > >>> =20 > >>> > >>from a bogus=20 > >> =20 > >> > >>>DNS server. This is sometimes called a "pharming" attack, > >>>2) An attacking client obtains a legitimate Home Agent=20 > >>> =20 > >>> > >>address from a=20 > >> =20 > >> > >>>legitimate server. > >>> > >>> =20 > >>> > >><$Rafa>I have a comment regarding this case 1): I think any=20 > >>user already > >>authenticated and authorized to use mobility service could launch > >>this attack becuase user already owns a valid certificate and=20 > >>therefore > >>a legitimate client could verify this certificate. The issue is this > >>user is NOT AUTHORIZED to be a Home Agent. what do you think?? > >> > >> =20 > >> > > > >I don't get your point. Which scenario are you referring to? Are you > >assuming only certificates is used or also AAA? > > =20 > > > <$Rafa> I am assuming only certificates. >=20 >=20 > > =20 > > > >>>The risk in Case 1 is mitigated because the Mobile Node is=20 > >>> =20 > >>> > >>required to=20 > >> =20 > >> > >>>conduct an IKE transaction with the Home Agent prior to=20 > >>> =20 > >>> > >>performing a=20 > >> =20 > >> > >>>Binding Update to establish Mobile IPv6 service. According to the=20 > >>>IKEv2 specification [7], the responder must present the=20 > >>> =20 > >>> > >>initiator with=20 > >> =20 > >> > >>>a valid certificate containing the responder's public key, and the=20 > >>>responder to initiator IKE_AUTH message must be protected with an=20 > >>>authenticator calculated using the public key in the certificate.=20 > >>>Thus, an attacker would have to set up both a bogus DNS=20 > >>> =20 > >>> > >>server and a=20 > >> =20 > >> > >>>bogus Home Agent, and provision the Home Agent with a=20 > >>> =20 > >>> > >>certificate that=20 > >> =20 > >> > >>>a victim Mobile Node could verify. If the Mobile Node can=20 > >>> =20 > >>> > >>detect that=20 > >> =20 > >> > >>>the certificate is not trustworthy, the attack will be=20 > >>> =20 > >>> > >>foiled when the=20 > >> =20 > >> > >>>Mobile Node attempts to set up the IKE SA. > >>> > >>> > >>> =20 > >>> > >> > >> > >> =20 > >> > >>>9.5. Dynamic DNS Update > >>>Mobile IPv6 bootstrapping recommends the Home Agent to update the=20 > >>>Mobile Node's FQDN with a dynamically assigned home address rather=20 > >>>than have the Mobile Node itself do it (see Section 6 above). This=20 > >>>choice was motivated by a concern for preventing redirection-based=20 > >>>flooding attacks (see draft-ietf-mip6-ro-sec [19] for more=20 > >>> =20 > >>> > >>information=20 > >> =20 > >> > >>>about redirection-based flooding attacks and the role=20 > >>> =20 > >>> > >>preventing them=20 > >> =20 > >> > >>>played in the design of Mobile IPv6 route optimization security).=20 > >>>Exactly as for route optimization, it is possible for a=20 > >>> =20 > >>> > >>node that is=20 > >> =20 > >> > >>>the legitimate owner of a DNS FQDN - in the sense that it has a=20 > >>>security association with the DNS server allowing it to perform=20 > >>>dynamic DNS update of its FQDN - to bind its FQDN to the=20 > >>> =20 > >>> > >>address of a=20 > >> =20 > >> > >>>victim, then redirect large volumes of traffic at the victim. The=20 > >>>attack may be propagated without the owner's knowledge, for=20 > >>> =20 > >>> > >>example,=20 > >> =20 > >> > >>>if the node is compromised by malware, or it may be=20 > >>> =20 > >>> > >>intentional if the=20 > >> =20 > >> > >>>node itself is the attacker. > >>>While it is possible to prevent redirection attacks=20 > through ingress=20 > >>>filtering on access routers, ISPs have little or no incentive to=20 > >>>deploy ingress filtering. In some cases, if an attack could=20 > >>> =20 > >>> > >>result in=20 > >> =20 > >> > >>>substantial financial gain, it is even possible that a=20 > >>> =20 > >>> > >>corrupt ISP may=20 > >> =20 > >> > >>>have an incentive not to deploy ingress filters such as has=20 > >>> =20 > >>> > >>been the=20 > >> =20 > >> > >>>case for spam. Consequently, the security for dynamic=20 > >>> =20 > >>> > >>Mobile Node FQDN=20 > >> =20 > >> > >>>update has been assigned to the Home Agent, where active network=20 > >>>administration and vigilant defense measures are more=20 > >>> =20 > >>> > >>likely to (but=20 > >> =20 > >> > >>>G. Giaretta, Ed. Expires December 22, 2005 [Page 25] > >>> > >>> > >>> > >>> > >>> > >>> > >>>Internet-Draft MIPv6 bootstrapping in split scenario June 2005 > >>>are not assured of) mitigating problems, and the owner of=20 > >>> =20 > >>> > >>the Mobile=20 > >> =20 > >> > >>>Node is more likely to detect a problem if it occurs. > >>>If a Home Agent performs dynamic DNS update on behalf of=20 > the Mobile=20 > >>>Node directly with the DNS server, the Home Agent MUST have=20 > >>> =20 > >>> > >>a security=20 > >> =20 > >> > >>>association of some type with the DNS server. The security=20 > >>> =20 > >>> > >>association=20 > >> =20 > >> > >>>MAY be established either using DNSSEC [16] or TSIG/TKEY=20 > >>> =20 > >>> > >>[17][18]. A=20 > >> =20 > >> > >>>security association is required even if the DNS server is=20 > >>> =20 > >>> > >>in the same=20 > >> =20 > >> > >>>administrative domain as the Home Agent. The security association=20 > >>>SHOULD be separate from the security associations used for other=20 > >>>purposes, such as AAA. > >>>In the case where the Mobility Service Provider is=20 > >>> =20 > >>> > >>different from the=20 > >> =20 > >> > >>>Mobility Service Authorizer, the network administrators=20 > may want to=20 > >>>limit the number of cross-administrative domain security=20 > >>> =20 > >>> > >>associations.=20 > >> =20 > >> > >>>If the Mobile Node's FQDN is in the Mobility Service Authorizer's=20 > >>>domain, since a security association for AAA signaling involved in=20 > >>>mobility service authorization is required in any case, the=20 > >>> =20 > >>> > >>Home Agent=20 > >> =20 > >> > >>>can send the Mobile Node's FQDN to the AAA server under the HA-AAA=20 > >>>server security association, > >>> =20 > >>> > >>$Rafa> MSA's AAA Server?? or MSP's AAA server?? > >> > >> =20 > >> > > > >To the MSA's AAA server through the MSP's AAA server. The MSA's AAA > >server updates the MSA's DNS server.=20 > > > > =20 > > > >>So far, these are my comments. > >> > >> =20 > >> > > > >Thanks again, > > > >--Gerardo > > > > =20 > > > >>Regards. > >> > >>--=20 > >>------------------------------------------------------ > >>Rafael Marin Lopez > >>Faculty of Computer Science-University of Murcia > >>30071 Murcia - Spain > >>Telf: +34968367645 e-mail: rafa@dif.um.es > >>------------------------------------------------------ > >> > >> > >> > >> > >> > >> > >> > >> > >>Gerardo Giaretta wrote: > >> > >> =20 > >> > >>>Dear WG, > >>> > >>>the bootstrapping DT has submitted a solution draft. The document > >>>defines how a Mobile Node can bootstrap MIPv6 operations from > >>>non-topological information and pre-configured security=20 > >>> =20 > >>> > >>credentials. The > >> =20 > >> > >>>solution solves the boostrapping problem when the Mobile=20 > >>> =20 > >>> > >>Node's mobility > >> =20 > >> > >>>service is authorized by a different service provider than=20 > >>> =20 > >>> > >>basic network > >> =20 > >> > >>>access (i.e. split scenario). > >>> > >>>The draft can be found at > >>> > >>> =20 > >>> > >>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrapp > >>ing-split- > >> =20 > >> > >>>00.txt. > >>> > >>>The DT is currently working on optimized solutions for integrated > >>>scenario (i.e. mobility service and basic network access=20 > >>> =20 > >>> > >>are authorized > >> =20 > >> > >>>by the same entity). > >>> > >>>Please read the document and provide comments. > >>> > >>>Thanks and regards, > >>> > >>>--Gerardo (DT editor) > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>Gruppo Telecom Italia - Direzione e coordinamento di=20 > Telecom Italia=20 > >>>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=20 > the persons > >>>above and may contain confidential information. If you=20 > have received > >>>the message in error, be informed that any use of the=20 > content hereof > >>>is prohibited. Please return it immediately to the sender=20 > and delete > >>>the message. Should you have any questions, please send an=20 > 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 > >>> > >>> > >>> > >>> > >>> =20 > >>> > >> > >> > >>Gerardo Giaretta wrote: > >> > >> =20 > >> > >>>Dear WG, > >>> > >>>the bootstrapping DT has submitted a solution draft. The document > >>>defines how a Mobile Node can bootstrap MIPv6 operations from > >>>non-topological information and pre-configured security=20 > >>> =20 > >>> > >>credentials. The > >> =20 > >> > >>>solution solves the boostrapping problem when the Mobile=20 > >>> =20 > >>> > >>Node's mobility > >> =20 > >> > >>>service is authorized by a different service provider than=20 > >>> =20 > >>> > >>basic network > >> =20 > >> > >>>access (i.e. split scenario). > >>> > >>>The draft can be found at > >>>http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap > >>> =20 > >>> > >>ping-split- > >> =20 > >> > >>>00.txt. > >>> > >>>The DT is currently working on optimized solutions for integrated > >>>scenario (i.e. mobility service and basic network access are=20 > >>> =20 > >>> > >>authorized > >> =20 > >> > >>>by the same entity). > >>> > >>>Please read the document and provide comments. > >>> > >>>Thanks and regards, > >>> > >>>--Gerardo (DT editor) > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>Gruppo Telecom Italia - Direzione e coordinamento di Telecom=20 > >>> =20 > >>> > >>Italia S.p.A. > >> =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=3D=3D=3D=3D > >>>CONFIDENTIALITY NOTICE > >>>This message and its attachments are addressed solely to=20 > the persons > >>>above and may contain confidential information. If you=20 > have received > >>>the message in error, be informed that any use of the=20 > content hereof > >>>is prohibited. Please return it immediately to the sender=20 > and delete > >>>the message. Should you have any questions, please send an=20 > 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 > >>> > >>> > >>> > >>> =20 > >>> > >>--=20 > >>------------------------------------------------------ > >>Rafael Marin Lopez > >>Faculty of Computer Science-University of Murcia > >>30071 Murcia - Spain > >>Telf: +34968367645 e-mail: rafa@dif.um.es > >>------------------------------------------------------ > >> > >> > >> =20 > >> > > > > > >Gruppo Telecom Italia - Direzione e coordinamento di Telecom=20 > 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 > > > > > > =20 > > >=20 >=20 > --=20 > ------------------------------------------------------ > Rafael Marin Lopez > Faculty of Computer Science-University of Murcia > 30071 Murcia - Spain > Telf: +34968367645 e-mail: rafa@dif.um.es > ------------------------------------------------------ >=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=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 Jul 27 08:58:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlUn-00070Z-ME; Wed, 27 Jul 2005 08:58:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlUk-00070F-MI for mip6@megatron.ietf.org; Wed, 27 Jul 2005 08:58:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24701 for ; Wed, 27 Jul 2005 08:58:44 -0400 (EDT) Received: from mx2.buaa.edu.cn ([219.239.227.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxlzt-000437-GH for mip6@ietf.org; Wed, 27 Jul 2005 09:31:04 -0400 Received: from mx1.buaa.edu.cn (mx1.buaa.edu.cn [192.168.128.5]) by mx2.buaa.edu.cn (Postfix) with ESMTP id 60A1937F65 for ; Wed, 27 Jul 2005 20:57:57 +0800 (CST) Received: from [210.76.115.36] by 10.0.0.130 with StormMail ESMTP id 53198.6155546149; Wed, 27 Jul 2005 21:29:28 +0800 (CST) Message-ID: <42E784B8.6080505@cse.buaa.edu.cn> Date: Wed, 27 Jul 2005 20:57:28 +0800 From: Li Qin User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Bootstrapping DT solution draft References: <200507251413.KAA22955@ietf.org> <02cd01c591c6$1c870510$626015ac@dcml.docomolabsusa.com> In-Reply-To: <02cd01c591c6$1c870510$626015ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , mip6@ietf.org, "DENG, HUI -HCHIBJ" , Vijay Devarapalli 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 > Can you say why? > > If the MSP != MSA, then it is the MSA's AAA server that is authorizing the > mobility service, and the AAA_MSA is in a separate domain. Thus, the AAA_MSA > has no knowledge of the MSP's toplogy. We think MSP also need to authorize its own HA to mobility subscriber. -Qin _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 27 09:07:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxldG-0001mD-Tu; Wed, 27 Jul 2005 09:07:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxldE-0001kg-SN for mip6@megatron.ietf.org; Wed, 27 Jul 2005 09:07:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25778 for ; Wed, 27 Jul 2005 09:07:30 -0400 (EDT) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxm8T-0004Rl-BR for mip6@ietf.org; Wed, 27 Jul 2005 09:39:51 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 3FD00809D; Wed, 27 Jul 2005 15:07:12 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1DxlcG-0002hH-CZ; Wed, 27 Jul 2005 15:06:32 +0200 Date: Wed, 27 Jul 2005 15:06:32 +0200 From: Julien Bournelle To: Li Qin Subject: Re: [Mip6] Bootstrapping DT solution draft Message-ID: <20050727130632.GQ9706@ipv6-3.int-evry.fr> References: <200507251413.KAA22955@ietf.org> <02cd01c591c6$1c870510$626015ac@dcml.docomolabsusa.com> <42E784B8.6080505@cse.buaa.edu.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42E784B8.6080505@cse.buaa.edu.cn> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Gerardo Giaretta , mip6@ietf.org, James Kempf , "DENG, HUI -HCHIBJ" , Vijay Devarapalli 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 Hi, On Wed, Jul 27, 2005 at 08:57:28PM +0800, Li Qin wrote: > > Can you say why? > > > > If the MSP != MSA, then it is the MSA's AAA server that is authorizing the > > mobility service, and the AAA_MSA is in a separate domain. Thus, the AAA_MSA > > has no knowledge of the MSP's toplogy. > We think MSP also need to authorize its own HA to mobility subscriber. I'm not sure to well understand your point. Can you clarify it ? thanks, Julien > > -Qin > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 -- julien.bournelle at int-evry.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Jul 27 11:15:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxndG-0005jh-S1; Wed, 27 Jul 2005 11:15:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxndF-0005jC-5T for mip6@megatron.ietf.org; Wed, 27 Jul 2005 11:15:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06458 for ; Wed, 27 Jul 2005 11:15:38 -0400 (EDT) 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.43) id 1Dxo8V-0000Gl-8K for mip6@ietf.org; Wed, 27 Jul 2005 11:48:00 -0400 Message-ID: <079801c592be$09aef670$626015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Li Qin" References: <200507251413.KAA22955@ietf.org> <02cd01c591c6$1c870510$626015ac@dcml.docomolabsusa.com> <42E784B8.6080505@cse.buaa.edu.cn> Subject: Re: [Mip6] Bootstrapping DT solution draft Date: Wed, 27 Jul 2005 08:15:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , mip6@ietf.org, "DENG, HUI -HCHIBJ" , Vijay Devarapalli 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 Why do you think that the provision of the HA address must be authorized? jak ----- Original Message ----- From: "Li Qin" To: "James Kempf" Cc: "Yong" ; "Vijay Devarapalli" ; "Li Qin" ; "Gerardo Giaretta" ; ; "DENG, HUI -HCHIBJ" Sent: Wednesday, July 27, 2005 5:57 AM Subject: Re: [Mip6] Bootstrapping DT solution draft > > Can you say why? > > > > If the MSP != MSA, then it is the MSA's AAA server that is authorizing the > > mobility service, and the AAA_MSA is in a separate domain. Thus, the AAA_MSA > > has no knowledge of the MSP's toplogy. > We think MSP also need to authorize its own HA to mobility subscriber. > > -Qin > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 28 13:40:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCNO-0004Z8-KK; Thu, 28 Jul 2005 13:40:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyCNM-0004WI-7U; Thu, 28 Jul 2005 13:40:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15251; Thu, 28 Jul 2005 13:40:52 -0400 (EDT) Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyCsq-0004gb-HG; Thu, 28 Jul 2005 14:13:30 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6SHYu4N020578; Thu, 28 Jul 2005 20:34:58 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jul 2005 20:40:31 +0300 Received: from mvebe101.NOE.Nokia.com ([172.19.64.23]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jul 2005 12:40:28 -0500 Received: from 205.226.2.40 ([205.226.2.40]) by mvebe101.NOE.Nokia.com ([172.19.64.23]) with Microsoft Exchange Server HTTP-DAV ; Thu, 28 Jul 2005 17:40:27 +0000 Received: from vijayd2 by mvebe101.americas.nokia.com; 28 Jul 2005 10:40:27 -0700 From: Vijay Devarapalli To: mip6@ietf.org, nemo@ietf.org Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 28 Jul 2005 10:40:27 -0700 Message-Id: <1122572427.30127.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-16) X-OriginalArrivalTime: 28 Jul 2005 17:40:28.0697 (UTC) FILETIME=[71B72890:01C5939B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Subject: [Mip6] v4 traversal slides 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 [I am resending. apologize if you get multiple copies.] hi all, here are the slides that will be presented as a status update from the mip6trans design team next week at the MIP6 and NEMO WG meetings. http://people.nokia.net/vijayd/mip6trans/ietf63_mip6_mip6trans.pdf unfortunately, we didn't have enough time to submit an internet draft. the above slideset talks about the scenarios the design team is going to solve. it also lists the solution requirements. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 28 20:15:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyIWq-0006eh-DA; Thu, 28 Jul 2005 20:15:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyIWp-0006e5-22; Thu, 28 Jul 2005 20:15:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08642; Thu, 28 Jul 2005 20:15:05 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyJ2M-0006Cf-Su; Thu, 28 Jul 2005 20:47:44 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j6SNhlC13293; Thu, 28 Jul 2005 16:43:47 -0700 X-mProtect: <200507282343> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp162227.americas.nokia.com (10.241.162.227, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdlFPWLl; Wed, 27 Jul 2005 22:23:36 PDT Message-ID: <42E8731A.6000308@iprg.nokia.com> Date: Wed, 27 Jul 2005 22:54:34 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org, nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Subject: [Mip6] v4 traversal slides 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 hi all, here are the slides that will be presented as a status update from the mip6trans design team next week at the MIP6 and NEMO WG meetings. http://people.nokia.net/vijayd/mip6trans/ietf63_mip6_mip6trans.pdf unfortunately, we didnt have enough time to submit an internet draft. the above slideset talks about the scenarios the design team is going to solve. it also lists the solution requirements. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Jul 28 23:36:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyLg8-0002lE-JM; Thu, 28 Jul 2005 23:36:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyLg6-0002l7-6y for mip6@megatron.ietf.org; Thu, 28 Jul 2005 23:36:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17337; Thu, 28 Jul 2005 23:36:51 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyMBe-0002Mg-Mz; Fri, 29 Jul 2005 00:09:33 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6T3VrsY020195; Fri, 29 Jul 2005 06:31:58 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jul 2005 06:35:26 +0300 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jul 2005 22:35:23 -0500 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 28 Jul 2005 22:35:22 -0500 Message-ID: <456943D540CFC14A8D7138E64843F853015A9FE9@daebe101.NOE.Nokia.com> Thread-Topic: Revised MIP6 WG agenda for IETF63 Thread-Index: AcWT7oyUnB1JMgHGQ7GAfGNQR1CP9w== To: X-OriginalArrivalTime: 29 Jul 2005 03:35:23.0916 (UTC) FILETIME=[8DB954C0:01C593EE] X-Spam-Score: 0.3 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: gdommety@cisco.com, mip6@ietf.org Subject: [Mip6] Revised MIP6 WG agenda for IETF63 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 Hello, Below is the revised agenda for the Mobility for IPv6 (MIP6) WG. Please post the same. -Basavaraj =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Agenda of Mobility for IPv6 (mip6) WG meeting at IETF63 Tuesday August 2nd, 2006 1630-1800 Afternoon Session II and 1815-1945 Afternoon Session III (180 Mins) Chair(s): Basavaraj Patil Gopal Dommety ------------------------------------------ 1. Agenda, Bluesheets, Note-takers and Jabber scribes 5 Mins 2. WG documents status update Chairs 15 Mins I-Ds and TAHI test suite update Current WG topics: 3. Mobile IPv6 bootstrapping in split and integrated scenarios=20 draft-ietf-mip6-bootstrapping-split-00 Gerardo Giaretta 20 Mins 4. Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture draft-ietf-mip6-ikev2-ipsec-02 Vijay Devarapalli 15 Mins 5. V4 traversal for IPv6 mobility protocols - Scenarios http://people.nokia.net/vijayd/mip6trans/ietf63_mip6_mip6trans.ppt Design Team 20 Mins I-D: draft-ietf-mip6-dsmip-problem-00 Hesham Soliman 10 Mins =20 =20 6. IP Address Location Privacy and IP Mobility draft-koodli-mip6-location-privacy-00 Rajeev Koodli 10 Mins Topics of relevance to MIP6 protocol, that need consideration: 7. Review summary of I-D draft-irtf-mobopts-ro-enhancements-01 Christian Vogt 10 Mins 8. HA Reliability and load balancing 25 Mins a. draft-deng-mip6-vrrp-homeagent-reliability-00.txt Hui Deng =20 b. draft-devarapalli-mip6-nemo-local-haha-00.txt Vijay Devarapalli c. draft-haley-mip6-ha-switch-00.txt James Kempf d. draft-li-mip6-ha-init-bootstrap-00 Q. Li=09 9. Securing Home Agent List in MIP6 draft-dutta-mip6-ra-00 Sachin Dutta 10 Mins 10. Chairs on new Items a. Application interface to exchange mobility information with Mobility subsystem draft-momose-mip6-mipsock-00 Tsuyoshi MOMOSE 5 Mins b. Care-of Address Test for MIPv6 using a State Cookie draft-dupont-mipv6-rrcookie-01 Francis Dupont 5 Mins 11. Next steps Chairs 10 Mins Total time : 160 Mins Slides of the presentations will be available before the meeting at : http://people.nokia.net/patil/MIP6-IETF63/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Jul 29 03:31:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyPLQ-0003lx-Jx; Fri, 29 Jul 2005 03:31:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyB1I-00038e-5M; Thu, 28 Jul 2005 12:14:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09368; Thu, 28 Jul 2005 12:14:01 -0400 (EDT) Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyBWk-00029a-Ix; Thu, 28 Jul 2005 12:46:37 -0400 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.11/8.12.9) with ESMTP id j6SFtGjJ032170; Thu, 28 Jul 2005 17:55:16 +0200 Received: from sophia.inria.fr (penguin.inria.fr [138.96.240.36]) by sophia.inria.fr (8.12.11/8.12.9) with ESMTP id j6SFp9Bs030775; Thu, 28 Jul 2005 17:51:09 +0200 Message-ID: <42E8FEED.BCDCB162@sophia.inria.fr> Date: Thu, 28 Jul 2005 17:51:09 +0200 From: Sara Alouf X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.23 i686) X-Accept-Language: en, fr, pt MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 To: undisclosed-recipients:; X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (sophia.inria.fr [138.96.64.20]); Thu, 28 Jul 2005 17:54:30 +0200 (MEST) X-Virus-Scanned: by amavisd-new at sophia.inria.fr Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sophia.inria.fr id j6SFtGjJ032170 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 29 Jul 2005 03:31:44 -0400 Subject: [Mip6] Performance 2005: 2nd call for participation 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 Dear colleague, My sincere apologies if you receive multiple copies of this call for participation. Would you please forward it to interested colleagues and students? Thank you, Sara Alouf Publicity chair of Performance 2005 ------------------------------------------------------------------------ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D C A L L for P A R T I C I P A T I O N =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D *** PERFORMANCE 2005 *** The 24th IFIP WG7.3 International Symposium on Computer Performance Modeling, Measurement and Evaluation Juan-les-Pins, France October 3-7, 2005 http://www-sop.inria.fr/maestro/performance2005/ =20 The 24th IFIP WG7.3 International Symposium on Computer Performance Modeling, Measurement and Evaluation (PERFORMANCE 2005) will be held in Juan-les-Pins, France on October 5-7, 2005 (3 full days). The tutorials will be held on October 3 and 4, 2005. The Technical Program has been published (http://www-sop.inria.fr/maestro/performance2005/program.html), including the list of accepted posters. This year, there will be 2 keynote lectures given respectively by Profs. J.-P. Hubaux (EPFL) and P.R. Kumar (University of Illinois at Urbana-Champaign). ** NEW ** There will be a work-in-progress session on Wednesday 5, 2005. Presentations should last 5 to 10 minutes. To register to this session, titles and abstracts are to be sent to the session chair K.Avrachenkov@sophia.inria.fr. Presentations will be selected on a first come first served basis, in the limit of slots available. The conference registration form can be found on the conference website. The early registration deadline is **September 3, 2005**. Student travel grant: A number of student travel grants will be available. Details on how to apply can be found on the conference website. The student grants applications are due by **August 1, 2005**. Conference hotel: Rooms have been reserved at a negotiated rate at Hotel Ambassador 50-52, chemin des Sables B.P. 49 - 06160 Juan-Les-Pins Cedex FRANCE Tel: +33 (0)4 92 93 74 10 - Fax: +33 (0)4 93 67 79 85 e-mail: manager@hotel-ambassadeur.com URL: http://www.hotel-ambassadeur.com/ A list of nearby hotels has been posted on the conference website. ------------------------------------------------------------------------ General Chair: Philippe Nain (INRIA, France) Program Committee Co-Chairs: Cheng-Shang Chang (National Tsing Hua U., Taiwan) Daniel A. Menasc=E9 (George Mason U., USA) Tutorial Co-Chairs: Eitan Altman (INRIA, France) Zhen Liu (IBM T. J. Watson Reseach Center, USA) Proceedings Chair: Rudesindo Nunez Queija (CWI & U. Eindhoven, Netherlands) Posters Chair: Thomas Bonald (France Telecom R&D, France) Local arrangements: Ephie Deriche (INRIA, France) Dany Sergeant (INRIA, France) Finance Chair: Dany Sergeant (INRIA, France) Publicity Chair and webmaster: Sara Alouf (INRIA, France) Corporate Sponsors: IBM T.J. Watson Research Center France Telecom R&D Texas Instruments Institutional Sponsors: IFIP WG7.3 Computer Performance Foundation INRIA Conseil R=E9gional de la R=E9gion Provence-Alpes-C=F4te-d'Azur Conseil G=E9n=E9ral des Alpes-Maritimes ------------------------------------------------------------------------ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Jul 31 06:22:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzAxW-0001eF-7u; Sun, 31 Jul 2005 06:22:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzAxU-0001e7-78; Sun, 31 Jul 2005 06:22:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15275; Sun, 31 Jul 2005 06:22:13 -0400 (EDT) Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzBTV-0004V6-Hq; Sun, 31 Jul 2005 06:55:23 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 54AA7100; Sun, 31 Jul 2005 06:21:55 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 31 Jul 2005 06:21:55 -0400 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 31 Jul 2005 06:21:53 -0400 Message-ID: <936A4045C332714F975800409DE09240B31546@tayexc14.americas.cpqcorp.net> Thread-Topic: Re: [nemo] v4 traversal slides Thread-Index: AcWTnAPnTDagx3irQk+ryYNjYIGNjAAxdmagAFWy4mA= From: "Bound, Jim" To: , X-OriginalArrivalTime: 31 Jul 2005 10:21:55.0108 (UTC) FILETIME=[ACD55E40:01C595B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: Subject: [Mip6] Re: [nemo] v4 traversal slides 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 Folks, I think we need to at least address and discuss the scenario where the HA is on IPv6-Dominant network, meaning IPv4 routing has been shut off per policy of the user on that network. The MN shows up on IPv4-Only access network. Bi-directional commo is required between MN and HA, but MN has entered IPv4 net. We need to consider this in our scenarios. I have communicated this to some and talking with Pascal T. This is a real scenario that is being planned today by several large enterpises. Thanks /jim -----Original Message----- From: nemo-bounces@ietf.org [mailto:nemo-bounces@ietf.org] On Behalf Of Vijay Devarapalli Sent: Thursday, July 28, 2005 7:40 PM To: mip6@ietf.org;=20 Subject: [nemo] v4 traversal slides [I am resending. apologize if you get multiple copies.] hi all,=20 here are the slides that will be presented as a status=20 update from the mip6trans design team next week at the=20 MIP6 and NEMO WG meetings.=20 http://people.nokia.net/vijayd/mip6trans/ietf63_mip6_mip6trans.pdf=20 unfortunately, we didn't have enough time to submit an=20 internet draft.=20 the above slideset talks about the scenarios the design=20 team is going to solve. it also lists the solution=20 requirements.=20 Vijay=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6