From mobopts-bounces@irtf.org Wed Mar 01 20:19:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEcTW-0006ck-Vn; Wed, 01 Mar 2006 20:19:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEcTW-0006ar-5G for mobopts@irtf.org; Wed, 01 Mar 2006 20:19:26 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEcTU-0001Xb-Ef for mobopts@irtf.org; Wed, 01 Mar 2006 20:19:26 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k220f9q28633 for ; Wed, 1 Mar 2006 16:41:09 -0800 X-mProtect: <200603020041> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14180.americas.nokia.com (172.18.141.80, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdavvefC; Wed, 01 Mar 2006 16:41:07 PST Message-ID: <4406480D.3080604@iprg.nokia.com> Date: Wed, 01 Mar 2006 17:19:09 -0800 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mobopts@irtf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Mobopts] Meeting in Dallas X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Folks, we are meeting for two hours in Dallas. We will go over the new Research Track RFC process. We should also have good discussion on current and new topics. Please indicate your interest to present with: 1. Title 2. Document URL 3. Time for presentation Thanks, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 03 11:15:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFCvz-0001b5-SO; Fri, 03 Mar 2006 11:15:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFCvy-0001b0-OQ for mobopts@irtf.org; Fri, 03 Mar 2006 11:15:14 -0500 Received: from smtp1.int-evry.fr ([157.159.10.44]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFCvx-00037g-Fh for mobopts@irtf.org; Fri, 03 Mar 2006 11:15:14 -0500 Received: from lor-maknavic3.int-evry.fr (lor-maknavic3.int-evry.fr [157.159.103.217]) by smtp1.int-evry.fr (Postfix) with ESMTP id 8C04C18CDE5; Fri, 3 Mar 2006 17:15:32 +0100 (CET) From: Pars Mutaf To: "mobopts@irtf.org" In-Reply-To: <43FD0B61.4040207@iprg.nokia.com> References: <43FD0B61.4040207@iprg.nokia.com> Content-Type: text/plain Organization: INT Evry Date: Fri, 03 Mar 2006 17:15:32 +0100 Message-Id: <1141402532.1625.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-INT-MailScanner-From: pars.mutaf@int-evry.fr X-Spam-Score: 0.5 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: iwrandom@gmail.com Subject: [Mobopts] Randomness from Wi-Fi background noise X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pars.mutaf@int-evry.fr List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi folks, This is slightly off topic but I know that some people on list would be interested. A while ago I wrote a C code for generating true random numbers from Wi-Fi background noise :-D For the theory of operation and C code click: http://www.freewebs.com/pmutaf/iwrandom.html Enjoy! pars ps: In fact, honestly, I'm interested in your Wi-Fi material. If you test the code PLEASE return feedback (vendor name, driver) to iwrandom@gmail.com ps2: hey this is not completely off topic! true random numbers are needed for Optimistic DAD ;-) _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Sun Mar 05 18:04:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG2HM-0004du-0C; Sun, 05 Mar 2006 18:04:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG2H3-0004aW-TY for mobopts@irtf.org; Sun, 05 Mar 2006 18:04:26 -0500 Received: from mail.av.it.pt ([193.136.92.53] helo=av.it.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG2H2-0005Ai-Ix for mobopts@irtf.org; Sun, 05 Mar 2006 18:04:25 -0500 Received: from [192.168.0.156] (HELO mars.innerghost.net) by av.it.pt (CommuniGate Pro SMTP 4.3.7) with ESMTP id 4178251; Sun, 05 Mar 2006 23:02:28 +0000 Received: by mars.innerghost.net (Postfix, from userid 1000) id 7EC0C40E6; Sun, 5 Mar 2006 23:04:22 +0000 (WET) Date: Sun, 5 Mar 2006 23:04:22 +0000 From: Hugo Santos To: mobopts@irtf.org Message-ID: <20060305230422.GE14880@innerghost.net> Mail-Followup-To: mobopts@irtf.org, ruilaa@det.ua.pt, Ilka Miloucheva , karl.jonas@ieee.org Mime-Version: 1.0 User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: karl.jonas@ieee.org, Ilka Miloucheva Subject: [Mobopts] New I-D: Context Transfer of Mobile IPv6 Multicast Listeners X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0353888817==" Errors-To: mobopts-bounces@irtf.org --===============0353888817== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XuV1QlJbYrcVoo+x" Content-Disposition: inline --XuV1QlJbYrcVoo+x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi everyone, We've submited a new Internet Draft on the Context Transfer of Mobile IPv6 Multicast Listeners, including integration with fast mobility scenarios. Title: Context Transfer of Mobile IPv6 Multicast Listeners Abstract: This document describes a framework for the Context Transfer Protocol to provide the transfer of multicast listener context information between Access Router to optimize the re-activation of the multicast flows required by the terminals with minimal service disruption. URL: http://www.ietf.org/internet-drafts/draft-santos-mobopts-mcast-ctx-transfer-00.txt Any comments are appreciated. Thanks, Hugo Santos --XuV1QlJbYrcVoo+x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFEC2527asb/itUNKwRAnh7AJwP+IuYN4w3bjlaO+fP+HeUTrnEwgCg0IFm finiwAHcaW+cpkCzuNhChfk= =vd8v -----END PGP SIGNATURE----- --XuV1QlJbYrcVoo+x-- --===============0353888817== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0353888817==-- From mobopts-bounces@irtf.org Mon Mar 06 04:15:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGBkt-0003zI-DR; Mon, 06 Mar 2006 04:11:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGBks-0003zD-10 for mobopts@irtf.org; Mon, 06 Mar 2006 04:11:50 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGBkq-0006uY-OI for mobopts@irtf.org; Mon, 06 Mar 2006 04:11:50 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id CD8F4200C8E1 for ; Mon, 6 Mar 2006 10:11:52 +0100 (CET) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30172-10 for ; Mon, 6 Mar 2006 10:11:52 +0100 (CET) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id BBCF62007D79 for ; Mon, 6 Mar 2006 10:11:52 +0100 (CET) Received: from [10.1.1.115] ([10.1.1.115]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Mar 2006 10:11:47 +0100 Message-ID: <440BFCD2.7000508@netlab.nec.de> Date: Mon, 06 Mar 2006 10:11:46 +0100 From: Telemaco Melia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "mobopts@irtf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2006 09:11:47.0338 (UTC) FILETIME=[FEDC1EA0:01C640FD] X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.5 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Mobopts] Updated draft X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi folks, Ass long as is not announced please find at the following link the updated document. ftp://195.37.70.21/pub/internet-drafts/draft-melia-mobopts-niho-ps-01.txt Comments are welcome. cheers, telemaco -- Telemaco Melia telemaco.melia@netlab.nec.de Research Staff Member Tel: +49 (0) 6221 90511-42 Network Laboratories Fax: +49 (0) 6221 90511-55 NEC Europe Ltd. Web: http://netlab.nec.de Kurfrsten-Anlage 36 D-69115 Heidelberg Germany _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Mar 06 06:49:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGEDO-0004tM-9T; Mon, 06 Mar 2006 06:49:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGEDN-0004oa-HV for mobopts@irtf.org; Mon, 06 Mar 2006 06:49:25 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGEDM-0005bk-3G for mobopts@irtf.org; Mon, 06 Mar 2006 06:49:25 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FGEDA-00037P-OH; Mon, 06 Mar 2006 12:49:14 +0100 Received: from [IPv6:2001:638:204:6:20c:6eff:fe40:8d95] (archimedes.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:20c:6eff:fe40:8d95]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 80410A590; Mon, 6 Mar 2006 12:49:12 +0100 (CET) Message-ID: <440C21B8.7050600@tm.uka.de> Date: Mon, 06 Mar 2006 12:49:12 +0100 From: Christian Vogt User-Agent: Mozilla/5.0 (X11; U; Linux i686; de-DE; rv:1.7.12) Gecko/20050923 Thunderbird/1.0.7 Mnenhy/0.7.2.0 MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] Meeting in Dallas References: <4406480D.3080604@iprg.nokia.com> In-Reply-To: <4406480D.3080604@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.9 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.5 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Jari Arkko , William Arbaugh , "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Rajeev, I'd like to present the new versions of the EBU and CBA specifications: http://www.ietf.org/internet-drafts/draft-vogt-mobopts-simple-ebu-00.txt http://www.ietf.org/internet-drafts/draft-vogt-mobopts-simple-cba-00.txt Presentation title: "Early Binding Updates for Mobile IPv6 and Credit-Based Authorization -- A Status Update" Presentation time: 10 minutes The main part of draft-vogt-mobopts-simple-ebu-00.txt is a listing of diff's that one needs to apply to RFC3775 in order to arrive at a Mobile IPv6 variant that supports Early Binding Updates. (The draft thus resembles the style of draft-ietf-ipv6-optimistic-dad-07.txt.) The EBU specification was also conceptually revised in that no new MH types are necessary for "early Binding Update" and "early Binding Acknowledgment" messages. The new CBA specification, draft-vogt-mobopts-simple-cba-00.txt, is limited to the simple mode, where a mobile node gets credit for packets that it sends. This limitation of scope makes the draft quite concise. Furthermore, both of the above drafts should be ready to enter the publication process. - Christian -- Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH) www.tm.uka.de/~chvogt/pubkey/ Rajeev Koodli wrote: > > Folks, > > we are meeting for two hours in Dallas. > > We will go over the new Research Track RFC process. > We should also have good discussion on current and > new topics. > > Please indicate your interest to present with: > > 1. Title > 2. Document URL > 3. Time for presentation > > Thanks, > > -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Mar 06 16:25:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNCT-0000zu-W6; Mon, 06 Mar 2006 16:25:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGNCT-0000zN-5L for mobopts@irtf.org; Mon, 06 Mar 2006 16:25:05 -0500 Received: from thumper.research.telcordia.com ([128.96.41.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGNCP-0007PN-Sq for mobopts@irtf.org; Mon, 06 Mar 2006 16:25:05 -0500 Received: from [192.4.8.161] (adutta-laptop.research.telcordia.com [192.4.8.161]) by thumper.research.telcordia.com (8.13.5/8.13.5) with ESMTP id k26LP1UM013596 for ; Mon, 6 Mar 2006 16:25:01 -0500 (EST) Message-ID: <440CA8B0.6090605@research.telcordia.com> Date: Mon, 06 Mar 2006 16:25:04 -0500 From: Ashutosh Dutta User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobopts@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Mobopts] Updated MPA drafts and heterogeneous requirement drafts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Dear Colleagues, We have submitted the updated version of MPA framework, MPA implementation and heteogeneous requirement drafts. Following are the URL for these drafts. http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-framework-02.txt http://www.ietf.org/internet-drafts/draft-ohba-mobopts-mpa-implementation-02.txt http://www.ietf.org/internet-drafts/draft-ohba-mobopts-heterogeneous-requirement-01.txt Regards Ashutosh _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 07 20:20:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGnLZ-0003rA-OS; Tue, 07 Mar 2006 20:20:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGnLX-0003qX-Uq for mobopts@irtf.org; Tue, 07 Mar 2006 20:20:11 -0500 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGnLX-0006Wj-ME for mobopts@irtf.org; Tue, 07 Mar 2006 20:20:11 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id DFDC8800089 for ; Wed, 8 Mar 2006 03:20:10 +0200 (EET) Date: Wed, 8 Mar 2006 03:20:10 +0200 (EET) From: Wassim Haddad To: mobopts@irtf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Mobopts] OMIPv6 Privacy X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, FYI, A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Anonymity and Unlinkability Extension for OMIPv6 Author(s) : W. Haddad, et al. Filename : draft-haddad-privacy-omipv6-anonymity-01.txt Pages : 19 Date : 2006-3-7 The "Optimized Mobile IPv6 with CBA" (OMIPv6) protocol specifies a new route optimization (RO) mechanism, which offers better security, less signaling messages and reduces the handoff latency. This document describes a new extension to be added to the OMIPv6 protocol in order to provide the anonymity and the unlinkability aspects at the IP layer. Comments appreciated. Regards, Wassim H. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Mar 08 16:28:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6D5-0008Hv-HC; Wed, 08 Mar 2006 16:28:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH6D3-0008HA-GS for mobopts@irtf.org; Wed, 08 Mar 2006 16:28:41 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH6D3-0007mc-1P for mobopts@irtf.org; Wed, 08 Mar 2006 16:28:41 -0500 Message-ID: <02a301c642f7$bc73f870$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Rajeev Koodli" , References: <43FD0B61.4040207@iprg.nokia.com> Subject: Re: [Mobopts] New IRTF process for RG RFCs Date: Wed, 8 Mar 2006 13:32:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org What is the IRSG? jak ----- Original Message ----- From: "Rajeev Koodli" To: Sent: Wednesday, February 22, 2006 5:09 PM Subject: [Mobopts] New IRTF process for RG RFCs > > Folks, > > after considerable deliberation, we have a new process which I believe > will bring a much-needed formal peer review process for RG documents. I > feel this is very good for us, personally having brought it up many a time > earlier, including during the IAB review of MobOpts in Paris. So, I am > looking forward to it. > > Please see the process description below. I hope it is encouraging to all! > > Regards, > > -Rajeev > > ps: to begin with, I will act as the shepherd (see below). > > ............................................................... > > - An RG decides to publish a document using the IRTF publication > track. The RG performs a review for editorial and technical > content. The document should have a statement in the abstract > identifying the document as the product of the RG and a paragraph > in the first section describing the level of support for the > document (e.g., "this document represents the consensus of the > FOOBAR RG", "the views in this document were considered > controversial by the FOOBAR RG but the RG reached a consensus that > the document should still be published") and the breadth of review > for the document. I.e., was this document read by all the active > contributors, 3 people, or folks who are not "in" the RG but are > expert in the area? It should also be very clear throughout the > document that it is not an IETF product and is not a standard. If > an experimental protocol is described appropriate caveats need to > be present. > > - Documents should have a shepherd. This is a relatively new > concept developed in the IETF to ensure that issues raised in the > review and publication process (e.g., by the IESG and RFC Editor) > are responded to in a timely manner. The IETF shepherding process > is described in draft-ietf-proto-wgchair-doc-shepherding-05.txt > and should be adapted to the IRTF publication process as some > items in the draft will not apply. > > - The sponsoring RG chair brings the document to the IRSG for > publication. The expectation is that the RG chair has already > reviewed the draft thoroughly and considers it of publishable > quality editorially and technically. The RG should be copied on > the mail message requesting IRSG review. > > - A (firm) eight-week IRSG review period follows after which a poll > is taken. Reviews should be similar to that for a conference > paper. Votes can be: > > = 'ready to publish' -- requires a thorough read and reasonably > detailed review > > = 'not ready to publish' -- requires a thorough read, reasonably > detailed review, and actionable comments. > > = 'no objection' -- I don't object if this document goes forward; > I've read the document (perhaps quickly); I have some small > comments which are not show stoppers; I don't have great > expertise in the area. > > = 'request more time to review' -- a commitment to to provide a > thorough review in a specified period of time. > > Reviews should be written to be public. In particular, they > should be sent to the submitted RG mailing list. (We may need a > tracker of some sort to collect reviews.) > > At least two other IRSG members (besides the one sponsoring the > document) need to vote 'ready to publish' for the document to move > forward. Any vote of 'not ready to publish' will hold a documents > progress until the comments are addressed. The IRTF chair may > choose to override 'not ready to publish' holds that, in the > opinion of the chair, have received an adequate response. > > - The document is submitted to the RFC Editor who does not perform > an ISR review. The RFC Editor sends it to the IESG for an RFC3932 > review. There are several reasons why the IESG may block a > document, described in RFC3932 section 4. (The document shepherd > should be responsible for checking the IETF datatracker for IESG > blocking and non-blocking comments and forward them to the RG.) > > - Rather than the disclaimers found in RFC3932, the IESG will > instruct the RFC Editor to add the following disclaimer: > > "This RFC is a product of the Internet Research Task Force and > is not a candidate for any level of Internet Standard. The IRTF > publishes the results of Internet-related research and > development activities. These results may not be suitable for > deployment." > > For documents that specify a protocol or other technology, and > that have been considered in the IETF at one time: > > "This RFC is a product of the Internet Research Task Force. The > content of this RFC was at one time considered by the IETF, and > therefore it may resemble a current IETF work in progress or a > published IETF work. However, this is not an IETF document is > not a candidate for any level of Internet Standard. The IRTF > publishes the results of Internet-related research and > development activities. These results may not be suitable for > deployment." > > (These disclaimers will require approval by the IESG.) > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Mar 08 19:56:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH9S2-0000B4-AY; Wed, 08 Mar 2006 19:56:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH9S0-0008Vm-Vn for mobopts@irtf.org; Wed, 08 Mar 2006 19:56:20 -0500 Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH9Rz-000484-Iw for mobopts@irtf.org; Wed, 08 Mar 2006 19:56:20 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id A9FD6800090; Thu, 9 Mar 2006 02:56:18 +0200 (EET) Date: Thu, 9 Mar 2006 02:56:18 +0200 (EET) From: Wassim Haddad To: mobopts@irtf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Wassim.Haddad@ericsson.com Subject: [Mobopts] Optimizing SEND (OptiSEND) X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, FYI, A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Secure Neighbor Discovery (SEND) Optimization and Adaptation for Mobility: The OptiSEN$ Author(s) : W. Haddad, et al. Filename : draft-haddad-mipshop-optisend-01.txt Pages : 11 Date : 2006-3-8 This memo describes a new set of mechanisms, which aims to increase the Secure Neighbor Discovery (SEND) protocol usability by reducing the required processing power on small devices and adapting it to mobile environment requirements while maintaining its efficiency. Comments appreciated. Regards, Wassim H. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Mar 09 16:44:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSw6-0007WM-5S; Thu, 09 Mar 2006 16:44:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHSw5-0007WH-BG for mobopts@irtf.org; Thu, 09 Mar 2006 16:44:41 -0500 Received: from oak.research.panasonic.com ([150.169.1.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHSw4-0006gl-2U for mobopts@irtf.org; Thu, 09 Mar 2006 16:44:41 -0500 Received: from redwood.research.panasonic.com (redwood.research.panasonic.com [150.169.3.3]) by oak.research.panasonic.com (1.1.1/1.1.1) with ESMTP id k29LZIoT014331; Thu, 9 Mar 2006 16:35:18 -0500 Received: from [150.169.1.178] (video.Research.Panasonic.COM [150.169.1.178]) by redwood.research.panasonic.com (MOS 3.7.4b-GA) with ESMTP id ADZ02081; Thu, 9 Mar 2006 16:34:21 -0500 (EST) Message-ID: <44109F91.3090104@research.panasonic.com> Date: Thu, 09 Mar 2006 16:35:13 -0500 From: Greg Daley User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobopts] New IRTF process for RG RFCs References: <43FD0B61.4040207@iprg.nokia.com> <02a301c642f7$bc73f870$026115ac@dcml.docomolabsusa.com> In-Reply-To: <02a301c642f7$bc73f870$026115ac@dcml.docomolabsusa.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Rajeev Koodli , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi James, James Kempf wrote: > What is the IRSG? > IRSG := Internet Research Steering Group The IRSG is the set of IRTF WG chairs plus the IRTF Chair. This is described on http://www.irtf.org/ Greg _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 10 19:31:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHs0m-0001Rx-Th; Fri, 10 Mar 2006 19:31:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHs0m-0001Rs-AP for mobopts@irtf.org; Fri, 10 Mar 2006 19:31:12 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHs0l-0006Zk-QI for mobopts@irtf.org; Fri, 10 Mar 2006 19:31:12 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k2ANqYg03646 for ; Fri, 10 Mar 2006 15:52:34 -0800 X-mProtect: <200603102352> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.49, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdNOHOxb; Fri, 10 Mar 2006 15:52:32 PST Message-ID: <44121A3B.8090900@iprg.nokia.com> Date: Fri, 10 Mar 2006 16:30:51 -0800 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mobopts@irtf.org" Subject: [Fwd: Re: [Mobopts] New IRTF process for RG RFCs] Content-Type: multipart/mixed; boundary="------------010205010400010507090707" X-Spam-Score: 0.5 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org This is a multi-part message in MIME format. --------------010205010400010507090707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks Greg. I guess I forgot to do Reply All. -Rajeev --------------010205010400010507090707 Content-Type: message/rfc822; name="Re: [Mobopts] New IRTF process for RG RFCs" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Re: [Mobopts] New IRTF process for RG RFCs" Message-ID: <440F84A6.1040408@iprg.nokia.com> Date: Wed, 08 Mar 2006 17:28:06 -0800 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mobopts] New IRTF process for RG RFCs References: <43FD0B61.4040207@iprg.nokia.com> <02a301c642f7$bc73f870$026115ac@dcml.docomolabsusa.com> In-Reply-To: <02a301c642f7$bc73f870$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jim, James Kempf wrote: > What is the IRSG? IRSG is RG chairs, IRTF chair and some members invited by the IRTF chair. -Rajeev > > jak > > ----- Original Message ----- From: "Rajeev Koodli" > To: > Sent: Wednesday, February 22, 2006 5:09 PM > Subject: [Mobopts] New IRTF process for RG RFCs > > >> >> Folks, >> >> after considerable deliberation, we have a new process which I believe >> will bring a much-needed formal peer review process for RG documents. >> I feel this is very good for us, personally having brought it up many >> a time earlier, including during the IAB review of MobOpts in Paris. >> So, I am looking forward to it. >> >> Please see the process description below. I hope it is encouraging to >> all! >> >> Regards, >> >> -Rajeev >> >> ps: to begin with, I will act as the shepherd (see below). >> >> ............................................................... >> >> - An RG decides to publish a document using the IRTF publication >> track. The RG performs a review for editorial and technical >> content. The document should have a statement in the abstract >> identifying the document as the product of the RG and a paragraph >> in the first section describing the level of support for the >> document (e.g., "this document represents the consensus of the >> FOOBAR RG", "the views in this document were considered >> controversial by the FOOBAR RG but the RG reached a consensus that >> the document should still be published") and the breadth of review >> for the document. I.e., was this document read by all the active >> contributors, 3 people, or folks who are not "in" the RG but are >> expert in the area? It should also be very clear throughout the >> document that it is not an IETF product and is not a standard. If >> an experimental protocol is described appropriate caveats need to >> be present. >> >> - Documents should have a shepherd. This is a relatively new >> concept developed in the IETF to ensure that issues raised in the >> review and publication process (e.g., by the IESG and RFC Editor) >> are responded to in a timely manner. The IETF shepherding process >> is described in draft-ietf-proto-wgchair-doc-shepherding-05.txt >> and should be adapted to the IRTF publication process as some >> items in the draft will not apply. >> >> - The sponsoring RG chair brings the document to the IRSG for >> publication. The expectation is that the RG chair has already >> reviewed the draft thoroughly and considers it of publishable >> quality editorially and technically. The RG should be copied on >> the mail message requesting IRSG review. >> >> - A (firm) eight-week IRSG review period follows after which a poll >> is taken. Reviews should be similar to that for a conference >> paper. Votes can be: >> >> = 'ready to publish' -- requires a thorough read and reasonably >> detailed review >> >> = 'not ready to publish' -- requires a thorough read, reasonably >> detailed review, and actionable comments. >> >> = 'no objection' -- I don't object if this document goes forward; >> I've read the document (perhaps quickly); I have some small >> comments which are not show stoppers; I don't have great >> expertise in the area. >> >> = 'request more time to review' -- a commitment to to provide a >> thorough review in a specified period of time. >> >> Reviews should be written to be public. In particular, they >> should be sent to the submitted RG mailing list. (We may need a >> tracker of some sort to collect reviews.) >> >> At least two other IRSG members (besides the one sponsoring the >> document) need to vote 'ready to publish' for the document to move >> forward. Any vote of 'not ready to publish' will hold a documents >> progress until the comments are addressed. The IRTF chair may >> choose to override 'not ready to publish' holds that, in the >> opinion of the chair, have received an adequate response. >> >> - The document is submitted to the RFC Editor who does not perform >> an ISR review. The RFC Editor sends it to the IESG for an RFC3932 >> review. There are several reasons why the IESG may block a >> document, described in RFC3932 section 4. (The document shepherd >> should be responsible for checking the IETF datatracker for IESG >> blocking and non-blocking comments and forward them to the RG.) >> >> - Rather than the disclaimers found in RFC3932, the IESG will >> instruct the RFC Editor to add the following disclaimer: >> >> "This RFC is a product of the Internet Research Task Force and >> is not a candidate for any level of Internet Standard. The IRTF >> publishes the results of Internet-related research and >> development activities. These results may not be suitable for >> deployment." >> >> For documents that specify a protocol or other technology, and >> that have been considered in the IETF at one time: >> >> "This RFC is a product of the Internet Research Task Force. The >> content of this RFC was at one time considered by the IETF, and >> therefore it may resemble a current IETF work in progress or a >> published IETF work. However, this is not an IETF document is >> not a candidate for any level of Internet Standard. The IRTF >> publishes the results of Internet-related research and >> development activities. These results may not be suitable for >> deployment." >> >> (These disclaimers will require approval by the IESG.) >> >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts >> > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts --------------010205010400010507090707 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --------------010205010400010507090707-- From mobopts-bounces@irtf.org Mon Mar 13 13:24:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIric-0003Ke-7W; Mon, 13 Mar 2006 13:24:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrib-0003KZ-Ax for mobopts@irtf.org; Mon, 13 Mar 2006 13:24:33 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIriZ-00082B-JN for mobopts@irtf.org; Mon, 13 Mar 2006 13:24:33 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k2DHjkU01665 for ; Mon, 13 Mar 2006 09:45:46 -0800 X-mProtect: <200603131745> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14152.americas.nokia.com (172.18.141.52, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpd0nVeuc; Mon, 13 Mar 2006 09:45:44 PST Message-ID: <4415B8D1.10801@iprg.nokia.com> Date: Mon, 13 Mar 2006 10:24:17 -0800 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mobopts@irtf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Mobopts] Agenda X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello folks, here is the agenda for the meeting. Also, I am thinking of having an informal dinner meeting on Wednesday after the plenary. Please send me a note if you would like to join. Regards, -Rajeev 1. Introduction, document status, new IRTF RFC process, Rajeev, 15 minutes. 2. Link Characteristics Information conveyance, Jouni Korhonen, 20 minutes. Some experimental results on modified TCP quickstart as a function of MIP6 handovers (no document yet) 3. Network-initiated handovers, Telemaco Melia, 20 minutes. draft-melia-mobopts-niho-ps-01.txt 4. Early Binding Updates for Mobile IPv6 and Credit-Based Authorization, Christian Vogt, 20 minutes. draft-vogt-mobopts-simple-ebu-00.txt draft-vogt-mobopts-simple-cba-00.txt 5. MIP6 Location Privacy, Qiu Ying, 30 minutes. draft-irtf-mobopts-location-privacy-solutions-00.txt 6. Context Transfer of Mobile IPv6 Multicast Listeners, Hugo Santos, 15 minutes. draft-santos-mobopts-mcast-ctx-transfer-00.txt _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 14 02:34:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ43M-0006zm-7b; Tue, 14 Mar 2006 02:34:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJ43L-0006xO-5K for mobopts@irtf.org; Tue, 14 Mar 2006 02:34:47 -0500 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJ43G-0008O6-NQ for mobopts@irtf.org; Tue, 14 Mar 2006 02:34:47 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 9DAE3200C948; Tue, 14 Mar 2006 08:34:48 +0100 (CET) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10338-10; Tue, 14 Mar 2006 08:34:48 +0100 (CET) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 8AB7D200C946; Tue, 14 Mar 2006 08:34:48 +0100 (CET) Received: from [10.1.1.115] ([10.1.1.115]) by venus.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Mar 2006 08:34:41 +0100 Message-ID: <44167211.5050105@netlab.nec.de> Date: Tue, 14 Mar 2006 08:34:41 +0100 From: Telemaco Melia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Rajeev Koodli Subject: Re: [Mobopts] Agenda References: <4415B8D1.10801@iprg.nokia.com> In-Reply-To: <4415B8D1.10801@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Mar 2006 07:34:41.0530 (UTC) FILETIME=[C1B65DA0:01C64739] X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Rajeev, I ll join the dinner. Let me know. Telemaco Rajeev Koodli wrote: > > Hello folks, > > here is the agenda for the meeting. > > Also, I am thinking of having an informal dinner meeting on Wednesday > after the plenary. Please send me a note if you would like to join. > > Regards, > > -Rajeev > > > 1. Introduction, document status, new IRTF RFC process, Rajeev, 15 > minutes. > > 2. Link Characteristics Information conveyance, Jouni Korhonen, 20 > minutes. > > Some experimental results on modified TCP quickstart as a function > of MIP6 handovers (no document yet) > > 3. Network-initiated handovers, Telemaco Melia, 20 minutes. > > draft-melia-mobopts-niho-ps-01.txt > > 4. Early Binding Updates for Mobile IPv6 and Credit-Based > Authorization, Christian Vogt, 20 minutes. > > draft-vogt-mobopts-simple-ebu-00.txt > draft-vogt-mobopts-simple-cba-00.txt > > 5. MIP6 Location Privacy, Qiu Ying, 30 minutes. > > draft-irtf-mobopts-location-privacy-solutions-00.txt > > 6. Context Transfer of Mobile IPv6 Multicast Listeners, Hugo Santos, 15 > minutes. > > draft-santos-mobopts-mcast-ctx-transfer-00.txt > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts -- Telemaco Melia telemaco.melia@netlab.nec.de Research Staff Member Tel: +49 (0) 6221 90511-42 Network Laboratories Fax: +49 (0) 6221 90511-55 NEC Europe Ltd. Web: http://netlab.nec.de Kurfrsten-Anlage 36 D-69115 Heidelberg Germany _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 14 23:09:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJNKM-0007Ln-Ft; Tue, 14 Mar 2006 23:09:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJNKK-0007Li-Si for mobopts@irtf.org; Tue, 14 Mar 2006 23:09:36 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJNKH-0001Ay-5r for mobopts@irtf.org; Tue, 14 Mar 2006 23:09:36 -0500 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 <0IW500H0OI75Q0@mailout3.samsung.com> for mobopts@irtf.org; Wed, 15 Mar 2006 13:09:05 +0900 (KST) Received: from daniellaptop ([168.219.198.108]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IW500CMEI75MG@mmp2.samsung.com> for mobopts@irtf.org; Wed, 15 Mar 2006 13:09:05 +0900 (KST) Date: Wed, 15 Mar 2006 13:09:17 +0900 From: Soohong Daniel Park Subject: Re: [Mobopts] Agenda To: Rajeev Koodli , mobopts@irtf.org Message-id: <01f901c647e6$3a79d170$6cc6dba8@daniellaptop> 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; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4415B8D1.10801@iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org > Also, I am thinking of having an informal dinner meeting on Wednesday > after the plenary. Please send me a note if you would like to join. Just enjoy a meal ? or Any MobOpts related discussion ? Thanks in advance. Daniel (Soohong Daniel Park) Mobile Convergence Laboratory, SAMSUNG Electronics. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Mar 15 15:01:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJcBI-0005kB-0K; Wed, 15 Mar 2006 15:01:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJcBG-0005k4-Sn for mobopts@irtf.org; Wed, 15 Mar 2006 15:01:14 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJcBF-0005Js-Hf for mobopts@irtf.org; Wed, 15 Mar 2006 15:01:14 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k2FJMMp26493; Wed, 15 Mar 2006 11:22:22 -0800 X-mProtect: <200603151922> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14179.americas.nokia.com (172.18.141.79, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdznh0us; Wed, 15 Mar 2006 09:26:59 PST Message-ID: <44185756.2000502@iprg.nokia.com> Date: Wed, 15 Mar 2006 10:05:10 -0800 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soohong Daniel Park Subject: Re: [Mobopts] Agenda References: <4415B8D1.10801@iprg.nokia.com> <01f901c647e6$3a79d170$6cc6dba8@daniellaptop> In-Reply-To: <01f901c647e6$3a79d170$6cc6dba8@daniellaptop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Soohong Daniel Park wrote: >>Also, I am thinking of having an informal dinner meeting on Wednesday >>after the plenary. Please send me a note if you would like to join. > > > Just enjoy a meal ? or Any MobOpts related discussion ? > Both :-) -Rajeev > Thanks in advance. > > Daniel (Soohong Daniel Park) > Mobile Convergence Laboratory, SAMSUNG Electronics. > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Mar 16 13:36:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJxKg-0005Mn-EN; Thu, 16 Mar 2006 13:36:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJkqH-0005RT-TI for mobopts@irtf.org; Thu, 16 Mar 2006 00:16:09 -0500 Received: from tom.iecc.com ([208.31.42.38]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJkqH-0004n6-Cq for mobopts@irtf.org; Thu, 16 Mar 2006 00:16:09 -0500 Received: (qmail 9477 invoked from network); 16 Mar 2006 05:16:08 -0000 Received: (ofmipd 127.0.0.1); 16 Mar 2006 05:15:46 -0000 Date: 16 Mar 2006 00:16:08 -0500 Message-ID: From: "John R Levine" To: irtf@irtf.org Cleverness: None detected MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Thu, 16 Mar 2006 13:36:22 -0500 Cc: mobopts@irtf.org Subject: [Mobopts] Review of draft-irtf-mobopts-ro-enhancements-06 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org The new IRTF publication process for research group documents includes peer review by chairs of other RGs. I'm the chair of the ASRG, and I claim no great expertise in mobile IP, so my review is primarily about the readability and utility of this document for a technical but non-specialist audience. Basically, I think it's quite good, and could be published as is although I have a few minor suggestions. The document starts with an description of the mobile IP environment and the goals of mobile optimization, and then enumerates a toolbox of techniques that might be used to improve a node's migration process from one address to another. Some of the techniques are fairly tricky, but I didn't have any trouble following them, even the dread ASCII art. My only suggestion is that I would have found it useful in section 3 to have a paragraph or two summarizing the salient characteristics of the mobile environment, such as power limitations that leadi to a desire to minimize traffic when a device is not moving. These all come up in the discussions of the techniques, but for those of us not steeped in mobile-thought, it would have been useful to see a list of them before starting into the toolbox so I could more easily understand the tradeoffs in using the techniques. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor "More Wiener schnitzel, please", said Tom, revealingly. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 21 10:21:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLifu-0001jS-Ej; Tue, 21 Mar 2006 10:21:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLift-0001jJ-9g for mobopts@irtf.org; Tue, 21 Mar 2006 10:21:33 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLifs-0003gT-Te for mobopts@irtf.org; Tue, 21 Mar 2006 10:21:33 -0500 Received: from [130.129.133.103] (DHCP-Wireless-133-103.ietf65.org [130.129.133.103]) by kyoto.netlab.nec.de (Postfix) with ESMTP id EE4EA1BAC4D; Tue, 21 Mar 2006 16:20:28 +0100 (CET) Message-ID: <442019F5.7070805@netlab.nec.de> Date: Tue, 21 Mar 2006 16:21:25 +0100 From: Telemaco Melia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: RIERA Julien RD-RESA-ISS References: <429B23056C84A54BBE91FE41452E17D203951CCB@FTRDMEL2.rd.francetelecom.fr> In-Reply-To: <429B23056C84A54BBE91FE41452E17D203951CCB@FTRDMEL2.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: "mobopts@irtf.org" Subject: [Mobopts] Re: Network initiated handovers problem statement Draft X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Julien, Thanks for your feedback on the ID. (I cc the mailing list just to=20 trigger discussions). Can you elaborate a bit more your concern? regards, telemaco RIERA Julien RD-RESA-ISS wrote: > > Hello Telemaco, > I just finished reading the new release of your draft "Network=20 > initiated handovers problem statement". > > This is a very interesting draft, and I agree with most of the points=20 > you raised in it. > I just wanted to highlight that in 4.3 paragraph (Inter-domain=20 > handovers), you wrote that the user just need a relationship with its=20 > service provider. > > If I totally agree that the service provider is the one who permit=20 > mobility (as a service), I think in most of today's deployments, user=20 > will need a relationship with the NAP or ISP. Not in order to provide=20 > or not mobility service but at least in order to allow the user=20 > accessing the network. > > Some networks are freely accessible, but in operator deployments, it=20 > should be needed to authenticate the user before letting it access its=20 > network. > > I guess this kind of relationship should be between the user and the=20 > NAP or ISP and not between NAP/ISP and the service provider. > > This is just a detail, but still I wanted to highlight it to you, to=20 > be sure I didn't misunderstand you nor you missed this point. > > Regards, > Julien > > > > > Julien RIERA > *& france telecom* > *Division R&D* > __________________________ > *Ing=E9nieur R&D* > RESA/BWA > Pi=E8ce 212 E > 38-40 Rue du G=E9n=E9ral Leclerc > 92794 Issy-Moulineaux C=E9dex 9 > __________________________ > > T=E9l. : +33.1.45.29.89.94 > Fax : +33.1.45.29.63.07 > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 21 11:39:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjt7-0005LZ-7o; Tue, 21 Mar 2006 11:39:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLjt5-0005LT-SM for mobopts@irtf.org; Tue, 21 Mar 2006 11:39:15 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLjt5-0006pM-Et for mobopts@irtf.org; Tue, 21 Mar 2006 11:39:15 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 17:39:13 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 17:39:10 +0100 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E038A5736@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Network initiated handovers problem statement Draft Thread-Index: AcZM+yPrnExZlS/SQhiZGEFAsnKTJQABqNHQ From: To: , X-OriginalArrivalTime: 21 Mar 2006 16:39:13.0605 (UTC) FILETIME=[FCAD9F50:01C64D05] X-Spam-Score: 0.2 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: mobopts@irtf.org Subject: [Mobopts] RE: Network initiated handovers problem statement Draft X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Julien, See my comments inline.=20 > Hi Julien, >=20 > Thanks for your feedback on the ID. (I cc the mailing list just to=20 > trigger discussions). > Can you elaborate a bit more your concern? >=20 > regards, > telemaco >=20 > RIERA Julien RD-RESA-ISS wrote: > > > > Hello Telemaco, > > I just finished reading the new release of your draft "Network=20 > > initiated handovers problem statement". > > > > This is a very interesting draft, and I agree with most of=20 > the points=20 > > you raised in it. > > I just wanted to highlight that in 4.3 paragraph (Inter-domain=20 > > handovers), you wrote that the user just need a=20 > relationship with its=20 > > service provider. > > > > If I totally agree that the service provider is the one who permit=20 > > mobility (as a service), I think in most of today's=20 > deployments, user=20 > > will need a relationship with the NAP or ISP. Not in order=20 > to provide=20 > > or not mobility service but at least in order to allow the user=20 > > accessing the network. Yes that is true in most existing deployment models. > > Some networks are freely accessible, but in operator=20 > deployments, it=20 > > should be needed to authenticate the user before letting it=20 > access its=20 > > network. Even if the users gets authenticated to/throught some NAP/ISP it does not really require that the user has a relationship with=20 that NAP/ISP. In e.g. roaming cases it is more or less required that the 'home' service provider says to NAP/ISP that it is ok to let this user to get the access. Assuming the NAP/ISP has a relationship with the service provider. > > I guess this kind of relationship should be between the=20 > user and the=20 > > NAP or ISP and not between NAP/ISP and the service provider. Why? This kind of deployments are already relevant (and deployed). For example in cases where the service provider does not want to build its own access networks but rather establishes a bunch of roaming = relationships with access network provides. > > > > This is just a detail, but still I wanted to highlight it=20 > to you, to=20 > > be sure I didn't misunderstand you nor you missed this point. It's good to have comments. > > Regards, > > Julien Cheers, Jouni > > > > > > > > > > Julien RIERA > > *& france telecom* > > *Division R&D* > > __________________________ > > *Ing=E9nieur R&D* > > RESA/BWA > > Pi=E8ce 212 E > > 38-40 Rue du G=E9n=E9ral Leclerc > > 92794 Issy-Moulineaux C=E9dex 9 > > __________________________ > > > > T=E9l. : +33.1.45.29.89.94 > > Fax : +33.1.45.29.63.07 > > >=20 >=20 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 21 11:57:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkAb-0008Vh-QM; Tue, 21 Mar 2006 11:57:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkAa-0008RY-KB for mobopts@irtf.org; Tue, 21 Mar 2006 11:57:20 -0500 Received: from sehan001bb.han.telia.se ([131.115.18.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkAa-0007jE-9V for mobopts@irtf.org; Tue, 21 Mar 2006 11:57:20 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 17:57:19 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Mar 2006 17:57:15 +0100 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E038A5737@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Network initiated handovers problem statement Draft Thread-Index: AcZM+yNOUnximYVoTm23qgFS2OGGvwACedJgAAA8sUA= From: To: , X-OriginalArrivalTime: 21 Mar 2006 16:57:19.0055 (UTC) FILETIME=[83A825F0:01C64D08] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: mobopts@irtf.org Subject: [Mobopts] RE: Network initiated handovers problem statement Draft X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Julien, > Hi, >=20 > The underlying question within my comment is: what did you=20 > meant (in the 4.3 part mentioned) by "relationship" ? > Was it a packet redirection relationship or did you meant=20 > relationship in a whole? As an commercial / roaming relationship. So that the NAP/ISP and the service provider know about each other and are able to exchange AAA / signaling traffic between each other even before letting the user to get access (assuming the access network has access control). > I fact mobility involves a lot of points: packet redirection=20 > is one of them; mobility service authorisation is also one.=20 > But network access authorisation is still needed. Yes.. > If we are talking about roles (or the entire process=20 > including all AAA needs), then access network authorisation=20 > is needed in most of scenarios. And then this relationship=20 > (user/NAP or ISP) should be highlight in this paragraph. Yes.. maybe the draft is not too clear on the AAA part but that is assumed. Currently it says: "In addition to obvious security and AAA related challenges between the service operator, ISPs and NAPs, the general..." That should be opened a bit more. Probably a paragraph or two or even a subsection. Cheers, Jouni >=20 >=20 > Julien >=20 > > -----Message d'origine----- > > De : Telemaco Melia [mailto:telemaco.melia@netlab.nec.de]=20 > > Envoy=E9 : mardi 21 mars 2006 16:21 > > =C0 : RIERA Julien RD-RESA-ISS > > Cc : jouni.korhonen@teliasonera.com; mobopts@irtf.org > > Objet : Re: Network initiated handovers problem statement Draft > >=20 > > Hi Julien, > >=20 > > Thanks for your feedback on the ID. (I cc the mailing list=20 > > just to trigger discussions). > > Can you elaborate a bit more your concern? > >=20 > > regards, > > telemaco > >=20 > > RIERA Julien RD-RESA-ISS wrote: > > > > > > Hello Telemaco, > > > I just finished reading the new release of your draft "Network=20 > > > initiated handovers problem statement". > > > > > > This is a very interesting draft, and I agree with most of=20 > > the points=20 > > > you raised in it. > > > I just wanted to highlight that in 4.3 paragraph (Inter-domain=20 > > > handovers), you wrote that the user just need a=20 > > relationship with its=20 > > > service provider. > > > > > > If I totally agree that the service provider is the one=20 > who permit=20 > > > mobility (as a service), I think in most of today's=20 > > deployments, user=20 > > > will need a relationship with the NAP or ISP. Not in order=20 > > to provide=20 > > > or not mobility service but at least in order to allow the user=20 > > > accessing the network. > > > > > > Some networks are freely accessible, but in operator=20 > > deployments, it=20 > > > should be needed to authenticate the user before letting it=20 > > access its=20 > > > network. > > > > > > I guess this kind of relationship should be between the=20 > > user and the=20 > > > NAP or ISP and not between NAP/ISP and the service provider. > > > > > > This is just a detail, but still I wanted to highlight it=20 > > to you, to=20 > > > be sure I didn't misunderstand you nor you missed this point. > > > > > > Regards, > > > Julien > > > > > > > > > > > > > > > Julien RIERA > > > *& france telecom* > > > *Division R&D* > > > __________________________ > > > *Ing=E9nieur R&D* > > > RESA/BWA > > > Pi=E8ce 212 E > > > 38-40 Rue du G=E9n=E9ral Leclerc > > > 92794 Issy-Moulineaux C=E9dex 9 > > > __________________________ > > > > > > T=E9l. : +33.1.45.29.89.94 > > > Fax : +33.1.45.29.63.07 > > > > >=20 > >=20 >=20 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 21 12:16:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkTG-00061R-GE; Tue, 21 Mar 2006 12:16:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkTE-0005yo-Ln for mobopts@irtf.org; Tue, 21 Mar 2006 12:16:36 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkTC-0000BS-1w for mobopts@irtf.org; Tue, 21 Mar 2006 12:16:36 -0500 Received: from [130.129.133.103] (unknown [130.129.133.103]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 60B4E1BAC4D; Tue, 21 Mar 2006 18:15:29 +0100 (CET) Message-ID: <442034EF.6030104@netlab.nec.de> Date: Tue, 21 Mar 2006 18:16:31 +0100 From: Telemaco Melia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: julien.riera@francetelecom.com References: <5D25AEFB114D034FBDC8B156FCA78E038A5737@SEHAN021MB.tcad.telia.se> In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E038A5737@SEHAN021MB.tcad.telia.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: mobopts@irtf.org Subject: [Mobopts] Re: Network initiated handovers problem statement Draft X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Basically the ID assumes the presence of a AAA back-end. Probably this is not clear enough. Good point for the next version. telemaco jouni.korhonen@teliasonera.com wrote: > Hi Julien, > > =20 >> Hi, >> >> The underlying question within my comment is: what did you=20 >> meant (in the 4.3 part mentioned) by "relationship" ? >> Was it a packet redirection relationship or did you meant=20 >> relationship in a whole? >> =20 > > As an commercial / roaming relationship. So that the NAP/ISP > and the service provider know about each other and are able to > exchange AAA / signaling traffic between each other even before > letting the user to get access (assuming the access network has > access control). > > =20 >> I fact mobility involves a lot of points: packet redirection=20 >> is one of them; mobility service authorisation is also one.=20 >> But network access authorisation is still needed. >> =20 > > Yes.. > > =20 >> If we are talking about roles (or the entire process=20 >> including all AAA needs), then access network authorisation=20 >> is needed in most of scenarios. And then this relationship=20 >> (user/NAP or ISP) should be highlight in this paragraph. >> =20 > > Yes.. maybe the draft is not too clear on the AAA part but > that is assumed. Currently it says: > > "In addition to obvious security and AAA related challenges > between the service operator, ISPs and NAPs, the general..." > > That should be opened a bit more. Probably a paragraph or two > or even a subsection. > > Cheers, > Jouni > > =20 >> Julien >> >> =20 >>> -----Message d'origine----- >>> De : Telemaco Melia [mailto:telemaco.melia@netlab.nec.de]=20 >>> Envoy=E9 : mardi 21 mars 2006 16:21 >>> =C0 : RIERA Julien RD-RESA-ISS >>> Cc : jouni.korhonen@teliasonera.com; mobopts@irtf.org >>> Objet : Re: Network initiated handovers problem statement Draft >>> >>> Hi Julien, >>> >>> Thanks for your feedback on the ID. (I cc the mailing list=20 >>> just to trigger discussions). >>> Can you elaborate a bit more your concern? >>> >>> regards, >>> telemaco >>> >>> RIERA Julien RD-RESA-ISS wrote: >>> =20 >>>> Hello Telemaco, >>>> I just finished reading the new release of your draft "Network=20 >>>> initiated handovers problem statement". >>>> >>>> This is a very interesting draft, and I agree with most of=20 >>>> =20 >>> the points=20 >>> =20 >>>> you raised in it. >>>> I just wanted to highlight that in 4.3 paragraph (Inter-domain=20 >>>> handovers), you wrote that the user just need a=20 >>>> =20 >>> relationship with its=20 >>> =20 >>>> service provider. >>>> >>>> If I totally agree that the service provider is the one=20 >>>> =20 >> who permit=20 >> =20 >>>> mobility (as a service), I think in most of today's=20 >>>> =20 >>> deployments, user=20 >>> =20 >>>> will need a relationship with the NAP or ISP. Not in order=20 >>>> =20 >>> to provide=20 >>> =20 >>>> or not mobility service but at least in order to allow the user=20 >>>> accessing the network. >>>> >>>> Some networks are freely accessible, but in operator=20 >>>> =20 >>> deployments, it=20 >>> =20 >>>> should be needed to authenticate the user before letting it=20 >>>> =20 >>> access its=20 >>> =20 >>>> network. >>>> >>>> I guess this kind of relationship should be between the=20 >>>> =20 >>> user and the=20 >>> =20 >>>> NAP or ISP and not between NAP/ISP and the service provider. >>>> >>>> This is just a detail, but still I wanted to highlight it=20 >>>> =20 >>> to you, to=20 >>> =20 >>>> be sure I didn't misunderstand you nor you missed this point. >>>> >>>> Regards, >>>> Julien >>>> >>>> >>>> >>>> >>>> Julien RIERA >>>> *& france telecom* >>>> *Division R&D* >>>> __________________________ >>>> *Ing=E9nieur R&D* >>>> RESA/BWA >>>> Pi=E8ce 212 E >>>> 38-40 Rue du G=E9n=E9ral Leclerc >>>> 92794 Issy-Moulineaux C=E9dex 9 >>>> __________________________ >>>> >>>> T=E9l. : +33.1.45.29.89.94 >>>> Fax : +33.1.45.29.63.07 >>>> >>>> =20 >>> =20 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 21 12:23:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkaG-0008ON-SM; Tue, 21 Mar 2006 12:23:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkaF-0008OI-Gz for mobopts@irtf.org; Tue, 21 Mar 2006 12:23:51 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkaE-0000Rd-6D for mobopts@irtf.org; Tue, 21 Mar 2006 12:23:51 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k2LGikc07608 for ; Tue, 21 Mar 2006 08:44:46 -0800 X-mProtect: <200603211644> Nokia Silicon Valley Messaging Protection Received: from danira-pool05284.americas.nokia.com (10.241.52.84, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdC2wykY; Tue, 21 Mar 2006 08:44:44 PST Message-ID: <44203695.4090001@iprg.nokia.com> Date: Tue, 21 Mar 2006 09:23:33 -0800 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mobopts@irtf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Mobopts] IRTF RFC ID X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Folks, draft-irtf-rfcs-00.txt is the ID which is documenting the process. Regards, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 21 12:33:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkjr-0008QL-Mg; Tue, 21 Mar 2006 12:33:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkjq-0008QA-99 for mobopts@irtf.org; Tue, 21 Mar 2006 12:33:46 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkjo-0000jL-UL for mobopts@irtf.org; Tue, 21 Mar 2006 12:33:46 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k2LGsfM18577 for ; Tue, 21 Mar 2006 08:54:41 -0800 X-mProtect: <200603211654> Nokia Silicon Valley Messaging Protection Received: from danira-pool05284.americas.nokia.com (10.241.52.84, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdRNrCYB; Tue, 21 Mar 2006 08:54:39 PST Message-ID: <442038E8.7040704@iprg.nokia.com> Date: Tue, 21 Mar 2006 09:33:28 -0800 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mobopts@irtf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Mobopts] Wednesday dinner X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello Folks, based on input from the Hotel Concierge, I suggest Alfredo Trattoria, 5404 Lemmon Ave. Dallas (Phone: 214 526-3331). It is about 3 miles. If you know of a better place nearby, please suggest. Regards, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 21 15:45:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLniw-0002lQ-8P; Tue, 21 Mar 2006 15:45:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLniu-0002lE-Cg for mobopts@irtf.org; Tue, 21 Mar 2006 15:45:00 -0500 Received: from frontend-1.servers.ua.pt ([193.136.173.2] helo=cgpmail.ua.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLniq-00088T-JL for mobopts@irtf.org; Tue, 21 Mar 2006 15:45:00 -0500 Received: from discworld.det.ua.pt (account ruilaa@det.ua.pt [193.136.82.194] verified) by frontend1.cgpmail.ua.pt (CommuniGate Pro SMTP 4.3.8) with ESMTPSA id 12132838; Tue, 21 Mar 2006 20:44:54 +0000 Received: by discworld.det.ua.pt (Postfix, from userid 500) id 05ACB6242C3; Tue, 21 Mar 2006 20:44:59 +0000 (WET) Subject: Re: [Mobopts] RE: Network initiated handovers problem statement Draft In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E038A5737@SEHAN021MB.tcad.telia.se> To: jouni.korhonen@teliasonera.com Date: Tue, 21 Mar 2006 20:44:59 +0000 (WET) X-Mailer: ELM [version 2.4ME+ PL100 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-15 Message-Id: <20060321204459.05ACB6242C3@discworld.det.ua.pt> From: ruilaa@det.ua.pt (Rui Aguiar) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: julien.riera@francetelecom.com, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi: >=20 > Yes.. maybe the draft is not too clear on the AAA part but > that is assumed. Currently it says: >=20 > "In addition to obvious security and AAA related challenges > between the service operator, ISPs and NAPs, the general..." >=20 > That should be opened a bit more. Probably a paragraph or two > or even a subsection. Yes. But the AAA issues are often too near the agreements of operators, and we should avoid touching that. On the other hand, some improved scenarios maybe will help? Best Regards Rui >=20 > Cheers, > Jouni >=20 > >=20 > >=20 > > Julien > >=20 > > > -----Message d'origine----- > > > De : Telemaco Melia [mailto:telemaco.melia@netlab.nec.de]=20 > > > Envoy=E9 : mardi 21 mars 2006 16:21 > > > =C0 : RIERA Julien RD-RESA-ISS > > > Cc : jouni.korhonen@teliasonera.com; mobopts@irtf.org > > > Objet : Re: Network initiated handovers problem statement Draft > > >=20 > > > Hi Julien, > > >=20 > > > Thanks for your feedback on the ID. (I cc the mailing list=20 > > > just to trigger discussions). > > > Can you elaborate a bit more your concern? > > >=20 > > > regards, > > > telemaco > > >=20 > > > RIERA Julien RD-RESA-ISS wrote: > > > > > > > > Hello Telemaco, > > > > I just finished reading the new release of your draft "Network=20 > > > > initiated handovers problem statement". > > > > > > > > This is a very interesting draft, and I agree with most of=20 > > > the points=20 > > > > you raised in it. > > > > I just wanted to highlight that in 4.3 paragraph (Inter-domain=20 > > > > handovers), you wrote that the user just need a=20 > > > relationship with its=20 > > > > service provider. > > > > > > > > If I totally agree that the service provider is the one=20 > > who permit=20 > > > > mobility (as a service), I think in most of today's=20 > > > deployments, user=20 > > > > will need a relationship with the NAP or ISP. Not in order=20 > > > to provide=20 > > > > or not mobility service but at least in order to allow the user=20 > > > > accessing the network. > > > > > > > > Some networks are freely accessible, but in operator=20 > > > deployments, it=20 > > > > should be needed to authenticate the user before letting it=20 > > > access its=20 > > > > network. > > > > > > > > I guess this kind of relationship should be between the=20 > > > user and the=20 > > > > NAP or ISP and not between NAP/ISP and the service provider. > > > > > > > > This is just a detail, but still I wanted to highlight it=20 > > > to you, to=20 > > > > be sure I didn't misunderstand you nor you missed this point. > > > > > > > > Regards, > > > > Julien > > > > > > > > > > > > > > > > > > > > Julien RIERA > > > > *& france telecom* > > > > *Division R&D* > > > > __________________________ > > > > *Ing=E9nieur R&D* > > > > RESA/BWA > > > > Pi=E8ce 212 E > > > > 38-40 Rue du G=E9n=E9ral Leclerc > > > > 92794 Issy-Moulineaux C=E9dex 9 > > > > __________________________ > > > > > > > > T=E9l. : +33.1.45.29.89.94 > > > > Fax : +33.1.45.29.63.07 > > > > > > >=20 > > >=20 > >=20 >=20 > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts >=20 --=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=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D http://www.ict2006.org 13th International Conference in Telecommunications Rui L.A. Aguiar || DD EEEE TTTTT U U AA ruilaa@det.ua.pt || D D E T U U A A Dpt Electronica e Telecomunicacoes|| D D EEE T U U AAAAAAAA Universidade de Aveiro || D D E T U U A A 3810 AVEIRO PORTUGAL || DD EEEE T UU A A Fax:+351.234.381941 or 381128; Phone:+351.234. 381937 or 370200(ext23022= )=20 http://www.av.it.pt/collaborators/personal/ruilaa =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 21 17:00:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLott-0001Co-AJ; Tue, 21 Mar 2006 17:00:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLotr-0001Cj-V8 for mobopts@irtf.org; Tue, 21 Mar 2006 17:00:23 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLotq-0005Uk-MF for mobopts@irtf.org; Tue, 21 Mar 2006 17:00:23 -0500 Received: from [130.129.133.103] (DHCP-Wireless-133-103.ietf65.org [130.129.133.103]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B696A1BAC4D; Tue, 21 Mar 2006 22:59:16 +0100 (CET) Message-ID: <44207773.50008@netlab.nec.de> Date: Tue, 21 Mar 2006 23:00:19 +0100 From: Telemaco Melia User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "mobopts@irtf.org" Subject: Re: [Mobopts] Wednesday dinner References: <442038E8.7040704@iprg.nokia.com> In-Reply-To: <442038E8.7040704@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Rajeev Koodli X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org We should probably organize taxis for everybody. Should we meet in the lobby? telemaco Rajeev Koodli wrote: > > Hello Folks, > > based on input from the Hotel Concierge, I suggest Alfredo Trattoria, > 5404 Lemmon Ave. Dallas (Phone: 214 526-3331). It is about 3 miles. If > you know of a better place nearby, please suggest. > > Regards, > > -Rajeev > > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 21 17:40:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpWx-0002Ad-2C; Tue, 21 Mar 2006 17:40:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLpWw-0002AY-Bf for mobopts@irtf.org; Tue, 21 Mar 2006 17:40:46 -0500 Received: from sehan002bb.han.telia.se ([131.115.18.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLpWu-0007px-Op for mobopts@irtf.org; Tue, 21 Mar 2006 17:40:46 -0500 Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 23:40:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7232.53 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: [Mobopts] RE: Network initiated handovers problem statement Draft Date: Tue, 21 Mar 2006 23:40:35 +0100 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E038A5742@SEHAN021MB.tcad.telia.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mobopts] RE: Network initiated handovers problem statement Draft Thread-Index: AcZNKFB1Q1zEoBLSSVGTRPkfqlg0lgADzkrw From: To: X-OriginalArrivalTime: 21 Mar 2006 22:40:42.0993 (UTC) FILETIME=[7C8F9610:01C64D38] X-Spam-Score: 0.2 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: julien.riera@francetelecom.com, mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, =20 > Hi: >=20 > >=20 > > Yes.. maybe the draft is not too clear on the AAA part but > > that is assumed. Currently it says: > >=20 > > "In addition to obvious security and AAA related challenges > > between the service operator, ISPs and NAPs, the general..." > >=20 > > That should be opened a bit more. Probably a paragraph or two > > or even a subsection. > Yes. But the AAA issues are often too near the agreements of=20 > operators, > and we should avoid touching that. On the other hand, some improved > scenarios maybe will help? I see no problem on addressing and opening the above issue on technical level. We are not going to define e.g. roaming principles anyway rather the basic problems & requirements on AAA level within draft's scope. Cheers, Jouni >=20 > Best Regards >=20 > Rui >=20 > >=20 > > Cheers, > > Jouni > >=20 > > >=20 > > >=20 > > > Julien > > >=20 > > > > -----Message d'origine----- > > > > De : Telemaco Melia [mailto:telemaco.melia@netlab.nec.de]=20 > > > > Envoy=E9 : mardi 21 mars 2006 16:21 > > > > =C0 : RIERA Julien RD-RESA-ISS > > > > Cc : jouni.korhonen@teliasonera.com; mobopts@irtf.org > > > > Objet : Re: Network initiated handovers problem statement Draft > > > >=20 > > > > Hi Julien, > > > >=20 > > > > Thanks for your feedback on the ID. (I cc the mailing list=20 > > > > just to trigger discussions). > > > > Can you elaborate a bit more your concern? > > > >=20 > > > > regards, > > > > telemaco > > > >=20 > > > > RIERA Julien RD-RESA-ISS wrote: > > > > > > > > > > Hello Telemaco, > > > > > I just finished reading the new release of your=20 > draft "Network=20 > > > > > initiated handovers problem statement". > > > > > > > > > > This is a very interesting draft, and I agree with most of=20 > > > > the points=20 > > > > > you raised in it. > > > > > I just wanted to highlight that in 4.3 paragraph=20 > (Inter-domain=20 > > > > > handovers), you wrote that the user just need a=20 > > > > relationship with its=20 > > > > > service provider. > > > > > > > > > > If I totally agree that the service provider is the one=20 > > > who permit=20 > > > > > mobility (as a service), I think in most of today's=20 > > > > deployments, user=20 > > > > > will need a relationship with the NAP or ISP. Not in order=20 > > > > to provide=20 > > > > > or not mobility service but at least in order to=20 > allow the user=20 > > > > > accessing the network. > > > > > > > > > > Some networks are freely accessible, but in operator=20 > > > > deployments, it=20 > > > > > should be needed to authenticate the user before letting it=20 > > > > access its=20 > > > > > network. > > > > > > > > > > I guess this kind of relationship should be between the=20 > > > > user and the=20 > > > > > NAP or ISP and not between NAP/ISP and the service provider. > > > > > > > > > > This is just a detail, but still I wanted to highlight it=20 > > > > to you, to=20 > > > > > be sure I didn't misunderstand you nor you missed this point. > > > > > > > > > > Regards, > > > > > Julien > > > > > > > > > > > > > > > > > > > > > > > > > Julien RIERA > > > > > *& france telecom* > > > > > *Division R&D* > > > > > __________________________ > > > > > *Ing=E9nieur R&D* > > > > > RESA/BWA > > > > > Pi=E8ce 212 E > > > > > 38-40 Rue du G=E9n=E9ral Leclerc > > > > > 92794 Issy-Moulineaux C=E9dex 9 > > > > > __________________________ > > > > > > > > > > T=E9l. : +33.1.45.29.89.94 > > > > > Fax : +33.1.45.29.63.07 > > > > > > > > >=20 > > > >=20 > > >=20 > >=20 > > _______________________________________________ > > Mobopts mailing list > > Mobopts@irtf.org > > https://www1.ietf.org/mailman/listinfo/mobopts > >=20 >=20 > --=20 >=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > http://www.ict2006.org > 13th International Conference in Telecommunications >=20 > Rui L.A. Aguiar || DD EEEE TTTTT U =20 > U AA > ruilaa@det.ua.pt || D D E T U =20 > U A A > Dpt Electronica e Telecomunicacoes|| D D EEE T U =20 > U AAAAAAAA > Universidade de Aveiro || D D E T U =20 > U A A > 3810 AVEIRO PORTUGAL || DD EEEE T UU=20 > A A > Fax:+351.234.381941 or 381128; Phone:+351.234. 381937 or=20 > 370200(ext23022)=20 > http://www.av.it.pt/collaborators/personal/ruilaa > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=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 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Mar 22 15:35:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMA3S-0000p4-Ls; Wed, 22 Mar 2006 15:35:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMA3R-0000mD-HZ for mobopts@irtf.org; Wed, 22 Mar 2006 15:35:41 -0500 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 1FMA3O-0000pM-QQ for mobopts@irtf.org; Wed, 22 Mar 2006 15:35:41 -0500 Received: (qmail 7849 invoked from network); 22 Mar 2006 20:35:35 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;a2a2f0f2e4d216b0223fe7cfc9f21c37; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by ip-11-194-65-202.rev.dyxnet.com with SMTP; 22 Mar 2006 20:35:35 -0000 Received: (qmail 28473 invoked from network); 22 Mar 2006 20:35:35 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;99abec15df9b85c80fe8e84af9fb4b7a; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 22 Mar 2006 20:35:35 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 04:20:53 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 23 Mar 2006 04:20:51 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38019233BF@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mipshop] Input for 802.21 ps document Thread-Index: AcZN7a7qDziv6F4uQPe3BwyNiAsnDAAACaTn From: "DENG, HUI -HCHBJ" To: "Telemaco Melia" , , X-OriginalArrivalTime: 22 Mar 2006 20:20:53.0465 (UTC) FILETIME=[1E6CF490:01C64DEE] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1143059735.378-28470-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.01/0.05 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1143059735.850-7844-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.01 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Mobopts] RE: [Mipshop] Input for 802.21 ps document X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1907211796==" Errors-To: mobopts-bounces@irtf.org --===============1907211796== content-class: urn:content-classes:message Content-Type: text/plain;charset="utf-8" Content-Transfer-Encoding: base64 aXQgaXMgbm90IGNsZWFyIHRoYXQgdGhpcyBkb2N1bWVudCBzaG91bGQgYmUgc2VuZCB0byBtaXBz aG9wIG9yIG1vYm9wdHMsIA0KYW55IGhvdywgSSBjb3B5IHRvIG1vYm9wdHMuDQogDQpBcyBJIHJl Y2FsbGVkIGluIGxhc3QgdGltZSBpZXRmIG1lZXRpbmcsIFJhamVldiBhcnJhbmdlZCB0aGlzIHdv cmsgYWxyZWFkeSwNCldlIGFsc28gd291bGQgbGlrZSB0byBrbm93IGhvdyB0byBwcm9jZWVkIHRo aXMuDQogDQotSHVpDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBUZWxl bWFjbyBNZWxpYSBbbWFpbHRvOnRlbGVtYWNvLm1lbGlhQG5ldGxhYi5uZWMuZGVdIA0KCVNlbnQ6 IDIwMDYtMy0yMyAo5pif5pyf5ZubKSA0OjE3IA0KCVRvOiBtaXBzaG9wQGlldGYub3JnIA0KCUNj OiBqb3VuaS5rb3Job25lbkB0ZWxpYXNvbmVyYS5jb20gDQoJU3ViamVjdDogW01pcHNob3BdIElu cHV0IGZvciA4MDIuMjEgcHMgZG9jdW1lbnQNCgkNCgkNCg0KCUZvbGtzLA0KCQ0KCUJhc2VkIG9u IHRoZSBkaXNjdXNzaW9ucyByYWlzZWQgZHVyaW5nIHRoZSBtaXBzaG9wIHNlc3Npb24gb24gODAy LjIxLA0KCXdlIHdvdWxkIGxpa2UgdG8gc3VnZ2VzdCB0aGUgZm9sbG93aW5nIElEIGRyYWZ0LW1l bGlhLW1vYm9wdHMtbmloby1wcy0wMQ0KCWFzIHBvdGVudGlhbA0KCWlucHV0IGZvciBhIHByb2Js ZW0gc3RhdGVtZW50IGRvY3VtZW50Lg0KCQ0KCUNvbW1lbnRzIGFyZSB3ZWxjb21lLg0KCQ0KCXRl bGVtYWNvDQoJDQoJDQoJDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCglNaXBzaG9wIG1haWxpbmcgbGlzdA0KCU1pcHNob3BAaWV0Zi5vcmcNCglodHRw czovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taXBzaG9wDQoJDQoNCg== Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. --===============1907211796== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============1907211796==-- From mobopts-bounces@irtf.org Thu Mar 23 01:22:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMJDB-0006zt-T5; Thu, 23 Mar 2006 01:22:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMJD9-0006zG-TP for mobopts@irtf.org; Thu, 23 Mar 2006 01:22:20 -0500 Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMJD8-0001R5-Do for mobopts@irtf.org; Thu, 23 Mar 2006 01:22:19 -0500 Received: from [127.0.0.1] (kobe.netlab.nec.de [195.37.70.60]) by kyoto.netlab.nec.de (Postfix) with ESMTP id D25F41BAC4D; Thu, 23 Mar 2006 07:21:01 +0100 (CET) Message-ID: <44223E97.9060000@netlab.nec.de> Date: Thu, 23 Mar 2006 07:22:15 +0100 From: Telemaco Melia User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc3 (X11/20050929) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "DENG, HUI -HCHBJ" References: <834B54D356AA8F46B9B233DD88BEAA38019233BF@hcbjdc2> In-Reply-To: <834B54D356AA8F46B9B233DD88BEAA38019233BF@hcbjdc2> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Rajeev Koodli , mobopts@irtf.org Subject: [Mobopts] Re: [Mipshop] Input for 802.21 ps document X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Thanks Hui for forwarding. Actually, after a talk with Srini and Stefano they suggested to forward the document on the mipshop mailing list to raise discussions. Let's see the comments from other reviewers. regards, Telemaco DENG, HUI -HCHBJ wrote: >it is not clear that this document should be send to mipshop or mobopts,= =20 >any how, I copy to mobopts. >=20 >As I recalled in last time ietf meeting, Rajeev arranged this work alrea= dy, >We also would like to know how to proceed this. >=20 >-Hui > > -----Original Message-----=20 > From: Telemaco Melia [mailto:telemaco.melia@netlab.nec.de]=20 > Sent: 2006-3-23 (=E6=98=9F=E6=9C=9F=E5=9B=9B) 4:17=20 > To: mipshop@ietf.org=20 > Cc: jouni.korhonen@teliasonera.com=20 > Subject: [Mipshop] Input for 802.21 ps document >=09 >=09 > > Folks, >=09 > Based on the discussions raised during the mipshop session on 802.21, > we would like to suggest the following ID draft-melia-mobopts-niho-ps-0= 1 > as potential > input for a problem statement document. >=09 > Comments are welcome. >=09 > telemaco >=09 >=09 >=09 > _______________________________________________ > Mipshop mailing list > Mipshop@ietf.org > https://www1.ietf.org/mailman/listinfo/mipshop >=09 > > =20 > --=20 Telemaco Melia telemaco.melia@netlab.nec.de Research Staff Member Tel: +49 (0) 6221 90511-42 Network Laboratories Fax: +49 (0) 6221 90511-55 NEC Europe Ltd. Web: http://www.netlab.nec.de Kurfrsten-Anlage 36 D-69115 Heidelberg Germany _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Mar 23 10:07:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRPU-0007ZY-09; Thu, 23 Mar 2006 10:07:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMRPS-0007Wa-GL for mobopts@irtf.org; Thu, 23 Mar 2006 10:07:34 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMRPR-0006TA-4f for mobopts@irtf.org; Thu, 23 Mar 2006 10:07:34 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k2NESOx00523 for ; Thu, 23 Mar 2006 06:28:24 -0800 X-mProtect: <200603231428> Nokia Silicon Valley Messaging Protection Received: from danira-pool05548.americas.nokia.com (10.241.55.48, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpde2YkMI; Thu, 23 Mar 2006 06:28:23 PST Message-ID: <4422B9A7.3030100@iprg.nokia.com> Date: Thu, 23 Mar 2006 07:07:19 -0800 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mobopts@irtf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Mobopts] presentations X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Presenters: please send me your presentation files. Christian and Telemaco: please send me your minutes. Thanks all for a good meeting! Regards, -Rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Mar 27 10:10:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtMo-0006xH-8j; Mon, 27 Mar 2006 10:10:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNtMm-0006vf-PR for mobopts@irtf.org; Mon, 27 Mar 2006 10:10:48 -0500 Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNtMl-0002Fo-8R for mobopts@irtf.org; Mon, 27 Mar 2006 10:10:48 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id D43F355CCD; Mon, 27 Mar 2006 17:10:46 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 02933-09; Mon, 27 Mar 2006 17:10:45 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 5CBE555CCC; Mon, 27 Mar 2006 17:10:45 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 0F45764D17F; Mon, 27 Mar 2006 17:10:42 +0200 (CEST) Date: Mon, 27 Mar 2006 17:10:42 +0200 From: Juergen Schoenwaelder To: mobopts@irtf.org, irsg@icir.org Message-ID: <20060327151042.GC24815@boskop.local> Mail-Followup-To: mobopts@irtf.org, irsg@icir.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: Subject: [Mobopts] review of X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, I have reviewed and I believe this document is basically ready for publication. It contains a nice survey of MIPv6 optimizations which I consider useful. Note that I am not an MIPv6 expert - I understand its basic principles, but my expertise clearly lies in other areas. Given my background, I would have loved to see also some discussion of operational issues of the various approaches (kind of management considerations), that is, how difficult will it be to debug problems, what needs to be configured where, when and by whom, what needs to be monitored to detect abuse or ongoing attacks, etc. On the operational side, simplicity usually wins and hence understanding the management impact of the various proposals is IMHO an important criterium for the evaluation. I have a more general observation I like to raise: I counted 29 citations of Internet Drafts out of 62 citations in total, which means almost 47% of all citations are "work in progress". I checked up to reference 22 and it seems that 5 out of the 17 cited IDs among the first 22 references have already expired. How much should we be concerned about publishing an RFC which points to quite a bit of documents not really archived (in the sense that there is not a defined entity in charge of maintaining access to the cited documents)? This issue clearly has a wider scope and may require some discussion or a policy within the IRTF as a whole. I did not go back to the document to check what the purpose of those citations are, that is, whether the main optimization idea is sufficiently summarized in the mobopts draft under review so that the reference more serves as a way to give credits. In such cases, I would not see a problem. If, however, a reference is really needed to fully grasp a proposal, then having dangling pointers is kind of problematic. Next to these quite general comments, I do have a few concrete comments and editorial suggestions: a) I suggest to move the first paragraph of section 1 to the end of section one. I find it a bit strange to start an introduction by explaining who has reviewed the document. After moving the paragraph, the first sentence in the now first paragraph should be reworded so that it does start a bit more reader friendly and not just "RFC 3775 [42] specifies". b) Section 1.1 page 4 last line: Do you really mean "not reluctant"? c) Section 1.1 page 5 last bullet: s/in the certifications/in certificates d) Section 1.2 page 6: introduce acronym BU the first time you use it e) Section 2 surprises me. The usual convention is to acknowledge contributors and reviewers at the end of an RFC but not in the middle. I suggest to move this section to the very end. Note that this also requires changes in the introduction. f) Section 4.7 talks about the credit-based authorization approach while 4.8 talks about heuristics. I am wondering whether credit-based authorization is no just another heuristic approach. g) Section 5.2: I would like to know whether there are "standard" scenarios people use in the community to compare the various approaches. Ideally, such "standard" scenarios would be derived from real-world measurements. If such "standard" scenarios exist, it might be useful to point to them so that researchers can easily publish comparable results. If such "standard" scenarios do not exist, you might want to raise the construction of such things in order to produce comparable results as a potential future work item. h) idnits complains that the document does not distinguish between normative and informative references. I guess all references are informative and I have no idea how strict today's rules are. i) Reference [48] says "to be presented" and the date is November 2004 - perhaps this actually got meanwhile presented? j) Given my background, I would have loved to see also some discussion of operational issues of the various approaches (kind of management considerations), that is, how difficult will it be to debug problems, what needs to be configured where, when and by whom, what needs to be monitored to detect abuse or ongoing attacks, etc. k) Reference [45] seems to be a bit screwed up. l) How useful is it to cite mailing list messages (I am referring to references [59] and [60])? Are there no other suitable references for the "optimistic" approach? m) Where was [8] published? /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Mar 27 19:50:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO2Q5-0008JU-C3; Mon, 27 Mar 2006 19:50:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO2Q4-0008JP-Lg for mobopts@irtf.org; Mon, 27 Mar 2006 19:50:48 -0500 Received: from vidi.ucdavis.edu ([169.237.105.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO2Q3-0005PT-9r for mobopts@irtf.org; Mon, 27 Mar 2006 19:50:48 -0500 Received: from localhost (localhost [127.0.0.1]) by vidi.ucdavis.edu (8.13.3/8.13.1/it-std-5.2.0) with ESMTP id k2S0ojHP023189 for ; Mon, 27 Mar 2006 16:50:45 -0800 (PST) Date: Mon, 27 Mar 2006 16:50:45 -0800 (PST) From: Fan Zhao X-X-Sender: fanzhao@vidi.ucdavis.edu To: mobopts@irtf.org In-Reply-To: <20060327151042.GC24815@boskop.local> Message-ID: References: <20060327151042.GC24815@boskop.local> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Mobopts] questions about EBU/CBA X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, I have some questions about EBU/CBA: 1. The way that EBU works assumes that MN knows what next network it will associate with during handover. However this information may not be available to MN always. 2. What is the incentive for CN to implement the CBA as there is no penalty if CN is involved into this kind of reflective DoS attack and also the fact is that the server (CN) in the current Internet does not care about its processing overhead unless itself is under DoS attack. I also have concerns that some application preformance may be hurt by CBA, which might again reduce the incentive to support CBA. It will be great that these issues can be addressed in the next versions of your drafts. Sincerely, fan _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Mar 27 20:48:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO3Jo-0006JI-NC; Mon, 27 Mar 2006 20:48:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO3Jn-0006JD-U5 for mobopts@irtf.org; Mon, 27 Mar 2006 20:48:23 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO3Jk-00082v-DJ for mobopts@irtf.org; Mon, 27 Mar 2006 20:48:23 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FO3Jf-0001bN-JK; Tue, 28 Mar 2006 03:48:19 +0200 Received: from [10.0.0.30] (unknown [207.191.27.122]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 83F52853F; Tue, 28 Mar 2006 03:48:14 +0200 (CEST) Message-ID: <442895DF.4040603@tm.uka.de> Date: Mon, 27 Mar 2006 19:48:15 -0600 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; 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: Fan Zhao Subject: Re: [Mobopts] questions about EBU/CBA References: <20060327151042.GC24815@boskop.local> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.5 (--) X-Spam-Status: No X-Spam-Report: -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.1 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Fan, thanks for your comments. My responses are in-line. > 1. The way that EBU works assumes that MN knows > what next network it will associate with during handover. > However this information may not be available to MN always. For proactive use of EBU, yes. In this case, the MN must use, e.g., Media-Independent Information Services to find out about potential target links and acquire the prefixes in use on those links. The MN can then send a proactive EBU message prior to handoff and switch to the new link once an EBA message is received on the old link. For reactive use of EBU, the MN does not need to know about its future point of attachment. > 2. What is the incentive for CN to implement the CBA as there > is no penalty if CN is involved into this kind of reflective > DoS attack and also the fact is that the server (CN) in the > current Internet does not care about its processing overhead > unless itself is under DoS attack. I also have concerns that > some application preformance may be hurt by CBA, which might > again reduce the incentive to support CBA. Well, as a content provider, wouldn't you get upset if someone misused resources of your servers for a flooding attack? And besides resource consumption, packets that your servers would send to the node under attack would originate from a source address that belongs to your domain. Having said that, and given that CBA is a rather simple mechanism, I'm positive that implementing CBA is worthwhile from the CN's perspective. Referring to your concern about the performance impact on applications, there are two things to consider: First, Mobile IPv6 with EBU/CBA is always at least as good as standard Mobile IPv6. Second, CBA works fine for all applications where the data sent by the MN and data sent by the CN are roughly balanced. CBA may run out of credit--- and hence preclude further route-optimized traffic until reachability verification completes--- if the CN sends at a much higher rate than the MN. Whether or not this happens depends on how much the asymmetry in data rates is, as well as on the speed of credit aging. Fortunately, credit aging is designed to work well for applications as asymmetric as a TCP download from the CN to the MN. Hope this helps. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Fan Zhao wrote: > Hi Christian, > > I have some questions about EBU/CBA: > 1. The way that EBU works assumes that MN knows > what next network it will associate with during handover. > However this information may not be available to MN always. > 2. What is the incentive for CN to implement the CBA as there > is no penalty if CN is involved into this kind of reflective > DoS attack and also the fact is that the server (CN) in the > current Internet does not care about its processing overhead > unless itself is under DoS attack. I also have concerns that > some application preformance may be hurt by CBA, which might > again reduce the incentive to support CBA. > > It will be great that these issues can be addressed in the > next versions of your drafts. > > Sincerely, > fan _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Mar 27 23:14:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO5ba-0002TR-Qz; Mon, 27 Mar 2006 23:14:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FO5bZ-0002T9-JZ for mobopts@irtf.org; Mon, 27 Mar 2006 23:14:53 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FO5bY-0005Qc-5V for mobopts@irtf.org; Mon, 27 Mar 2006 23:14:53 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4656289884; Tue, 28 Mar 2006 07:14:50 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id ED01389875; Tue, 28 Mar 2006 07:14:48 +0300 (EEST) Message-ID: <4428B81F.1090705@kolumbus.fi> Date: Mon, 27 Mar 2006 20:14:23 -0800 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fan Zhao Subject: Re: [Mobopts] questions about EBU/CBA References: <20060327151042.GC24815@boskop.local> <442895DF.4040603@tm.uka.de> In-Reply-To: <442895DF.4040603@tm.uka.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Christian Vogt , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org >>2. What is the incentive for CN to implement the CBA as there >>is no penalty if CN is involved into this kind of reflective >>DoS attack and also the fact is that the server (CN) in the >>current Internet does not care about its processing overhead >>unless itself is under DoS attack. I also have concerns that >>some application preformance may be hurt by CBA, which might >>again reduce the incentive to support CBA. >> >> Good question! If something is entirely up to a party that does not get a direct benefit from supporting that something, then this is often proven to lead to problems. However, there are certain things that we can do: o Setting the proper standards requirements (e.g. MUST implement and use). In many cases this is sufficient, unless the implementation is really expensive and complicated. o Defining our protocols in such a way that they simply do not work without that implementation in the other end. o Avoiding complex designs that would be burdensome to implement. --Jari _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 28 22:09:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOR3Q-0005Md-Q2; Tue, 28 Mar 2006 22:09:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOR3P-0005MX-Rs for mobopts@irtf.org; Tue, 28 Mar 2006 22:09:03 -0500 Received: from vidi.ucdavis.edu ([169.237.105.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOR3O-0004z2-DR for mobopts@irtf.org; Tue, 28 Mar 2006 22:09:03 -0500 Received: from localhost (localhost [127.0.0.1]) by vidi.ucdavis.edu (8.13.6/8.13.1/it-std-5.2.0) with ESMTP id k2T390rW008015; Tue, 28 Mar 2006 19:09:00 -0800 (PST) Date: Tue, 28 Mar 2006 19:09:00 -0800 (PST) From: Fan Zhao X-X-Sender: fanzhao@vidi.ucdavis.edu To: Christian Vogt Subject: CBA Re: [Mobopts] questions about EBU/CBA In-Reply-To: <442895DF.4040603@tm.uka.de> Message-ID: References: <20060327151042.GC24815@boskop.local> <442895DF.4040603@tm.uka.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, let me reply in seperate emails. > > 2. What is the incentive for CN to implement the CBA as there > > is no penalty if CN is involved into this kind of reflective > > DoS attack and also the fact is that the server (CN) in the > > current Internet does not care about its processing overhead > > unless itself is under DoS attack. I also have concerns that > > some application preformance may be hurt by CBA, which might > > again reduce the incentive to support CBA. > > Well, as a content provider, wouldn't you get upset if someone misused > resources of your servers for a flooding attack? The redirection attack should be addressed by address verification. Due to the lack of address verification in EBU, CBA is invented; but CBA cannot distinguish between the good and the bad, thus it is a double-sided sword. 1) If the target of the attacker is the content provider itself (CN in this context), it is similar with supporting many MNs. CBA is not the solution to help CN because both good and bad MN (the attacker) receives the same treatment. Also there are many other ways to flood CN. 2) If the target of the attacker is other entity that is not in the same domain of CN (If the victim is in the same domain as CN, it is similar with flooding CN as the link to this domain is affected.), from the perspective of economics, CN should consider whether it is worth sacrificing the performance experienced by (many) good MNs for the protection of other entity that CN in fact does not care about. > > And besides resource consumption, packets that your servers would send > to the node under attack would originate from a source address that > belongs to your domain. Then what? The reality is that there is no penalty for CN to become a reflector: 1) You cannot block CN because it is in a different domain; 2) The service of CN is needed by other MNs, thus it cannot be shut down. So the one motivated is MN itself. The history that MN communicates with CN can be one kind of "credit", which is represented by hash chain in draft-zhao-mip6-rr-ext-01 and is used to distinuguish the good from the bad. > > Having said that, and given that CBA is a rather simple mechanism, I'm > positive that implementing CBA is worthwhile from the CN's perspective. There is a scalability issue for CN: even though CBA for each flow is light-weight, it could become a burden given many flows. There are always costs for security. > > Referring to your concern about the performance impact on applications, > there are two things to consider: First, Mobile IPv6 with EBU/CBA is > always at least as good as standard Mobile IPv6. Can you please elaborate? > Second, CBA works fine > for all applications where the data sent by the MN and data sent by the > CN are roughly balanced. > > CBA may run out of credit--- and hence preclude further route-optimized > traffic until reachability verification completes--- if the CN sends at > a much higher rate than the MN. Whether or not this happens depends on > how much the asymmetry in data rates is, as well as on the speed of > credit aging. Fortunately, credit aging is designed to work well for > applications as asymmetric as a TCP download from the CN to the MN. I am also wondering how the parameters, CreditAgingFactor and CreditAgingInterval, are set up? It should be application-specific rather than static. So a procedure to derive those parameters dynamically might need to be added in the next version. Sincerely, fan > > Hope this helps. > > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > > > > Fan Zhao wrote: > > Hi Christian, > > > > I have some questions about EBU/CBA: > > 1. The way that EBU works assumes that MN knows > > what next network it will associate with during handover. > > However this information may not be available to MN always. > > 2. What is the incentive for CN to implement the CBA as there > > is no penalty if CN is involved into this kind of reflective > > DoS attack and also the fact is that the server (CN) in the > > current Internet does not care about its processing overhead > > unless itself is under DoS attack. I also have concerns that > > some application preformance may be hurt by CBA, which might > > again reduce the incentive to support CBA. > > > > It will be great that these issues can be addressed in the > > next versions of your drafts. > > > > Sincerely, > > fan > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 28 22:25:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FORJP-0005gU-HV; Tue, 28 Mar 2006 22:25:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FORJO-0005eE-SA for mobopts@irtf.org; Tue, 28 Mar 2006 22:25:34 -0500 Received: from vidi.ucdavis.edu ([169.237.105.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FORJN-0005ch-HQ for mobopts@irtf.org; Tue, 28 Mar 2006 22:25:34 -0500 Received: from localhost (localhost [127.0.0.1]) by vidi.ucdavis.edu (8.13.6/8.13.1/it-std-5.2.0) with ESMTP id k2T3PWJ1008126; Tue, 28 Mar 2006 19:25:32 -0800 (PST) Date: Tue, 28 Mar 2006 19:25:32 -0800 (PST) From: Fan Zhao X-X-Sender: fanzhao@vidi.ucdavis.edu To: Jari Arkko Subject: Re: [Mobopts] questions about EBU/CBA In-Reply-To: <4428B81F.1090705@kolumbus.fi> Message-ID: References: <20060327151042.GC24815@boskop.local> <442895DF.4040603@tm.uka.de> <4428B81F.1090705@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Christian Vogt , mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Jari, I think it works if like that. The reasons I brought out my questions are just because 1) In the protocol design sometimes the assumption that a communicating peer is compliant may not be true. 2) Incentive needs to be considered in the protocol design, especially security mechanisms always come with costs. Sincerely, fan On Mon, 27 Mar 2006, Jari Arkko wrote: > Good question! If something is entirely up to a party > that does not get a direct benefit from supporting > that something, then this is often proven to lead to > problems. However, there are certain things that > we can do: > > o Setting the proper standards requirements (e.g. MUST > implement and use). In many cases this is sufficient, > unless the implementation is really expensive and > complicated. > > o Defining our protocols in such a way that they > simply do not work without that implementation > in the other end. > > o Avoiding complex designs that would be burdensome > to implement. > > --Jari > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Tue Mar 28 22:41:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FORZD-0005dA-2z; Tue, 28 Mar 2006 22:41:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FORZB-0005av-Os for mobopts@irtf.org; Tue, 28 Mar 2006 22:41:53 -0500 Received: from vidi.ucdavis.edu ([169.237.105.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FORZA-0006AU-BY for mobopts@irtf.org; Tue, 28 Mar 2006 22:41:53 -0500 Received: from localhost (localhost [127.0.0.1]) by vidi.ucdavis.edu (8.13.6/8.13.1/it-std-5.2.0) with ESMTP id k2T3fpAr008291; Tue, 28 Mar 2006 19:41:51 -0800 (PST) Date: Tue, 28 Mar 2006 19:41:51 -0800 (PST) From: Fan Zhao X-X-Sender: fanzhao@vidi.ucdavis.edu To: Christian Vogt Subject: Re: [Mobopts] questions about EBU/CBA In-Reply-To: <442895DF.4040603@tm.uka.de> Message-ID: References: <20060327151042.GC24815@boskop.local> <442895DF.4040603@tm.uka.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, I am wondering if there are better terms rather than reactive registration and proactive registration because in reactive registration HoT is proactively elicited. Sincerely, fan On Mon, 27 Mar 2006, Christian Vogt wrote: > Hi Fan, > > thanks for your comments. My responses are in-line. > > > 1. The way that EBU works assumes that MN knows > > what next network it will associate with during handover. > > However this information may not be available to MN always. > > For proactive use of EBU, yes. In this case, the MN must use, e.g., > Media-Independent Information Services to find out about potential > target links and acquire the prefixes in use on those links. The MN can > then send a proactive EBU message prior to handoff and switch to the new > link once an EBA message is received on the old link. > > For reactive use of EBU, the MN does not need to know about its future > point of attachment. > > > 2. What is the incentive for CN to implement the CBA as there > > is no penalty if CN is involved into this kind of reflective > > DoS attack and also the fact is that the server (CN) in the > > current Internet does not care about its processing overhead > > unless itself is under DoS attack. I also have concerns that > > some application preformance may be hurt by CBA, which might > > again reduce the incentive to support CBA. > > Well, as a content provider, wouldn't you get upset if someone misused > resources of your servers for a flooding attack? > > And besides resource consumption, packets that your servers would send > to the node under attack would originate from a source address that > belongs to your domain. > > Having said that, and given that CBA is a rather simple mechanism, I'm > positive that implementing CBA is worthwhile from the CN's perspective. > > Referring to your concern about the performance impact on applications, > there are two things to consider: First, Mobile IPv6 with EBU/CBA is > always at least as good as standard Mobile IPv6. Second, CBA works fine > for all applications where the data sent by the MN and data sent by the > CN are roughly balanced. > > CBA may run out of credit--- and hence preclude further route-optimized > traffic until reachability verification completes--- if the CN sends at > a much higher rate than the MN. Whether or not this happens depends on > how much the asymmetry in data rates is, as well as on the speed of > credit aging. Fortunately, credit aging is designed to work well for > applications as asymmetric as a TCP download from the CN to the MN. > > Hope this helps. > > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > > > > Fan Zhao wrote: > > Hi Christian, > > > > I have some questions about EBU/CBA: > > 1. The way that EBU works assumes that MN knows > > what next network it will associate with during handover. > > However this information may not be available to MN always. > > 2. What is the incentive for CN to implement the CBA as there > > is no penalty if CN is involved into this kind of reflective > > DoS attack and also the fact is that the server (CN) in the > > current Internet does not care about its processing overhead > > unless itself is under DoS attack. I also have concerns that > > some application preformance may be hurt by CBA, which might > > again reduce the incentive to support CBA. > > > > It will be great that these issues can be addressed in the > > next versions of your drafts. > > > > Sincerely, > > fan > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Mar 29 00:34:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOTKG-0004yz-QF; Wed, 29 Mar 2006 00:34:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOTKF-0004yu-FJ for mobopts@irtf.org; Wed, 29 Mar 2006 00:34:35 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOTKD-0001OI-OA for mobopts@irtf.org; Wed, 29 Mar 2006 00:34:35 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FOTK8-0004oQ-U8; Wed, 29 Mar 2006 07:34:32 +0200 Received: from [10.0.0.21] (vpn-cl-162-232.rz.uni-karlsruhe.de [141.3.162.232]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id B22688648; Wed, 29 Mar 2006 07:34:27 +0200 (CEST) Message-ID: <442A1C61.5050301@tm.uka.de> Date: Tue, 28 Mar 2006 23:34:25 -0600 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; 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: Fan Zhao Subject: Re: CBA Re: [Mobopts] questions about EBU/CBA References: <20060327151042.GC24815@boskop.local> <442895DF.4040603@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.7 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello Fan! Some comments in-line: >> Well, as a content provider, wouldn't you get upset if someone >> misused resources of your servers for a flooding attack? > > The redirection attack should be addressed by address verification. > Due to the lack of address verification in EBU, CBA is invented; but > CBA cannot distinguish between the good and the bad, thus it is a > double-sided sword. > > 1) If the target of the attacker is the content provider itself (CN > in this context), it is similar with supporting many MNs. CBA is not > the solution to help CN because both good and bad MN (the attacker) > receives the same treatment. Also there are many other ways to flood > CN. I wasn't concerned about an attack on the CN (i.e., content provider), but rather an attack against a third party that the CN becomed involved in. Such an attack binds resources of the CN, which the CN could otherwise be spent on useful traffic. Still, you are right in saying that the resources bound for the attack may not have a noticable impact if the CN is well-provisioned. But the resources consumed by CBA are minor, too--- especially in the case where the CN is strong. If this is not incentive enough, it is up to the protocol specification to make either preemtive reachability verification, or concurrent reachability verification plus CBA a "MUST" to safeguard the Internet as a whole. Things are actually a bit similar with TCP's congestion-avoidance mechanism. Congestion avoidance ensures fair share of network resources between concurrent connections. Like CBA, congestion avoidance is a sender-based mechanism. Non-compliance typically leads to better throughput results for a single connection at the cost of other connections. But most CNs are nevertheless TCP-friendly. While this comparison is not 100% correct, it does show that there is a willingness to support mechanisms even if the benefits of doing so cannot be directly reaped. >> Referring to your concern about the performance impact on >> applications, there are two things to consider: First, Mobile IPv6 >> with EBU/CBA is always at least as good as standard Mobile IPv6. > > Can you please elaborate? With EBU/CBA, the MN can send and receive packets earlier than with standard Mobile IPv6 provided that it has sufficient credit. If it has sufficient credit, EBU/CBA obviously performs better than standard Mobile IPv6. If the MN does not have sufficient credit, there are two options: (a) The CN directs the packets to the MN's HoA. Then, communications can at least continue, albeit via a sub-optimal path. This may be an advantage over standard Mobile IPv6. (b) The CN drops the packets that it cannot send to the MN CoA directly. In this case, the performance of EBU/CBA is the same as that of standard Mobile IPv6 for packets that the CN sends. The MN can still send packets from an unverified CoA, however. >> Second, CBA works fine for all applications where the data sent by >> the MN and data sent by the CN are roughly balanced. >> >> CBA may run out of credit--- and hence preclude further >> route-optimized traffic until reachability verification >> completes--- if the CN sends at a much higher rate than the MN. >> Whether or not this happens depends on how much the asymmetry in >> data rates is, as well as on the speed of credit aging. >> Fortunately, credit aging is designed to work well for applications >> as asymmetric as a TCP download from the CN to the MN. > > I am also wondering how the parameters, CreditAgingFactor and > CreditAgingInterval, are set up? It should be application-specific > rather than static. So a procedure to derive those parameters > dynamically might need to be added in the next version. CreditAgingFactor and CreditAgingInterval are static parameters. They are chosen in a way that a MN downloading data from a CN can earn sufficient credit even though the MN sends much less than the CN. Assume a PMTU of 1500 bytes. Say, the CN sends full-sized TCP segments, and the MN sends a TCP ACK without any TCP options for every second segment. This is the worst asymmetry that can happen with TCP (given PMTU = 1500 bytes). Further assume, that the nodes need 500ms for the concurrent CoA test. Given and consumed credit equals the size of packets (in bytes) received and sent by the CN, respectively. The question is how long the MN needs to collect credit before simple CBA allows it to do an optimized handoff. So, what's the ratio between the size of packets that the CN sends and the size of packets that the MN sends? The CN sends two full-sized TCP segments. This is 3000 bytes or 3000 credits. The MN sends a TCP ACK upon reception of the second TCP segment. This ACK is composed as follows: IPv6 header (40 bytes) Destination Options Extension Header (24 bytes) HoA Option Padding TCP ACK (20 bytes) Hence, the entire packet is 84 bytes big, and worth 84 credits. The asymmetry ratio between the CN-to-MN flow and the MN-to-CN flow is thus 3000 bytes / 84 bytes = 35.7. The MN therefore needs at least 500ms * 35.7 = 17.9 seconds between two successive handoffs for acquiring sufficient credit for a 500-ms concurrent CoA test. The aging interval should be no shorter than 2 * 17.9 = 35.7 seconds, however, if the credit is cut in half after each such interval. (Folks were talking about 30-seconds to 1-minute aging intervals anyway.) Note that the assumed RTT of 500ms just for a concurrent CoA test is quite long. In many realistic scenarios will the RTT be lower. Moreover, the MN may have more to say than just ACK's. And it gets credit for duplicate ACK's, too. Hope this helps. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Fan Zhao wrote: > Hi Christian, > > let me reply in seperate emails. > > >>>2. What is the incentive for CN to implement the CBA as there >>>is no penalty if CN is involved into this kind of reflective >>>DoS attack and also the fact is that the server (CN) in the >>>current Internet does not care about its processing overhead >>>unless itself is under DoS attack. I also have concerns that >>>some application preformance may be hurt by CBA, which might >>>again reduce the incentive to support CBA. >> >>Well, as a content provider, wouldn't you get upset if someone misused >>resources of your servers for a flooding attack? > > The redirection attack should be addressed by address verification. > Due to the lack of address verification in EBU, CBA is invented; > but CBA cannot distinguish between the good and the bad, thus it is a > double-sided sword. > > 1) If the target of the attacker is the content provider itself (CN > in this context), it is similar with supporting many MNs. CBA is not the > solution to help CN because both good and bad MN (the attacker) receives > the same treatment. Also there are many other ways to flood CN. > > 2) If the target of the attacker is other entity that is not in the > same domain of CN (If the victim is in the same domain as CN, it is similar > with flooding CN as the link to this domain is affected.), from the > perspective of economics, CN should consider whether it is worth > sacrificing the performance experienced by (many) good MNs for > the protection of other entity that CN in fact does not care about. > > >>And besides resource consumption, packets that your servers would send >>to the node under attack would originate from a source address that >>belongs to your domain. > > Then what? The reality is that there is no penalty for CN to become > a reflector: 1) You cannot block CN because it is in a different domain; > 2) The service of CN is needed by other MNs, thus it cannot be shut down. > > So the one motivated is MN itself. The history that MN communicates with > CN can be one kind of "credit", which is represented by hash chain > in draft-zhao-mip6-rr-ext-01 and is used to distinuguish the good from > the bad. > > >>Having said that, and given that CBA is a rather simple mechanism, I'm >>positive that implementing CBA is worthwhile from the CN's perspective. > > There is a scalability issue for CN: even though CBA for each flow > is light-weight, it could become a burden given many > flows. There are always costs for security. > > >>Referring to your concern about the performance impact on applications, >>there are two things to consider: First, Mobile IPv6 with EBU/CBA is >>always at least as good as standard Mobile IPv6. > > Can you please elaborate? > > >>Second, CBA works fine >>for all applications where the data sent by the MN and data sent by the >>CN are roughly balanced. >> >>CBA may run out of credit--- and hence preclude further route-optimized >>traffic until reachability verification completes--- if the CN sends at >>a much higher rate than the MN. Whether or not this happens depends on >>how much the asymmetry in data rates is, as well as on the speed of >>credit aging. Fortunately, credit aging is designed to work well for >>applications as asymmetric as a TCP download from the CN to the MN. > > I am also wondering how the parameters, CreditAgingFactor and > CreditAgingInterval, are set up? It should be application-specific > rather than static. So a procedure to derive those parameters > dynamically might need to be added in the next version. > > Sincerely, > fan > > >>Hope this helps. >> >>- Christian >> >>-- >>Christian Vogt, Institute of Telematics, University of Karlsruhe >>www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Mar 29 00:38:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOTOE-0007nk-8F; Wed, 29 Mar 2006 00:38:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOTOD-0007nf-Es for mobopts@irtf.org; Wed, 29 Mar 2006 00:38:41 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOTOC-0001Ta-57 for mobopts@irtf.org; Wed, 29 Mar 2006 00:38:41 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FOTO5-0004zF-1A; Wed, 29 Mar 2006 07:38:39 +0200 Received: from [10.0.0.21] (vpn-cl-162-232.rz.uni-karlsruhe.de [141.3.162.232]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 3962E8648; Wed, 29 Mar 2006 07:38:31 +0200 (CEST) Message-ID: <442A1D54.2090901@tm.uka.de> Date: Tue, 28 Mar 2006 23:38:28 -0600 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; 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: Fan Zhao Subject: Re: [Mobopts] questions about EBU/CBA References: <20060327151042.GC24815@boskop.local> <442895DF.4040603@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.7 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Fan, the "registration" does not include the RR according to RFC3775 terminology. Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Fan Zhao wrote: > Hi Christian, > > I am wondering if there are better terms > rather than reactive registration and proactive registration > because in reactive registration HoT is > proactively elicited. > > Sincerely, > fan > > On Mon, 27 Mar 2006, Christian Vogt wrote: _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Mar 29 19:34:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOl7T-0002ps-Jd; Wed, 29 Mar 2006 19:34:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOl7S-0002pn-Jm for mobopts@irtf.org; Wed, 29 Mar 2006 19:34:34 -0500 Received: from veni.ucdavis.edu ([169.237.105.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOl7R-0002mq-0e for mobopts@irtf.org; Wed, 29 Mar 2006 19:34:34 -0500 Received: from localhost (localhost [127.0.0.1]) by veni.ucdavis.edu (8.13.6/8.13.1/it-std-5.2.0) with ESMTP id k2U0YVeZ002292; Wed, 29 Mar 2006 16:34:31 -0800 (PST) Date: Wed, 29 Mar 2006 16:34:31 -0800 (PST) From: Fan Zhao X-X-Sender: fanzhao@veni.ucdavis.edu To: Christian Vogt Subject: Re: CBA Re: [Mobopts] questions about EBU/CBA In-Reply-To: <442A1C61.5050301@tm.uka.de> Message-ID: References: <20060327151042.GC24815@boskop.local> <442895DF.4040603@tm.uka.de> <442A1C61.5050301@tm.uka.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, I saw you skipped many of my comments. Does it mean you agree on them? Please see my reply below. On Tue, 28 Mar 2006, Christian Vogt wrote: > Hello Fan! > > Some comments in-line: > > >> Well, as a content provider, wouldn't you get upset if someone > >> misused resources of your servers for a flooding attack? > > > > The redirection attack should be addressed by address verification. > > Due to the lack of address verification in EBU, CBA is invented; but > > CBA cannot distinguish between the good and the bad, thus it is a > > double-sided sword. > > > > 1) If the target of the attacker is the content provider itself (CN > > in this context), it is similar with supporting many MNs. CBA is not > > the solution to help CN because both good and bad MN (the attacker) > > receives the same treatment. Also there are many other ways to flood > > CN. > > I wasn't concerned about an attack on the CN (i.e., content provider), I knew. Just include it for the completeness. > but rather an attack against a third party that the CN becomed involved > in. Yes. I did mention it in the original post. > Such an attack binds resources of the CN, which the CN could > otherwise be spent on useful traffic. > > Still, you are right in saying that the resources bound for the attack > may not have a noticable impact if the CN is well-provisioned. This is not all I mean. But I understand CBA is not for that purpose. > But the resources consumed by CBA are minor, too--- especially in the > case where the CN is strong. I am not just looking at the resources consumed by CBA, but also the impacts on the performances of good MNs, which you did not address here. > If this is not incentive enough, it is up > to the protocol specification to make either preemtive reachability > verification, or concurrent reachability verification plus CBA a "MUST" > to safeguard the Internet as a whole. My main concern is whether CBA is the best choice. > > Things are actually a bit similar with TCP's congestion-avoidance > mechanism. Congestion avoidance ensures fair share of network resources > between concurrent connections. Like CBA, congestion avoidance is a > sender-based mechanism. Non-compliance typically leads to better > throughput results for a single connection at the cost of other > connections. But most CNs are nevertheless TCP-friendly. > > While this comparison is not 100% correct, it does show that there is a > willingness to support mechanisms even if the benefits of doing so > cannot be directly reaped. I understand your points. However many cases already show TCP behaves badly with non-compliant sender/receiver. A standard should not be just working but the best from all available. > > >> Referring to your concern about the performance impact on > >> applications, there are two things to consider: First, Mobile IPv6 > >> with EBU/CBA is always at least as good as standard Mobile IPv6. > > > > Can you please elaborate? > > With EBU/CBA, the MN can send and receive packets earlier than with > standard Mobile IPv6 provided that it has sufficient credit. If it has > sufficient credit, EBU/CBA obviously performs better than standard > Mobile IPv6. > > If the MN does not have sufficient credit, there are two options: > > (a) The CN directs the packets to the MN's HoA. Then, communications > can at least continue, albeit via a sub-optimal path. This may be an > advantage over standard Mobile IPv6. > > (b) The CN drops the packets that it cannot send to the MN CoA > directly. In this case, the performance of EBU/CBA is the same as that > of standard Mobile IPv6 for packets that the CN sends. Why? In MIP6, CN always sends the packets whenever requested, right? But here CN has to drop it. But you may count the advantages that EBU results in. I do not know which performance is better definitely in this case. > The MN can still > send packets from an unverified CoA, however. > > >> Second, CBA works fine for all applications where the data sent by > >> the MN and data sent by the CN are roughly balanced. > >> > >> CBA may run out of credit--- and hence preclude further > >> route-optimized traffic until reachability verification > >> completes--- if the CN sends at a much higher rate than the MN. > >> Whether or not this happens depends on how much the asymmetry in > >> data rates is, as well as on the speed of credit aging. > >> Fortunately, credit aging is designed to work well for applications > >> as asymmetric as a TCP download from the CN to the MN. > > > > I am also wondering how the parameters, CreditAgingFactor and > > CreditAgingInterval, are set up? It should be application-specific > > rather than static. So a procedure to derive those parameters > > dynamically might need to be added in the next version. > > CreditAgingFactor and CreditAgingInterval are static parameters. They > are chosen in a way that a MN downloading data from a CN can earn > sufficient credit even though the MN sends much less than the CN. > > Assume a PMTU of 1500 bytes. Say, the CN sends full-sized TCP segments, > and the MN sends a TCP ACK without any TCP options for every second > segment. This is the worst asymmetry that can happen with TCP (given > PMTU = 1500 bytes). Further assume, that the nodes need 500ms for the > concurrent CoA test. > > Given and consumed credit equals the size of packets (in bytes) received > and sent by the CN, respectively. > > The question is how long the MN needs to collect credit before simple > CBA allows it to do an optimized handoff. So, what's the ratio between > the size of packets that the CN sends and the size of packets that the > MN sends? > > The CN sends two full-sized TCP segments. This is 3000 bytes or 3000 > credits. > > The MN sends a TCP ACK upon reception of the second TCP segment. This > ACK is composed as follows: > > IPv6 header (40 bytes) > Destination Options Extension Header (24 bytes) > HoA Option > Padding > TCP ACK (20 bytes) > > Hence, the entire packet is 84 bytes big, and worth 84 credits. > > The asymmetry ratio between the CN-to-MN flow and the MN-to-CN flow is > thus 3000 bytes / 84 bytes = 35.7. The MN therefore needs at least > 500ms * 35.7 = 17.9 seconds between two successive handoffs for > acquiring sufficient credit for a 500-ms concurrent CoA test. > > The aging interval should be no shorter than 2 * 17.9 = 35.7 seconds, > however, if the credit is cut in half after each such interval. (Folks > were talking about 30-seconds to 1-minute aging intervals anyway.) > > Note that the assumed RTT of 500ms just for a concurrent CoA test is > quite long. In many realistic scenarios will the RTT be lower. > Moreover, the MN may have more to say than just ACK's. And it gets > credit for duplicate ACK's, too. My feeling is CreditAgingFactor and CreditAgingInterval can only be derived empirically, which cannot guarantee to work optimally in any situation (even we do not what is optimal.). Thus these parameters should be different with different network and application. For example, RTT in wireless network may vary dramatically. Sincerely, fan > > Hope this helps. > > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > > > > Fan Zhao wrote: > > Hi Christian, > > > > let me reply in seperate emails. > > > > > >>>2. What is the incentive for CN to implement the CBA as there > >>>is no penalty if CN is involved into this kind of reflective > >>>DoS attack and also the fact is that the server (CN) in the > >>>current Internet does not care about its processing overhead > >>>unless itself is under DoS attack. I also have concerns that > >>>some application preformance may be hurt by CBA, which might > >>>again reduce the incentive to support CBA. > >> > >>Well, as a content provider, wouldn't you get upset if someone misused > >>resources of your servers for a flooding attack? > > > > The redirection attack should be addressed by address verification. > > Due to the lack of address verification in EBU, CBA is invented; > > but CBA cannot distinguish between the good and the bad, thus it is a > > double-sided sword. > > > > 1) If the target of the attacker is the content provider itself (CN > > in this context), it is similar with supporting many MNs. CBA is not the > > solution to help CN because both good and bad MN (the attacker) receives > > the same treatment. Also there are many other ways to flood CN. > > > > 2) If the target of the attacker is other entity that is not in the > > same domain of CN (If the victim is in the same domain as CN, it is similar > > with flooding CN as the link to this domain is affected.), from the > > perspective of economics, CN should consider whether it is worth > > sacrificing the performance experienced by (many) good MNs for > > the protection of other entity that CN in fact does not care about. > > > > > >>And besides resource consumption, packets that your servers would send > >>to the node under attack would originate from a source address that > >>belongs to your domain. > > > > Then what? The reality is that there is no penalty for CN to become > > a reflector: 1) You cannot block CN because it is in a different domain; > > 2) The service of CN is needed by other MNs, thus it cannot be shut down. > > > > So the one motivated is MN itself. The history that MN communicates with > > CN can be one kind of "credit", which is represented by hash chain > > in draft-zhao-mip6-rr-ext-01 and is used to distinuguish the good from > > the bad. > > > > > >>Having said that, and given that CBA is a rather simple mechanism, I'm > >>positive that implementing CBA is worthwhile from the CN's perspective. > > > > There is a scalability issue for CN: even though CBA for each flow > > is light-weight, it could become a burden given many > > flows. There are always costs for security. > > > > > >>Referring to your concern about the performance impact on applications, > >>there are two things to consider: First, Mobile IPv6 with EBU/CBA is > >>always at least as good as standard Mobile IPv6. > > > > Can you please elaborate? > > > > > >>Second, CBA works fine > >>for all applications where the data sent by the MN and data sent by the > >>CN are roughly balanced. > >> > >>CBA may run out of credit--- and hence preclude further route-optimized > >>traffic until reachability verification completes--- if the CN sends at > >>a much higher rate than the MN. Whether or not this happens depends on > >>how much the asymmetry in data rates is, as well as on the speed of > >>credit aging. Fortunately, credit aging is designed to work well for > >>applications as asymmetric as a TCP download from the CN to the MN. > > > > I am also wondering how the parameters, CreditAgingFactor and > > CreditAgingInterval, are set up? It should be application-specific > > rather than static. So a procedure to derive those parameters > > dynamically might need to be added in the next version. > > > > Sincerely, > > fan > > > > > >>Hope this helps. > >> > >>- Christian > >> > >>-- > >>Christian Vogt, Institute of Telematics, University of Karlsruhe > >>www.tm.uka.de/~chvogt/pubkey/ > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Mar 29 19:36:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOl9Q-0003UM-RD; Wed, 29 Mar 2006 19:36:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOl9Q-0003UH-42 for mobopts@irtf.org; Wed, 29 Mar 2006 19:36:36 -0500 Received: from veni.ucdavis.edu ([169.237.105.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOl9O-0002qi-On for mobopts@irtf.org; Wed, 29 Mar 2006 19:36:36 -0500 Received: from localhost (localhost [127.0.0.1]) by veni.ucdavis.edu (8.13.6/8.13.1/it-std-5.2.0) with ESMTP id k2U0aXL8002375; Wed, 29 Mar 2006 16:36:33 -0800 (PST) Date: Wed, 29 Mar 2006 16:36:33 -0800 (PST) From: Fan Zhao X-X-Sender: fanzhao@veni.ucdavis.edu To: Christian Vogt Subject: Re: [Mobopts] questions about EBU/CBA In-Reply-To: <442A1D54.2090901@tm.uka.de> Message-ID: References: <20060327151042.GC24815@boskop.local> <442895DF.4040603@tm.uka.de> <442A1D54.2090901@tm.uka.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, I knew that. What I mean is that in reactive registration there is proactive HoTi/HoT, which may cause confustion. But it is not a big deal. Sincerely, fan On Tue, 28 Mar 2006, Christian Vogt wrote: > Fan, > > the "registration" does not include the RR according to RFC3775 > terminology. > > Regards, > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > > > > Fan Zhao wrote: > > Hi Christian, > > > > I am wondering if there are better terms > > rather than reactive registration and proactive registration > > because in reactive registration HoT is > > proactively elicited. > > > > Sincerely, > > fan > > > > On Mon, 27 Mar 2006, Christian Vogt wrote: > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Mar 29 22:20:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOnhs-00014r-DV; Wed, 29 Mar 2006 22:20:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOnhr-00014m-6L for mobopts@irtf.org; Wed, 29 Mar 2006 22:20:19 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOnhp-0002k4-9T for mobopts@irtf.org; Wed, 29 Mar 2006 22:20:19 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FOnhk-0006CW-2P; Thu, 30 Mar 2006 05:20:16 +0200 Received: from [10.0.0.21] (vpn-cl-167-195.rz.uni-karlsruhe.de [141.3.167.195]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id C9935A543; Thu, 30 Mar 2006 05:20:10 +0200 (CEST) Message-ID: <442B4E6A.2040308@tm.uka.de> Date: Wed, 29 Mar 2006 21:20:10 -0600 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; 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: Fan Zhao Subject: Re: CBA Re: [Mobopts] questions about EBU/CBA References: <20060327151042.GC24815@boskop.local> <442895DF.4040603@tm.uka.de> <442A1C61.5050301@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.7 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Fan - > I saw you skipped many of my comments. Does it mean you agree on > them? Some of your later comments were already attended to by an earlier in-line comment from my side. I think I did not skip anything but your reference to your draft. That I would like to re-read first before I make a statement. >> But the resources consumed by CBA are minor, too--- especially in >> the case where the CN is strong. > > I am not just looking at the resources consumed by CBA, but also the > impacts on the performances of good MNs, which you did not address > here. Sure, I did. See my later explanation on what happens in case a MN has insufficient credit during handoff. This is exactly the situation were CBA might have a performance impact. Performance is still better than with standard Mobile IPv6. But at the cost of security, which I consider inacceptable, you may be able to increase performance if you deactivated CBA. >> Things are actually a bit similar with TCP's congestion-avoidance >> mechanism. Congestion avoidance ensures fair share of network resources >> between concurrent connections. Like CBA, congestion avoidance is a >> sender-based mechanism. Non-compliance typically leads to better >> throughput results for a single connection at the cost of other >> connections. But most CNs are nevertheless TCP-friendly. >> >> While this comparison is not 100% correct, it does show that there is a >> willingness to support mechanisms even if the benefits of doing so >> cannot be directly reaped. > > I understand your points. However many cases already show TCP behaves > badly with non-compliant sender/receiver. A standard should not be > just working but the best from all available. My point is that there is wide acceptance of mechanisms which may imply minor disadvantages for a single connection, but are to the advantage of the Internet as a whole. TCP congestion avoidance is one example, CBA is another. Sure there will always be nodes that don't comply. But the majority of nodes does and will. >> With EBU/CBA, the MN can send and receive packets earlier than with >> standard Mobile IPv6 provided that it has sufficient credit. If it has >> sufficient credit, EBU/CBA obviously performs better than standard >> Mobile IPv6. >> >> If the MN does not have sufficient credit, there are two options: >> >> (a) The CN directs the packets to the MN's HoA. Then, communications >> can at least continue, albeit via a sub-optimal path. This may be an >> advantage over standard Mobile IPv6. >> >> (b) The CN drops the packets that it cannot send to the MN CoA >> directly. In this case, the performance of EBU/CBA is the same as that >> of standard Mobile IPv6 for packets that the CN sends. > > Why? In MIP6, CN always sends the packets whenever requested, right? > But here CN has to drop it. But you may count the advantages that EBU > results in. I do not know which performance is better definitely in this > case. Consider a handoff scenario. With standard Mobile IPv6, the CN continues to send packets to the MN's old CoA until it receives the Binding Update message. These packets won't be received by the MN any more, so the CN could just as well have dropped the packets in the first place. Also, until the CN receives the Binding Update message, it will drop all received packets that the MN sends to it from the new CoA due to a binding-cache mismatch. With EBU/CBA, the CN learns about the CoA earlier, namely, when it receives the Early Binding Update message. It will already accept packets that the MN sends from the new CoA as of then. This is one advantage that EBU/CBA has over standard Mobile IPv6. Furthermore, if the MN has sufficient credit, the CN can also send route-optimized packets to the MN's new CoA. This is a second advantage of EBU/CBA in case credit is available. [If the MN does not have sufficient credit, the CN may opt to send packets for the MN to the HoA. This may be another advantage, provided the path through the home agent is not too long.] > My feeling is CreditAgingFactor and CreditAgingInterval can only > be derived empirically, which cannot guarantee to work optimally in any > situation (even we do not what is optimal.). Thus these > parameters should be different with different network and > application. For example, RTT in wireless network may vary > dramatically. So you think 500ms for a CoTI-CoT exchange may not be sufficient? Note that, if the MN-CN RTT is that high, *reactive* end-to-end mobility optimizations may not be strong enough anyway. After all, it would take the same MN-CN RTT until the MN has updated the CN with the new CoA and the first data packet from the CN has propagated to the new CoA. But you can do *proactive* handoffs with EBU/CBA, too, as described in draft-vogt-mobopts-simple-ebu-00.txt. In such a case, the MN's credit must cover the L2-handoff delay in addition to the latency of the CoTI-CoT exchange. So yes, there will be situations where the MN may have less credit than it would want to have. As you say, this is the cost of security. But there are two important observations that one should make: - This is not an all-or-nothing game. Even if credit is insufficient to cover the entire handoff period, the CN will still send part of the packets to the MN in a route-optimization way until all credit is gone. Hence, lack of credit is unlikely to have an impact throughout the *entire* handoff period, but it may have an impact later during the handoff period. - Applications that benefit most from EBU/CBA are real-time applications with direct user interaction such as VoIP. Such applications are typically symmetric in terms of the data rates from the MN to the CN and vice versa. This is where CBA won't have a performance impact at all, all the more since the MN earns new credit for sending packets while it consumes existing credit for receiving packets. Referring to your proposal to make credit aging adaptive to different application and network scenarios: Unfortunately, this is infeasible from a security standpoint. Credit aging prevents an attacker with low-bandwidth Internet attachment from acquiring inappropriate volumes of credit over a long time. Such an attacker could misuse its credit for a burst of flooding packets which does not compare to what the attacker itself would be capable to send. Given that the type of application can be selected by the MN (or an attacker), and given that it is by far untrivial for the CN to securely acquire information about the MN's Internet attachment, credit aging ought to be kept static and should be designed to work well in a majority of cases with the types of applications that benefit most. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Fan Zhao wrote: > Hi Christian, > > I saw you skipped many of my comments. Does it mean you agree on > them? > > Please see my reply below. > > On Tue, 28 Mar 2006, Christian Vogt wrote: > > >> Hello Fan! >> >> Some comments in-line: >> >> >>>> Well, as a content provider, wouldn't you get upset if someone >>>> misused resources of your servers for a flooding attack? >>> >>> The redirection attack should be addressed by address >>> verification. Due to the lack of address verification in EBU, CBA >>> is invented; but CBA cannot distinguish between the good and the >>> bad, thus it is a double-sided sword. >>> >>> 1) If the target of the attacker is the content provider itself >>> (CN in this context), it is similar with supporting many MNs. CBA >>> is not the solution to help CN because both good and bad MN (the >>> attacker) receives the same treatment. Also there are many other >>> ways to flood CN. >> >> I wasn't concerned about an attack on the CN (i.e., content >> provider), > > I knew. Just include it for the completeness. > > >> but rather an attack against a third party that the CN becomed >> involved in. > > Yes. I did mention it in the original post. > > >> Such an attack binds resources of the CN, which the CN could >> otherwise be spent on useful traffic. >> >> Still, you are right in saying that the resources bound for the >> attack may not have a noticable impact if the CN is >> well-provisioned. > > This is not all I mean. But I understand CBA is not for that purpose. > > > >> But the resources consumed by CBA are minor, too--- especially in >> the case where the CN is strong. > > I am not just looking at the resources consumed by CBA, but also the > impacts on the performances of good MNs, which you did not address > here. > > >> If this is not incentive enough, it is up to the protocol >> specification to make either preemtive reachability verification, >> or concurrent reachability verification plus CBA a "MUST" to >> safeguard the Internet as a whole. > > My main concern is whether CBA is the best choice. > > >> Things are actually a bit similar with TCP's congestion-avoidance >> mechanism. Congestion avoidance ensures fair share of network >> resources between concurrent connections. Like CBA, congestion >> avoidance is a sender-based mechanism. Non-compliance typically >> leads to better throughput results for a single connection at the >> cost of other connections. But most CNs are nevertheless >> TCP-friendly. >> >> While this comparison is not 100% correct, it does show that there >> is a willingness to support mechanisms even if the benefits of >> doing so cannot be directly reaped. > > I understand your points. However many cases already show TCP behaves > badly with non-compliant sender/receiver. A standard should not be > just working but the best from all available. > > >>>> Referring to your concern about the performance impact on >>>> applications, there are two things to consider: First, Mobile >>>> IPv6 with EBU/CBA is always at least as good as standard Mobile >>>> IPv6. >>> >>> Can you please elaborate? >> >> With EBU/CBA, the MN can send and receive packets earlier than with >> standard Mobile IPv6 provided that it has sufficient credit. If >> it has sufficient credit, EBU/CBA obviously performs better than >> standard Mobile IPv6. >> >> If the MN does not have sufficient credit, there are two options: >> >> (a) The CN directs the packets to the MN's HoA. Then, >> communications can at least continue, albeit via a sub-optimal >> path. This may be an advantage over standard Mobile IPv6. >> >> (b) The CN drops the packets that it cannot send to the MN CoA >> directly. In this case, the performance of EBU/CBA is the same as >> that of standard Mobile IPv6 for packets that the CN sends. > > Why? In MIP6, CN always sends the packets whenever requested, right? > But here CN has to drop it. But you may count the advantages that EBU > results in. I do not know which performance is better definitely in > this case. > > >> The MN can still send packets from an unverified CoA, however. >> >> >>>> Second, CBA works fine for all applications where the data sent >>>> by the MN and data sent by the CN are roughly balanced. >>>> >>>> CBA may run out of credit--- and hence preclude further >>>> route-optimized traffic until reachability verification >>>> completes--- if the CN sends at a much higher rate than the MN. >>>> Whether or not this happens depends on how much the asymmetry >>>> in data rates is, as well as on the speed of credit aging. >>>> Fortunately, credit aging is designed to work well for >>>> applications as asymmetric as a TCP download from the CN to the >>>> MN. >>> >>> I am also wondering how the parameters, CreditAgingFactor and >>> CreditAgingInterval, are set up? It should be >>> application-specific rather than static. So a procedure to derive >>> those parameters dynamically might need to be added in the next >>> version. >> >> CreditAgingFactor and CreditAgingInterval are static parameters. >> They are chosen in a way that a MN downloading data from a CN can >> earn sufficient credit even though the MN sends much less than the >> CN. >> >> Assume a PMTU of 1500 bytes. Say, the CN sends full-sized TCP >> segments, and the MN sends a TCP ACK without any TCP options for >> every second segment. This is the worst asymmetry that can happen >> with TCP (given PMTU = 1500 bytes). Further assume, that the nodes >> need 500ms for the concurrent CoA test. >> >> Given and consumed credit equals the size of packets (in bytes) >> received and sent by the CN, respectively. >> >> The question is how long the MN needs to collect credit before >> simple CBA allows it to do an optimized handoff. So, what's the >> ratio between the size of packets that the CN sends and the size of >> packets that the MN sends? >> >> The CN sends two full-sized TCP segments. This is 3000 bytes or >> 3000 credits. >> >> The MN sends a TCP ACK upon reception of the second TCP segment. >> This ACK is composed as follows: >> >> IPv6 header (40 bytes) Destination Options Extension Header (24 >> bytes) HoA Option Padding TCP ACK (20 bytes) >> >> Hence, the entire packet is 84 bytes big, and worth 84 credits. >> >> The asymmetry ratio between the CN-to-MN flow and the MN-to-CN flow >> is thus 3000 bytes / 84 bytes = 35.7. The MN therefore needs at >> least 500ms * 35.7 = 17.9 seconds between two successive handoffs >> for acquiring sufficient credit for a 500-ms concurrent CoA test. >> >> The aging interval should be no shorter than 2 * 17.9 = 35.7 >> seconds, however, if the credit is cut in half after each such >> interval. (Folks were talking about 30-seconds to 1-minute aging >> intervals anyway.) >> >> Note that the assumed RTT of 500ms just for a concurrent CoA test >> is quite long. In many realistic scenarios will the RTT be lower. >> Moreover, the MN may have more to say than just ACK's. And it gets >> credit for duplicate ACK's, too. > > My feeling is CreditAgingFactor and CreditAgingInterval can only be > derived empirically, which cannot guarantee to work optimally in any > situation (even we do not what is optimal.). Thus these parameters > should be different with different network and application. For > example, RTT in wireless network may vary dramatically. > > Sincerely, fan > > >> Hope this helps. >> >> - Christian >> >> -- Christian Vogt, Institute of Telematics, University of Karlsruhe >> www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Mar 30 00:39:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOps0-0000PK-VA; Thu, 30 Mar 2006 00:38:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOprz-0000PA-6d for mobopts@irtf.org; Thu, 30 Mar 2006 00:38:55 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOprx-00073w-LD for mobopts@irtf.org; Thu, 30 Mar 2006 00:38:55 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FOprt-0003R7-Ct; Thu, 30 Mar 2006 07:38:52 +0200 Received: from [10.0.0.21] (vpn-cl-167-195.rz.uni-karlsruhe.de [141.3.167.195]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 79EE28648; Thu, 30 Mar 2006 07:38:48 +0200 (CEST) Message-ID: <442B6EE6.4000303@tm.uka.de> Date: Wed, 29 Mar 2006 23:38:46 -0600 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; 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: fanzhao@ucdavis.edu X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.7 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Mobopts Subject: [Mobopts] Review of draft-zhao-mip6-rr-ext-01.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Fan - I reviewed your draft draft-zhao-mip6-rr-ext-01.txt. Here are some comments. Section 4.2: > Then HA establishes a table where > home_init_ha_cookie, HoA and home_init_cookie are stored in one entry > and home_init_ha_cookie is a primary key. Please note that HA > creates the table entry only after it verifies the received packet > from MN, thus it does not risk the Denial-of-Service attack at this > stage. Later, when HA receives the HoT packet that seems like from > CN, HA just needs to perform the table lookup operation to verify the > cookie. The management of this table does not result in too much > extra cost because HA needs to remember the recent home_init_cookie > in the original MIP6 RR test anyway. RFC3775 does not require the HA to remember the home init cookie. The home init cookie in Home Test message received from a CN is checked by the MN only. > However if HA still concerns > about the memory cost, HA can generate home_init_ha_cookie by > AES(Kha, HoA | home_init_cookie) and only need to remember 1) > home_init_ha_cookie or 2) the output of a hash function over > home_init_ha_cookie or 3) even nothing. I don't think storage would be a problem. The HA has a Binding Cache and an IPsec security context for the MN anyway. Also, as you say, a Home Test Init message cannot be spoofed due to the MN-HA tunnel. So the memory requirement per MN is constant. Section 4.3: Given that the CN does not send the home keygen token to the MN's home address (but to the HA's address), how can the CN know that the MN is reachable at the home address? It seems that an attacker could send a HoTI message from an arbitrary address A, claiming that A be its HA's address. The attacker would generate the HV in the HoTI message based on the home address that it intends to hijack. The attacker would then receive a home keygen token which allows it to authenticate a BU on behalf of the true owner of the home address. Your could mitigate the attack to some extent by including the prefix of the HA's address in the home keygen token, and by having the CN check whether that prefix equals the home-address prefix. This would at least verify the reachability of the home-address prefix. But you would still not verify reachability at the home address itself. Section 4.4 and 4.5: You are proposing a hash chain that can be used to extend the lifetime of a MN's binding at a CN. The approach you are suggesting is in fact similar to the one described in [1], so you may want to include a reference in the Related Work section and spend some words on the pros and cons of either approach. [1] draft-arkko-mipv6-binding-lifetime-extension-00.txt BTW, the approach in [1] has the advantage that the MN must not pre-compute a hash chain. Instead, the MN can just hash a value obtained during the previous correspondent registration with a value obtained during the current registration. Section 4.4: > The original MIP6 RR test allows an attacker to intercept the traffic > even though this attacker is only able to eavesdrop the traffic in > the IPv6 network, which makes the MIP6 network slightly less secure > than the IPv6 network. You should probably say that, for this to happen, the attacker would have to be located on the path between the home address and the CN. Elsewhere, the attacker cannot get hold of the home keygen token that it would need for such an attack. > 3. If seqÆ < seq and h_seqÆ <> H(h_seq)^(seq-seqÆ), CN realizes > that there is an attacker that can successfully finish the > extended RR test; however, CN is not sure whether this BU > message is from the attacker or a valid MN based on its > current knowledge. Thus CN disables this entry, indicates > the reason in the BA message and forwards the data packets to > the home address. CNÆs policy may decide to accept the new > BU message for this HoA when the current session with this > HoA is ended or after a certain amount of time. Note that the MN may crash and reboot, in which case the MN and the CN would get out of sync with respect to the current h_seq. If the CN blocks the HoA for a while, as you suggest above, you prevent such a MN from starting over with a new hash chain. > The hash chain information should not be lost due to the reboot in CN > and MN. While it is not a big problem for CN as it is just a fresh > start, it is better for MN to store the hash chain information in the > hard disk so that the synchronization between MN and CN can be > restored. Ah, I see. But you can eliminate the requirement for stable storage if the CN does not block the HoA in the described case. Ok, that's it. Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Mar 30 00:39:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOpsV-0000ak-Bx; Thu, 30 Mar 2006 00:39:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOpsT-0000af-TA for mobopts@irtf.org; Thu, 30 Mar 2006 00:39:25 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOpsS-00074m-IW for mobopts@irtf.org; Thu, 30 Mar 2006 00:39:25 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FOpsQ-0003Sb-1B; Thu, 30 Mar 2006 07:39:24 +0200 Received: from [10.0.0.21] (vpn-cl-167-195.rz.uni-karlsruhe.de [141.3.167.195]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id BA2848648; Thu, 30 Mar 2006 07:39:20 +0200 (CEST) Message-ID: <442B6F07.4090606@tm.uka.de> Date: Wed, 29 Mar 2006 23:39:19 -0600 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; 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: fanzhao@ucdavis.edu X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.7 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Jari Arkko , Mobopts Subject: [Mobopts] CBA vs. draft-zhao-mip6-rr-ext-01.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Fan, in a previous email, you suggested that the hash-chain mechanism described in [1] could be an alternative for Credit-Based Authorization. I don't agree with that perception. [1] draft-zhao-mip6-rr-ext-01.txt In [1], a MN can prove through a chain of hashes that it has successfully gone through the past i correspondent registrations, where i is an integer value between 0 and N, and N is initially selected by the MN. Like the similar strategy described in [2], your approach can be used to extend the lifetime of the MN's binding at the CN. [2] draft-arkko-mipv6-binding-lifetime-extension-00.txt But a hash chain does not provide any evidence to the CN that a new care-of address, chosen by the MN, is correct. An attacker could easily re-register with the same CN several times, using valid care-of addresses, in order to increase the length of its hash chain. If the CN took this as an indication that the MN's next care-of address can be trusted, it would be wrong. The point is that an attacker (alias the MN) does not have to send a single data packet until its hash chain is long. But when its hash chain is long enough to make the CN trustful, the attacker could register a false care-of address and initate a redirection-based flooding attack. Such an attack can have significant amplification given that the attacker did not send data packets prior to the attack. Credit-Based Authorization does not have this vulnerability because it limits the data volume a CN can send to a MN's unverified care-of address to the data volume that the CN has recently received from that MN. Take care, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Mar 30 14:24:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2kt-0001ZM-D0; Thu, 30 Mar 2006 14:24:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2kr-0001Yb-Dg for mobopts@irtf.org; Thu, 30 Mar 2006 14:24:25 -0500 Received: from mail.av.it.pt ([193.136.92.53] helo=av.it.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP2kq-0004Al-Pp for mobopts@irtf.org; Thu, 30 Mar 2006 14:24:25 -0500 Received: from [217.129.138.181] (HELO mars.innerghost.net) by av.it.pt (CommuniGate Pro SMTP 4.3.7) with ESMTP id 4383910 for mobopts@irtf.org; Thu, 30 Mar 2006 20:24:22 +0100 Received: by mars.innerghost.net (Postfix, from userid 1000) id B7A234100; Thu, 30 Mar 2006 20:24:21 +0100 (WEST) Date: Thu, 30 Mar 2006 20:24:21 +0100 From: Hugo Santos To: mobopts@irtf.org Message-ID: <20060330192421.GA10008@innerghost.net> Mail-Followup-To: mobopts@irtf.org Mime-Version: 1.0 User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Mobopts] Regarding 'Context Transfer of Mobile IPv6 Multicast Listeners' X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0145334760==" Errors-To: mobopts-bounces@irtf.org --===============0145334760== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I'm one of the authors of the Internet Draft 'Context Transfer of Mobile IPv6 Multicast Listeners'. Alfredo Matos presented this document on our behalf in IETF65. Some answers on the questions that were raised during the presentation, and that he could not address in detail, are thus due from us. Two major comments were made: Kempf's intervention on the CXTP RFC; and Rajeev's comment on the interaction of this work with FHO and CARD. Regarding James Kempf's intervention, indeed the CXTP RFC includes in the appendix a description of a use of CXTP and MLD, but this solution is in our opinion rather limited. Besides being limited to MLDv1 (ASM only) it transfer the complete interface multicast state between Access Routers and not the mobile node's individual interest. For complex service scenarios, with many nodes and many groups this basic approach does not seem adequate. As for Rajeev's comment: if FHO is used, the reconstruction of the trees may be so fast that taking the multicast state information retrieved from CARD into consideration for the handover might indeed be irrelevant (in this particular item we expect to have experimental results soon). However, this assumes some type of widely used FHO. Currently, we have no assurance that this is realistic so we envision scenarios where CARD might be used when FHO is not available. So this information might still be relevant in those cases. Our feedback from cellular operators has not been clear regarding this assumption. For instance in inter-domain scenarios this information may be useful. We are currently discussing the inclusion or not of the CARD section in the next draft version after Rajeev's input. We would like to thank in advance the group's interest. Naturally any other comments from the group will be extremely welcomed. Best Regards, Hugo Santos --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFELDBl7asb/itUNKwRAt8+AJ9LWLnDY4iLwhrZls6UIHBoB5uzlQCfVvHP GXw5awE2X2cV3UY6LX8dglc= =D3wC -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- --===============0145334760== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --===============0145334760==-- From mobopts-bounces@irtf.org Thu Mar 30 23:11:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPAyW-0000Ey-Cn; Thu, 30 Mar 2006 23:11:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPAyU-0000CA-Mt for mobopts@irtf.org; Thu, 30 Mar 2006 23:11:02 -0500 Received: from mx2.ucdavis.edu ([169.237.104.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPAyU-00025q-7y for mobopts@irtf.org; Thu, 30 Mar 2006 23:11:02 -0500 Received: from celerio.ucdavis.edu (celerio.ucdavis.edu [169.237.104.178]) by mx2.ucdavis.edu (8.13.6/8.13.1/it-defang-5.4.0) with ESMTP id k2V4AwNT001511; Thu, 30 Mar 2006 20:10:59 -0800 (PST) Received: (from www@localhost) by celerio.ucdavis.edu (8.12.10/8.12.9/Submit) id k2V4AwKZ001474; Thu, 30 Mar 2006 20:10:58 -0800 (PST) Date: Thu, 30 Mar 2006 20:10:58 -0800 (PST) Message-Id: <200603310410.k2V4AwKZ001474@celerio.ucdavis.edu> To: Christian Vogt From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [169.237.7.192] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.12 X-Spam-Score: 1.1 (+) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: Mobopts Subject: [Mobopts] Review of draft-arkko-mipv6-binding-lifetime-extension-00 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, Please see my comments below on draft-arkko-mipv6- binding-lifetime-extension-00 (in short, BLE). In BLE and rr-ext (either mip6-rr-ext or mobopts-rr-ext) the way hash chain is used is different. rr-ext utilizes the one-way attribute of hash function to authenticate the identity without home address test thus hash chain elements are generated firstly and are used in the reverse order from being generated; while BLE uses hash operation to associate with the previous binding and aggregate a sequence of bindings together, thus hash elements are generated in the chronological order. It is not just a coincidence that both drafts uses hash function, but it means that hash function has some values in RR test, right? 1. In abstract, "This requirement results in an average signaling traffic of around 7 bits per second when the hosts are not moving around. This traffic load by itself is neglible," s/neglible/negligible 2. In abstract, "but can be problematic for hosts in standby mode." The need of keeping RO state alive in CN when MN is in standby mode really depends on the communication pattern of MN. For example, if MN sleeps for a long time before communicating with CN again, IMHO, the shorter delay of communication when MN wakes up does not justify the overhead caused by repeating RO with CN periodically. This comment is also related to the second paragraph in section 1. 3. In abstract, "that can reduce this signaling load to around 0.1 bits per second" If I understand this correctly, the overhead is reduced to 0.1 bit/second when the lifetime is 8 hour. I think other metrics are also useful, for example, how long does it take for MN to achieve an 8-hour lifetime and to reduce the overhead to 0.1 bits/second, what is average overhead (bit/second)? Depending on the mobility pattern, MN may not have the opportunity to enjoy the very low overhead. Assume that the initial lifetime is 2.1=7*0.3 minutes and after renewing for n times, the lifetime is 2.1*1.3^n=8*60=480 minutes. Then the total waiting time is 2.1 + 2.1*1.3 + ... + 2.1*1.3^(n-1) = 1593 minutes = 26.55 hours. The average overhead is (376*n bytes)/(2.1 + 2.1*1.3 + ... + 2.1*1.3^(n-1)) when 2.1*1.3^(n-1)<=8*60. 4. If I understand correctly, Section 4.1 shows the effort-damage consideration can be applied to the frequency of address tests. A malicious or compromised MN may not mind investing 26.55 hours to achieve 8 hour long lifetime binding (MN may solicit a large amount of traffic and then leave the current location after achieving 8-hour BU lifetime with CN, which causes the damages to both CN and the previous access network.), which opens a larger vulnerable window and thus is still very profitable for attackers. >From the view of a good MN, it wishes to achieve the longer lifetime as quick as possible. However, in order to make difficulty for the malicious MN (CN does not know MN is malicious or not.), a good MN still has to wait for a very long time to enjoy the benefit of long binding lifetime. In other words, if MN does not stay for a long enough time period, MN may experience more overhead than that in MIP6. 5. On page 7, "The requested lifetime in the Binding Update is not limited to MAX_RR_BINDING_LIFETIME (7 minutes) but rather t * 0.3." Should be "t * 1.3"? 6. The computation of Kcredit in the extended RR test is still vulnerable to the eavesdroppers on both MN-CN and HA-CN path. 7. In Section 4.4, the field of N is defined in Lifetime Credit Authorization Option. I think probably the sequence number field in BU message can be reused for this purpose, thus no need to define a new field. 8. The modified RR test procedure still needs to pass through home agent. 9. The draft may also consider utilizing the fact that MN does not change its CoA in order to improve the security. This draft (BLE in short) proposes to extend the binding lifetime in order to reduce the signaling overhead and battery consumption when MN does not change its location. In Section 5 of draft-zhao- mobopts-rr-ext-00 (rrext in short, and draft-zhao-mip6-rr-ext-01 as well) we also consider this case. Below is a short comparison. 1. Both drafts use hash chain to prove MN's identity to CN. BLE combines the new Kbm with the old ones while rrext uses a one-way hash chain in the reverse order of hash chain generation. By doing so, BLE needs less memory, but BLE is still vulnerable to the eavesdroppers on both MN-CN and HA-CN path. rrext does need to allocate more memory to keep the unused hash chain elements, but MN can easily re-generate the hash chain once the old one is depleted and the memory and hash operation are cheap nowadays. For example, assume that a hash element is 16 bytes, 1 M memory can keep hash elements enough for many days use. Also rrext can detect the eavesdropper on both MN-CN and HA-CN path. 2. BLE works best for a MN staying at the same location for a very long time, but rrext benefits MN under any mobility pattern. 3. BLE may expose to a larger vulnerable window by extending the lifetime, but rrext does not. 4. In rrext, the signaling overhead is a little bit more than (256*8)bits/(7*60)seconds = 4.9 bits/second constantly. We can also analyze the power consumption in both drafts. For example, we may compute how much power is consumed during a certain time period where the amount of power consumed is equal to c1*f(the number of bits sent and received during BU with CN) + c2*g(the length of time period when MN is awake to send the packets.) + other consumptions. rrext sends and receives fewer bits than BLE and spends less time as well because of home address test procedure in BLE while the lifetime in BLE may be longer than in rrext. Sicnerely, fan _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 31 01:22:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPD1Q-0001qr-QV; Fri, 31 Mar 2006 01:22:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPD1P-0001pk-Nf for mobopts@irtf.org; Fri, 31 Mar 2006 01:22:11 -0500 Received: from mx3.ucdavis.edu ([169.237.104.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPD1H-00075G-2y for mobopts@irtf.org; Fri, 31 Mar 2006 01:22:06 -0500 Received: from tremex.ucdavis.edu (tremex.ucdavis.edu [169.237.104.172]) by mx3.ucdavis.edu (8.13.6/8.13.1/it-defang-5.4.0) with ESMTP id k2V6LrNT011893; Thu, 30 Mar 2006 22:21:53 -0800 (PST) Received: from tremex.ucdavis.edu (localhost [127.0.0.1]) by tremex.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id k2V6Lr6I016146; Thu, 30 Mar 2006 22:21:53 -0800 (PST) Received: (from www@localhost) by tremex.ucdavis.edu (8.12.10/8.12.9/Submit) id k2V6LqYN016145; Thu, 30 Mar 2006 22:21:52 -0800 (PST) Date: Thu, 30 Mar 2006 22:21:52 -0800 (PST) Message-Id: <200603310621.k2V6LqYN016145@tremex.ucdavis.edu> To: Christian Vogt From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [169.237.7.192] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: Mobopts Subject: [Mobopts] RE: Review of draft-zhao-mip6-rr-ext-01.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, Thanks for your review. > Fan - > > I reviewed your draft draft-zhao-mip6-rr-ext-01.txt. Here are some > comments. > > Section 4.2: > > > Then HA establishes a table where > > home_init_ha_cookie, HoA and home_init_cookie are stored in one > entry > > and home_init_ha_cookie is a primary key. Please note that HA > > creates the table entry only after it verifies the received packet > > from MN, thus it does not risk the Denial-of-Service attack at this > > stage. Later, when HA receives the HoT packet that seems like from > > CN, HA just needs to perform the table lookup operation to verify > the > > cookie. The management of this table does not result in too much > > extra cost because HA needs to remember the recent home_init_cookie > > in the original MIP6 RR test anyway. > > RFC3775 does not require the HA to remember the home init cookie. The > home init cookie in Home Test message received from a CN is checked by > the MN only. Right. This extension to MIP6 RR is for location privacy. draft-zhao-mip6-rr-ext-00 does not include the location privacy consideration. > > > However if HA still concerns > > about the memory cost, HA can generate home_init_ha_cookie by > > AES(Kha, HoA | home_init_cookie) and only need to remember 1) > > home_init_ha_cookie or 2) the output of a hash function over > > home_init_ha_cookie or 3) even nothing. > > I don't think storage would be a problem. The HA has a Binding Cache > and an IPsec security context for the MN anyway. Also, as you say, a > Home Test Init message cannot be spoofed due to the MN-HA tunnel. So > the memory requirement per MN is constant. OK. > > Section 4.3: > > Given that the CN does not send the home keygen token to the MN's home > address (but to the HA's address), how can the CN know that the MN is > reachable at the home address? > > It seems that an attacker could send a HoTI message from an arbitrary > address A, claiming that A be its HA's address. The attacker would > generate the HV in the HoTI message based on the home address that it > intends to hijack. The attacker would then receive a home keygen token > which allows it to authenticate a BU on behalf of the true owner of the > home address. > > Your could mitigate the attack to some extent by including the prefix of > the HA's address in the home keygen token, and by having the CN check > whether that prefix equals the home-address prefix. This would at least > verify the reachability of the home-address prefix. But you would still > not verify reachability at the home address itself. > The idea of hiding MNP by hash function is for RRNP (RR test on network prefix owned by MR; MR's HoA is still in the home address test.) in NEMO originally; however at that moment, NEMO WG is not chartered to work on the RO solution yet. Thus I transplanted it to MIP6 RR test. In a later sister draft, draft-zhao-mobopts-rr-ext-00, (maybe I should rather refer this draft.) I have removed this part already. I am actually thinking not to hide HoA on the path of HA_CN as the attacker on this path can probe HoA and do a lot of attacks already. > Section 4.4 and 4.5: > > You are proposing a hash chain that can be used to extend the lifetime > of a MN's binding at a CN. It may be for this purpose. But my original motivation is to reduce the delay and detect the attack. > The approach you are suggesting is in fact > similar to the one described in [1], so you may want to include a > reference in the Related Work section and spend some words on the pros > and cons of either approach. At the moment when we prepare this draft, we do not know BLE yet. That is why it is not in the related works. I am sure I will add it to the next version. I have sent a seperate email regarding to [1] and the comparisons between them. I think the way hash chain is generated and used is different. > > [1] draft-arkko-mipv6-binding-lifetime-extension-00.txt > > BTW, the approach in [1] has the advantage that the MN must not > pre-compute a hash chain. Instead, the MN can just hash a value > obtained during the previous correspondent registration with a value > obtained during the current registration. My draft just wants to utilize the one-way property of hash function. Pre-somputing hash chain is a concern, this is the standard method and the memory cost is acceptable. Again, the different way to generate and use hash chain is because of the different purposes in these two drafts. > > Section 4.4: > > > The original MIP6 RR test allows an attacker to intercept the > traffic > > even though this attacker is only able to eavesdrop the traffic in > > the IPv6 network, which makes the MIP6 network slightly less secure > > than the IPv6 network. > > You should probably say that, for this to happen, the attacker would > have to be located on the path between the home address and the CN. > Elsewhere, the attacker cannot get hold of the home keygen token that it > would need for such an attack. OK to reword this sentence. > > > 3. If seqÆ < seq and h_seqÆ <> H(h_seq)^(seq-seqÆ), CN > realizes > > that there is an attacker that can successfully finish the > > extended RR test; however, CN is not sure whether this BU > > message is from the attacker or a valid MN based on its > > current knowledge. Thus CN disables this entry, indicates > > the reason in the BA message and forwards the data packets > to > > the home address. CNÆs policy may decide to accept the new > > BU message for this HoA when the current session with this > > HoA is ended or after a certain amount of time. > > Note that the MN may crash and reboot, in which case the MN and the CN > would get out of sync with respect to the current h_seq. If the CN > blocks the HoA for a while, as you suggest above, you prevent such a MN > from starting over with a new hash chain. > > > The hash chain information should not be lost due to the reboot in > CN > > and MN. While it is not a big problem for CN as it is just a fresh > > start, it is better for MN to store the hash chain information in > the > > hard disk so that the synchronization between MN and CN can be > > restored. > > Ah, I see. But you can eliminate the requirement for stable storage if > the CN does not block the HoA in the described case. Maybe it is from an attacker. But CN does not block HoA persistently. Thanks. Sincerely, fan > > Ok, that's it. > > Regards, > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 31 01:51:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPDTd-0004i6-J5; Fri, 31 Mar 2006 01:51:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPDTc-0004gg-0E for mobopts@irtf.org; Fri, 31 Mar 2006 01:51:20 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPDR3-0007wK-32 for mobopts@irtf.org; Fri, 31 Mar 2006 01:48:44 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FPDQu-0002vc-Js; Fri, 31 Mar 2006 08:48:40 +0200 Received: from [10.0.0.21] (vpn-cl-162-81.rz.uni-karlsruhe.de [141.3.162.81]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id BA594864F; Fri, 31 Mar 2006 08:48:31 +0200 (CEST) Message-ID: <442CD0BD.9080900@tm.uka.de> Date: Fri, 31 Mar 2006 00:48:29 -0600 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; 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: Fan Zhao References: <200603310621.k2V6LqYN016145@tremex.ucdavis.edu> In-Reply-To: <200603310621.k2V6LqYN016145@tremex.ucdavis.edu> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit X-Spam-Score: -4.7 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Cc: Mobopts Subject: [Mobopts] Re: Review of draft-zhao-mip6-rr-ext-01.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Fan. > The idea of hiding MNP by hash function is for RRNP (RR test on > network prefix owned by MR; MR's HoA is still in the home address > test.) in NEMO originally; however at that moment, NEMO WG is not > chartered to work on the RO solution yet. Thus I transplanted it to > MIP6 RR test. In a later sister draft, draft-zhao-mobopts-rr-ext-00, > (maybe I should rather refer this draft.) I have removed this part > already. I am actually thinking not to hide HoA on the path of HA_CN > as the attacker on this path can probe HoA and do a lot of attacks > already. Yes, I think that would be better. Agree with the rest. Regards, - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Fan Zhao wrote: > Hi Christian, > > Thanks for your review. > > >> Fan - >> >> I reviewed your draft draft-zhao-mip6-rr-ext-01.txt. Here are some >> comments. >> >> Section 4.2: >> >> >>> Then HA establishes a table where home_init_ha_cookie, HoA and >>> home_init_cookie are stored in one >> >> entry >> >>> and home_init_ha_cookie is a primary key. Please note that HA >>> creates the table entry only after it verifies the received >>> packet from MN, thus it does not risk the Denial-of-Service >>> attack at this stage. Later, when HA receives the HoT packet >>> that seems like from CN, HA just needs to perform the table >>> lookup operation to verify >> >> the >> >>> cookie. The management of this table does not result in too much >>> extra cost because HA needs to remember the recent >>> home_init_cookie in the original MIP6 RR test anyway. >> >> RFC3775 does not require the HA to remember the home init cookie. >> The home init cookie in Home Test message received from a CN is >> checked by the MN only. > > Right. This extension to MIP6 RR is for location privacy. > draft-zhao-mip6-rr-ext-00 does not include the location privacy > consideration. > > >>> However if HA still concerns about the memory cost, HA can >>> generate home_init_ha_cookie by AES(Kha, HoA | home_init_cookie) >>> and only need to remember 1) home_init_ha_cookie or 2) the output >>> of a hash function over home_init_ha_cookie or 3) even nothing. >> >> I don't think storage would be a problem. The HA has a Binding >> Cache and an IPsec security context for the MN anyway. Also, as >> you say, a Home Test Init message cannot be spoofed due to the >> MN-HA tunnel. So the memory requirement per MN is constant. > > OK. > > >> Section 4.3: >> >> Given that the CN does not send the home keygen token to the MN's >> home address (but to the HA's address), how can the CN know that >> the MN is reachable at the home address? >> >> It seems that an attacker could send a HoTI message from an >> arbitrary address A, claiming that A be its HA's address. The >> attacker would generate the HV in the HoTI message based on the >> home address that it intends to hijack. The attacker would then >> receive a home keygen token which allows it to authenticate a BU on >> behalf of the true owner of the home address. >> >> Your could mitigate the attack to some extent by including the >> prefix of the HA's address in the home keygen token, and by having >> the CN check whether that prefix equals the home-address prefix. >> This would at least verify the reachability of the home-address >> prefix. But you would still not verify reachability at the home >> address itself. >> > > The idea of hiding MNP by hash function is for RRNP (RR test on > network prefix owned by MR; MR's HoA is still in the home address > test.) in NEMO originally; however at that moment, NEMO WG is not > chartered to work on the RO solution yet. Thus I transplanted it to > MIP6 RR test. In a later sister draft, draft-zhao-mobopts-rr-ext-00, > (maybe I should rather refer this draft.) I have removed this part > already. I am actually thinking not to hide HoA on the path of HA_CN > as the attacker on this path can probe HoA and do a lot of attacks > already. > > >> Section 4.4 and 4.5: >> >> You are proposing a hash chain that can be used to extend the >> lifetime of a MN's binding at a CN. > > It may be for this purpose. But my original motivation is to reduce > the delay and detect the attack. > > >> The approach you are suggesting is in fact similar to the one >> described in [1], so you may want to include a reference in the >> Related Work section and spend some words on the pros and cons of >> either approach. > > At the moment when we prepare this draft, we do not know BLE yet. > That is why it is not in the related works. I am sure I will add it > to the next version. > > I have sent a seperate email regarding to [1] and the comparisons > between them. I think the way hash chain is generated and used is > different. > > >> [1] draft-arkko-mipv6-binding-lifetime-extension-00.txt >> >> BTW, the approach in [1] has the advantage that the MN must not >> pre-compute a hash chain. Instead, the MN can just hash a value >> obtained during the previous correspondent registration with a >> value obtained during the current registration. > > My draft just wants to utilize the one-way property of hash function. > Pre-somputing hash chain is a concern, this is the standard method > and the memory cost is acceptable. Again, the different way to > generate and use hash chain is because of the different purposes in > these two drafts. > > >> Section 4.4: >> >> >>> The original MIP6 RR test allows an attacker to intercept the >> >> traffic >> >>> even though this attacker is only able to eavesdrop the traffic >>> in the IPv6 network, which makes the MIP6 network slightly less >>> secure than the IPv6 network. >> >> You should probably say that, for this to happen, the attacker >> would have to be located on the path between the home address and >> the CN. Elsewhere, the attacker cannot get hold of the home keygen >> token that it would need for such an attack. > > OK to reword this sentence. > > >>> 3. If seqÆ < seq and h_seqÆ <> H(h_seq)^(seq-seqÆ), CN >> >> realizes >> >>> that there is an attacker that can successfully finish the >>> extended RR test; however, CN is not sure whether this BU message >>> is from the attacker or a valid MN based on its current >>> knowledge. Thus CN disables this entry, indicates the reason in >>> the BA message and forwards the data packets >> >> to >> >>> the home address. CNÆs policy may decide to accept the new BU >>> message for this HoA when the current session with this HoA is >>> ended or after a certain amount of time. >> >> Note that the MN may crash and reboot, in which case the MN and the >> CN would get out of sync with respect to the current h_seq. If the >> CN blocks the HoA for a while, as you suggest above, you prevent >> such a MN from starting over with a new hash chain. >> >> >>> The hash chain information should not be lost due to the reboot >>> in >> >> CN >> >>> and MN. While it is not a big problem for CN as it is just a >>> fresh start, it is better for MN to store the hash chain >>> information in >> >> the >> >>> hard disk so that the synchronization between MN and CN can be >>> restored. >> >> Ah, I see. But you can eliminate the requirement for stable >> storage if the CN does not block the HoA in the described case. > > Maybe it is from an attacker. But CN does not block HoA persistently. > > > Thanks. > > Sincerely, fan > > >> Ok, that's it. >> >> Regards, - Christian >> >> -- Christian Vogt, Institute of Telematics, University of Karlsruhe >> www.tm.uka.de/~chvogt/pubkey/ >> _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 31 02:24:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPDzL-0004TK-VN; Fri, 31 Mar 2006 02:24:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPDyc-0003wE-GO for mobopts@irtf.org; Fri, 31 Mar 2006 02:23:22 -0500 Received: from vici.ucdavis.edu ([169.237.105.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPDwV-00016j-9B for mobopts@irtf.org; Fri, 31 Mar 2006 02:21:12 -0500 Received: from localhost (localhost [127.0.0.1]) by vici.ucdavis.edu (8.13.6/8.13.1/it-std-5.2.0) with ESMTP id k2V7L2HS009463; Thu, 30 Mar 2006 23:21:02 -0800 (PST) Date: Thu, 30 Mar 2006 23:21:02 -0800 (PST) From: Fan Zhao X-X-Sender: fanzhao@vici.ucdavis.edu To: Christian Vogt In-Reply-To: <442B6F07.4090606@tm.uka.de> Message-ID: References: <442B6F07.4090606@tm.uka.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: Mobopts , Jari Arkko Subject: [Mobopts] Re: CBA vs. draft-zhao-mip6-rr-ext-01.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi, Christian, On Wed, 29 Mar 2006, Christian Vogt wrote: > Hi Fan, > > in a previous email, you suggested that the hash-chain mechanism > described in [1] could be an alternative for Credit-Based Authorization. > I don't agree with that perception. > > [1] draft-zhao-mip6-rr-ext-01.txt > > In [1], a MN can prove through a chain of hashes that it has > successfully gone through the past i correspondent registrations, where > i is an integer value between 0 and N, and N is initially selected by > the MN. > > Like the similar strategy described in [2], your approach can be used to > extend the lifetime of the MN's binding at the CN. > > [2] draft-arkko-mipv6-binding-lifetime-extension-00.txt The idea in my mind is actually very similar with [2], i.e. using the history of communication for a future prediction but with an additional reaction. > > But a hash chain does not provide any evidence to the CN that a new > care-of address, chosen by the MN, is correct. An attacker could easily > re-register with the same CN several times, using valid care-of > addresses, in order to increase the length of its hash chain. If the CN > took this as an indication that the MN's next care-of address can be > trusted, it would be wrong. The idea is the following: CN may start to establish the trust with a previously unknown MN given the ongoing communication. At certain point when MN starts the handover, CN can still continue to send the traffic to the unverified CoA. If MN is not malicious, this maximizes the benefits of EBU because Mn can receive the traffic from CN seamlessly. If MN is the attacker to attack another victim, the victim is able to send back a message to CN to request to stop forwarding the traffic. With an additional message exchange like the address verification procedure, CN can verify that this request is indeed from the address that it currently forwards the traffic to (More precisely, the request can be from any node on the path anyway.), and then CN would stop forwarding and give the negative feedback to this malicious MN. It is very similar with the real world, for example, the relationship between humans. >From the incentive point of view, CN is likely to support this option because 1) it can serve the good MN better. 2) it can stop forwarding the traffic to the wrong place as it wastes its resources. MN is likely to support this option if the handover delay is really important as it can receive the traffic quickly during handover. Any other node would appreciate the option that helps stop receiving the wrong traffic from CN. Otherwise, when it is under the attack, it can not do anything about it except dropping the offending traffic at the last hop. It will be very happy to provide the negative feedback to CN once the attack starts. > > The point is that an attacker (alias the MN) does not have to send a > single data packet until its hash chain is long. But when its hash > chain is long enough to make the CN trustful, the attacker could > register a false care-of address and initate a redirection-based > flooding attack. > > Such an attack can have significant amplification given that the > attacker did not send data packets prior to the attack. > > Credit-Based Authorization does not have this vulnerability because it > limits the data volume a CN can send to a MN's unverified care-of > address to the data volume that the CN has recently received from that MN. So my point is that CBA could limit the attack effects. However, it does not maximize the benefits of EBU. The optimal case is that the good MN should always receive the traffic without limitation and the bad attacker should not succeed. But CBA treats them the same way. My proposal sacrifices the victims for the best service for good MNs because the reality is CN would not have to hold guilty if involved in reflective DDoS attack and the victim would use that option to help themselves anyway. What do you think? Sincerely, fan > > Take care, > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 31 03:06:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEdz-0005CV-Ve; Fri, 31 Mar 2006 03:06:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEc5-0004ei-Sm for mobopts@irtf.org; Fri, 31 Mar 2006 03:04:09 -0500 Received: from vici.ucdavis.edu ([169.237.105.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPEO1-0002hZ-NR for mobopts@irtf.org; Fri, 31 Mar 2006 02:49:41 -0500 Received: from localhost (localhost [127.0.0.1]) by vici.ucdavis.edu (8.13.6/8.13.1/it-std-5.2.0) with ESMTP id k2V7nVBZ009610; Thu, 30 Mar 2006 23:49:31 -0800 (PST) Date: Thu, 30 Mar 2006 23:49:31 -0800 (PST) From: Fan Zhao X-X-Sender: fanzhao@vici.ucdavis.edu To: Fan Zhao In-Reply-To: Message-ID: References: <442B6F07.4090606@tm.uka.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Christian Vogt , Jari Arkko , Mobopts Subject: [Mobopts] Re: CBA vs. draft-zhao-mip6-rr-ext-01.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, One sidenote: CN may not extend the lifetime of binding for each successful binding. Sincerely, fan On Thu, 30 Mar 2006, Fan Zhao wrote: > Hi, Christian, > > On Wed, 29 Mar 2006, Christian Vogt wrote: > > > Hi Fan, > > > > in a previous email, you suggested that the hash-chain mechanism > > described in [1] could be an alternative for Credit-Based Authorization. > > I don't agree with that perception. > > > > [1] draft-zhao-mip6-rr-ext-01.txt > > > > In [1], a MN can prove through a chain of hashes that it has > > successfully gone through the past i correspondent registrations, where > > i is an integer value between 0 and N, and N is initially selected by > > the MN. > > > > Like the similar strategy described in [2], your approach can be used to > > extend the lifetime of the MN's binding at the CN. > > > > [2] draft-arkko-mipv6-binding-lifetime-extension-00.txt > The idea in my mind is actually very similar with [2], i.e. > using the history of communication for a future prediction > but with an additional reaction. > > > > > But a hash chain does not provide any evidence to the CN that a new > > care-of address, chosen by the MN, is correct. An attacker could easily > > re-register with the same CN several times, using valid care-of > > addresses, in order to increase the length of its hash chain. If the CN > > took this as an indication that the MN's next care-of address can be > > trusted, it would be wrong. > The idea is the following: > CN may start to establish the trust with a previously unknown MN > given the ongoing communication. At certain point when MN > starts the handover, CN can still continue to send the traffic to > the unverified CoA. If MN is not malicious, this maximizes the > benefits of EBU because Mn can receive the traffic from CN > seamlessly. If MN is the attacker to attack another victim, > the victim is able to send back a message to CN to request to > stop forwarding the traffic. With an additional message exchange > like the address verification procedure, CN can verify that this > request is indeed from the address that it currently forwards the > traffic to (More precisely, the request can be from anFrom mobopts-bounces@irtf.org Fri Mar 31 03:06:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEdz-0005CV-Ve; Fri, 31 Mar 2006 03:06:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEc5-0004ei-Sm for mobopts@irtf.org; Fri, 31 Mar 2006 03:04:09 -0500 Received: from vici.ucdavis.edu ([169.237.105.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPEO1-0002hZ-NR for mobopts@irtf.org; Fri, 31 Mar 2006 02:49:41 -0500 Received: from localhost (localhost [127.0.0.1]) by vici.ucdavis.edu (8.13.6/8.13.1/it-std-5.2.0) with ESMTP id k2V7nVBZ009610; Thu, 30 Mar 2006 23:49:31 -0800 (PST) Date: Thu, 30 Mar 2006 23:49:31 -0800 (PST) From: Fan Zhao X-X-Sender: fanzhao@vici.ucdavis.edu To: Fan Zhao In-Reply-To: Message-ID: References: <442B6F07.4090606@tm.uka.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Christian Vogt , Jari Arkko , Mobopts Subject: [Mobopts] Re: CBA vs. draft-zhao-mip6-rr-ext-01.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, One sidenote: CN may not extend the lifetime of binding for each successful binding. Sincerely, fan On Thu, 30 Mar 2006, Fan Zhao wrote: > Hi, Christian, > > On Wed, 29 Mar 2006, Christian Vogt wrote: > > > Hi Fan, > > > > in a previous email, you suggested that the hash-chain mechanism > > described in [1] could be an alternative for Credit-Based Authorization. > > I don't agree with that perception. > > > > [1] draft-zhao-mip6-rr-ext-01.txt > > > > In [1], a MN can prove through a chain of hashes that it has > > successfully gone through the past i correspondent registrations, where > > i is an integer value between 0 and N, and N is initially selected by > > the MN. > > > > Like the similar strategy described in [2], your approach can be used to > > extend the lifetime of the MN's binding at the CN. > > > > [2] draft-arkko-mipv6-binding-lifetime-extension-00.txt > The idea in my mind is actually very similar with [2], i.e. > using the history of communication for a future prediction > but with an additional reaction. > > > > > But a hash chain does not provide any evidence to the CN that a new > > care-of address, chosen by the MN, is correct. An attacker could easily > > re-register with the same CN several times, using valid care-of > > addresses, in order to increase the length of its hash chain. If the CN > > took this as an indication that the MN's next care-of address can be > > trusted, it would be wrong. > The idea is the following: > CN may start to establish the trust with a previously unknown MN > given the ongoing communication. At certain point when MN > starts the handover, CN can still continue to send the traffic to > the unverified CoA. If MN is not malicious, this maximizes the > benefits of EBU because Mn can receive the traffic from CN > seamlessly. If MN is the attacker to attack another victim, > the victim is able to send back a message to CN to request to > stop forwarding the traffic. With an additional message exchange > like the address verification procedure, CN can verify that this > request is indeed from the address that it currently forwards the > traffic to (More precisely, the request can be from any node > on the path anyway.), and then CN would stop forwarding and > give the negative feedback to this malicious MN. > > It is very similar with the real world, for example, the relationship > between humans. > > >From the incentive point of view, > CN is likely to support this option because 1) it can serve > the good MN better. 2) it can stop forwarding the traffic to > the wrong place as it wastes its resources. > > MN is likely to support this option if the handover delay is > really important as it can receive the traffic quickly during > handover. > > Any other node would appreciate the option that helps stop receiving > the wrong traffic from CN. Otherwise, when it is under the attack, it > can not do anything about it except dropping the offending > traffic at the last hop. It will be very happy to provide > the negative feedback to CN once the attack starts. > > > > > The point is that an attacker (alias the MN) does not have to send a > > single data packet until its hash chain is long. But when its hash > > chain is long enough to make the CN trustful, the attacker could > > register a false care-of address and initate a redirection-based > > flooding attack. > > > > Such an attack can have significant amplification given that the > > attacker did not send data packets prior to the attack. > > > > Credit-Based Authorization does not have this vulnerability because it > > limits the data volume a CN can send to a MN's unverified care-of > > address to the data volume that the CN has recently received from that MN. > So my point is that CBA could limit the attack effects. > However, it does not maximize the benefits of EBU. The optimal case > is that the good MN should always receive the traffic without > limitation and the bad attacker should not succeed. But CBA treats > them the same way. > > My proposal sacrifices the victims for the best service for good MNs > because the reality is CN would not have to hold guilty if involved in > reflective DDoS attack and the victim would use that option to help > themselves anyway. > > What do you think? > > Sincerely, > fan > > > > > Take care, > > - Christian > > > > -- > > Christian Vogt, Institute of Telematics, University of Karlsruhe > > www.tm.uka.de/~chvogt/pubkey/ > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 31 03:06:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEe0-0005Cr-A0; Fri, 31 Mar 2006 03:06:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEc5-0004je-NB for mobopts@irtf.org; Fri, 31 Mar 2006 03:04:09 -0500 Received: from vici.ucdavis.edu ([169.237.105.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPEOR-0002iW-RO for mobopts@irtf.org; Fri, 31 Mar 2006 02:50:04 -0500 Received: from localhost (localhost [127.0.0.1]) by vici.ucdavis.edu (8.13.6/8.13.1/it-std-5.2.0) with ESMTP id k2V7o34h009617; Thu, 30 Mar 2006 23:50:03 -0800 (PST) Date: Thu, 30 Mar 2006 23:50:03 -0800 (PST) From: Fan Zhao X-X-Sender: fanzhao@vici.ucdavis.edu To: Christian Vogt Subject: Re: CBA Re: [Mobopts] questions about EBU/CBA In-Reply-To: <442B4E6A.2040308@tm.uka.de> Message-ID: References: <20060327151042.GC24815@boskop.local> <442895DF.4040603@tm.uka.de> <442A1C61.5050301@tm.uka.de> <442B4E6A.2040308@tm.uka.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: on the path anyway.), and then CN would stop forwarding and > give the negative feedback to this malicious MN. > > It is very similar with the real world, for example, the relationship > between humans. > > >From the incentive point of view, > CN is likely to support this option because 1) it can serve > the good MN better. 2) it can stop forwarding the traffic to > the wrong place as it wastes its resources. > > MN is likely to support this option if the handover delay is > really important as it can receive the traffic quickly during > handover. > > Any other node would appreciate the option that helps stop receiving > the wrong traffic from CN. Otherwise, when it is under the attack, it > can not do anything about it except dropping the offending > traffic at the last hop. It will be very happy to provide > the negative feedback to CN once the attack starts. > > > > > The point is that an attacker (alias the MN) does not have to send a > > single data packet until its hash chain is long. But when its hash > > chain is long enough to make the CN trustful, the attacker could > > register a false care-of address and initate a redirection-based > > flooding attack. > > > > Such an attack can have significant amplification given that the > > attacker did not send data packets prior to the attack. > > > > Credit-Based Authorization does not have this vulnerability because it > > limits the data volume a CN can send to a MN's unverified care-of > > address to the data volume that the CN has recently received from that MN. > So my point is that CBA could limit the attack effects. > However, it does not maximize the benefits of EBU. The optimal case > is that the good MN should always receive the traffic without > limitation and the bad attacker should not succeed. But CBA treats > them the same way. > > My proposal sacrifices the victims for the best service for good MNs > because the reality is CN would not have to hold guilty if involved in > reflective DDoS attack and the victim would use that option to help > themselves anyway. > > What do you think? > > Sincerely, > fan > > > > > Take care, > > - Christian > > > > -- > > Christian Vogt, Institute of Telematics, University of Karlsruhe > > www.tm.uka.de/~chvogt/pubkey/ > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 31 03:06:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEe0-0005Cr-A0; Fri, 31 Mar 2006 03:06:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPEc5-0004je-NB for mobopts@irtf.org; Fri, 31 Mar 2006 03:04:09 -0500 Received: from vici.ucdavis.edu ([169.237.105.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPEOR-0002iW-RO for mobopts@irtf.org; Fri, 31 Mar 2006 02:50:04 -0500 Received: from localhost (localhost [127.0.0.1]) by vici.ucdavis.edu (8.13.6/8.13.1/it-std-5.2.0) with ESMTP id k2V7o34h009617; Thu, 30 Mar 2006 23:50:03 -0800 (PST) Date: Thu, 30 Mar 2006 23:50:03 -0800 (PST) From: Fan Zhao X-X-Sender: fanzhao@vici.ucdavis.edu To: Christian Vogt Subject: Re: CBA Re: [Mobopts] questions about EBU/CBA In-Reply-To: <442B4E6A.2040308@tm.uka.de> Message-ID: References: <20060327151042.GC24815@boskop.local> <442895DF.4040603@tm.uka.de> <442A1C61.5050301@tm.uka.de> <442B4E6A.2040308@tm.uka.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, Sorry I do not have enough time to reply on this email. I will do that tomorrow. Good day. Sincerely, fan On Wed, 29 Mar 2006, Christian Vogt wrote: > Fan - > > > I saw you skipped many of my comments. Does it mean you agree on > > them? > > Some of your later comments were already attended to by an earlier > in-line comment from my side. I think I did not skip anything but your > reference to your draft. That I would like to re-read first before I > make a statement. > > >> But the resources consumed by CBA are minor, too--- especially in > >> the case where the CN is strong. > > > > I am not just looking at the resources consumed by CBA, but also the > > impacts on the performances of good MNs, which you did not address > > here. > > Sure, I did. See my later explanation on what happens in case a MN has > insufficient credit during handoff. This is exactly the situation were > CBA might have a performance impact. Performance is still better than > with standard Mobile IPv6. But at the cost of security, which I > consider inacceptable, you may be able to increase performance if you > deactivated CBA. > > >> Things are actually a bit similar with TCP's congestion-avoidance > >> mechanism. Congestion avoidance ensures fair share of network resources > >> between concurrent connections. Like CBA, congestion avoidance is a > >> sender-based mechanism. Non-compliance typically leads to better > >> throughput results for a single connection at the cost of other > >> connections. But most CNs are nevertheless TCP-friendly. > >> > >> While this comparison is not 100% correct, it does show that there is a > >> willingness to support mechanisms even if the benefits of doing so > >> cannot be directly reaped. > > > > I understand your points. However many cases already show TCP behaves > > badly with non-compliant sender/receiver. A standard should not be > > just working but the best from all available. > > My point is that there is wide acceptance of mechanisms which may imply > minor disadvantages for a single connection, but are to the advantage of > the Internet as a whole. TCP congestion avoidance is one example, CBA > is another. Sure there will always be nodes that don't comply. But the > majority of nodes does and will. > > >> With EBU/CBA, the MN can send and receive packets earlier than with > >> standard Mobile IPv6 provided that it has sufficient credit. If it has > >> sufficient credit, EBU/CBA obviously performs better than standard > >> Mobile IPv6. > >> > >> If the MN does not have sufficient credit, there are two options: > >> > >> (a) The CN directs the packets to the MN's HoA. Then, communications > >> can at least continue, albeit via a sub-optimal path. This may be an > >> advantage over standard Mobile IPv6. > >> > >> (b) The CN drops the packets that it cannot send to the MN CoA > >> directly. In this case, the performance of EBU/CBA is the same as that > >> of standard Mobile IPv6 for packets that the CN sends. > > > > Why? In MIP6, CN always sends the packets whenever requested, right? > > But here CN has to drop it. But you may count the advantages that EBU > > results in. I do not know which performance is better definitely in this > > case. > > Consider a handoff scenario. With standard Mobile IPv6, the CN > continues to send packets to the MN's old CoA until it receives the > Binding Update message. These packets won't be received by the MN any > more, so the CN could just as well have dropped the packets in the first > place. > > Also, until the CN receives the Binding Update message, it will drop all > received packets that the MN sends to it from the new CoA due to a > binding-cache mismatch. > > With EBU/CBA, the CN learns about the CoA earlier, namelyopts>, List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, Sorry I do not have enough time to reply on this email. I will do that tomorrow. Good day. Sincerely, fan On Wed, 29 Mar 2006, Christian Vogt wrote: > Fan - > > > I saw you skipped many of my comments. Does it mean you agree on > > them? > > Some of your later comments were already attended to by an earlier > in-line comment from my side. I think I did not skip anything but your > reference to your draft. That I would like to re-read first before I > make a statement. > > >> But the resources consumed by CBA are minor, too--- especially in > >> the case where the CN is strong. > > > > I am not just looking at the resources consumed by CBA, but also the > > impacts on the performances of good MNs, which you did not address > > here. > > Sure, I did. See my later explanation on what happens in case a MN has > insufficient credit during handoff. This is exactly the situation were > CBA might have a performance impact. Performance is still better than > with standard Mobile IPv6. But at the cost of security, which I > consider inacceptable, you may be able to increase performance if you > deactivated CBA. > > >> Things are actually a bit similar with TCP's congestion-avoidance > >> mechanism. Congestion avoidance ensures fair share of network resources > >> between concurrent connections. Like CBA, congestion avoidance is a > >> sender-based mechanism. Non-compliance typically leads to better > >> throughput results for a single connection at the cost of other > >> connections. But most CNs are nevertheless TCP-friendly. > >> > >> While this comparison is not 100% correct, it does show that there is a > >> willingness to support mechanisms even if the benefits of doing so > >> cannot be directly reaped. > > > > I understand your points. However many cases already show TCP behaves > > badly with non-compliant sender/receiver. A standard should not be > > just working but the best from all available. > > My point is that there is wide acceptance of mechanisms which may imply > minor disadvantages for a single connection, but are to the advantage of > the Internet as a whole. TCP congestion avoidance is one example, CBA > is another. Sure there will always be nodes that don't comply. But the > majority of nodes does and will. > > >> With EBU/CBA, the MN can send and receive packets earlier than with > >> standard Mobile IPv6 provided that it has sufficient credit. If it has > >> sufficient credit, EBU/CBA obviously performs better than standard > >> Mobile IPv6. > >> > >> If the MN does not have sufficient credit, there are two options: > >> > >> (a) The CN directs the packets to the MN's HoA. Then, communications > >> can at least continue, albeit via a sub-optimal path. This may be an > >> advantage over standard Mobile IPv6. > >> > >> (b) The CN drops the packets that it cannot send to the MN CoA > >> directly. In this case, the performance of EBU/CBA is the same as that > >> of standard Mobile IPv6 for packets that the CN sends. > > > > Why? In MIP6, CN always sends the packets whenever requested, right? > > But here CN has to drop it. But you may count the advantages that EBU > > results in. I do not know which performance is better definitely in this > > case. > > Consider a handoff scenario. With standard Mobile IPv6, the CN > continues to send packets to the MN's old CoA until it receives the > Binding Update message. These packets won't be received by the MN any > more, so the CN could just as well have dropped the packets in the first > place. > > Also, until the CN receives the Binding Update message, it will drop all > received packets that the MN sends to it from the new CoA due to a > binding-cache mismatch. > > With EBU/CBA, the CN learns about the CoA earlier, namely, when it > receives the Early Binding Update message. It will already accept > packets that the MN sends from the new CoA as of then. This is one > advantage that EBU/CBA has over standard Mobile IPv6. > > Furthermore, if the MN has sufficient credit, the CN can also send > route-optimized packets to the MN's new CoA. This is a second advantage > of EBU/CBA in case credit is available. > > [If the MN does not have sufficient credit, the CN may opt to send > packets for the MN to the HoA. This may be another advantage, provided > the path through the home agent is not too long.] > > > My feeling is CreditAgingFactor and CreditAgingInterval can only > > be derived empirically, which cannot guarantee to work optimally in any > > situation (even we do not what is optimal.). Thus these > > parameters should be different with different network and > > application. For example, RTT in wireless network may vary > > dramatically. > > So you think 500ms for a CoTI-CoT exchange may not be sufficient? > > Note that, if the MN-CN RTT is that high, *reactive* end-to-end mobility > optimizations may not be strong enough anyway. After all, it would take > the same MN-CN RTT until the MN has updated the CN with the new CoA and > the first data packet from the CN has propagated to the new CoA. > > But you can do *proactive* handoffs with EBU/CBA, too, as described in > draft-vogt-mobopts-simple-ebu-00.txt. In such a case, the MN's credit > must cover the L2-handoff delay in addition to the latency of the > CoTI-CoT exchange. > > So yes, there will be situations where the MN may have less credit than > it would want to have. As you say, this is the cost of security. But > there are two important observations that one should make: > > - This is not an all-or-nothing game. Even if credit is insufficient to > cover the entire handoff period, the CN will still send part of the > packets to the MN in a route-optimization way until all credit is gone. > Hence, lack of credit is unlikely to have an impact throughout the > *entire* handoff period, but it may have an impact later during the > handoff period. > > - Applications that benefit most from EBU/CBA are real-time applications > with direct user interaction such as VoIP. Such applications are > typically symmetric in terms of the data rates from the MN to the CN and > vice versa. This is where CBA won't have a performance impact at all, > all the more since the MN earns new credit for sending packets while it > consumes existing credit for receiving packets. > > Referring to your proposal to make credit aging adaptive to different > application and network scenarios: Unfortunately, this is infeasible > from a security standpoint. Credit aging prevents an attacker with > low-bandwidth Internet attachment from acquiring inappropriate volumes > of credit over a long time. Such an attacker could misuse its credit > for a burst of flooding packets which does not compare to what the > attacker itself would be capable to send. > > Given that the type of application can be selected by the MN (or an > attacker), and given that it is by far untrivial for the CN to securely > acquire information about the MN's Internet attachment, credit aging > ought to be kept static and should be designed to work well in a > majority of cases with the types of applications that benefit most. > > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > > > > Fan Zhao wrote: > > Hi Christian, > > > > I saw you skipped many of my comments. Does it mean you agree on > > them? > > > > Please see my reply below. > > > > On Tue, 28 Mar 2006, Christian Vogt wrote: > > > > > >> Hello Fan! > >> > >> Some comments in-line: > >> > >> > >>>> Well, as a content provider, wouldn't you get upset if someone > >>>> misused resources of your servers for a flooding attack? > >>> > >>> The redirection attack should be addressed by address > >>> verification. Due to the lack of address verification in EBU, CBA > >>> is invented; but CBA cannot distinguish betw, when it > receives the Early Binding Update message. It will already accept > packets that the MN sends from the new CoA as of then. This is one > advantage that EBU/CBA has over standard Mobile IPv6. > > Furthermore, if the MN has sufficient credit, the CN can also send > route-optimized packets to the MN's new CoA. This is a second advantage > of EBU/CBA in case credit is available. > > [If the MN does not have sufficient credit, the CN may opt to send > packets for the MN to the HoA. This may be another advantage, provided > the path through the home agent is not too long.] > > > My feeling is CreditAgingFactor and CreditAgingInterval can only > > be derived empirically, which cannot guarantee to work optimally in any > > situation (even we do not what is optimal.). Thus these > > parameters should be different with different network and > > application. For example, RTT in wireless network may vary > > dramatically. > > So you think 500ms for a CoTI-CoT exchange may not be sufficient? > > Note that, if the MN-CN RTT is that high, *reactive* end-to-end mobility > optimizations may not be strong enough anyway. After all, it would take > the same MN-CN RTT until the MN has updated the CN with the new CoA and > the first data packet from the CN has propagated to the new CoA. > > But you can do *proactive* handoffs with EBU/CBA, too, as described in > draft-vogt-mobopts-simple-ebu-00.txt. In such a case, the MN's credit > must cover the L2-handoff delay in addition to the latency of the > CoTI-CoT exchange. > > So yes, there will be situations where the MN may have less credit than > it would want to have. As you say, this is the cost of security. But > there are two important observations that one should make: > > - This is not an all-or-nothing game. Even if credit is insufficient to > cover the entire handoff period, the CN will still send part of the > packets to the MN in a route-optimization way until all credit is gone. > Hence, lack of credit is unlikely to have an impact throughout the > *entire* handoff period, but it may have an impact later during the > handoff period. > > - Applications that benefit most from EBU/CBA are real-time applications > with direct user interaction such as VoIP. Such applications are > typically symmetric in terms of the data rates from the MN to the CN and > vice versa. This is where CBA won't have a performance impact at all, > all the more since the MN earns new credit for sending packets while it > consumes existing credit for receiving packets. > > Referring to your proposal to make credit aging adaptive to different > application and network scenarios: Unfortunately, this is infeasible > from a security standpoint. Credit aging prevents an attacker with > low-bandwidth Internet attachment from acquiring inappropriate volumes > of credit over a long time. Such an attacker could misuse its credit > for a burst of flooding packets which does not compare to what the > attacker itself would be capable to send. > > Given that the type of application can be selected by the MN (or an > attacker), and given that it is by far untrivial for the CN to securely > acquire information about the MN's Internet attachment, credit aging > ought to be kept static and should be designed to work well in a > majority of cases with the types of applications that benefit most. > > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > > > > Fan Zhao wrote: > > Hi Christian, > > > > I saw you skipped many of my comments. Does it mean you agree on > > them? > > > > Please see my reply below. > > > > On Tue, 28 Mar 2006, Christian Vogt wrote: > > > > > >> Hello Fan! > >> > >> Some comments in-line: > >> > >> > >>>> Well, as a content provider, wouldn't you get upset if someone > >>>> misused resources of your servers for a flooding attack? > >>> > >>> The redirection attack should be addressed by address > >>> verification. Due to the lack of address verification in EBU, CBA > >>> is invented; but CBA cannot distinguish between the good and the > >>> bad, thus it is a double-sided sword. > >>> > >>> 1) If the target of the attacker is the content provider itself > >>> (CN in this context), it is similar with supporting many MNs. CBA > >>> is not the solution to help CN because both good and bad MN (the > >>> attacker) receives the same treatment. Also there are many other > >>> ways to flood CN. > >> > >> I wasn't concerned about an attack on the CN (i.e., content > >> provider), > > > > I knew. Just include it for the completeness. > > > > > >> but rather an attack against a third party that the CN becomed > >> involved in. > > > > Yes. I did mention it in the original post. > > > > > >> Such an attack binds resources of the CN, which the CN could > >> otherwise be spent on useful traffic. > >> > >> Still, you are right in saying that the resources bound for the > >> attack may not have a noticable impact if the CN is > >> well-provisioned. > > > > This is not all I mean. But I understand CBA is not for that purpose. > > > > > > > >> But the resources consumed by CBA are minor, too--- especially in > >> the case where the CN is strong. > > > > I am not just looking at the resources consumed by CBA, but also the > > impacts on the performances of good MNs, which you did not address > > here. > > > > > >> If this is not incentive enough, it is up to the protocol > >> specification to make either preemtive reachability verification, > >> or concurrent reachability verification plus CBA a "MUST" to > >> safeguard the Internet as a whole. > > > > My main concern is whether CBA is the best choice. > > > > > >> Things are actually a bit similar with TCP's congestion-avoidance > >> mechanism. Congestion avoidance ensures fair share of network > >> resources between concurrent connections. Like CBA, congestion > >> avoidance is a sender-based mechanism. Non-compliance typically > >> leads to better throughput results for a single connection at the > >> cost of other connections. But most CNs are nevertheless > >> TCP-friendly. > >> > >> While this comparison is not 100% correct, it does show that there > >> is a willingness to support mechanisms even if the benefits of > >> doing so cannot be directly reaped. > > > > I understand your points. However many cases already show TCP behaves > > badly with non-compliant sender/receiver. A standard should not be > > just working but the best from all available. > > > > > >>>> Referring to your concern about the performance impact on > >>>> applications, there are two things to consider: First, Mobile > >>>> IPv6 with EBU/CBA is always at least as good as standard Mobile > >>>> IPv6. > >>> > >>> Can you please elaborate? > >> > >> With EBU/CBA, the MN can send and receive packets earlier than with > >> standard Mobile IPv6 provided that it has sufficient credit. If > >> it has sufficient credit, EBU/CBA obviously performs better than > >> standard Mobile IPv6. > >> > >> If the MN does not have sufficient credit, there are two options: > >> > >> (a) The CN directs the packets to the MN's HoA. Then, > >> communications can at least continue, albeit via a sub-optimal > >> path. This may be an advantage over standard Mobile IPv6. > >> > >> (b) The CN drops the packets that it cannot send to the MN CoA > >> directly. In this case, the performance of EBU/CBA is the same as > >> that of standard Mobile IPv6 for packets that the CN sends. > > > > Why? In MIP6, CN always sends the packets whenever requested, right? > > But here CN has to drop it. But you may count the advantages that EBU > > results in. I do not know which performance is better definitely in > > this case. > > > > > >> The MN can still send packets from an unverified CoA, however. > >> > >> > >>>> Second, CBA works fine for all applications where the data sent > >>>> by the MN and data sent by the CN are roughly balanced. > >>>> > >>>> CBA may run out of credit--- and hence preclude further > >>>> route-optimized traffic until reachability verification > >>>> completes--- if the CN sends at a much higher rate than the MN. > >>>> Wheteen the good and the > >>> bad, thus it is a double-sided sword. > >>> > >>> 1) If the target of the attacker is the content provider itself > >>> (CN in this context), it is similar with supporting many MNs. CBA > >>> is not the solution to help CN because both good and bad MN (the > >>> attacker) receives the same treatment. Also there are many other > >>> ways to flood CN. > >> > >> I wasn't concerned about an attack on the CN (i.e., content > >> provider), > > > > I knew. Just include it for the completeness. > > > > > >> but rather an attack against a third party that the CN becomed > >> involved in. > > > > Yes. I did mention it in the original post. > > > > > >> Such an attack binds resources of the CN, which the CN could > >> otherwise be spent on useful traffic. > >> > >> Still, you are right in saying that the resources bound for the > >> attack may not have a noticable impact if the CN is > >> well-provisioned. > > > > This is not all I mean. But I understand CBA is not for that purpose. > > > > > > > >> But the resources consumed by CBA are minor, too--- especially in > >> the case where the CN is strong. > > > > I am not just looking at the resources consumed by CBA, but also the > > impacts on the performances of good MNs, which you did not address > > here. > > > > > >> If this is not incentive enough, it is up to the protocol > >> specification to make either preemtive reachability verification, > >> or concurrent reachability verification plus CBA a "MUST" to > >> safeguard the Internet as a whole. > > > > My main concern is whether CBA is the best choice. > > > > > >> Things are actually a bit similar with TCP's congestion-avoidance > >> mechanism. Congestion avoidance ensures fair share of network > >> resources between concurrent connections. Like CBA, congestion > >> avoidance is a sender-based mechanism. Non-compliance typically > >> leads to better throughput results for a single connection at the > >> cost of other connections. But most CNs are nevertheless > >> TCP-friendly. > >> > >> While this comparison is not 100% correct, it does show that there > >> is a willingness to support mechanisms even if the benefits of > >> doing so cannot be directly reaped. > > > > I understand your points. However many cases already show TCP behaves > > badly with non-compliant sender/receiver. A standard should not be > > just working but the best from all available. > > > > > >>>> Referring to your concern about the performance impact on > >>>> applications, there are two things to consider: First, Mobile > >>>> IPv6 with EBU/CBA is always at least as good as standard Mobile > >>>> IPv6. > >>> > >>> Can you please elaborate? > >> > >> With EBU/CBA, the MN can send and receive packets earlier than with > >> standard Mobile IPv6 provided that it has sufficient credit. If > >> it has sufficient credit, EBU/CBA obviously performs better than > >> standard Mobile IPv6. > >> > >> If the MN does not have sufficient credit, there are two options: > >> > >> (a) The CN directs the packets to the MN's HoA. Then, > >> communications can at least continue, albeit via a sub-optimal > >> path. This may be an advantage over standard Mobile IPv6. > >> > >> (b) The CN drops the packets that it cannot send to the MN CoA > >> directly. In this case, the performance of EBU/CBA is the same as > >> that of standard Mobile IPv6 for packets that the CN sends. > > > > Why? In MIP6, CN always sends the packets whenever requested, right? > > But here CN has to drop it. But you may count the advantages that EBU > > results in. I do not know which performance is better definitely in > > this case. > > > > > >> The MN can still send packets from an unverified CoA, however. > >> > >> > >>>> Second, CBA works fine for all applications where the data sent > >>>> by the MN and data sent by the CN are roughly balanced. > >>>> > >>>> CBA may run out of credit--- and hence preclude further > >>>> route-optimized traffic until reachability verification > >>>> completes--- if the CN sends at a much higher rate than the MN. > >>>> Whether or not this happens depends on how much the asymmetry > >>>> in data rates is, as well as on the speed of credit aging. > >>>> Fortunately, credit aging is designed to work well for > >>>> applications as asymmetric as a TCP download from the CN to the > >>>> MN. > >>> > >>> I am also wondering how the parameters, CreditAgingFactor and > >>> CreditAgingInterval, are set up? It should be > >>> application-specific rather than static. So a procedure to derive > >>> those parameters dynamically might need to be added in the next > >>> version. > >> > >> CreditAgingFactor and CreditAgingInterval are static parameters. > >> They are chosen in a way that a MN downloading data from a CN can > >> earn sufficient credit even though the MN sends much less than the > >> CN. > >> > >> Assume a PMTU of 1500 bytes. Say, the CN sends full-sized TCP > >> segments, and the MN sends a TCP ACK without any TCP options for > >> every second segment. This is the worst asymmetry that can happen > >> with TCP (given PMTU = 1500 bytes). Further assume, that the nodes > >> need 500ms for the concurrent CoA test. > >> > >> Given and consumed credit equals the size of packets (in bytes) > >> received and sent by the CN, respectively. > >> > >> The question is how long the MN needs to collect credit before > >> simple CBA allows it to do an optimized handoff. So, what's the > >> ratio between the size of packets that the CN sends and the size of > >> packets that the MN sends? > >> > >> The CN sends two full-sized TCP segments. This is 3000 bytes or > >> 3000 credits. > >> > >> The MN sends a TCP ACK upon reception of the second TCP segment. > >> This ACK is composed as follows: > >> > >> IPv6 header (40 bytes) Destination Options Extension Header (24 > >> bytes) HoA Option Padding TCP ACK (20 bytes) > >> > >> Hence, the entire packet is 84 bytes big, and worth 84 credits. > >> > >> The asymmetry ratio between the CN-to-MN flow and the MN-to-CN flow > >> is thus 3000 bytes / 84 bytes = 35.7. The MN therefore needs at > >> least 500ms * 35.7 = 17.9 seconds between two successive handoffs > >> for acquiring sufficient credit for a 500-ms concurrent CoA test. > >> > >> The aging interval should be no shorter than 2 * 17.9 = 35.7 > >> seconds, however, if the credit is cut in half after each such > >> interval. (Folks were talking about 30-seconds to 1-minute aging > >> intervals anyway.) > >> > >> Note that the assumed RTT of 500ms just for a concurrent CoA test > >> is quite long. In many realistic scenarios will the RTT be lower. > >> Moreover, the MN may have more to say than just ACK's. And it gets > >> credit for duplicate ACK's, too. > > > > My feeling is CreditAgingFactor and CreditAgingInterval can only be > > derived empirically, which cannot guarantee to work optimally in any > > situation (even we do not what is optimal.). Thus these parameters > > should be different with different network and application. For > > example, RTT in wireless network may vary dramatically. > > > > Sincerely, fan > > > > > >> Hope this helps. > >> > >> - Christian > >> > >> -- Christian Vogt, Institute of Telematics, University of Karlsruhe > >> www.tm.uka.de/~chvogt/pubkey/ > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts her or not this happens depends on how much the asymmetry > >>>> in data rates is, as well as on the speed of credit aging. > >>>> Fortunately, credit aging is designed to work well for > >>>> applications as asymmetric as a TCP download from the CN to the > >>>> MN. > >>> > >>> I am also wondering how the parameters, CreditAgingFactor and > >>> CreditAgingInterval, are set up? It should be > >>> application-specific rather than static. So a procedure to derive > >>> those parameters dynamically might need to be added in the next > >>> version. > >> > >> CreditAgingFactor and CreditAgingInterval are static parameters. > >> They are chosen in a way that a MN downloading data from a CN can > >> earn sufficient credit even though the MN sends much less than the > >> CN. > >> > >> Assume a PMTU of 1500 bytes. Say, the CN sends full-sized TCP > >> segments, and the MN sends a TCP ACK without any TCP options for > >> every second segment. This is the worst asymmetry that can happen > >> with TCP (given PMTU = 1500 bytes). Further assume, that the nodes > >> need 500ms for the concurrent CoA test. > >> > >> Given and consumed credit equals the size of packets (in bytes) > >> received and sent by the CN, respectively. > >> > >> The question is how long the MN needs to collect credit before > >> simple CBA allows it to do an optimized handoff. So, what's the > >> ratio between the size of packets that the CN sends and the size of > >> packets that the MN sends? > >> > >> The CN sends two full-sized TCP segments. This is 3000 bytes or > >> 3000 credits. > >> > >> The MN sends a TCP ACK upon reception of the second TCP segment. > >> This ACK is composed as follows: > >> > >> IPv6 header (40 bytes) Destination Options Extension Header (24 > >> bytes) HoA Option Padding TCP ACK (20 bytes) > >> > >> Hence, the entire packet is 84 bytes big, and worth 84 credits. > >> > >> The asymmetry ratio between the CN-to-MN flow and the MN-to-CN flow > >> is thus 3000 bytes / 84 bytes = 35.7. The MN therefore needs at > >> least 500ms * 35.7 = 17.9 seconds between two successive handoffs > >> for acquiring sufficient credit for a 500-ms concurrent CoA test. > >> > >> The aging interval should be no shorter than 2 * 17.9 = 35.7 > >> seconds, however, if the credit is cut in half after each such > >> interval. (Folks were talking about 30-seconds to 1-minute aging > >> intervals anyway.) > >> > >> Note that the assumed RTT of 500ms just for a concurrent CoA test > >> is quite long. In many realistic scenarios will the RTT be lower. > >> Moreover, the MN may have more to say than just ACK's. And it gets > >> credit for duplicate ACK's, too. > > > > My feeling is CreditAgingFactor and CreditAgingInterval can only be > > derived empirically, which cannot guarantee to work optimally in any > > situation (even we do not what is optimal.). Thus these parameters > > should be different with different network and application. For > > example, RTT in wireless network may vary dramatically. > > > > Sincerely, fan > > > > > >> Hope this helps. > >> > >> - Christian > >> > >> -- Christian Vogt, Institute of Telematics, University of Karlsruhe > >> www.tm.uka.de/~chvogt/pubkey/ > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 31 14:43:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPPWk-0001Kf-Vw; Fri, 31 Mar 2006 14:43:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPPWj-0001KZ-8W for mobopts@irtf.org; Fri, 31 Mar 2006 14:43:21 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPPWh-0001UU-QA for mobopts@irtf.org; Fri, 31 Mar 2006 14:43:21 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k2VJ3oQ07884 for ; Fri, 31 Mar 2006 11:03:50 -0800 X-mProtect: <200603311903> Nokia Silicon Valley Messaging Protection Received: from da-niradhcp160236.americas.nokia.com (10.241.160.236, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdhEGuIX; Fri, 31 Mar 2006 11:03:48 PST Message-ID: <442D8644.1000801@iprg.nokia.com> Date: Fri, 31 Mar 2006 11:43:00 -0800 From: Rajeev Koodli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "mobopts@irtf.org" Content-Type: multipart/mixed; boundary="------------010904070209080601000108" X-Spam-Score: 0.5 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Mobopts] [Fwd: [IRSG] id citations [was Re: review of ]] X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org This is a multi-part message in MIME format. --------------010904070209080601000108 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------010904070209080601000108 Content-Type: message/rfc822; name="[IRSG] id citations [was Re: review of ]" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="[IRSG] id citations [was Re: review of ]" Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA27066 for ; Wed, 29 Mar 2006 10:40:01 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k2TI0cK05141 for ; Wed, 29 Mar 2006 10:00:38 -0800 X-mProtect: <200603291800> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdF0y9IR; Wed, 29 Mar 2006 10:00:36 PST X-Scanned: Wed, 29 Mar 2006 10:39:46 -0800 Nokia Message Protector V1.3.35 2005042208 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id k2TIdkFN014754 for ; Wed, 29 Mar 2006 10:39:46 -0800 Received: from UNKNOWN (128.9.144.145, claiming to be "gamma.isi.edu") by mailrelay.iprg.nokia.com 00mvJngI; Wed, 29 Mar 2006 10:39:45 PST Received: from gamma.isi.edu (localhost [127.0.0.1]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2TIar214836; Wed, 29 Mar 2006 10:36:53 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by gamma.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2TIa0214227 for ; Wed, 29 Mar 2006 10:36:00 -0800 (PST) Received: from [10.0.1.5] (static-71-246-51-26.lsanca.fios.verizon.net [71.246.51.26]) by vapor.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k2TIZ6F19664; Wed, 29 Mar 2006 10:35:06 -0800 (PST) In-Reply-To: <20060327223415.GA325@boskop.local> References: <20060327223415.GA325@boskop.local> Mime-Version: 1.0 (Apple Message framework v746.3) Message-Id: <24B59C75-4209-43DE-A638-74E462258B0D@isi.edu> From: Aaron Falk Date: Wed, 29 Mar 2006 10:35:05 -0800 To: j.schoenwaelder@iu-bremen.de X-Mailer: Apple Mail (2.746.3) X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean, Found to be clean Cc: irsg@ISI.EDU Subject: [IRSG] id citations [was Re: review of ] X-BeenThere: irsg@mailman.isi.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IRSG private list List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: irsg-bounces@mailman.isi.edu Errors-To: irsg-bounces@mailman.isi.edu X-MailScanner-From: irsg-bounces@mailman.isi.edu On Mar 27, 2006, at 2:34 PM, Juergen Schoenwaelder wrote: > I have a more general observation I like to raise: I counted 29 > citations of Internet Drafts out of 62 citations in total, which means > almost 47% of all citations are "work in progress". I checked up to > reference 22 and it seems that 5 out of the 17 cited IDs among the > first 22 references have already expired. How much should we be > concerned about publishing an RFC which points to quite a bit of > documents not really archived (in the sense that there is not a > defined entity in charge of maintaining access to the cited > documents)? This issue clearly has a wider scope and may require some > discussion or a policy within the IRTF as a whole. I did not go back > to the document to check what the purpose of those citations are, that > is, whether the main optimization idea is sufficiently summarized in > the mobopts draft under review so that the reference more serves as a > way to give credits. In such cases, I would not see a problem. If, > however, a reference is really needed to fully grasp a proposal, then > having dangling pointers is kind of problematic. Juergen- My expectation is that many IRTF documents will cite drafts as IRTF work may draw on less mature activities in the IETF. I don't see this as a problem although it's important that authors not assume the reader will be able to find these documents as they may expire or have title changes. If the work truly relies on the other work in progress, the citation should be normative. The RFC Editor will allow normative references in non-standards documents although authors should consider their use carefully as RFC publication will be delayed until all normative references are published. (I've seen multi-year delays as a result of normative references in IETF documents.) One way around this is to summarize the critical portion of the cited document and make the rest of the citation informative. --aaron _______________________________________________ IRSG mailing list IRSG@mailman.isi.edu http://mailman.isi.edu/mailman/listinfo/irsg --------------010904070209080601000108 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts --------------010904070209080601000108-- From mobopts-bounces@irtf.org Fri Mar 31 20:35:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPV1m-0000rk-K5; Fri, 31 Mar 2006 20:35:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPV1l-0000qi-F8 for mobopts@irtf.org; Fri, 31 Mar 2006 20:35:45 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPV1k-0003JV-UQ for mobopts@irtf.org; Fri, 31 Mar 2006 20:35:45 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D913C8988E; Sat, 1 Apr 2006 04:35:42 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1E1B789884; Sat, 1 Apr 2006 04:35:42 +0300 (EEST) Message-ID: <442DD607.1090409@kolumbus.fi> Date: Sat, 01 Apr 2006 04:23:19 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fan Zhao Subject: Re: [Mobopts] Review of draft-arkko-mipv6-binding-lifetime-extension-00 References: <200603310410.k2V4AwKZ001474@celerio.ucdavis.edu> In-Reply-To: <200603310410.k2V4AwKZ001474@celerio.ucdavis.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.1 (+) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: Christian Vogt , Mobopts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Fan and thanks for your review. Inline: >In BLE and rr-ext (either mip6-rr-ext or mobopts-rr-ext) >the way hash chain is used is different. rr-ext utilizes >the one-way attribute of hash function to authenticate the >identity without home address test thus hash chain elements >are generated firstly and are used in the reverse order from >being generated; while BLE uses hash operation >to associate with the previous binding and aggregate >a sequence of bindings together, thus hash elements are generated >in the chronological order. > >It is not just a coincidence that both drafts uses hash function, >but it means that hash function has some values in RR test, right? > > I think the main point is showing that its the same node all the time; hash function is just a tool for that. Showing that you are talking to the same node is useful for some things (such as possibly giving some more "credit" in some form to it) but is not a sufficient condition by itself for securing RR. For instance, we also need to verify ownership in some way (e.g. home address test) and we also need to worry about setting things back to normal if a node has rebooted or when an attacker was able to show ownership temporarily before you. >2. In abstract, "but can be problematic for hosts in standby mode." >The need of keeping RO state alive in CN when MN is in standby mode >really depends on the communication pattern of MN. For example, if MN >sleeps for a long time before communicating with CN again, IMHO, the >shorter delay of communication when MN wakes up does not justify the >overhead caused by repeating RO with CN periodically. > > Right. All we are saying is that there are situations where its problematic. Its hard for me to quantify how frequent or non-frequent such situations are. Also, it depends on your preferences: maybe your communication is of such importance that you actually do want to receive it as soon as possible. >3. In abstract, "that can reduce this signaling load to around 0.1 >bits per second" > >If I understand this correctly, the overhead is reduced to >0.1 bit/second when the lifetime is 8 hour. I think other metrics >are also useful, for example, how long does it take for MN to achieve >an 8-hour lifetime and to reduce the overhead to 0.1 bits/second, > Right. > what >is average overhead (bit/second)? Depending on the mobility pattern, >MN may not have the opportunity to enjoy the very low overhead. > > Yes. >Assume that the initial lifetime is 2.1=7*0.3 minutes and after >renewing for n times, the lifetime is 2.1*1.3^n=8*60=480 minutes. >Then the total waiting time is 2.1 + 2.1*1.3 + ... + 2.1*1.3^(n-1) >= 1593 minutes = 26.55 hours. > >The average overhead is (376*n bytes)/(2.1 + 2.1*1.3 + ... + 2.1*1.3^(n-1)) >when 2.1*1.3^(n-1)<=8*60. > >4. If I understand correctly, Section 4.1 shows the effort-damage >consideration can be applied to the frequency of address tests. A >malicious or compromised MN may not mind investing 26.55 hours to >achieve 8 hour long lifetime binding (MN may solicit a large amount >of traffic and then leave the current location after achieving 8-hour >BU lifetime with CN, which causes the damages to both CN and the >previous access network.), which opens a larger vulnerable window >and thus is still very profitable for attackers. > > But its not merely about the willingness of the malicious party to invest its own effort. He also needs to be in the right position in the network to do this. For instance, in order to run a home test he needs to be on the path to the home address. >>From the view of a good MN, it wishes to achieve the longer lifetime >as quick as possible. However, in order to make difficulty for the >malicious MN (CN does not know MN is malicious or not.), a good MN >still has to wait for a very long time to enjoy the benefit of long >binding lifetime. In other words, if MN does not stay for a long >enough time period, MN may experience more overhead than that in MIP6. > > True. But this depends on the selection of the parameters -- see also below. >5. On page 7, "The requested lifetime in the Binding Update is not >limited to MAX_RR_BINDING_LIFETIME (7 minutes) but rather t * 0.3." > >Should be "t * 1.3"? > > Well, its a design decision. We wanted the method to be both tighter and looser than original RR, depending on how long your association has lasted; its an attempt to provide a balanced value based on information, rather than applying a chosen fixed value. When we start at 0.3, the initial bindings do in fact last less than 7 mins. >6. The computation of Kcredit in the extended RR test is still >vulnerable to the eavesdroppers on both MN-CN and >HA-CN path. > > Nothing from the original RR really changes with this draft, only the lifetimes. Having said that, I'd note that an RR attack always needs an active attacker, as far as I know. You can certainly look at the values that go by, but they are worthless unless you actually intend to send a harmful BU. >7. In Section 4.4, the field of N is defined in Lifetime Credit >Authorization Option. I think probably the sequence number field >in BU message can be reused for this purpose, thus no need to >define a new field. > > Sure. >8. The modified RR test procedure still needs to pass through home >agent. > > Yep. >9. The draft may also consider utilizing the fact that MN does not >change its CoA in order to improve the security. > > Oh yes. Anyway, in general I think what we've got in cba-cga is what would provide most benefit right now, and at least I am not actively pursuing BLE at this time. >Below is a short comparison. > > I'll leave this to Christian, I did not have time to re-read rr-ext to provide sufficiently good feedback. Thanks for the comparison in any case! --Jari _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 31 21:27:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPVq5-0004jv-TU; Fri, 31 Mar 2006 21:27:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPVq4-0004jq-Qs for mobopts@irtf.org; Fri, 31 Mar 2006 21:27:44 -0500 Received: from vici.ucdavis.edu ([169.237.105.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPVq4-0005Fk-Bs for mobopts@irtf.org; Fri, 31 Mar 2006 21:27:44 -0500 Received: from localhost (localhost [127.0.0.1]) by vici.ucdavis.edu (8.13.6/8.13.1/it-std-5.2.0) with ESMTP id k312Rh8q016106; Fri, 31 Mar 2006 18:27:43 -0800 (PST) Date: Fri, 31 Mar 2006 18:27:43 -0800 (PST) From: Fan Zhao X-X-Sender: fanzhao@vici.ucdavis.edu To: Jari Arkko Subject: Re: [Mobopts] Review of draft-arkko-mipv6-binding-lifetime-extension-00 In-Reply-To: <442DD607.1090409@kolumbus.fi> Message-ID: References: <200603310410.k2V4AwKZ001474@celerio.ucdavis.edu> <442DD607.1090409@kolumbus.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 1.1 (+) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: Christian Vogt , Mobopts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Jari, Thanks for your reply. On Sat, 1 Apr 2006, Jari Arkko wrote: > Hi Fan and thanks for your review. Inline: > > >In BLE and rr-ext (either mip6-rr-ext or mobopts-rr-ext) > >the way hash chain is used is different. rr-ext utilizes > >the one-way attribute of hash function to authenticate the > >identity without home address test thus hash chain elements > >are generated firstly and are used in the reverse order from > >being generated; while BLE uses hash operation > >to associate with the previous binding and aggregate > >a sequence of bindings together, thus hash elements are generated > >in the chronological order. > > > >It is not just a coincidence that both drafts uses hash function, > >but it means that hash function has some values in RR test, right? > > > > > I think the main point is showing that its the same node > all the time; hash function is just a tool for that. Showing > that you are talking to the same node is useful for some things > (such as possibly giving some more "credit" in some form to > it) but is not a sufficient condition by itself for securing RR. > For instance, we also need to verify ownership in some way > (e.g. home address test) and we also need to worry about > setting things back to normal if a node has rebooted or > when an attacker was able to show ownership temporarily > before you. Exactly. > > >2. In abstract, "but can be problematic for hosts in standby mode." > >The need of keeping RO state alive in CN when MN is in standby mode > >really depends on the communication pattern of MN. For example, if MN > >sleeps for a long time before communicating with CN again, IMHO, the > >shorter delay of communication when MN wakes up does not justify the > >overhead caused by repeating RO with CN periodically. > > > > > Right. All we are saying is that there are situations where its > problematic. Its hard for me to quantify how frequent or > non-frequent such situations are. Also, it depends on your > preferences: maybe your communication is of such importance > that you actually do want to receive it as soon as possible. OK. > > >3. In abstract, "that can reduce this signaling load to around 0.1 > >bits per second" > > > >If I understand this correctly, the overhead is reduced to > >0.1 bit/second when the lifetime is 8 hour. I think other metrics > >are also useful, for example, how long does it take for MN to achieve > >an 8-hour lifetime and to reduce the overhead to 0.1 bits/second, > > > Right. > > > what > >is average overhead (bit/second)? Depending on the mobility pattern, > >MN may not have the opportunity to enjoy the very low overhead. > > > > > Yes. > > >Assume that the initial lifetime is 2.1=7*0.3 minutes and after > >renewing for n times, the lifetime is 2.1*1.3^n=8*60=480 minutes. > >Then the total waiting time is 2.1 + 2.1*1.3 + ... + 2.1*1.3^(n-1) > >= 1593 minutes = 26.55 hours. > > > >The average overhead is (376*n bytes)/(2.1 + 2.1*1.3 + ... + 2.1*1.3^(n-1)) > >when 2.1*1.3^(n-1)<=8*60. > > > >4. If I understand correctly, Section 4.1 shows the effort-damage > >consideration can be applied to the frequency of address tests. A > >malicious or compromised MN may not mind investing 26.55 hours to > >achieve 8 hour long lifetime binding (MN may solicit a large amount > >of traffic and then leave the current location after achieving 8-hour > >BU lifetime with CN, which causes the damages to both CN and the > >previous access network.), which opens a larger vulnerable window > >and thus is still very profitable for attackers. > > > > > But its not merely about the willingness of the malicious > party to invest its own effort. He also needs to be in the > right position in the network to do this. For instance, > in order to run a home test he needs to be on the path > to the home address. Agreed. This is my assumption. > > >>From the view of a good MN, it wishes to achieve the longer lifetime > >as quick as possible. However, in order to make difficulty for the > >malicious MN (CN does not know MN is malicious or not.), a good MN > >still has to wait for a very long time to enjoy the benefit of long > >binding lifetime. In other words, if MN does not stay for a long > >enough time period, MN may experience more overhead than that in MIP6. > > > > > True. But this depends on the selection of the parameters -- see > also below. > > >5. On page 7, "The requested lifetime in the Binding Update is not > >limited to MAX_RR_BINDING_LIFETIME (7 minutes) but rather t * 0.3." > > > >Should be "t * 1.3"? > > > > > Well, its a design decision. We wanted the method to be both tighter > and looser than original RR, depending on how long your association > has lasted; its an attempt to provide a balanced value based on > information, rather than applying a chosen fixed value. When > we start at 0.3, the initial bindings do in fact last less than 7 mins. OK. > > >6. The computation of Kcredit in the extended RR test is still > >vulnerable to the eavesdroppers on both MN-CN and > >HA-CN path. > > > > > Nothing from the original RR really changes with this draft, > only the lifetimes. Having said that, I'd note that an RR > attack always needs an active attacker, as far as I know. > You can certainly look at the values that go by, but they > are worthless unless you actually intend to send a harmful > BU. Agreed. > > >7. In Section 4.4, the field of N is defined in Lifetime Credit > >Authorization Option. I think probably the sequence number field > >in BU message can be reused for this purpose, thus no need to > >define a new field. > > > > > Sure. > > >8. The modified RR test procedure still needs to pass through home > >agent. > > > > > Yep. > > >9. The draft may also consider utilizing the fact that MN does not > >change its CoA in order to improve the security. > > > > > Oh yes. Anyway, in general I think what we've got in cba-cga is what > would provide most benefit right now, and at least I am not actively > pursuing BLE at this time. > > >Below is a short comparison. > > > > > I'll leave this to Christian, I did not have time to re-read > rr-ext to provide sufficiently good feedback. Thanks for the > comparison in any case! Thanks for your reply too. Sincerely, fan > > --Jari > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 31 22:11:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPWWj-0006OF-Ap; Fri, 31 Mar 2006 22:11:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPWWh-0006OA-2U for mobopts@irtf.org; Fri, 31 Mar 2006 22:11:47 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPWWf-00071K-Fq for mobopts@irtf.org; Fri, 31 Mar 2006 22:11:47 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FPWWW-0006zX-Fz; Sat, 01 Apr 2006 05:11:44 +0200 Received: from [10.0.0.21] (vpn-cl-165-172.rz.uni-karlsruhe.de [141.3.165.172]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 547E8881A; Sat, 1 Apr 2006 05:11:35 +0200 (CEST) Message-ID: <442DEF65.1050008@tm.uka.de> Date: Fri, 31 Mar 2006 21:11:33 -0600 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.3.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Jari Arkko , Fan Zhao Subject: Re: [Mobopts] Review of draft-arkko-mipv6-binding-lifetime-extension-00 References: <200603310410.k2V4AwKZ001474@celerio.ucdavis.edu> <442DD607.1090409@kolumbus.fi> In-Reply-To: <442DD607.1090409@kolumbus.fi> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.7 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 1.1 (+) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: Mobopts X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Jari, hi Fan, one thing up front: >> 5. On page 7, "The requested lifetime in the Binding Update is not >> limited to MAX_RR_BINDING_LIFETIME (7 minutes) but rather t * 0.3." >> >> Should be "t * 1.3"? Note that t is the *total* time that the MN's binding did so far exist. It's not just the previous lifetime. Therefore, the coefficient must not be greater than 1.0. If the coefficient was greater than 1.0, an attacker could get a binding lifetime that is longer than the time the attacker has been on the right path to maintain the binding. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Jari Arkko wrote: > Hi Fan and thanks for your review. Inline: > > >>In BLE and rr-ext (either mip6-rr-ext or mobopts-rr-ext) >>the way hash chain is used is different. rr-ext utilizes >>the one-way attribute of hash function to authenticate the >>identity without home address test thus hash chain elements >>are generated firstly and are used in the reverse order from >>being generated; while BLE uses hash operation >>to associate with the previous binding and aggregate >>a sequence of bindings together, thus hash elements are generated >>in the chronological order. >> >>It is not just a coincidence that both drafts uses hash function, >>but it means that hash function has some values in RR test, right? >> >> > > I think the main point is showing that its the same node > all the time; hash function is just a tool for that. Showing > that you are talking to the same node is useful for some things > (such as possibly giving some more "credit" in some form to > it) but is not a sufficient condition by itself for securing RR. > For instance, we also need to verify ownership in some way > (e.g. home address test) and we also need to worry about > setting things back to normal if a node has rebooted or > when an attacker was able to show ownership temporarily > before you. > > >>2. In abstract, "but can be problematic for hosts in standby mode." >>The need of keeping RO state alive in CN when MN is in standby mode >>really depends on the communication pattern of MN. For example, if MN >>sleeps for a long time before communicating with CN again, IMHO, the >>shorter delay of communication when MN wakes up does not justify the >>overhead caused by repeating RO with CN periodically. >> >> > > Right. All we are saying is that there are situations where its > problematic. Its hard for me to quantify how frequent or > non-frequent such situations are. Also, it depends on your > preferences: maybe your communication is of such importance > that you actually do want to receive it as soon as possible. > > >>3. In abstract, "that can reduce this signaling load to around 0.1 >>bits per second" >> >>If I understand this correctly, the overhead is reduced to >>0.1 bit/second when the lifetime is 8 hour. I think other metrics >>are also useful, for example, how long does it take for MN to achieve >>an 8-hour lifetime and to reduce the overhead to 0.1 bits/second, >> > > Right. > > >>what >>is average overhead (bit/second)? Depending on the mobility pattern, >>MN may not have the opportunity to enjoy the very low overhead. >> >> > > Yes. > > >>Assume that the initial lifetime is 2.1=7*0.3 minutes and after >>renewing for n times, the lifetime is 2.1*1.3^n=8*60=480 minutes. >>Then the total waiting time is 2.1 + 2.1*1.3 + ... + 2.1*1.3^(n-1) >>= 1593 minutes = 26.55 hours. >> >>The average overhead is (376*n bytes)/(2.1 + 2.1*1.3 + ... + 2.1*1.3^(n-1)) >>when 2.1*1.3^(n-1)<=8*60. >> >>4. If I understand correctly, Section 4.1 shows the effort-damage >>consideration can be applied to the frequency of address tests. A >>malicious or compromised MN may not mind investing 26.55 hours to >>achieve 8 hour long lifetime binding (MN may solicit a large amount >>of traffic and then leave the current location after achieving 8-hour >>BU lifetime with CN, which causes the damages to both CN and the >>previous access network.), which opens a larger vulnerable window >>and thus is still very profitable for attackers. >> >> > > But its not merely about the willingness of the malicious > party to invest its own effort. He also needs to be in the > right position in the network to do this. For instance, > in order to run a home test he needs to be on the path > to the home address. > > >>>From the view of a good MN, it wishes to achieve the longer lifetime >>as quick as possible. However, in order to make difficulty for the >>malicious MN (CN does not know MN is malicious or not.), a good MN >>still has to wait for a very long time to enjoy the benefit of long >>binding lifetime. In other words, if MN does not stay for a long >>enough time period, MN may experience more overhead than that in MIP6. >> >> > > True. But this depends on the selection of the parameters -- see > also below. > > >>5. On page 7, "The requested lifetime in the Binding Update is not >>limited to MAX_RR_BINDING_LIFETIME (7 minutes) but rather t * 0.3." >> >>Should be "t * 1.3"? >> >> > > Well, its a design decision. We wanted the method to be both tighter > and looser than original RR, depending on how long your association > has lasted; its an attempt to provide a balanced value based on > information, rather than applying a chosen fixed value. When > we start at 0.3, the initial bindings do in fact last less than 7 mins. > > >>6. The computation of Kcredit in the extended RR test is still >>vulnerable to the eavesdroppers on both MN-CN and >>HA-CN path. >> >> > > Nothing from the original RR really changes with this draft, > only the lifetimes. Having said that, I'd note that an RR > attack always needs an active attacker, as far as I know. > You can certainly look at the values that go by, but they > are worthless unless you actually intend to send a harmful > BU. > > >>7. In Section 4.4, the field of N is defined in Lifetime Credit >>Authorization Option. I think probably the sequence number field >>in BU message can be reused for this purpose, thus no need to >>define a new field. >> >> > > Sure. > > >>8. The modified RR test procedure still needs to pass through home >>agent. >> >> > > Yep. > > >>9. The draft may also consider utilizing the fact that MN does not >>change its CoA in order to improve the security. >> >> > > Oh yes. Anyway, in general I think what we've got in cba-cga is what > would provide most benefit right now, and at least I am not actively > pursuing BLE at this time. > > >>Below is a short comparison. >> >> > > I'll leave this to Christian, I did not have time to re-read > rr-ext to provide sufficiently good feedback. Thanks for the > comparison in any case! > > --Jari > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 31 23:17:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPXY2-0006O1-D2; Fri, 31 Mar 2006 23:17:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPXY0-0006Nr-Vm for mobopts@irtf.org; Fri, 31 Mar 2006 23:17:12 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPXXz-0001DO-7c for mobopts@irtf.org; Fri, 31 Mar 2006 23:17:12 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FPXXu-0001dK-I5; Sat, 01 Apr 2006 06:17:09 +0200 Received: from [10.0.0.21] (vpn-cl-165-172.rz.uni-karlsruhe.de [141.3.165.172]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 8C9808708; Sat, 1 Apr 2006 06:17:05 +0200 (CEST) Message-ID: <442DFEBF.8030205@tm.uka.de> Date: Fri, 31 Mar 2006 22:17:03 -0600 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.3.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Fan Zhao References: <200603310410.k2V4AwKZ001474@celerio.ucdavis.edu> In-Reply-To: <200603310410.k2V4AwKZ001474@celerio.ucdavis.edu> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.7 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 1.1 (+) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: Mobopts Subject: [Mobopts] Re: Review of draft-arkko-mipv6-binding-lifetime-extension-00 X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Fan, thanks for reviewing draft-arkko-mipv6-binding-lifetime-extension-00! Jari did already respond to the first part of your comments. I will attend to the rest in the following. > This draft (BLE in short) proposes to extend the binding lifetime in > order to reduce the signaling overhead and battery consumption when > MN does not change its location. In Section 5 of draft-zhao- > mobopts-rr-ext-00 (rrext in short, and draft-zhao-mip6-rr-ext-01 as > well) we also consider this case. Below is a short comparison. > > 1. Both drafts use hash chain to prove MN's identity to CN. BLE > combines the new Kbm with the old ones while rrext uses a one-way > hash chain in the reverse order of hash chain generation. > > By doing so, BLE needs less memory, but BLE is still vulnerable to > the eavesdroppers on both MN-CN and HA-CN path. Right. Actually, being on the HA-CN path, plus the ability to send messages from there, is already sufficient to impersonate a MN (which may also be a stationary node, BTW). But that's a property of the RR, too. And as Jari has mentioned, the objective of BLE is to extend the binding lifetime, not to provide better security than the RR. > rrext does need to > allocate more memory to keep the unused hash chain elements, but MN > can easily re-generate the hash chain once the old one is depleted > and the memory and hash operation are cheap nowadays. For example, > assume that a hash element is 16 bytes, 1 M memory can keep hash > elements enough for many days use. I don't think the memory is such a big deal for rrext. It's just a bit of a disadvantage that the MN must start over from the very beginning when its hash elements are used up. > Also rrext can detect the > eavesdropper on both MN-CN and HA-CN path. This is based on the assumption that the MN and the CN never lose state. You propose that the hash elements must be kept in stable storage. Where this is feasible, yes, rrext is immune against an attacker on the HA-CN path. Having said that, I'm still a bit sceptical about not having a fallback mechanism. In scenarios where stable storage at both the MN and the CN is not feasible, the fallback mechanism would allow an attacker on the HA-CN path to reset the hash chain. (It is always like that because the fallback mechanism will, by definition, have to work without knowledge of the hash chain.) Therefore, the existence of a fallback mechanism would in fact eliminate rrext's immunity against attackers on the HA-CN path. > 2. BLE works best for a MN staying at the same location for a very > long time, but rrext benefits MN under any mobility pattern. Wait a moment: Be it BLE or rrext, the MN will have to register anew when it changes its c/o address. Also in both cases, the new binding lifetime is always higher (modulo a small start-up period in BLE) than the lifetime in RFC3775. Note that, in BLE, a new lifetime is calculated as 0.3*t, where t is the *total* time during which the binding has been in existance. It is not just the lifetime used during the previous registration, neither is it reset in case the c/o address changes. In other words, t may cover multiple registrations for multiple c/o addresses. > 3. BLE may expose to a larger vulnerable window by extending the > lifetime, but rrext does not. But that is a matter of choosing protocol-configuration variables, right? > 4. In rrext, the signaling overhead is a little bit more than > (256*8)bits/(7*60)seconds = 4.9 bits/second constantly. Ok. > We can also analyze the power consumption in both drafts. For > example, we may compute how much power is consumed during a certain > time period where the amount of power consumed is equal to c1*f(the > number of bits sent and received during BU with CN) + c2*g(the length > of time period when MN is awake to send the packets.) + other > consumptions. Right. You can also compare just the signaling overhead during a certain time period. That would actually be more meaningful IMO. > rrext sends and receives fewer bits than BLE and spends less time as > well because of home address test procedure in BLE while the lifetime > in BLE may be longer than in rrext. Are you saying that rrext omits the home-address test? - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Fan Zhao wrote: > Hi Christian, > > Please see my comments below on draft-arkko-mipv6- > binding-lifetime-extension-00 (in short, BLE). > > In BLE and rr-ext (either mip6-rr-ext or mobopts-rr-ext) the way hash > chain is used is different. rr-ext utilizes the one-way attribute of > hash function to authenticate the identity without home address test > thus hash chain elements are generated firstly and are used in the > reverse order from being generated; while BLE uses hash operation to > associate with the previous binding and aggregate a sequence of > bindings together, thus hash elements are generated in the > chronological order. > > It is not just a coincidence that both drafts uses hash function, but > it means that hash function has some values in RR test, right? > > 1. In abstract, "This requirement results in an average signaling > traffic of around 7 bits per second when the hosts are not moving > around. This traffic load by itself is neglible," > s/neglible/negligible > > 2. In abstract, "but can be problematic for hosts in standby mode." > The need of keeping RO state alive in CN when MN is in standby mode > really depends on the communication pattern of MN. For example, if MN > sleeps for a long time before communicating with CN again, IMHO, the > shorter delay of communication when MN wakes up does not justify the > overhead caused by repeating RO with CN periodically. > > This comment is also related to the second paragraph in section 1. > > 3. In abstract, "that can reduce this signaling load to around 0.1 > bits per second" > > If I understand this correctly, the overhead is reduced to 0.1 > bit/second when the lifetime is 8 hour. I think other metrics are > also useful, for example, how long does it take for MN to achieve an > 8-hour lifetime and to reduce the overhead to 0.1 bits/second, what > is average overhead (bit/second)? Depending on the mobility pattern, > MN may not have the opportunity to enjoy the very low overhead. > > Assume that the initial lifetime is 2.1=7*0.3 minutes and after > renewing for n times, the lifetime is 2.1*1.3^n=8*60=480 minutes. > Then the total waiting time is 2.1 + 2.1*1.3 + ... + 2.1*1.3^(n-1) = > 1593 minutes = 26.55 hours. > > The average overhead is (376*n bytes)/(2.1 + 2.1*1.3 + ... + > 2.1*1.3^(n-1)) when 2.1*1.3^(n-1)<=8*60. > > 4. If I understand correctly, Section 4.1 shows the effort-damage > consideration can be applied to the frequency of address tests. A > malicious or compromised MN may not mind investing 26.55 hours to > achieve 8 hour long lifetime binding (MN may solicit a large amount > of traffic and then leave the current location after achieving 8-hour > BU lifetime with CN, which causes the damages to both CN and the > previous access network.), which opens a larger vulnerable window and > thus is still very profitable for attackers. > > From the view of a good MN, it wishes to achieve the longer lifetime > as quick as possible. However, in order to make difficulty for the > malicious MN (CN does not know MN is malicious or not.), a good MN > still has to wait for a very long time to enjoy the benefit of long > binding lifetime. In other words, if MN does not stay for a long > enough time period, MN may experience more overhead than that in > MIP6. > > 5. On page 7, "The requested lifetime in the Binding Update is not > limited to MAX_RR_BINDING_LIFETIME (7 minutes) but rather t * 0.3." > > Should be "t * 1.3"? > > 6. The computation of Kcredit in the extended RR test is still > vulnerable to the eavesdroppers on both MN-CN and HA-CN path. > > 7. In Section 4.4, the field of N is defined in Lifetime Credit > Authorization Option. I think probably the sequence number field in > BU message can be reused for this purpose, thus no need to define a > new field. > > 8. The modified RR test procedure still needs to pass through home > agent. > > 9. The draft may also consider utilizing the fact that MN does not > change its CoA in order to improve the security. > > This draft (BLE in short) proposes to extend the binding lifetime in > order to reduce the signaling overhead and battery consumption when > MN does not change its location. In Section 5 of draft-zhao- > mobopts-rr-ext-00 (rrext in short, and draft-zhao-mip6-rr-ext-01 as > well) we also consider this case. Below is a short comparison. > > 1. Both drafts use hash chain to prove MN's identity to CN. BLE > combines the new Kbm with the old ones while rrext uses a one-way > hash chain in the reverse order of hash chain generation. > > By doing so, BLE needs less memory, but BLE is still vulnerable to > the eavesdroppers on both MN-CN and HA-CN path. rrext does need to > allocate more memory to keep the unused hash chain elements, but MN > can easily re-generate the hash chain once the old one is depleted > and the memory and hash operation are cheap nowadays. For example, > assume that a hash element is 16 bytes, 1 M memory can keep hash > elements enough for many days use. Also rrext can detect the > eavesdropper on both MN-CN and HA-CN path. > > 2. BLE works best for a MN staying at the same location for a very > long time, but rrext benefits MN under any mobility pattern. > > 3. BLE may expose to a larger vulnerable window by extending the > lifetime, but rrext does not. > > 4. In rrext, the signaling overhead is a little bit more than > (256*8)bits/(7*60)seconds = 4.9 bits/second constantly. > > We can also analyze the power consumption in both drafts. For > example, we may compute how much power is consumed during a certain > time period where the amount of power consumed is equal to c1*f(the > number of bits sent and received during BU with CN) + c2*g(the length > of time period when MN is awake to send the packets.) + other > consumptions. > > rrext sends and receives fewer bits than BLE and spends less time as > well because of home address test procedure in BLE while the lifetime > in BLE may be longer than in rrext. > > Sicnerely, fan _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 31 23:27:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPXiJ-0002KQ-9G; Fri, 31 Mar 2006 23:27:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPXiI-0002KL-S8 for mobopts@irtf.org; Fri, 31 Mar 2006 23:27:50 -0500 Received: from warsaw.ucdavis.edu ([169.237.104.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPXiI-0001hF-3E for mobopts@irtf.org; Fri, 31 Mar 2006 23:27:50 -0500 Received: from phaenicia.ucdavis.edu (phaenicia.ucdavis.edu [169.237.104.170]) by warsaw.ucdavis.edu (8.13.6/8.13.1/it-defang-5.4.0) with ESMTP id k314RmBU002572; Fri, 31 Mar 2006 20:27:48 -0800 (PST) Received: from phaenicia.ucdavis.edu (localhost [127.0.0.1]) by phaenicia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id k314RmwD006571; Fri, 31 Mar 2006 20:27:48 -0800 (PST) Received: (from www@localhost) by phaenicia.ucdavis.edu (8.12.10/8.12.9/Submit) id k314Rlrr006570; Fri, 31 Mar 2006 20:27:47 -0800 (PST) Date: Fri, 31 Mar 2006 20:27:47 -0800 (PST) Message-Id: <200604010427.k314Rlrr006570@phaenicia.ucdavis.edu> To: Christian Vogt Subject: Re: CBA Re: [Mobopts] questions about EBU/CBA From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [169.237.7.192] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.157 X-Spam-Score: 0.3 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Christian, > Fan - > > > I saw you skipped many of my comments. Does it mean you agree on > > them? > > Some of your later comments were already attended to by an earlier > in-line comment from my side. I think I did not skip anything but your > reference to your draft. That I would like to re-read first before I > make a statement. OK. > > >> But the resources consumed by CBA are minor, too--- especially in > >> the case where the CN is strong. > > > > I am not just looking at the resources consumed by CBA, but also the > > impacts on the performances of good MNs, which you did not address > > here. > > Sure, I did. See my later explanation on what happens in case a MN has > insufficient credit during handoff. This is exactly the situation were > CBA might have a performance impact. Performance is still better than > with standard Mobile IPv6. But at the cost of security, which I > consider inacceptable, you may be able to increase performance if you > deactivated CBA. IMO, address verification is still the best compromise among security, performance and costs so far. It is very difficult to make changes as the equilibrium of these factors will be broken unless there is a killer application so that the people want to use it even with the risk/costs. > > >> Things are actually a bit similar with TCP's congestion-avoidance > >> mechanism. Congestion avoidance ensures fair share of network > resources > >> between concurrent connections. Like CBA, congestion avoidance is a > >> sender-based mechanism. Non-compliance typically leads to better > >> throughput results for a single connection at the cost of other > >> connections. But most CNs are nevertheless TCP-friendly. > >> > >> While this comparison is not 100% correct, it does show that there is > a > >> willingness to support mechanisms even if the benefits of doing so > >> cannot be directly reaped. > > > > I understand your points. However many cases already show TCP behaves > > badly with non-compliant sender/receiver. A standard should not be > > just working but the best from all available. > > My point is that there is wide acceptance of mechanisms which may imply > minor disadvantages for a single connection, but are to the advantage of > the Internet as a whole. TCP congestion avoidance is one example, CBA > is another. Sure there will always be nodes that don't comply. But the > majority of nodes does and will. OK, point taken. It might be because of the history reasons. TCP is already established for so many years that even very good changes, such as syn cookie, are not widely used. Security depends on the weakest link. If the Internet is originally secure, we should do everything we can to keep it perfectly secure. But now it is not and probably will never be. Different vulnerabilities has different levels of severity. The severe vulnerability may make the whole Internet in trouble, thus each node still has incentives to prevent it with the inevitable costs. The efforts to completely prevent any threats may be in vain in a imperfect world. > > >> With EBU/CBA, the MN can send and receive packets earlier than with > >> standard Mobile IPv6 provided that it has sufficient credit. If it > has > >> sufficient credit, EBU/CBA obviously performs better than standard > >> Mobile IPv6. > >> > >> If the MN does not have sufficient credit, there are two options: > >> > >> (a) The CN directs the packets to the MN's HoA. Then, communications > >> can at least continue, albeit via a sub-optimal path. This may be an > >> advantage over standard Mobile IPv6. > >> > >> (b) The CN drops the packets that it cannot send to the MN CoA > >> directly. In this case, the performance of EBU/CBA is the same as > that > >> of standard Mobile IPv6 for packets that the CN sends. > > > > Why? In MIP6, CN always sends the packets whenever requested, right? > > But here CN has to drop it. But you may count the advantages that EBU > > results in. I do not know which performance is better definitely in > this > > case. > > Consider a handoff scenario. With standard Mobile IPv6, the CN > continues to send packets to the MN's old CoA until it receives the > Binding Update message. These packets won't be received by the MN any > more, so the CN could just as well have dropped the packets in the first > place. > > Also, until the CN receives the Binding Update message, it will drop all > received packets that the MN sends to it from the new CoA due to a > binding-cache mismatch. > > With EBU/CBA, the CN learns about the CoA earlier, namely, when it > receives the Early Binding Update message. It will already accept > packets that the MN sends from the new CoA as of then. This is one > advantage that EBU/CBA has over standard Mobile IPv6. > > Furthermore, if the MN has sufficient credit, the CN can also send > route-optimized packets to the MN's new CoA. This is a second advantage > of EBU/CBA in case credit is available. > > [If the MN does not have sufficient credit, the CN may opt to send > packets for the MN to the HoA. This may be another advantage, provided > the path through the home agent is not too long.] OK. However with a unidirectional UDP communication between CN and MN, there is no credit but costs generated. Overall CBA/EBU yields benefits more or less but I am not sure if it is signaficant considering the cost. > > > My feeling is CreditAgingFactor and CreditAgingInterval can only > > be derived empirically, which cannot guarantee to work optimally in any > > situation (even we do not what is optimal.). Thus these > > parameters should be different with different network and > > application. For example, RTT in wireless network may vary > > dramatically. > > So you think 500ms for a CoTI-CoT exchange may not be sufficient? No, I am just thinking that the amount of credits should be _just_ enough for the communication before the new CoA verification is done, thus different applications/network communications may need different credits. In some situations this amount of credits is even less than the credits collected via CBA. Along the line of your thinking, in order to keep the flooding attack unattractive to attackers, you want to associate the credits with the efforts of packet sending before, which may cause the insufficient credits. > > Note that, if the MN-CN RTT is that high, *reactive* end-to-end mobility > optimizations may not be strong enough anyway. After all, it would take > the same MN-CN RTT until the MN has updated the CN with the new CoA and > the first data packet from the CN has propagated to the new CoA. > > But you can do *proactive* handoffs with EBU/CBA, too, as described in > draft-vogt-mobopts-simple-ebu-00.txt. In such a case, the MN's credit > must cover the L2-handoff delay in addition to the latency of the > CoTI-CoT exchange. > > So yes, there will be situations where the MN may have less credit than > it would want to have. As you say, this is the cost of security. But > there are two important observations that one should make: > > - This is not an all-or-nothing game. Even if credit is insufficient to > cover the entire handoff period, the CN will still send part of the > packets to the MN in a route-optimization way until all credit is gone. > Hence, lack of credit is unlikely to have an impact throughout the > *entire* handoff period, but it may have an impact later during the > handoff period. > > - Applications that benefit most from EBU/CBA are real-time applications > with direct user interaction such as VoIP. Such applications are > typically symmetric in terms of the data rates from the MN to the CN and > vice versa. This is where CBA won't have a performance impact at all, > all the more since the MN earns new credit for sending packets while it > consumes existing credit for receiving packets. > > Referring to your proposal to make credit aging adaptive to different > application and network scenarios: Unfortunately, this is infeasible > from a security standpoint. Credit aging prevents an attacker with > low-bandwidth Internet attachment from acquiring inappropriate volumes > of credit over a long time. Such an attacker could misuse its credit > for a burst of flooding packets which does not compare to what the > attacker itself would be capable to send. > > Given that the type of application can be selected by the MN (or an > attacker), and given that it is by far untrivial for the CN to securely > acquire information about the MN's Internet attachment, credit aging > ought to be kept static and should be designed to work well in a > majority of cases with the types of applications that benefit most. Thanks for your time for discussions. At least I can say I understand your points clearly. Hope this concludes our discussions. Sincerely, fan > > - Christian > > -- > Christian Vogt, Institute of Telematics, University of Karlsruhe > www.tm.uka.de/~chvogt/pubkey/ > > > > Fan Zhao wrote: > > Hi Christian, > > > > I saw you skipped many of my comments. Does it mean you agree on > > them? > > > > Please see my reply below. > > > > On Tue, 28 Mar 2006, Christian Vogt wrote: > > > > > >> Hello Fan! > >> > >> Some comments in-line: > >> > >> > >>>> Well, as a content provider, wouldn't you get upset if someone > >>>> misused resources of your servers for a flooding attack? > >>> > >>> The redirection attack should be addressed by address > >>> verification. Due to the lack of address verification in EBU, CBA > >>> is invented; but CBA cannot distinguish between the good and the > >>> bad, thus it is a double-sided sword. > >>> > >>> 1) If the target of the attacker is the content provider itself > >>> (CN in this context), it is similar with supporting many MNs. CBA > >>> is not the solution to help CN because both good and bad MN (the > >>> attacker) receives the same treatment. Also there are many other > >>> ways to flood CN. > >> > >> I wasn't concerned about an attack on the CN (i.e., content > >> provider), > > > > I knew. Just include it for the completeness. > > > > > >> but rather an attack against a third party that the CN becomed > >> involved in. > > > > Yes. I did mention it in the original post. > > > > > >> Such an attack binds resources of the CN, which the CN could > >> otherwise be spent on useful traffic. > >> > >> Still, you are right in saying that the resources bound for the > >> attack may not have a noticable impact if the CN is > >> well-provisioned. > > > > This is not all I mean. But I understand CBA is not for that purpose. > > > > > > > >> But the resources consumed by CBA are minor, too--- especially in > >> the case where the CN is strong. > > > > I am not just looking at the resources consumed by CBA, but also the > > impacts on the performances of good MNs, which you did not address > > here. > > > > > >> If this is not incentive enough, it is up to the protocol > >> specification to make either preemtive reachability verification, > >> or concurrent reachability verification plus CBA a "MUST" to > >> safeguard the Internet as a whole. > > > > My main concern is whether CBA is the best choice. > > > > > >> Things are actually a bit similar with TCP's congestion-avoidance > >> mechanism. Congestion avoidance ensures fair share of network > >> resources between concurrent connections. Like CBA, congestion > >> avoidance is a sender-based mechanism. Non-compliance typically > >> leads to better throughput results for a single connection at the > >> cost of other connections. But most CNs are nevertheless > >> TCP-friendly. > >> > >> While this comparison is not 100% correct, it does show that there > >> is a willingness to support mechanisms even if the benefits of > >> doing so cannot be directly reaped. > > > > I understand your points. However many cases already show TCP behaves > > badly with non-compliant sender/receiver. A standard should not be > > just working but the best from all available. > > > > > >>>> Referring to your concern about the performance impact on > >>>> applications, there are two things to consider: First, Mobile > >>>> IPv6 with EBU/CBA is always at least as good as standard Mobile > >>>> IPv6. > >>> > >>> Can you please elaborate? > >> > >> With EBU/CBA, the MN can send and receive packets earlier than with > >> standard Mobile IPv6 provided that it has sufficient credit. If > >> it has sufficient credit, EBU/CBA obviously performs better than > >> standard Mobile IPv6. > >> > >> If the MN does not have sufficient credit, there are two options: > >> > >> (a) The CN directs the packets to the MN's HoA. Then, > >> communications can at least continue, albeit via a sub-optimal > >> path. This may be an advantage over standard Mobile IPv6. > >> > >> (b) The CN drops the packets that it cannot send to the MN CoA > >> directly. In this case, the performance of EBU/CBA is the same as > >> that of standard Mobile IPv6 for packets that the CN sends. > > > > Why? In MIP6, CN always sends the packets whenever requested, right? > > But here CN has to drop it. But you may count the advantages that EBU > > results in. I do not know which performance is better definitely in > > this case. > > > > > >> The MN can still send packets from an unverified CoA, however. > >> > >> > >>>> Second, CBA works fine for all applications where the data sent > >>>> by the MN and data sent by the CN are roughly balanced. > >>>> > >>>> CBA may run out of credit--- and hence preclude further > >>>> route-optimized traffic until reachability verification > >>>> completes--- if the CN sends at a much higher rate than the MN. > >>>> Whether or not this happens depends on how much the asymmetry > >>>> in data rates is, as well as on the speed of credit aging. > >>>> Fortunately, credit aging is designed to work well for > >>>> applications as asymmetric as a TCP download from the CN to the > >>>> MN. > >>> > >>> I am also wondering how the parameters, CreditAgingFactor and > >>> CreditAgingInterval, are set up? It should be > >>> application-specific rather than static. So a procedure to derive > >>> those parameters dynamically might need to be added in the next > >>> version. > >> > >> CreditAgingFactor and CreditAgingInterval are static parameters. > >> They are chosen in a way that a MN downloading data from a CN can > >> earn sufficient credit even though the MN sends much less than the > >> CN. > >> > >> Assume a PMTU of 1500 bytes. Say, the CN sends full-sized TCP > >> segments, and the MN sends a TCP ACK without any TCP options for > >> every second segment. This is the worst asymmetry that can happen > >> with TCP (given PMTU = 1500 bytes). Further assume, that the nodes > >> need 500ms for the concurrent CoA test. > >> > >> Given and consumed credit equals the size of packets (in bytes) > >> received and sent by the CN, respectively. > >> > >> The question is how long the MN needs to collect credit before > >> simple CBA allows it to do an optimized handoff. So, what's the > >> ratio between the size of packets that the CN sends and the size of > >> packets that the MN sends? > >> > >> The CN sends two full-sized TCP segments. This is 3000 bytes or > >> 3000 credits. > >> > >> The MN sends a TCP ACK upon reception of the second TCP segment. > >> This ACK is composed as follows: > >> > >> IPv6 header (40 bytes) Destination Options Extension Header (24 > >> bytes) HoA Option Padding TCP ACK (20 bytes) > >> > >> Hence, the entire packet is 84 bytes big, and worth 84 credits. > >> > >> The asymmetry ratio between the CN-to-MN flow and the MN-to-CN flow > >> is thus 3000 bytes / 84 bytes = 35.7. The MN therefore needs at > >> least 500ms * 35.7 = 17.9 seconds between two successive handoffs > >> for acquiring sufficient credit for a 500-ms concurrent CoA test. > >> > >> The aging interval should be no shorter than 2 * 17.9 = 35.7 > >> seconds, however, if the credit is cut in half after each such > >> interval. (Folks were talking about 30-seconds to 1-minute aging > >> intervals anyway.) > >> > >> Note that the assumed RTT of 500ms just for a concurrent CoA test > >> is quite long. In many realistic scenarios will the RTT be lower. > >> Moreover, the MN may have more to say than just ACK's. And it gets > >> credit for duplicate ACK's, too. > > > > My feeling is CreditAgingFactor and CreditAgingInterval can only be > > derived empirically, which cannot guarantee to work optimally in any > > situation (even we do not what is optimal.). Thus these parameters > > should be different with different network and application. For > > example, RTT in wireless network may vary dramatically. > > > > Sincerely, fan > > > > > >> Hope this helps. > >> > >> - Christian > >> > >> -- Christian Vogt, Institute of Telematics, University of Karlsruhe > >> www.tm.uka.de/~chvogt/pubkey/ > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 31 23:44:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPXyq-0000Gt-7y; Fri, 31 Mar 2006 23:44:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPXyp-0000Gl-2j for mobopts@irtf.org; Fri, 31 Mar 2006 23:44:55 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPXyn-00029N-Bp for mobopts@irtf.org; Fri, 31 Mar 2006 23:44:55 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FPXyh-0002sr-4R; Sat, 01 Apr 2006 06:44:50 +0200 Received: from [10.0.0.21] (vpn-cl-165-172.rz.uni-karlsruhe.de [141.3.165.172]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id E0816864F; Sat, 1 Apr 2006 06:44:45 +0200 (CEST) Message-ID: <442E053C.30501@tm.uka.de> Date: Fri, 31 Mar 2006 22:44:44 -0600 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.3.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Fan Zhao References: <442B6F07.4090606@tm.uka.de> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -4.7 (----) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -0.3 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Cc: Jari Arkko , Mobopts Subject: [Mobopts] Re: CBA vs. draft-zhao-mip6-rr-ext-01.txt X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Fan, couple of responses below. >> Hi Fan, >> >> in a previous email, you suggested that the hash-chain mechanism >> described in [1] could be an alternative for Credit-Based >> Authorization. I don't agree with that perception. >> >> [1] draft-zhao-mip6-rr-ext-01.txt >> >> In [1], a MN can prove through a chain of hashes that it has >> successfully gone through the past i correspondent registrations, >> where i is an integer value between 0 and N, and N is initially >> selected by the MN. >> >> Like the similar strategy described in [2], your approach can be >> used to extend the lifetime of the MN's binding at the CN. >> >> [2] draft-arkko-mipv6-binding-lifetime-extension-00.txt > > The idea in my mind is actually very similar with [2], i.e. using the > history of communication for a future prediction but with an > additional reaction. > >> But a hash chain does not provide any evidence to the CN that a new >> care-of address, chosen by the MN, is correct. An attacker could >> easily re-register with the same CN several times, using valid >> care-of addresses, in order to increase the length of its hash >> chain. If the CN took this as an indication that the MN's next >> care-of address can be trusted, it would be wrong. > > The idea is the following: CN may start to establish the trust with a > previously unknown MN given the ongoing communication. At certain > point when MN starts the handover, CN can still continue to send the > traffic to the unverified CoA. If MN is not malicious, this maximizes > the benefits of EBU because Mn can receive the traffic from CN > seamlessly. If MN is the attacker to attack another victim, the > victim is able to send back a message to CN to request to stop > forwarding the traffic. With an additional message exchange like the > address verification procedure, CN can verify that this request is > indeed from the address that it currently forwards the traffic to > (More precisely, the request can be from any node on the path > anyway.), and then CN would stop forwarding and give the negative > feedback to this malicious MN. I don't like the idea of allowing an attacker to do what it wants and requiring other nodes to protect themselves in case of an attack. E.g., how would you realize the additional message exchange that you are describing when the victim is a legacy node that does not support your mobility protocol? > It is very similar with the real world, for example, the relationship > between humans. Human behavior may not always be a good measure. ;-) > From the incentive point of view, CN is likely to support this option > because 1) it can serve the good MN better. 2) it can stop forwarding > the traffic to the wrong place as it wastes its resources. See my comment above. > MN is likely to support this option if the handover delay is really > important as it can receive the traffic quickly during handover. > > Any other node would appreciate the option that helps stop receiving > the wrong traffic from CN. Otherwise, when it is under the attack, it > can not do anything about it except dropping the offending traffic > at the last hop. It will be very happy to provide the negative > feedback to CN once the attack starts. Again, see above. >> The point is that an attacker (alias the MN) does not have to send >> a single data packet until its hash chain is long. But when its >> hash chain is long enough to make the CN trustful, the attacker >> could register a false care-of address and initate a >> redirection-based flooding attack. >> >> Such an attack can have significant amplification given that the >> attacker did not send data packets prior to the attack. >> >> Credit-Based Authorization does not have this vulnerability because >> it limits the data volume a CN can send to a MN's unverified >> care-of address to the data volume that the CN has recently >> received from that MN. > > So my point is that CBA could limit the attack effects. However, it > does not maximize the benefits of EBU. The optimal case is that the > good MN should always receive the traffic without limitation and the > bad attacker should not succeed. But CBA treats them the same way. In simple CBA (where the MN gets credit for packets that the CN has received from it), the MN will always have enough credit if it sends approximately at the same rate as the CN does. This is the case for interactive real-time applications such as VoIP, i.e., the type of application for which the need for optimization is probably most urgent. But even for applications like TCP downloads, where most data goes from the CN to the MN, the MN is very likely to gather sufficient credit with most mobility patterns given the chosen parameters for credit aging. BTW, with advanced CBA (where the MN gets credit for packets received from the CN), you don't have a problem with any type of application. See draft-vogt-mobopts-credit-based-authorization-00.txt. > My proposal sacrifices the victims for the best service for good MNs > because the reality is CN would not have to hold guilty if involved > in reflective DDoS attack and the victim would use that option to > help themselves anyway. > > What do you think? See my comments above. Alright, take care! - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Fan Zhao wrote: > Hi, Christian, > > On Wed, 29 Mar 2006, Christian Vogt wrote: > > >> Hi Fan, >> >> in a previous email, you suggested that the hash-chain mechanism >> described in [1] could be an alternative for Credit-Based >> Authorization. I don't agree with that perception. >> >> [1] draft-zhao-mip6-rr-ext-01.txt >> >> In [1], a MN can prove through a chain of hashes that it has >> successfully gone through the past i correspondent registrations, >> where i is an integer value between 0 and N, and N is initially >> selected by the MN. >> >> Like the similar strategy described in [2], your approach can be >> used to extend the lifetime of the MN's binding at the CN. >> >> [2] draft-arkko-mipv6-binding-lifetime-extension-00.txt > > The idea in my mind is actually very similar with [2], i.e. using the > history of communication for a future prediction but with an > additional reaction. > > >> But a hash chain does not provide any evidence to the CN that a new >> care-of address, chosen by the MN, is correct. An attacker could >> easily re-register with the same CN several times, using valid >> care-of addresses, in order to increase the length of its hash >> chain. If the CN took this as an indication that the MN's next >> care-of address can be trusted, it would be wrong. > > The idea is the following: CN may start to establish the trust with a > previously unknown MN given the ongoing communication. At certain > point when MN starts the handover, CN can still continue to send the > traffic to the unverified CoA. If MN is not malicious, this maximizes > the benefits of EBU because Mn can receive the traffic from CN > seamlessly. If MN is the attacker to attack another victim, the > victim is able to send back a message to CN to request to stop > forwarding the traffic. With an additional message exchange like the > address verification procedure, CN can verify that this request is > indeed from the address that it currently forwards the traffic to > (More precisely, the request can be from any node on the path > anyway.), and then CN would stop forwarding and give the negative > feedback to this malicious MN. > > It is very similar with the real world, for example, the relationship > between humans. > > From the incentive point of view, CN is likely to support this option > because 1) it can serve the good MN better. 2) it can stop forwarding > the traffic to the wrong place as it wastes its resources. > > MN is likely to support this option if the handover delay is really > important as it can receive the traffic quickly during handover. > > Any other node would appreciate the option that helps stop receiving > the wrong traffic from CN. Otherwise, when it is under the attack, it > can not do anything about it except dropping the offending traffic > at the last hop. It will be very happy to provide the negative > feedback to CN once the attack starts. > > >> The point is that an attacker (alias the MN) does not have to send >> a single data packet until its hash chain is long. But when its >> hash chain is long enough to make the CN trustful, the attacker >> could register a false care-of address and initate a >> redirection-based flooding attack. >> >> Such an attack can have significant amplification given that the >> attacker did not send data packets prior to the attack. >> >> Credit-Based Authorization does not have this vulnerability because >> it limits the data volume a CN can send to a MN's unverified >> care-of address to the data volume that the CN has recently >> received from that MN. > > So my point is that CBA could limit the attack effects. However, it > does not maximize the benefits of EBU. The optimal case is that the > good MN should always receive the traffic without limitation and the > bad attacker should not succeed. But CBA treats them the same way. > > My proposal sacrifices the victims for the best service for good MNs > because the reality is CN would not have to hold guilty if involved > in reflective DDoS attack and the victim would use that option to > help themselves anyway. > > What do you think? > > Sincerely, fan > > >> Take care, - Christian >> >> -- Christian Vogt, Institute of Telematics, University of Karlsruhe >> www.tm.uka.de/~chvogt/pubkey/ >> _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Mar 31 23:55:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPY8t-0004IR-As; Fri, 31 Mar 2006 23:55:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPY8s-0004Ev-BC for mobopts@irtf.org; Fri, 31 Mar 2006 23:55:18 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPY8r-0002T0-DE for mobopts@irtf.org; Fri, 31 Mar 2006 23:55:18 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=smtp.ipv6.tm.uni-karlsruhe.de) by iramx1.ira.uni-karlsruhe.de with esmtps id 1FPY8j-0003LV-Py; Sat, 01 Apr 2006 06:55:16 +0200 Received: from [10.0.0.21] (vpn-cl-165-172.rz.uni-karlsruhe.de [141.3.165.172]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 857E88648; Sat, 1 Apr 2006 06:55:08 +0200 (CEST) Message-ID: <442E07AA.9080001@tm.uka.de> Date: Fri, 31 Mar 2006 22:55:06 -0600 From: Christian Vogt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; us-US; rv:1.7.5) Gecko/20041206 Thunderbird/1.0 Mnenhy/0.7.3.0 X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Fan Zhao Subject: Re: CBA Re: [Mobopts] questions about EBU/CBA References: <200604010427.k314Rlrr006570@phaenicia.ucdavis.edu> In-Reply-To: <200604010427.k314Rlrr006570@phaenicia.ucdavis.edu> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Spam-Status: No X-Spam-Report: -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP 3.5 BAD_CREDIT BODY: Eliminate Bad Credit -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] -2.0 AWL AWL: From: address is in the auto white-list X-Spam-Score: 0.3 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org > Thanks for your time for discussions. At least I can say I understand > your points clearly. Hope this concludes our discussions. Alright, Fan, thanks likewise. - Christian -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ Fan Zhao wrote: > Hi Christian, > > >>Fan - >> >> >>>I saw you skipped many of my comments. Does it mean you agree on >>>them? >> >>Some of your later comments were already attended to by an earlier >>in-line comment from my side. I think I did not skip anything but your >>reference to your draft. That I would like to re-read first before I >>make a statement. > > OK. > > >>>>But the resources consumed by CBA are minor, too--- especially in >>>>the case where the CN is strong. >>> >>>I am not just looking at the resources consumed by CBA, but also the >>>impacts on the performances of good MNs, which you did not address >>>here. >> >>Sure, I did. See my later explanation on what happens in case a MN has >>insufficient credit during handoff. This is exactly the situation were >>CBA might have a performance impact. Performance is still better than >>with standard Mobile IPv6. But at the cost of security, which I >>consider inacceptable, you may be able to increase performance if you >>deactivated CBA. > > IMO, address verification is still the best compromise > among security, performance and costs so far. It is very difficult to > make changes as the equilibrium of these factors will be broken > unless there is a killer application so that the people want to > use it even with the risk/costs. > > >>>>Things are actually a bit similar with TCP's congestion-avoidance >>>>mechanism. Congestion avoidance ensures fair share of network >> >>resources >> >>>>between concurrent connections. Like CBA, congestion avoidance is a >>>>sender-based mechanism. Non-compliance typically leads to better >>>>throughput results for a single connection at the cost of other >>>>connections. But most CNs are nevertheless TCP-friendly. >>>> >>>>While this comparison is not 100% correct, it does show that there is >> >>a >> >>>>willingness to support mechanisms even if the benefits of doing so >>>>cannot be directly reaped. >>> >>>I understand your points. However many cases already show TCP behaves >>>badly with non-compliant sender/receiver. A standard should not be >>>just working but the best from all available. >> >>My point is that there is wide acceptance of mechanisms which may imply >>minor disadvantages for a single connection, but are to the advantage of >>the Internet as a whole. TCP congestion avoidance is one example, CBA >>is another. Sure there will always be nodes that don't comply. But the >>majority of nodes does and will. > > OK, point taken. It might be because of the history reasons. TCP is > already > established for so many years that even very good changes, such as > syn cookie, are not widely used. > > Security depends on the weakest link. If the Internet is originally > secure, we should do everything we can to keep it perfectly > secure. But now it is not and probably will never be. > Different vulnerabilities has different levels of severity. > The severe vulnerability may make the whole Internet > in trouble, thus each node still has incentives to prevent it with > the inevitable costs. The efforts to completely prevent any threats > may be in vain in a imperfect world. > > >>>>With EBU/CBA, the MN can send and receive packets earlier than with >>>>standard Mobile IPv6 provided that it has sufficient credit. If it >> >>has >> >>>>sufficient credit, EBU/CBA obviously performs better than standard >>>>Mobile IPv6. >>>> >>>>If the MN does not have sufficient credit, there are two options: >>>> >>>>(a) The CN directs the packets to the MN's HoA. Then, communications >>>>can at least continue, albeit via a sub-optimal path. This may be an >>>>advantage over standard Mobile IPv6. >>>> >>>>(b) The CN drops the packets that it cannot send to the MN CoA >>>>directly. In this case, the performance of EBU/CBA is the same as >> >>that >> >>>>of standard Mobile IPv6 for packets that the CN sends. >>> >>>Why? In MIP6, CN always sends the packets whenever requested, right? >>>But here CN has to drop it. But you may count the advantages that EBU >>>results in. I do not know which performance is better definitely in >> >>this >> >>>case. >> >>Consider a handoff scenario. With standard Mobile IPv6, the CN >>continues to send packets to the MN's old CoA until it receives the >>Binding Update message. These packets won't be received by the MN any >>more, so the CN could just as well have dropped the packets in the first >>place. >> >>Also, until the CN receives the Binding Update message, it will drop all >>received packets that the MN sends to it from the new CoA due to a >>binding-cache mismatch. >> >>With EBU/CBA, the CN learns about the CoA earlier, namely, when it >>receives the Early Binding Update message. It will already accept >>packets that the MN sends from the new CoA as of then. This is one >>advantage that EBU/CBA has over standard Mobile IPv6. >> >>Furthermore, if the MN has sufficient credit, the CN can also send >>route-optimized packets to the MN's new CoA. This is a second advantage >>of EBU/CBA in case credit is available. >> >>[If the MN does not have sufficient credit, the CN may opt to send >>packets for the MN to the HoA. This may be another advantage, provided >>the path through the home agent is not too long.] > > OK. However with a unidirectional UDP communication between CN and MN, > there is no credit but costs generated. Overall CBA/EBU yields > benefits more or less but I am not sure if it is > signaficant considering the cost. > > >>>My feeling is CreditAgingFactor and CreditAgingInterval can only >>>be derived empirically, which cannot guarantee to work optimally in any >>>situation (even we do not what is optimal.). Thus these >>>parameters should be different with different network and >>>application. For example, RTT in wireless network may vary >>>dramatically. >> >>So you think 500ms for a CoTI-CoT exchange may not be sufficient? > > No, I am just thinking that the amount of credits should > be _just_ enough for the communication before the new CoA verification > is done, thus different applications/network communications may need > different credits. In some situations this amount of credits is > even less than the credits collected via CBA. Along the line of > your thinking, in order to keep the flooding attack unattractive > to attackers, you want to associate the credits with the efforts of > packet sending before, which may cause the insufficient credits. > > >>Note that, if the MN-CN RTT is that high, *reactive* end-to-end mobility >>optimizations may not be strong enough anyway. After all, it would take >>the same MN-CN RTT until the MN has updated the CN with the new CoA and >>the first data packet from the CN has propagated to the new CoA. >> >>But you can do *proactive* handoffs with EBU/CBA, too, as described in >>draft-vogt-mobopts-simple-ebu-00.txt. In such a case, the MN's credit >>must cover the L2-handoff delay in addition to the latency of the >>CoTI-CoT exchange. >> >>So yes, there will be situations where the MN may have less credit than >>it would want to have. As you say, this is the cost of security. But >>there are two important observations that one should make: >> >>- This is not an all-or-nothing game. Even if credit is insufficient to >>cover the entire handoff period, the CN will still send part of the >>packets to the MN in a route-optimization way until all credit is gone. >> Hence, lack of credit is unlikely to have an impact throughout the >>*entire* handoff period, but it may have an impact later during the >>handoff period. >> >>- Applications that benefit most from EBU/CBA are real-time applications >>with direct user interaction such as VoIP. Such applications are >>typically symmetric in terms of the data rates from the MN to the CN and >>vice versa. This is where CBA won't have a performance impact at all, >>all the more since the MN earns new credit for sending packets while it >>consumes existing credit for receiving packets. >> >>Referring to your proposal to make credit aging adaptive to different >>application and network scenarios: Unfortunately, this is infeasible >>from a security standpoint. Credit aging prevents an attacker with >>low-bandwidth Internet attachment from acquiring inappropriate volumes >>of credit over a long time. Such an attacker could misuse its credit >>for a burst of flooding packets which does not compare to what the >>attacker itself would be capable to send. >> >>Given that the type of application can be selected by the MN (or an >>attacker), and given that it is by far untrivial for the CN to securely >>acquire information about the MN's Internet attachment, credit aging >>ought to be kept static and should be designed to work well in a >>majority of cases with the types of applications that benefit most. > > > Thanks for your time for discussions. At least I can say I understand > your points clearly. Hope this concludes our discussions. > > Sincerely, > fan > > >>- Christian >> >>-- >>Christian Vogt, Institute of Telematics, University of Karlsruhe >>www.tm.uka.de/~chvogt/pubkey/ >> >> >> >>Fan Zhao wrote: >> >>>Hi Christian, >>> >>>I saw you skipped many of my comments. Does it mean you agree on >>>them? >>> >>>Please see my reply below. >>> >>>On Tue, 28 Mar 2006, Christian Vogt wrote: >>> >>> >>> >>>>Hello Fan! >>>> >>>>Some comments in-line: >>>> >>>> >>>> >>>>>>Well, as a content provider, wouldn't you get upset if someone >>>>>>misused resources of your servers for a flooding attack? >>>>> >>>>>The redirection attack should be addressed by address >>>>>verification. Due to the lack of address verification in EBU, CBA >>>>>is invented; but CBA cannot distinguish between the good and the >>>>>bad, thus it is a double-sided sword. >>>>> >>>>>1) If the target of the attacker is the content provider itself >>>>>(CN in this context), it is similar with supporting many MNs. CBA >>>>>is not the solution to help CN because both good and bad MN (the >>>>>attacker) receives the same treatment. Also there are many other >>>>>ways to flood CN. >>>> >>>>I wasn't concerned about an attack on the CN (i.e., content >>>>provider), >>> >>>I knew. Just include it for the completeness. >>> >>> >>> >>>>but rather an attack against a third party that the CN becomed >>>>involved in. >>> >>>Yes. I did mention it in the original post. >>> >>> >>> >>>>Such an attack binds resources of the CN, which the CN could >>>>otherwise be spent on useful traffic. >>>> >>>>Still, you are right in saying that the resources bound for the >>>>attack may not have a noticable impact if the CN is >>>>well-provisioned. >>> >>>This is not all I mean. But I understand CBA is not for that purpose. >>> >>> >>> >>> >>>>But the resources consumed by CBA are minor, too--- especially in >>>>the case where the CN is strong. >>> >>>I am not just looking at the resources consumed by CBA, but also the >>>impacts on the performances of good MNs, which you did not address >>>here. >>> >>> >>> >>>>If this is not incentive enough, it is up to the protocol >>>>specification to make either preemtive reachability verification, >>>>or concurrent reachability verification plus CBA a "MUST" to >>>>safeguard the Internet as a whole. >>> >>>My main concern is whether CBA is the best choice. >>> >>> >>> >>>>Things are actually a bit similar with TCP's congestion-avoidance >>>>mechanism. Congestion avoidance ensures fair share of network >>>>resources between concurrent connections. Like CBA, congestion >>>>avoidance is a sender-based mechanism. Non-compliance typically >>>>leads to better throughput results for a single connection at the >>>>cost of other connections. But most CNs are nevertheless >>>>TCP-friendly. >>>> >>>>While this comparison is not 100% correct, it does show that there >>>>is a willingness to support mechanisms even if the benefits of >>>>doing so cannot be directly reaped. >>> >>>I understand your points. However many cases already show TCP behaves >>> badly with non-compliant sender/receiver. A standard should not be >>>just working but the best from all available. >>> >>> >>> >>>>>>Referring to your concern about the performance impact on >>>>>>applications, there are two things to consider: First, Mobile >>>>>>IPv6 with EBU/CBA is always at least as good as standard Mobile >>>>>>IPv6. >>>>> >>>>>Can you please elaborate? >>>> >>>>With EBU/CBA, the MN can send and receive packets earlier than with >>>> standard Mobile IPv6 provided that it has sufficient credit. If >>>>it has sufficient credit, EBU/CBA obviously performs better than >>>>standard Mobile IPv6. >>>> >>>>If the MN does not have sufficient credit, there are two options: >>>> >>>>(a) The CN directs the packets to the MN's HoA. Then, >>>>communications can at least continue, albeit via a sub-optimal >>>>path. This may be an advantage over standard Mobile IPv6. >>>> >>>>(b) The CN drops the packets that it cannot send to the MN CoA >>>>directly. In this case, the performance of EBU/CBA is the same as >>>>that of standard Mobile IPv6 for packets that the CN sends. >>> >>>Why? In MIP6, CN always sends the packets whenever requested, right? >>>But here CN has to drop it. But you may count the advantages that EBU >>> results in. I do not know which performance is better definitely in >>>this case. >>> >>> >>> >>>>The MN can still send packets from an unverified CoA, however. >>>> >>>> >>>> >>>>>>Second, CBA works fine for all applications where the data sent >>>>>>by the MN and data sent by the CN are roughly balanced. >>>>>> >>>>>>CBA may run out of credit--- and hence preclude further >>>>>>route-optimized traffic until reachability verification >>>>>>completes--- if the CN sends at a much higher rate than the MN. >>>>>> Whether or not this happens depends on how much the asymmetry >>>>>>in data rates is, as well as on the speed of credit aging. >>>>>>Fortunately, credit aging is designed to work well for >>>>>>applications as asymmetric as a TCP download from the CN to the >>>>>>MN. >>>>> >>>>>I am also wondering how the parameters, CreditAgingFactor and >>>>>CreditAgingInterval, are set up? It should be >>>>>application-specific rather than static. So a procedure to derive >>>>>those parameters dynamically might need to be added in the next >>>>>version. >>>> >>>>CreditAgingFactor and CreditAgingInterval are static parameters. >>>>They are chosen in a way that a MN downloading data from a CN can >>>>earn sufficient credit even though the MN sends much less than the >>>>CN. >>>> >>>>Assume a PMTU of 1500 bytes. Say, the CN sends full-sized TCP >>>>segments, and the MN sends a TCP ACK without any TCP options for >>>>every second segment. This is the worst asymmetry that can happen >>>>with TCP (given PMTU = 1500 bytes). Further assume, that the nodes >>>>need 500ms for the concurrent CoA test. >>>> >>>>Given and consumed credit equals the size of packets (in bytes) >>>>received and sent by the CN, respectively. >>>> >>>>The question is how long the MN needs to collect credit before >>>>simple CBA allows it to do an optimized handoff. So, what's the >>>>ratio between the size of packets that the CN sends and the size of >>>>packets that the MN sends? >>>> >>>>The CN sends two full-sized TCP segments. This is 3000 bytes or >>>>3000 credits. >>>> >>>>The MN sends a TCP ACK upon reception of the second TCP segment. >>>>This ACK is composed as follows: >>>> >>>>IPv6 header (40 bytes) Destination Options Extension Header (24 >>>>bytes) HoA Option Padding TCP ACK (20 bytes) >>>> >>>>Hence, the entire packet is 84 bytes big, and worth 84 credits. >>>> >>>>The asymmetry ratio between the CN-to-MN flow and the MN-to-CN flow >>>>is thus 3000 bytes / 84 bytes = 35.7. The MN therefore needs at >>>>least 500ms * 35.7 = 17.9 seconds between two successive handoffs >>>>for acquiring sufficient credit for a 500-ms concurrent CoA test. >>>> >>>>The aging interval should be no shorter than 2 * 17.9 = 35.7 >>>>seconds, however, if the credit is cut in half after each such >>>>interval. (Folks were talking about 30-seconds to 1-minute aging >>>>intervals anyway.) >>>> >>>>Note that the assumed RTT of 500ms just for a concurrent CoA test >>>>is quite long. In many realistic scenarios will the RTT be lower. >>>>Moreover, the MN may have more to say than just ACK's. And it gets >>>> credit for duplicate ACK's, too. >>> >>>My feeling is CreditAgingFactor and CreditAgingInterval can only be >>>derived empirically, which cannot guarantee to work optimally in any >>>situation (even we do not what is optimal.). Thus these parameters >>>should be different with different network and application. For >>>example, RTT in wireless network may vary dramatically. >>> >>>Sincerely, fan >>> >>> >>> >>>>Hope this helps. >>>> >>>>- Christian >>>> >>>>-- Christian Vogt, Institute of Telematics, University of Karlsruhe >>>> www.tm.uka.de/~chvogt/pubkey/ >> >> _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts