From exim@www1.ietf.org Tue Mar 2 20:59:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20254 for ; Tue, 2 Mar 2004 20:59:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLey-0005Hk-ER for mobopts-archive@odin.ietf.org; Tue, 02 Mar 2004 20:58:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i231wuCV020315 for mobopts-archive@odin.ietf.org; Tue, 2 Mar 2004 20:58:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLey-0005Ha-9X for mobopts-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 20:58:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20232 for ; Tue, 2 Mar 2004 20:58:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLev-0003sI-00 for mobopts-web-archive@irtf.org; Tue, 02 Mar 2004 20:58:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLdx-0003jY-00 for mobopts-web-archive@irtf.org; Tue, 02 Mar 2004 20:57:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyLd5-0003a9-00 for mobopts-web-archive@irtf.org; Tue, 02 Mar 2004 20:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLd6-0004hF-QI; Tue, 02 Mar 2004 20:57:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLcD-0004W7-Jt for mobopts@optimus.ietf.org; Tue, 02 Mar 2004 20:56:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19914 for ; Tue, 2 Mar 2004 20:56:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLcB-0003Op-00 for mobopts@irtf.org; Tue, 02 Mar 2004 20:56:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLb8-0003B4-00 for mobopts@irtf.org; Tue, 02 Mar 2004 20:54:59 -0500 Received: from fmr09.intel.com ([192.52.57.35] helo=hermes.hd.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1AyLa9-0002sM-00 for mobopts@irtf.org; Tue, 02 Mar 2004 20:53:57 -0500 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.9 2004/01/09 00:55:23 root Exp $) with ESMTP id i231rRGh011716 for ; Wed, 3 Mar 2004 01:53:27 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.hd.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.10 2004/03/01 19:22:27 root Exp $) with SMTP id i231r3X5026853 for ; Wed, 3 Mar 2004 01:53:27 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030217532614711 for ; Tue, 02 Mar 2004 17:53:26 -0800 Received: from orsmsx403.amr.corp.intel.com ([192.168.65.209]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Mar 2004 17:53:27 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C400C2.51BCB0EC" X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Tue, 2 Mar 2004 17:53:26 -0800 Message-ID: Thread-Topic: IEEE 802.21 Trigger Documents Thread-Index: AcQAwlFbn1HNNpYcTnihoLcLJt37/w== From: "Johnston, Dj" To: X-OriginalArrivalTime: 03 Mar 2004 01:53:27.0008 (UTC) FILETIME=[51D97E00:01C400C2] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Subject: [Mobopts] IEEE 802.21 Trigger Documents Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.9 required=5.0 tests=AWL,HTML_60_70,HTML_MESSAGE, OPT_HEADER autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C400C2.51BCB0EC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The documents relevant to the IEEE 802.21 triggers discussion this afternoon can be found at.. =20 http://www.ieee802.org/handoff/march04_meeting_docs/802.21_IETF_Mobopts_ r1.pdf =20 and =20 http://www.ieee802.org/handoff/march04_meeting_docs/Generalized_triggers -02.pdf =20 Regards, DJ (interim 802.21 chair) =20 ------_=_NextPart_001_01C400C2.51BCB0EC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
The = documents=20 relevant to the IEEE 802.21 triggers discussion this afternoon can be = found=20 at..
 
http://www.ieee802.org/handoff/march04_meeting_docs/802.21= _IETF_Mobopts_r1.pdf
 
and
 
http://www.ieee802.org/handoff/march04_meeting_docs/Gener= alized_triggers-02.pdf
 
Regards,
DJ = (interim 802.21=20 chair)
 
=00 ------_=_NextPart_001_01C400C2.51BCB0EC-- _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Tue Mar 2 22:56:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27180 for ; Tue, 2 Mar 2004 22:56:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNUJ-0002Wm-Kd for mobopts-archive@odin.ietf.org; Tue, 02 Mar 2004 22:56:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i233u3g4009710 for mobopts-archive@odin.ietf.org; Tue, 2 Mar 2004 22:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNUJ-0002WX-Fu for mobopts-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 22:56:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27100 for ; Tue, 2 Mar 2004 22:55:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNUG-0006cc-00 for mobopts-web-archive@irtf.org; Tue, 02 Mar 2004 22:56:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNTH-0006TU-00 for mobopts-web-archive@irtf.org; Tue, 02 Mar 2004 22:54:59 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyNSL-0006LW-00 for mobopts-web-archive@irtf.org; Tue, 02 Mar 2004 22:54:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyNSM-0001cd-SF for mobopts-web-archive@irtf.org; Tue, 02 Mar 2004 22:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNSM-0001zJ-D1; Tue, 02 Mar 2004 22:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyNRW-0001yJ-37 for mobopts@optimus.ietf.org; Tue, 02 Mar 2004 22:53:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27048 for ; Tue, 2 Mar 2004 22:53:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyNRS-0006Dw-00 for mobopts@irtf.org; Tue, 02 Mar 2004 22:53:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyNQe-00066E-00 for mobopts@irtf.org; Tue, 02 Mar 2004 22:52:17 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AyNPy-0005tF-00 for mobopts@irtf.org; Tue, 02 Mar 2004 22:51:34 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HTZ00J01EOY0R@mailout2.samsung.com> for mobopts@irtf.org; Wed, 03 Mar 2004 12:50:58 +0900 (KST) Received: from ep_ms3_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HTZ00D8CEOXUQ@mailout2.samsung.com> for mobopts@irtf.org; Wed, 03 Mar 2004 12:50:57 +0900 (KST) Received: from ep_spt01 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HTZ001XZEOXF8@ms3.samsung.com> for mobopts@irtf.org; Wed, 03 Mar 2004 12:50:57 +0900 (KST) Content-return: prohibited Date: Wed, 03 Mar 2004 03:51:06 +0000 (GMT) From: PARK SOO HONG Subject: Re :[Mobopts] IEEE 802.21 Trigger Documents X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2JpbA==?= =?windows-1252?B?ZSBQbGF0Zm9ybSBMYWI/UmVzZWFyY2hlcg==?= To: soohong.park@samsung.com Cc: "mobopts@irtf.org " Reply-to: soohong.park@samsung.com Message-id: <0HTZ001Y0EOXF8@ms3.samsung.com> MIME-version: 1.0 Content-type: text/html; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040303035046822@soohong.park X-MTR: 20040303035046822@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Generator: NamoMIME 1.1.0.14 Content-Transfer-Encoding: 7BIT Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.9 required=5.0 tests=AWL,HTML_40_50,HTML_MESSAGE, MIME_HTML_ONLY,OPT_HEADER,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Samsung Enterprise Portal mySingle Message >Hi folks,

>Either works for me too.

>We are glad to meet you in Seoul.

 

ditto, please let me know the fixed date



Regards

 

Daniel (Soohong Daniel Park)

Mobile Platform Laboratory. SAMSUNG Electronics


_______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Wed Mar 3 01:10:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05372 for ; Wed, 3 Mar 2004 01:10:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPa2-0005MT-2d for mobopts-archive@odin.ietf.org; Wed, 03 Mar 2004 01:10:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i236A6xB020601 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 01:10:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPa1-0005M0-QP for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 01:10:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05346 for ; Wed, 3 Mar 2004 01:10:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyPZy-0004on-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 01:10:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyPZ0-0004fz-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 01:09:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyPXz-0004Qn-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 01:07:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPY1-0004wb-TY; Wed, 03 Mar 2004 01:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPXB-0004l9-TN for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 01:07:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05212 for ; Wed, 3 Mar 2004 01:07:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyPX8-0004Mn-00 for mobopts@irtf.org; Wed, 03 Mar 2004 01:07:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyPWC-0004C6-00 for mobopts@irtf.org; Wed, 03 Mar 2004 01:06:08 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AyPVD-0003tO-00 for mobopts@irtf.org; Wed, 03 Mar 2004 01:05:07 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i2364adO012555; Tue, 2 Mar 2004 22:04:37 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2364XQ23755; Wed, 3 Mar 2004 07:04:33 +0100 (MET) Date: Tue, 2 Mar 2004 22:04:37 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark To: chvogt@tm.uka.de, mobopts@irtf.org Cc: erik.nordmark@sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Subject: [Mobopts] Comments on Early Binding Updates Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Since we ran out of mike time I have two points: I think basing the "credits" on amount of data sent by the MN instead of supposedly received by the MN makes sense for two reasons: - avoid needing crypto-strength proof that the MN has indeed received the packets it acknowledges - handle assymetric access link bandwidth Today the amount of flooding a node can cause is limited by the bandwidth it can transmit. Thus if you have ADSL you might be able to receive 1.5Mbps you can send much less. Unless this assymetry is a very temporary technological glitch we shouldn't ignore it. --- It might be worth-while to think about bandwidth and rate limiting as an alternative to byte/packet counting. While it is hard to determine the actual rate at which the MN can send, I think it would be interesting to understand this part. For instance, if the MN can only send at 64 kbps could one restrict the CN to send at 64 kbps until the CoA has been confirmed? (Perhaps there are orchestration issues here - could the MN use this to orchestrate multiple CNs for a DDoS?) Erik _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Wed Mar 3 01:59:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07244 for ; Wed, 3 Mar 2004 01:59:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQKw-00059k-Cg for mobopts-archive@odin.ietf.org; Wed, 03 Mar 2004 01:58:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i236wYeM019814 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 01:58:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQKw-00059V-7V for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 01:58:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07221 for ; Wed, 3 Mar 2004 01:58:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQKs-0003mW-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 01:58:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQK3-0003ca-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 01:57:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyQJP-0003Ru-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 01:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQJR-0004hV-QC; Wed, 03 Mar 2004 01:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQJ0-0004bm-6I for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 01:56:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07057 for ; Wed, 3 Mar 2004 01:56:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQIw-0003Q9-00 for mobopts@irtf.org; Wed, 03 Mar 2004 01:56:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQIF-0003FM-00 for mobopts@irtf.org; Wed, 03 Mar 2004 01:55:47 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AyQHO-000326-00 for mobopts@irtf.org; Wed, 03 Mar 2004 01:54:54 -0500 Message-ID: <4df901c400ec$8262ee60$3e6015ac@dclkempt40> From: "James Kempf" To: "Erik Nordmark" , , Cc: References: Subject: Re: [Mobopts] Comments on Early Binding Updates Date: Tue, 2 Mar 2004 22:55:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > Since we ran out of mike time I have two points: > > I think basing the "credits" on amount of data sent by the MN instead > of supposedly received by the MN makes sense for two reasons: > - avoid needing crypto-strength proof that the MN has indeed received > the packets it acknowledges > - handle assymetric access link bandwidth > > Today the amount of flooding a node can cause is limited by > the bandwidth it can transmit. Thus if you have ADSL you might be > able to receive 1.5Mbps you can send much less. > Unless this assymetry is a very temporary technological glitch > we shouldn't ignore it. > > --- > > It might be worth-while to think about bandwidth and rate limiting > as an alternative to byte/packet counting. While it is hard to determine > the actual rate at which the MN can send, I think it would be interesting > to understand this part. For instance, if the MN can only send at 64 kbps > could one restrict the CN to send at 64 kbps until the CoA has been confirmed? > (Perhaps there are orchestration issues here - could the MN use this to > orchestrate multiple CNs for a DDoS?) > How could one enforce this in a deployment/implementation where the MN's stack could be hacked to get around the limitation? jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Wed Mar 3 02:31:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05994 for ; Wed, 3 Mar 2004 02:31:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQqN-0008Ao-A5 for mobopts-archive@odin.ietf.org; Wed, 03 Mar 2004 02:31:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i237V34e031408 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 02:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQq7-00086q-45 for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 02:31:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04990 for ; Wed, 3 Mar 2004 02:30:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQpj-0001fk-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 02:30:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQnq-00010t-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 02:28:27 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyQlu-0000UW-03 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 02:26:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyQZu-0004hf-53 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 02:14:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQZu-0003Nz-4O; Wed, 03 Mar 2004 02:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQZF-00034Q-Jo for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 02:13:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20636 for ; Wed, 3 Mar 2004 02:13:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQZC-0006cN-00 for mobopts@irtf.org; Wed, 03 Mar 2004 02:13:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQYh-0006UA-00 for mobopts@irtf.org; Wed, 03 Mar 2004 02:12:48 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AyQXu-0006Ku-00 for mobopts@irtf.org; Wed, 03 Mar 2004 02:11:58 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 988A96A904; Wed, 3 Mar 2004 09:11:56 +0200 (EET) Message-ID: <404584B5.2050500@kolumbus.fi> Date: Wed, 03 Mar 2004 09:09:41 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: chvogt@tm.uka.de, mobopts@irtf.org Subject: Re: [Mobopts] Comments on Early Binding Updates References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > Since we ran out of mike time I have two points: > > I think basing the "credits" on amount of data sent by the MN instead > of supposedly received by the MN makes sense for two reasons: > - avoid needing crypto-strength proof that the MN has indeed received > the packets it acknowledges > - handle assymetric access link bandwidth > > Today the amount of flooding a node can cause is limited by > the bandwidth it can transmit. Thus if you have ADSL you might be > able to receive 1.5Mbps you can send much less. > Unless this assymetry is a very temporary technological glitch > we shouldn't ignore it. Right. > It might be worth-while to think about bandwidth and rate limiting > as an alternative to byte/packet counting. While it is hard to determine > the actual rate at which the MN can send, I think it would be interesting > to understand this part. For instance, if the MN can only send at 64 kbps > could one restrict the CN to send at 64 kbps until the CoA has been confirmed? > (Perhaps there are orchestration issues here - could the MN use this to > orchestrate multiple CNs for a DDoS?) Bandwidth limiting may be fine as well, at least if the "effort" needed to "show" that you can do 64 kbps is bigger than the effort needed to send IP packets with a spoofed source address at 64 kbps (which the mobile node can do in any case). The reason why we want to have this limit on the effort is to ensure that we don't introduce easier attacks than we already have in the Internet. Perhaps the real question, however, is which one is easier, packet counting or bandwidith limiting? In any case, these methods belong to the class of asymmetric cost schemes. The general idea is that attacker's cost increases faster than defense cost, damage cost, or like in this case, the cost of another attack. --Jari _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Wed Mar 3 02:31:38 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06013 for ; Wed, 3 Mar 2004 02:31:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQqP-0008Bo-Hr for mobopts-archive@odin.ietf.org; Wed, 03 Mar 2004 02:31:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i237V5gr031474 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 02:31:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQq5-00086P-7T for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 02:31:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04958 for ; Wed, 3 Mar 2004 02:30:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQph-0001eU-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 02:30:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQno-00010G-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 02:28:24 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyQlu-0000UW-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 02:26:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyQar-0004ij-0O for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 02:15:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQar-0003mj-5O; Wed, 03 Mar 2004 02:15:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQa1-0003SQ-PD for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 02:14:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20736 for ; Wed, 3 Mar 2004 02:14:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQZy-0006jS-00 for mobopts@irtf.org; Wed, 03 Mar 2004 02:14:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQZ0-0006at-00 for mobopts@irtf.org; Wed, 03 Mar 2004 02:13:07 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AyQY4-0006Rc-00 for mobopts@irtf.org; Wed, 03 Mar 2004 02:12:08 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 3B7236A904; Wed, 3 Mar 2004 09:12:07 +0200 (EET) Message-ID: <404584BF.60408@kolumbus.fi> Date: Wed, 03 Mar 2004 09:09:51 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: Erik Nordmark , chvogt@tm.uka.de, mobopts@irtf.org Subject: Re: [Mobopts] Comments on Early Binding Updates References: <4df901c400ec$8262ee60$3e6015ac@dclkempt40> In-Reply-To: <4df901c400ec$8262ee60$3e6015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James Kempf wrote: >>It might be worth-while to think about bandwidth and rate limiting >>as an alternative to byte/packet counting. While it is hard to determine >>the actual rate at which the MN can send, I think it would be interesting >>to understand this part. For instance, if the MN can only send at 64 kbps >>could one restrict the CN to send at 64 kbps until the CoA has been > > confirmed? > >>(Perhaps there are orchestration issues here - could the MN use this to >>orchestrate multiple CNs for a DDoS?) >> > > > How could one enforce this in a deployment/implementation where the MN's > stack could be hacked to get around the limitation? It does not matter what the MN's stack does. We have to assume it can be compromised, or even evil to begin with. But the point is that the MN has to provide some assurance to the CN that it has spent a lot of effort in past communication with the CN. Under this condition, the CN can send some packets to the claimed care-of address even before its verification. Why? Because an evil MN can already send spoofed TCP SYN packets or ICMP Echo Requests, and get a 1-1 flooding at the victim site. With the condition that we will set, the flooding is less than 1-1, i.e., you will have to do more work to get one packet to the victim. --Jari P.S. There might be an effect to what denial-of-service tracing mechanisms do for this. But the last time I checked, at least the IETF (maybe even the world) had given up on such tracing schemes. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Wed Mar 3 03:01:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08855 for ; Wed, 3 Mar 2004 03:01:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRJa-0000Gc-RN for mobopts-archive@odin.ietf.org; Wed, 03 Mar 2004 03:01:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2381EUq001014 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 03:01:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRJJ-0000E0-L0 for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 03:01:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08575 for ; Wed, 3 Mar 2004 03:00:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRIv-0007g6-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 03:00:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRHI-0007EQ-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 02:58:52 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRGU-00070O-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 02:58:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyRCd-0005ba-3I for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 02:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRCd-0007om-1o; Wed, 03 Mar 2004 02:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRCN-0007mX-O0 for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 02:53:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08144 for ; Wed, 3 Mar 2004 02:53:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRBu-0005M7-00 for mobopts@irtf.org; Wed, 03 Mar 2004 02:53:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRAw-0005AB-00 for mobopts@irtf.org; Wed, 03 Mar 2004 02:52:18 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1AyR9v-0004xJ-00 for mobopts@irtf.org; Wed, 03 Mar 2004 02:51:15 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i237pCi5003531; Wed, 3 Mar 2004 00:51:13 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i237p8Q03555; Wed, 3 Mar 2004 08:51:08 +0100 (MET) Date: Tue, 2 Mar 2004 23:51:12 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [Mobopts] Comments on Early Binding Updates To: James Kempf Cc: Erik Nordmark , chvogt@tm.uka.de, mobopts@irtf.org, erik.nordmark@sun.com In-Reply-To: "Your message with ID" <4df901c400ec$8262ee60$3e6015ac@dclkempt40> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 > How could one enforce this in a deployment/implementation where the MN's > stack could be hacked to get around the limitation? Logic lives on the CN. The MN's input to this piece of logic is only the number/rate that it sends to the CN. It can't "fake" this since it is limited by the outgoing bandwidth from the MN. Erik _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Wed Mar 3 06:44:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20100 for ; Wed, 3 Mar 2004 06:44:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUnP-00082j-EW for mobopts-archive@odin.ietf.org; Wed, 03 Mar 2004 06:44:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23BiFU9030911 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 06:44:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUnA-00081g-84 for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 06:44:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19991 for ; Wed, 3 Mar 2004 06:43:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyUmm-00072n-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 06:43:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyUly-0006re-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 06:42:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyUlC-0006gc-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 06:41:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUlF-0007fH-Rm; Wed, 03 Mar 2004 06:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUk7-0007Vd-SU for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 06:41:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19857 for ; Wed, 3 Mar 2004 06:40:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyUje-0006Pb-00 for mobopts@irtf.org; Wed, 03 Mar 2004 06:40:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyUik-0006Eo-00 for mobopts@irtf.org; Wed, 03 Mar 2004 06:39:26 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1AyUi0-0005xi-00 for mobopts@irtf.org; Wed, 03 Mar 2004 06:38:40 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i23Bc8dO013426; Wed, 3 Mar 2004 03:38:08 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i23Bc4Q27372; Wed, 3 Mar 2004 12:38:04 +0100 (MET) Date: Wed, 3 Mar 2004 03:38:09 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [Mobopts] Comments on Early Binding Updates To: James Kempf Cc: Erik Nordmark , chvogt@tm.uka.de, mobopts@irtf.org In-Reply-To: "Your message with ID" <4e5c01c400f5$7b8be610$3e6015ac@dclkempt40> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 > Not quite sure I follow. If the MN is responsible for sending a number/rate, > what's to prevent it from lying? Sorry for being unclear. The MN is sending data packets - nothing else. The CN can measure the number of packets/bytes sent by the MN over time and apply the logic (whichever one folks come up with) to come up with the limit it will use to for the number of packets/bytes (or rate?) that it will send to the new CoA until the CoA has been verified. Erik _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Wed Mar 3 14:09:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18624 for ; Wed, 3 Mar 2004 14:09:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aybjr-0000Rm-4V for mobopts-archive@odin.ietf.org; Wed, 03 Mar 2004 14:09:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23J93Jr001714 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 14:09:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aybjq-0000RZ-Uq for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 14:09:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18547 for ; Wed, 3 Mar 2004 14:09:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aybjo-0006Ni-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 14:09:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aybio-00069X-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 14:07:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aybht-0005wN-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 14:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aybhu-0008ST-H5; Wed, 03 Mar 2004 14:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aybgz-0008QA-Dr for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 14:06:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18384 for ; Wed, 3 Mar 2004 14:06:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aybgx-0005jJ-00 for mobopts@irtf.org; Wed, 03 Mar 2004 14:06:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AybgB-0005Xt-00 for mobopts@irtf.org; Wed, 03 Mar 2004 14:05:17 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AybfN-0005Ko-00; Wed, 03 Mar 2004 14:04:25 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1Aybf8-0003ef-00; Wed, 03 Mar 2004 20:04:11 +0100 Received: from atiswww by irams1.ira.uka.de with local (Exim 3.30 #7 ) id 1Aybf8-0005fq-00; Wed, 03 Mar 2004 20:04:10 +0100 Received: from 210.93.162.110 ([210.93.162.110]) by mailhost.ira.uka.de (IMP) with HTTP for ; Wed, 3 Mar 2004 20:04:09 +0100 Message-ID: <1078340649.40462c29dddda@mailhost.ira.uka.de> Date: Wed, 3 Mar 2004 20:04:09 +0100 From: Christian Vogt To: Francis.Dupont@enst-bretagne.fr, jari.arkko@kolumbus.fi, Erik.Nordmark@sun.com, kempf@docomolabs-usa.com Cc: mip6@ietf.org, mobopts@irtf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 210.93.162.110 Content-Transfer-Encoding: 8bit Subject: [Mobopts] Re: Comments on Early Binding Updates Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.8 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Francis, Jari, Erik, and James! Below are a few comments on your emails which you have sent to the MIP6 and MOBOPTS mailing lists following (or immediately preceding) my presentation on Early Binding Updates (http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updates-00.txt) at the MOBOPTS session. Best regards - Christian | | Christian Vogt | Institute of Telematics, University of Karlsruhe | www.tm.uka.de/~chvogt/ | Francis Dupont wrote on misuse of Early Binding Updates for flooding attacks: > > A second reason is that a 3-seconds time limit alone > > does not prevent a malicious node from continually > > refreshing a tentative CoA registration. > > this can be easily solve by some kind of hold-down > mechanism... In this case IMHO the best is just not to > reset the timer on "refresh". Francis, you propose that a mobile node be required to do a standard binding update within each two successive Early Binding Updates. This would be a simple and easy-to-implement mechanism. Unfortunately however, an attacker could easily trick this mechanism: It would direct a large data stream towards the attacked victim node for a time slightly shorter than an unconfirmed care-of address's (CoA's) lifetime. When the unconfirmed CoA is about to expire, the attacker would direct the data stream to itself by means of a standard Binding Update message, and it would immediately re-direct the data stream, by means of an Early Binding Update message, to the attacked victim node. The attacker could repeat this procedure indefinitely. There is another disadvantage of the hold-down mechanism: Suppose a mobile node sends to the correspondent node an Early Binding Update message. Then, all of a sudden, the handover fails, and the mobile node falls back to the original sub-network. In this situation, the mobile node would want to send to the correspondent node another Early Binding Update message, re-updating the correspondent node to the old CoA. With the hold-down mechanism, however, this second Early Binding Update message would be rejected, because there has been no standard binding update between this and the first Early Binding Update message. Jari Arkko commented on Credit-Based Authorization: > However, you can't really count on the packets that > the CN sends actually being delivered to the MN. For > instance, the MN might be on a slow link, sending > fake TCP ACKs towards the the CN. The CN would be > sending data at a high rate, but most of the packets > would be dropped by a router on the path. (This > observation was made by Erik Nordmark.) This is very true. If this threat is considered serious, one should refrain from using downlink packets as a criteria for credit collection. (A solution to use downlink packets nonetheless might be to have the correspondent node send to the mobile node, at random times, Challenge messages to which the mobile node must respond. Such Challenge messages would be dropped at the router with the same probability as any other data packet. The correspondent node would record for how many Challenge messages it receives a response. The mobile node's CREDIT counter would increase more or less fast depending on the percentage of responded-to Challenge messages. This "solution", however, is probably too complex and therefore unapplicable.) Francis Dupont commented on Credit-Based Authorization: > this is very complex and does nothing for a victim behind > a narrow link and an attacker behind a fast link James Kempf wrote on the same issue: > Jari's point - that the rate be constructed based on the > previous rate - might be more doable, but there might be > an issue with an MN that was on a broadband link, since > it could concievably bomb a node on a lower bandwidth > link (a point which has already been mentioned). IMO, there are two reason why an attacker may want to use reflection for a flooding attack. First, the attacker may want to reveal its identity. Second, the attacker may want to make use of an amplification which comes along with the reflection. Revealing one's identity is not possible with Mobile IPv6, because the correspondent node tags all outgoing data packets with the intended recipient's (i.e., the attacker's) home address. The home address, in turn, cannot be spoofed, because Early Binding Updates require the mobile node (or attacker) to do a home-address test before an Early Binding Update message can be sent. Amplification is also not possible with Early Binding Updates if Credit-Based Authorization is applied. This is because the data volume sent to an attacked victim node is limited by the data volume that the attacker must send itself. Francis and James, you argue that the attacker might be willing to spend this effort if it sits on a fast link. But if this is the case, there are other, more efficient attacks, which are already possible without Mobile IPv6. Jari Arkko elaborates on this: > But isn't this already the case today? I mean an attacker > behind a fast link can send a zillion spoofed TCP SYNs to > www.cnn.com and have the responses go my GPRS link, which > would be hosed. Erik Nordmark wrote: > It might be worth-while to think about bandwidth and rate > limiting as an alternative to byte/packet counting. While > it is hard to determine the actual rate at which the MN can > send, I think it would be interesting to understand this > part. For instance, if the MN can only send at 64 kbps > could one restrict the CN to send at 64 kbps until the CoA > has been confirmed? Using the uplink (mobile-node-to-correspondent-node) data rate as a limit on how much data the correspondent node can send to an unconfirmed CoA makes sense, because the uplink data rate is what determines the data rate with which an attacker can wage a flooding attack *without* Mobile IPv6. Thus, if a mobile node's (or attacker's) credit was based on the uplink data rate, misusing Early Binding Updates for flooding attacks would probably become inattractive. The disadvantage of using the uplink data rate as a limit on how much data the correspondent node can send to an unconfirmed CoA gets obvious if the former is much less than the latter. This is, e.g., the case with asymmetric applications like video streaming. If the correspondent node reduced the downlink data rate to the recently observed uplink data rate, it would not be able to send all packets that it receives from the application. The correspondent node would thus have to either buffer or drop those packets that do not fit within the limited downlink data rate. Buffering data packets is probably infeasible, as it significantly increases the required resources at the correspondent node. Moreover, a buffer may eventually overflow anyway. Throwing away packets is not a solution either, since it may seriously impact ongoing connections which are sensitive to data loss. TCP connections are one example. One might therefore restrict Early Binding Updates to loss-*in*sensitive applications only (which would include most delay-sensitive applications). Yet, making Early Binding Updates (an L3 protocol) applicable to only a certain set of applications is not a wise idea IMO. Francis Dupont wrote: > the important thing is the reflection flood using IPv6 > or Mobile IPv6 with relaxed/delayed CoA test, and the > direct flood using fake source address are *blocked* > by the ingress filtering. Yes, Francis, this is true if ingress filtering was universally applied. Until now, however, this is not the case. The correspondent node should therefore have a different means - e.g., the CoA test - to determine whether or not the mobile node is reachable. Mobile IPv6 goes the most secure way and requires a CoA test *before* CoA registration. If the CoA-test requirement is to be more relaxed, like with Early Binding Updates, the correspondent node needs more intelligence to prevent flooding attacks. One mechanism to provide this intelligence is Credit-Based Authentication. I agree that an attacker could bypass ingress filtering, if applied, by using an Alternate CoA option. In other words, the Alternate CoA option could render ingress filtering useless. As you say, Francis, the Alternate CoA option should therefore not be used with Early Binding Updates. I have previously mentioned this on the MIP6 mailing list (February 10, 2004). Francis Dupont wrote: > Is the "Early Binding Updates" document for mobopts > (an IRTF WG) or for mip6 (an IETF WG)? When submitting the Internet-Draft on Early Binding Updates, we assumed that it may best fit into the MIP6 WG. This is why the Internet-Draft has the "mip6" infix in its name. Of course, if the MIP6 community finds that there is a better place for Early Binding Updates, we would not hesitate to move the Internet-Draft. ------------------------------------------------------------- This message was sent through ATIS: http://atiswww.ira.uka.de _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Wed Mar 3 17:50:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02631 for ; Wed, 3 Mar 2004 17:50:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfBb-0002f7-2z for mobopts-archive@odin.ietf.org; Wed, 03 Mar 2004 17:49:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23MntxS010227 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 17:49:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyfBa-0002es-Ps for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 17:49:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02575 for ; Wed, 3 Mar 2004 17:49:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyfBY-00017P-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 17:49:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyfAe-0000vf-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 17:48:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayf9j-0000in-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 17:47:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayf9l-0002JO-Fk; Wed, 03 Mar 2004 17:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayf8m-0002Gz-RT for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 17:47:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02338 for ; Wed, 3 Mar 2004 17:46:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayf8k-0000UD-00 for mobopts@irtf.org; Wed, 03 Mar 2004 17:46:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayf7q-0000F3-00 for mobopts@irtf.org; Wed, 03 Mar 2004 17:46:04 -0500 Received: from hermes.rz.fhtw-berlin.de ([141.45.5.100]) by ietf-mx with esmtp (Exim 4.12) id 1Ayf6S-0007ZP-00; Wed, 03 Mar 2004 17:44:36 -0500 Received: from fhtw-berlin.de (APointe-a-Pitre-101-2-3-22.w80-15.abo.wanadoo.fr [80.15.129.22]) (authenticated bits=0) by hermes.rz.fhtw-berlin.de (8.12.11/8.12.2) with ESMTP id i23MiA0q026355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Mar 2004 23:44:23 +0100 (MET) Message-ID: <40465FB5.6080608@fhtw-berlin.de> Date: Wed, 03 Mar 2004 23:44:05 +0100 From: Thomas Schmidt User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rod.Walsh@nokia.com CC: joo.suh@samsung.com, mip6@ietf.org, mobopts@irtf.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mobopts] Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Rod, hi Joo, Rod.Walsh@nokia.com wrote: > I quickly read your Internet draft with interest and would like to > know if you will intend to discuss it on the mobopts mail list? > > I have been working on multicast to mobiles for some time and would > be happy to exchange ideas. > > > Here are some early thoughts on your document: > > The problem and solution seem to do a good job for multicast > receivers. > A matter of debate could be, wether FMIPv6 is a well suited fundament for multicast distribution. FMIP must be eager to anticipate handovers (if it will work well), thus exhibiting a significant likelyhood of wrong predictions. In the multicast case this will lead to an unwanted quantity of uneeded remote subscriptions, unneccessary branches in the multicast trees ... ... from our point of view the smoother hmipv6 MAP architecture is much more appropriate as multicast agents ... > How does the PAR learn of the NAR address? (In the sense that: Is > there something that would be in scope for Multicast Fast Handover, > that's different from unicast/existing fast handover?) > If we understand correctly: This is just taken from FMIPv6's prediction. There should be nothing exclusive to multicast. > Some discussion on IGMP/MLD-snooping and the role of access points as > switches could be appropriate too - to deal with the situation where > AP changes but AR does not. Mhmm, this might be more a concern of underlying L2 specification. The FMIPv6 approach leaves L2 specs to additional documents. > > Also, there are several security risks. Of particular trouble are the > DoS possibilities of setting up state in many "NARs" by a > broken/malicious "MN", and sending to multiple ARs malicious > multicast data (e.g. to destroy usability of the "expected service"). > SSM is worth mentioning and also access control. As far as I am > certain there are 2 ongoing activities on multicast (AR) access > control: MCOP, IGAP. And I think there's a 3rd in MAGMA - so no need > to address the whole access control solution, just explain the impact > and use for this fast multicast handover. (I guess you already have > these ideas for the 01 draft :) > > Tunnelling multicast from PAR to NAR is not so scalable, this should > be mentioned. Perhaps suggest a means to time-out these tunnels so > that the tunnelling is only transitory since using the "PAR" as the > tunnel other-end point reduces scalability of that AR. > Tunneling in this approach only occurs, if NAR refuses to subscribe to the wanted multicast group ... question is: when will this happen? On which bases would a NAR decide not to support a specific group? Cheers, Thomas & Matthias > The differentiation between receiver-only, sender-only and > reciever+sender MNs would be a good discussion item too. For > instance, I think your solution is great for receivers, but for > senders (especially send-only non-group-members) it does not solve > the problem. Perhaps this is just an issue of limiting the scope to > receiver mobility. Maybe it is currently helping readability to not > cover sender mobility in this draft, so one option is to consider > these aspects in a separate draft - at the same time or a later > stage. > > Also, one small NIT: please make it explicit which references are > normative (essential) and which are informative (I guess all 4 are > normative)? > > Have you had any earlier feedback or discussion on the MIPSHOP (or > other WG) email lists? > > > Cheers, Rod. > > > > -----Original Message----- From: mip6-admin@ietf.org > [mailto:mip6-admin@ietf.org]On Behalf Of ext Kyungjoo Suh Sent: > Wednesday, March 03, 2004 3:05 PM To: mip6@ietf.org ; ??? Subject: > [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > > Hi, > > New draft is available which is Fast multicast protocol. > > This document defines the Fast Multicast Protocol for Mobile IPv6 [2] > in the Fast Handovers environments whereby a mobile node (MN) can > receive multicast data with reduced loss and delay after handoffs. > > Please refer to following document. > > sincerely, Kyungjoo Suh (Joo) > > > > =================================================================================================== > > > I-D ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > -------------------------------------------------------------------------------- > > > To: IETF-Announce: ; Subject: I-D > ACTION:draft-suh-mipshop-fmcast-mip6-00.txt From: Internet-Drafts at > ietf.org Date: Fri, 06 Feb 2004 15:41:59 -0500 Reply-to: > Internet-Drafts at ietf.org Sender: owner-ietf-announce at ietf.org > > -------------------------------------------------------------------------------- > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Fast Multicast Protocol for Mobile IPv6 Author(s) : K. Suh > Filename : draft-suh-mipshop-fmcast-mip6-00.txt Pages : 13 Date : > 2004-2-6 This document defines the Fast Multicast Protocol for > Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile > node (MN) can receive multicast data with reduced loss and delay > after handoffs. The proposed protocol can be implemented by the > simple modification of the Fast Handovers protocol [1] so that it can > be easily applied to the Fast Handovers for Mobile IPv6. This > document does not need a certain assumption of a specific multicast > routing protocol, so that any existing multicast routing protocol can > be used with the proposed protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-suh-mipshop-fmcast-mip6-00.txt > > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the > message. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then "get > draft-suh-mipshop-fmcast-mip6-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: mailserv@ietf.org. In the body type: "FILE > /internet-drafts/draft-suh-mipshop-fmcast-mip6-00.txt". NOTE: The > mail server at ietf.org can return the document in MIME-encoded form > by using the "mpack" utility. To use this feature, insert the > command "ENCODING mime" before the "FILE" command. To decode the > response(s), you will need "munpack" or a MIME-compliant mail reader. > Different MIME-compliant mail readers exhibit different behavior, > especially when dealing with "multipart" MIME messages (i.e. > documents which have been split up into multiple messages), so check > your local documentation on how to manipulate these messages. Below > is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > > > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Wed Mar 3 19:16:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09259 for ; Wed, 3 Mar 2004 19:16:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygWo-0000CS-DH for mobopts-archive@odin.ietf.org; Wed, 03 Mar 2004 19:15:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i240Fsd5000764 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 19:15:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygWo-0000CF-3w for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 19:15:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09202 for ; Wed, 3 Mar 2004 19:15:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygWm-0001cU-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 19:15:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygVs-0001Pr-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 19:14:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AygUy-0001BE-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 19:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygUz-0008P9-Ah; Wed, 03 Mar 2004 19:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygUP-0008Np-Bo for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 19:13:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08922 for ; Wed, 3 Mar 2004 19:13:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygUN-0000zB-00 for mobopts@irtf.org; Wed, 03 Mar 2004 19:13:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygTI-0000iR-00 for mobopts@irtf.org; Wed, 03 Mar 2004 19:12:16 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AygSP-0000I2-00 for mobopts@irtf.org; Wed, 03 Mar 2004 19:11:21 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i240ApfX025655 for ; Wed, 3 Mar 2004 18:10:51 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 18:06:06 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Mar 2004 18:10:32 -0600 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 17VGX00Z; Wed, 3 Mar 2004 19:10:47 -0500 Date: Wed, 3 Mar 2004 19:10:18 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: Christian Vogt cc: Francis.Dupont@enst-bretagne.fr, , , , , In-Reply-To: <1078340649.40462c29dddda@mailhost.ira.uka.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 04 Mar 2004 00:06:06.0609 (UTC) FILETIME=[7D7C5810:01C4017C] Subject: [Mobopts] Re: [Mip6] Re: Comments on Early Binding Updates Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.5 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Hi Christian, I had just one comment. On Wed, 3 Mar 2004, Christian Vogt wrote: ... >Francis Dupont commented on Credit-Based Authorization: > >> this is very complex and does nothing for a victim behind >> a narrow link and an attacker behind a fast link > >James Kempf wrote on the same issue: > >> Jari's point - that the rate be constructed based on the >> previous rate - might be more doable, but there might be >> an issue with an MN that was on a broadband link, since >> it could concievably bomb a node on a lower bandwidth >> link (a point which has already been mentioned). > >IMO, there are two reason why an attacker may want to use reflection for >a flooding attack. First, the attacker may want to reveal its identity. >Second, the attacker may want to make use of an amplification which >comes along with the reflection. > >Revealing one's identity is not possible with Mobile IPv6, because the In fact it is the exact opposite. The attacking node's identity WILL ALWAYS be revealed in mobile ipv6. Did you mean hide instead of reveal? Regards Suresh This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Wed Mar 3 19:34:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10009 for ; Wed, 3 Mar 2004 19:34:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygoG-0001VO-1K for mobopts-archive@odin.ietf.org; Wed, 03 Mar 2004 19:33:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i240XuOa005786 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 19:33:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygoF-0001VF-Rm for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 19:33:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09980 for ; Wed, 3 Mar 2004 19:33:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygoE-0004U0-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 19:33:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygnI-0004Js-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 19:32:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AygmN-0004AD-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 19:31:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygmO-0001I6-6d; Wed, 03 Mar 2004 19:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygmL-0001H2-3H for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 19:31:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09906 for ; Wed, 3 Mar 2004 19:31:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygmJ-00049b-00 for mobopts@irtf.org; Wed, 03 Mar 2004 19:31:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyglS-000402-00 for mobopts@irtf.org; Wed, 03 Mar 2004 19:31:03 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Aygks-0003qb-00; Wed, 03 Mar 2004 19:30:26 -0500 Message-ID: <01ae01c4017f$f412be80$5f6115ac@dclkempt40> From: "James Kempf" To: "Thomas Schmidt" , Cc: , , References: <40465FB5.6080608@fhtw-berlin.de> Subject: Re: [Mobopts] Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt Date: Wed, 3 Mar 2004 16:30:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > I quickly read your Internet draft with interest and would like to > > know if you will intend to discuss it on the mobopts mail list? > > > > I have been working on multicast to mobiles for some time and would > > be happy to exchange ideas. > > Actually, we've found it the case of FMIPv4 on 802.11 that the performance for reactive handover is perfectly adequate. There is some slight additional delay and one loses packets during the L2 handover (if the proprietary buffer fowarding at the AP is turned off) but other than that, it works fine. Unfortuantely, I can't send the paper out because it is under consideration for publication. We haven't specifically looked at multicast, but I can't see how it could be a problem. The multicast traffic will get forwarded through the tunnel until the mobile node does MLD for the group with the new router, at which point the routing change will propagate. There is of course an issue with the route propagating, and, in that sense, HMIP might be better if the multicast routing tree is rooted in the MAP. jak > > > > Here are some early thoughts on your document: > > > > The problem and solution seem to do a good job for multicast > > receivers. > > > A matter of debate could be, wether FMIPv6 is a well suited fundament > for multicast distribution. FMIP must be eager to anticipate handovers > (if it will work well), thus exhibiting a significant likelyhood of > wrong predictions. > > In the multicast case this will lead to an unwanted quantity of uneeded > remote subscriptions, unneccessary branches in the multicast trees ... > > ... from our point of view the smoother hmipv6 MAP architecture is much > more appropriate as multicast agents ... > > > How does the PAR learn of the NAR address? (In the sense that: Is > > there something that would be in scope for Multicast Fast Handover, > > that's different from unicast/existing fast handover?) > > > > If we understand correctly: This is just taken from FMIPv6's prediction. > There should be nothing exclusive to multicast. > > > Some discussion on IGMP/MLD-snooping and the role of access points as > > switches could be appropriate too - to deal with the situation where > > AP changes but AR does not. > > Mhmm, this might be more a concern of underlying L2 specification. The > FMIPv6 approach leaves L2 specs to additional documents. > > > > Also, there are several security risks. Of particular trouble are the > > DoS possibilities of setting up state in many "NARs" by a > > broken/malicious "MN", and sending to multiple ARs malicious > > multicast data (e.g. to destroy usability of the "expected service"). > > SSM is worth mentioning and also access control. As far as I am > > certain there are 2 ongoing activities on multicast (AR) access > > control: MCOP, IGAP. And I think there's a 3rd in MAGMA - so no need > > to address the whole access control solution, just explain the impact > > and use for this fast multicast handover. (I guess you already have > > these ideas for the 01 draft :) > > > > Tunnelling multicast from PAR to NAR is not so scalable, this should > > be mentioned. Perhaps suggest a means to time-out these tunnels so > > that the tunnelling is only transitory since using the "PAR" as the > > tunnel other-end point reduces scalability of that AR. > > > Tunneling in this approach only occurs, if NAR refuses to subscribe to > the wanted multicast group ... question is: when will this happen? On > which bases would a NAR decide not to support a specific group? > > Cheers, > > Thomas & Matthias > > > > > > The differentiation between receiver-only, sender-only and > > reciever+sender MNs would be a good discussion item too. For > > instance, I think your solution is great for receivers, but for > > senders (especially send-only non-group-members) it does not solve > > the problem. Perhaps this is just an issue of limiting the scope to > > receiver mobility. Maybe it is currently helping readability to not > > cover sender mobility in this draft, so one option is to consider > > these aspects in a separate draft - at the same time or a later > > stage. > > > > Also, one small NIT: please make it explicit which references are > > normative (essential) and which are informative (I guess all 4 are > > normative)? > > > > Have you had any earlier feedback or discussion on the MIPSHOP (or > > other WG) email lists? > > > > > > Cheers, Rod. > > > > > > > > -----Original Message----- From: mip6-admin@ietf.org > > [mailto:mip6-admin@ietf.org]On Behalf Of ext Kyungjoo Suh Sent: > > Wednesday, March 03, 2004 3:05 PM To: mip6@ietf.org ; ??? Subject: > > [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > > > > > Hi, > > > > New draft is available which is Fast multicast protocol. > > > > This document defines the Fast Multicast Protocol for Mobile IPv6 [2] > > in the Fast Handovers environments whereby a mobile node (MN) can > > receive multicast data with reduced loss and delay after handoffs. > > > > Please refer to following document. > > > > sincerely, Kyungjoo Suh (Joo) > > > > > > > > ============================================================================ ======================= > > > > > > I-D ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > > > -------------------------------------------------------------------------- ------ > > > > > > To: IETF-Announce: ; Subject: I-D > > ACTION:draft-suh-mipshop-fmcast-mip6-00.txt From: Internet-Drafts at > > ietf.org Date: Fri, 06 Feb 2004 15:41:59 -0500 Reply-to: > > Internet-Drafts at ietf.org Sender: owner-ietf-announce at ietf.org > > > > -------------------------------------------------------------------------- ------ > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Fast Multicast Protocol for Mobile IPv6 Author(s) : K. Suh > > Filename : draft-suh-mipshop-fmcast-mip6-00.txt Pages : 13 Date : > > 2004-2-6 This document defines the Fast Multicast Protocol for > > Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile > > node (MN) can receive multicast data with reduced loss and delay > > after handoffs. The proposed protocol can be implemented by the > > simple modification of the Fast Handovers protocol [1] so that it can > > be easily applied to the Fast Handovers for Mobile IPv6. This > > document does not need a certain assumption of a specific multicast > > routing protocol, so that any existing multicast routing protocol can > > be used with the proposed protocol. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-suh-mipshop-fmcast-mip6-00.txt > > > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the > > message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then "get > > draft-suh-mipshop-fmcast-mip6-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: mailserv@ietf.org. In the body type: "FILE > > /internet-drafts/draft-suh-mipshop-fmcast-mip6-00.txt". NOTE: The > > mail server at ietf.org can return the document in MIME-encoded form > > by using the "mpack" utility. To use this feature, insert the > > command "ENCODING mime" before the "FILE" command. To decode the > > response(s), you will need "munpack" or a MIME-compliant mail reader. > > Different MIME-compliant mail readers exhibit different behavior, > > especially when dealing with "multipart" MIME messages (i.e. > > documents which have been split up into multiple messages), so check > > your local documentation on how to manipulate these messages. Below > > is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > > > > > _______________________________________________ Mip6 mailing list > > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ Mip6 mailing list > > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > 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 exim@www1.ietf.org Wed Mar 3 20:26:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12598 for ; Wed, 3 Mar 2004 20:26:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayhcb-0006IR-Vf for mobopts-archive@odin.ietf.org; Wed, 03 Mar 2004 20:25:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i241PvwH024197 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 20:25:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayhcb-0006IC-Oa for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 20:25:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12528 for ; Wed, 3 Mar 2004 20:25:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyhcZ-0005hA-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 20:25:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayhbd-0005Ug-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 20:24:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayhai-0005Gr-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 20:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayhaj-00066w-BM; Wed, 03 Mar 2004 20:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayha3-0005z2-Gg for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 20:23:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12283 for ; Wed, 3 Mar 2004 20:23:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayha1-00054P-00 for mobopts@irtf.org; Wed, 03 Mar 2004 20:23:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhZ1-0004rE-00 for mobopts@irtf.org; Wed, 03 Mar 2004 20:22:16 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AyhYI-0004c5-00 for mobopts@irtf.org; Wed, 03 Mar 2004 20:21:30 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HU1006C82EZ7X@mailout1.samsung.com> for mobopts@irtf.org; Thu, 04 Mar 2004 10:20:59 +0900 (KST) Received: from ep_ms7_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU100JEX2BY9V@mailout1.samsung.com> for mobopts@irtf.org; Thu, 04 Mar 2004 10:19:10 +0900 (KST) Received: from ep_spt02 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU100CX72BYDW@ms7.samsung.com> for mobopts@irtf.org; Thu, 04 Mar 2004 10:19:10 +0900 (KST) Content-return: prohibited Date: Thu, 04 Mar 2004 01:19:20 +0000 (GMT) From: Kyungjoo Suh Subject: Re :Re: [Mobopts] Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz8zRyBTdGFu?= =?windows-1252?B?ZGFyZHMgUiZhbXA7RCBMYWIuP2VuZ2luZWVy?= To: Kyungjoo Suh , James Kempf , Thomas Schmidt , "Rod.Walsh@nokia.com " , "mip6@ietf.org " , "mobopts@irtf.org " Reply-to: joo.suh@samsung.com Message-id: <4971616.1078363140064.JavaMail.weblogic@ep_app24> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040304011900053@joo.suh X-MTR: 20040304011900053@joo.suh X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Content-Transfer-Encoding: 7BIT Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.5 required=5.0 tests=AWL,OPT_HEADER, PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT HI, Rod, Thoma, and James, First of all, thank you so much for reviewing the draft. Here I quickly answer for some questions. welcome any comments. How does the PAR learn of the NAR address ? answer : We assume that the proposed scheme is operating on top of FMIPv6. In the FMIPv6 spec. it is assumed that PAR knows the NAR's address. Actually, this problem is not mentioned in the FMIPv6 spec. but left as unsolved problem. The problem is addressed in Seamoby WG. It is related to the CARD (Candidate Access Router Discovery) protocol and the reverse address translation (RAT). Precise information can be obtained from the current draft of the CARD protocol. In this version of draft, we do not address this problem because we are not proposing an enhancement version of FMIPv6 but a mutlicast protocol operating with FMIPv6. Therefore we assumed the same network situations (environments) as it assumed in the FMIPv6 draft. Except this assumption, to know the NAR address in advance, roughly there are two methods that can be applied to the proposed protocol. First, we may explicitly preconfigure or set the address of neighboring AR (this address is the address assigned to the wireless interface of the AR) to each AR. Second, a neighbor AR learning algorithm (NALA) can be used. To learn the neighbor AR's address, MN may send the previous AR's address to its current AR after performing handoff. Using this method, AR can learn the addresses of neighboring ARs. For more precise information on the second method, please refer to the ARIP draft (draft-....). Some discussion on IGMP/MLD-snooping and the role of access points as switches could be appropriate too- to deal with the situation where AP changes but AR does not. answer : In this version of draft, we only assume that the AR has the functionality of a AP to simplify our ideas. In the next version, we will also consider the situations what you mentioned. (draft-ietf-magma-snoop-10.txt : Considerations for IGMP and MLD Snooping Switches) (draft-ietf-magma-igmp-proxy-04.txt : IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")) Security Risks. answer : You're right. We just explain the protocol operation in this version. And we are going to include the solution for security risk in next version. As you mentioned, existing solutions such as MCOP, IGAP, and MAGMA to achieve SSM can be applied to our proposal. But, as I mentioned the operation of the proposed protocol is operating on top of FMIPv6. If FMIPv6 is secure enough, there may be no problems at all what you mentioned. This is because by the secure operations (signalings) of FMIPv6 itself (we think the secure operation of FMIPv6 is not fully addressed in the WG yet). such as secured (AAA passed) Router Solicitation for Proxy, Proxy Router Advertisement, HI, HACK, FBU and etc. The situation (DoS possibilities) happens when the malicious HI message is received at NAR not knowing that the message is generated by some attackers. But, the malicious HI messages cannot be generated if only authorized MNs are allowed to perform the FMIPv6 procedure. Even with this assumption (Secure FMIPv6), we admit that there are a lot of security holes that we didn't think of. Tunnelling answer : As mentioned earlier, our proposal is based on the FMIPv6 protocol. In the FMIPv6 protocol, there is a tunnelling scheme between PAR and the NCoA to forwarding data destined to the MN during MN's handoff. The FMIPv6 protocol only explains how create this tunnel. There is no explicit scheme for tunnel destruction. But, I think that the tunnels in the FMIPv6 spec. are soft-state based tunnels as they are in MIPv6. In other words, those tunnels are destroyed after some predefined threshold time for existence. Also we may consider an explicit tunnel destroy mechanism using MLD Done message. In our proposal, MN sends the MLD Done message to the PAR when it start receiving multicast packets directly from NAR. Therefore, PAR can destroy the tunnel when it receives the MLD Done message. However, thanks about your pointing outs. Scope of draft You're right. Our current draft concentrating on solving the multicast receiver problem when it handoffs. We also considered the case when MN becomes a sender. Two distinct mechanisms that we are currently thinking exist for a multicast sender problem. The first solution is a quite primitive one and it is to make MN to use the home-agent based multicast scheme when it is a multicast sender. In the second solution, MN may use the temporal "reverse" tunnel from PAR to MN until NAR finishes the join process to the multicast tree. We have a plan to include the multicast sender situation in the next version. Reference answer : We know that draft-ietf-mobileip-ipv6-24.txt is last version and will be RFC soon. Again, thank you for your comments. best regards, Joo (Kyungjoo Suh) ------- Original Message --------------------------------------------------------------------------------------------------------------------------------------------------------- Sender : James Kempf Date : 2004-03-04 09:30 Title : Re: [Mobopts] Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > I quickly read your Internet draft with interest and would like to > > know if you will intend to discuss it on the mobopts mail list? > > > > I have been working on multicast to mobiles for some time and would > > be happy to exchange ideas. > > Actually, we've found it the case of FMIPv4 on 802.11 that the performance for reactive handover is perfectly adequate. There is some slight additional delay and one loses packets during the L2 handover (if the proprietary buffer fowarding at the AP is turned off) but other than that, it works fine. Unfortuantely, I can't send the paper out because it is under consideration for publication. We haven't specifically looked at multicast, but I can't see how it could be a problem. The multicast traffic will get forwarded through the tunnel until the mobile node does MLD for the group with the new router, at which point the routing change will propagate. There is of course an issue with the route propagating, and, in that sense, HMIP might be better if the multicast routing tree is rooted in the MAP. jak > > > > Here are some early thoughts on your document: > > > > The problem and solution seem to do a good job for multicast > > receivers. > > > A matter of debate could be, wether FMIPv6 is a well suited fundament > for multicast distribution. FMIP must be eager to anticipate handovers > (if it will work well), thus exhibiting a significant likelyhood of > wrong predictions. > > In the multicast case this will lead to an unwanted quantity of uneeded > remote subscriptions, unneccessary branches in the multicast trees ... > > ... from our point of view the smoother hmipv6 MAP architecture is much > more appropriate as multicast agents ... > > > How does the PAR learn of the NAR address? (In the sense that: Is > > there something that would be in scope for Multicast Fast Handover, > > that's different from unicast/existing fast handover?) > > > > If we understand correctly: This is just taken from FMIPv6's prediction. > There should be nothing exclusive to multicast. > > > Some discussion on IGMP/MLD-snooping and the role of access points as > > switches could be appropriate too - to deal with the situation where > > AP changes but AR does not. > > Mhmm, this might be more a concern of underlying L2 specification. The > FMIPv6 approach leaves L2 specs to additional documents. > > > > Also, there are several security risks. Of particular trouble are the > > DoS possibilities of setting up state in many "NARs" by a > > broken/malicious "MN", and sending to multiple ARs malicious > > multicast data (e.g. to destroy usability of the "expected service"). > > SSM is worth mentioning and also access control. As far as I am > > certain there are 2 ongoing activities on multicast (AR) access > > control: MCOP, IGAP. And I think there's a 3rd in MAGMA - so no need > > to address the whole access control solution, just explain the impact > > and use for this fast multicast handover. (I guess you already have > > these ideas for the 01 draft :) > > > > Tunnelling multicast from PAR to NAR is not so scalable, this should > > be mentioned. Perhaps suggest a means to time-out these tunnels so > > that the tunnelling is only transitory since using the "PAR" as the > > tunnel other-end point reduces scalability of that AR. > > > Tunneling in this approach only occurs, if NAR refuses to subscribe to > the wanted multicast group ... question is: when will this happen? On > which bases would a NAR decide not to support a specific group? > > Cheers, > > Thomas & Matthias > > > > > > The differentiation between receiver-only, sender-only and > > reciever+sender MNs would be a good discussion item too. For > > instance, I think your solution is great for receivers, but for > > senders (especially send-only non-group-members) it does not solve > > the problem. Perhaps this is just an issue of limiting the scope to > > receiver mobility. Maybe it is currently helping readability to not > > cover sender mobility in this draft, so one option is to consider > > these aspects in a separate draft - at the same time or a later > > stage. > > > > Also, one small NIT: please make it explicit which references are > > normative (essential) and which are informative (I guess all 4 are > > normative)? > > > > Have you had any earlier feedback or discussion on the MIPSHOP (or > > other WG) email lists? > > > > > > Cheers, Rod. > > > > > > > > -----Original Message----- From: mip6-admin@ietf.org > > [mailto:mip6-admin@ietf.org]On Behalf Of ext Kyungjoo Suh Sent: > > Wednesday, March 03, 2004 3:05 PM To: mip6@ietf.org ; ??? Subject: > > [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > > > > > Hi, > > > > New draft is available which is Fast multicast protocol. > > > > This document defines the Fast Multicast Protocol for Mobile IPv6 [2] > > in the Fast Handovers environments whereby a mobile node (MN) can > > receive multicast data with reduced loss and delay after handoffs. > > > > Please refer to following document. > > > > sincerely, Kyungjoo Suh (Joo) > > > > > > > > ============================================================================ ======================= > > > > > > I-D ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > > > -------------------------------------------------------------------------- ------ > > > > > > To: IETF-Announce: ; Subject: I-D > > ACTION:draft-suh-mipshop-fmcast-mip6-00.txt From: Internet-Drafts at > > ietf.org Date: Fri, 06 Feb 2004 15:41:59 -0500 Reply-to: > > Internet-Drafts at ietf.org Sender: owner-ietf-announce at ietf.org > > > > -------------------------------------------------------------------------- ------ > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Fast Multicast Protocol for Mobile IPv6 Author(s) : K. Suh > > Filename : draft-suh-mipshop-fmcast-mip6-00.txt Pages : 13 Date : > > 2004-2-6 This document defines the Fast Multicast Protocol for > > Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile > > node (MN) can receive multicast data with reduced loss and delay > > after handoffs. The proposed protocol can be implemented by the > > simple modification of the Fast Handovers protocol [1] so that it can > > be easily applied to the Fast Handovers for Mobile IPv6. This > > document does not need a certain assumption of a specific multicast > > routing protocol, so that any existing multicast routing protocol can > > be used with the proposed protocol. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-suh-mipshop-fmcast-mip6-00.txt > > > > > > To remove yourself from the IETF Announcement list, send a message to > > ietf-announce-request with the word unsubscribe in the body of the > > message. > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username "anonymous" and a password of your e-mail address. After > > logging in, type "cd internet-drafts" and then "get > > draft-suh-mipshop-fmcast-mip6-00.txt". > > > > A list of Internet-Drafts directories can be found in > > http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: mailserv@ietf.org. In the body type: "FILE > > /internet-drafts/draft-suh-mipshop-fmcast-mip6-00.txt". NOTE: The > > mail server at ietf.org can return the document in MIME-encoded form > > by using the "mpack" utility. To use this feature, insert the > > command "ENCODING mime" before the "FILE" command. To decode the > > response(s), you will need "munpack" or a MIME-compliant mail reader. > > Different MIME-compliant mail readers exhibit different behavior, > > especially when dealing with "multipart" MIME messages (i.e. > > documents which have been split up into multiple messages), so check > > your local documentation on how to manipulate these messages. Below > > is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > > > > > > > > > > > _______________________________________________ Mip6 mailing list > > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ Mip6 mailing list > > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Wed Mar 3 20:30:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12830 for ; Wed, 3 Mar 2004 20:30:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhgU-0006hT-1G for mobopts-archive@odin.ietf.org; Wed, 03 Mar 2004 20:29:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i241TwDF025752 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 20:29:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhgT-0006hH-S4 for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 20:29:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12761 for ; Wed, 3 Mar 2004 20:29:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyhgR-0006OJ-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 20:29:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhfU-0006EW-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 20:28:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyheZ-00064j-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 20:27:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayhea-0006Ox-Ob; Wed, 03 Mar 2004 20:28:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayhdf-0006O2-OB for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 20:27:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12659 for ; Wed, 3 Mar 2004 20:27:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayhdd-0005uA-00 for mobopts@irtf.org; Wed, 03 Mar 2004 20:27:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayhco-0005jT-00 for mobopts@irtf.org; Wed, 03 Mar 2004 20:26:11 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Ayhc6-0005YX-00; Wed, 03 Mar 2004 20:25:26 -0500 Message-ID: <024d01c40187$a0e79200$5f6115ac@dclkempt40> From: "James Kempf" To: "Christian Vogt" , , , Cc: , References: <1078340649.40462c29dddda@mailhost.ira.uka.de> Date: Wed, 3 Mar 2004 17:25:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mobopts] Re: Comments on Early Binding Updates Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christian, > Yes, Francis, this is true if ingress filtering was universally applied. > Until now, however, this is not the case. The correspondent node should > therefore have a different means - e.g., the CoA test - to determine > whether or not the mobile node is reachable. Mobile IPv6 goes the most > secure way and requires a CoA test *before* CoA registration. If the > CoA-test requirement is to be more relaxed, like with Early Binding > Updates, the correspondent node needs more intelligence to prevent > flooding attacks. One mechanism to provide this intelligence is > Credit-Based Authentication. > Ingress filtering won't work if the MN is trying to bomb someone on its old link. The MN could send off the early BU, then move to a new subnet, leaving the victim on the old subnet subject to the attack. With standard RR, the MN could do the same trick for nodes on its link, but there the MN has some incentive not to, since the impact of a DoS attack on the MN's own traffic may be negative. Also, I've got a little concern about fixed time limits on the traffic restriction, in addition to the other issues you've mentioned here. If the layer 2 handover latency has considerable variability, it may be difficult to gauge the traffic restriction timeout such that a sufficient percentage of mobile nodes get adequate handover performance to maintain user satisfaction. As an example, according to Bill Arbaugh's work, the handover latency for 802.11 ranges anywhere from about 70 to 200 ms. Unless the time limit is outside 99.999% of the variability for the layer 2 handover technology in all kinds of deployments, it might lead to undesirable packet drops. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Wed Mar 3 21:15:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16256 for ; Wed, 3 Mar 2004 21:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiO9-0004HP-83 for mobopts-archive@odin.ietf.org; Wed, 03 Mar 2004 21:15:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i242F5vb016443 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 21:15:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiO8-0004H7-W4 for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:15:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16222 for ; Wed, 3 Mar 2004 21:15:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiO6-0007ik-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 21:15:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiN6-0007Xg-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 21:14:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyiM9-0007Mk-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 21:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiMA-0003py-4w; Wed, 03 Mar 2004 21:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiLP-0003iL-RA for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 21:12:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16050 for ; Wed, 3 Mar 2004 21:12:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiLN-0007B9-00 for mobopts@irtf.org; Wed, 03 Mar 2004 21:12:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiKc-0006xe-00 for mobopts@irtf.org; Wed, 03 Mar 2004 21:11:27 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AyiJk-0006il-00 for mobopts@irtf.org; Wed, 03 Mar 2004 21:10:32 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1AyiIo-00022h-00; Thu, 04 Mar 2004 03:09:34 +0100 Received: from atiswww by irams1.ira.uka.de with local (Exim 3.30 #7 ) id 1AyiIo-0005Ou-00; Thu, 04 Mar 2004 03:09:34 +0100 Received: from 210.93.162.110 ([210.93.162.110]) by mailhost.ira.uka.de (IMP) with HTTP for ; Thu, 4 Mar 2004 03:09:33 +0100 Message-ID: <1078366173.40468fde03399@mailhost.ira.uka.de> Date: Thu, 4 Mar 2004 03:09:34 +0100 From: Christian Vogt To: Suresh Krishnan Cc: Francis.Dupont@enst-bretagne.fr, jari.arkko@kolumbus.fi, Erik.Nordmark@sun.com, kempf@docomolabs-usa.com, mobopts@irtf.org Subject: Re: [Mobopts] Re: [Mip6] Re: Comments on Early Binding Updates References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 210.93.162.110 Content-Transfer-Encoding: 8bit Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > > Revealing one's identity is not possible with > > Mobile IPv6... > > In fact it is the exact opposite. The attacking > node's identity WILL ALWAYS be revealed in mobile > ipv6. Did you mean hide instead of reveal? Oh my God, thanks Suresh. Yes, I meant to say "conceal" or "hide one's identity". I guess it was late when I wrote that email... Thanks for pointing to this. - Christian | | Christian Vogt | Institute of Telematics, University of Karlsruhe | www.tm.uka.de/~chvogt/ | ------------------------------------------------------------- This message was sent through ATIS: http://atiswww.ira.uka.de _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Thu Mar 4 01:06:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02819 for ; Thu, 4 Mar 2004 01:06:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylzH-0008Ie-9b for mobopts-archive@odin.ietf.org; Thu, 04 Mar 2004 01:05:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2465dHT031904 for mobopts-archive@odin.ietf.org; Thu, 4 Mar 2004 01:05:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylzH-0008IV-0a for mobopts-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 01:05:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02677 for ; Thu, 4 Mar 2004 01:05:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AylzE-0007Hd-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 01:05:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AylxC-0006ee-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 01:03:30 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AylvU-0005xv-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 01:01:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AylgB-0006tr-Cf for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 00:45:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aylg9-0006js-7w; Thu, 04 Mar 2004 00:45:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyleU-00069l-85 for mobopts@optimus.ietf.org; Thu, 04 Mar 2004 00:44:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01176 for ; Thu, 4 Mar 2004 00:44:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyleR-0002q9-00 for mobopts@irtf.org; Thu, 04 Mar 2004 00:44:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyldK-0002Wz-00 for mobopts@irtf.org; Thu, 04 Mar 2004 00:42:59 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Aylbx-00028s-00; Thu, 04 Mar 2004 00:41:33 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i245erX17814; Thu, 4 Mar 2004 06:40:53 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i245eqSj064280; Thu, 4 Mar 2004 06:40:53 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403040540.i245eqSj064280@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Christian Vogt cc: jari.arkko@kolumbus.fi, Erik.Nordmark@sun.com, kempf@docomolabs-usa.com, mip6@ietf.org, mobopts@irtf.org In-reply-to: Your message of Wed, 03 Mar 2004 20:04:09 +0100. <1078340649.40462c29dddda@mailhost.ira.uka.de> Date: Thu, 04 Mar 2004 06:40:52 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mobopts] Re: Comments on Early Binding Updates Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 In your previous mail you wrote: Francis Dupont wrote on misuse of Early Binding Updates for flooding attacks: > > A second reason is that a 3-seconds time limit alone > > does not prevent a malicious node from continually > > refreshing a tentative CoA registration. > > this can be easily solve by some kind of hold-down > mechanism... In this case IMHO the best is just not to > reset the timer on "refresh". Francis, you propose that a mobile node be required to do a standard binding update within each two successive Early Binding Updates. => no, what I suggested is to wait 3 seconds from the first EBU and not to reset this timer to 3 seconds (i.e., let it run down to 0) when other EBUs is received. So a tentative CoA registration can't be refreshed continually for more than 3 seconds. Unfortunately however, an attacker could easily trick this mechanism: It would direct a large data stream towards the attacked victim node for a time slightly shorter than an unconfirmed care-of address's (CoA's) lifetime. => if ingress filtering is used and is effective, it can't. If ingress filtering is not used or is not effective, you are already dead and relaxed/delayed CoA check won't change this. When the unconfirmed CoA is about to expire, the attacker would direct the data stream to itself by means of a standard Binding Update message, and it would immediately re-direct the data stream, by means of an Early Binding Update message, to the attacked victim node. The attacker could repeat this procedure indefinitely. => this doesn't matter. There is another disadvantage of the hold-down mechanism: Suppose a mobile node sends to the correspondent node an Early Binding Update message. Then, all of a sudden, the handover fails, and the mobile node falls back to the original sub-network. In this situation, the mobile node would want to send to the correspondent node another Early Binding Update message, re-updating the correspondent node to the old CoA. With the hold-down mechanism, however, this second Early Binding Update message would be rejected, because there has been no standard binding update between this and the first Early Binding Update message. => this could be a problem with a real hold-down mechanism, but not for my simpler proposal: re-updates are not dropped, they just don't reset the timeout. Note that to remove a binding is not a problem (RO is an optimization), the thing to avoid is to keep an old binding. BTW the draft 24 takes care of this, for instance Kbm is different for deleting bindings... Jari Arkko commented on Credit-Based Authorization: => I am not interested to waste time about ineffective defense against inexistent attacks.. IMO, there are two reason why an attacker may want to use reflection for a flooding attack. First, the attacker may want to reveal its identity. => you mean hide? I can't see why the attacker may want to reveal its identity... Second, the attacker may want to make use of an amplification which comes along with the reflection. => unfortunately the attacker doesn't need any bounded amplification... But if this is the case, there are other, more efficient attacks, which are already possible without Mobile IPv6. => I buy this argument! Francis Dupont wrote: > the important thing is the reflection flood using IPv6 > or Mobile IPv6 with relaxed/delayed CoA test, and the > direct flood using fake source address are *blocked* > by the ingress filtering. Yes, Francis, this is true if ingress filtering was universally applied. => I know it is not universally applied and more I know exactly why... But my point is that when ingress filtering is not applied or is ineffective, you are a setting duck and nasty things can happen even if there is no moblte IPv6 capable correspondent node somewhere. Until now, however, this is not the case. The correspondent node should therefore have a different means - e.g., the CoA test - to determine whether or not the mobile node is reachable. Mobile IPv6 goes the most secure way and requires a CoA test *before* CoA registration. =>note this is true *only* for a common correspondent, not a home agent. If the CoA-test requirement is to be more relaxed, like with Early Binding Updates, the correspondent node needs more intelligence to prevent flooding attacks. => I strongly disagree about this need. I agree that an attacker could bypass ingress filtering, if applied, by using an Alternate CoA option. In other words, the Alternate CoA option could render ingress filtering useless. As you say, Francis, the Alternate CoA option should therefore not be used with Early Binding Updates. I have previously mentioned this on the MIP6 mailing list (February 10, 2004). => this is the only really need! Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Thu Mar 4 01:30:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05011 for ; Thu, 4 Mar 2004 01:30:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymMd-0004br-AN for mobopts-archive@odin.ietf.org; Thu, 04 Mar 2004 01:29:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i246Tl1h017718 for mobopts-archive@odin.ietf.org; Thu, 4 Mar 2004 01:29:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymMd-0004bh-4b for mobopts-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 01:29:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04855 for ; Thu, 4 Mar 2004 01:29:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AymMa-0004sK-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 01:29:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AymKz-0004NO-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 01:28:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AymJC-0003uk-05 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 01:26:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aym9L-0007TH-E2 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 01:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aym9K-00037B-JG; Thu, 04 Mar 2004 01:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aym8Y-0002tc-3n for mobopts@optimus.ietf.org; Thu, 04 Mar 2004 01:15:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03903 for ; Thu, 4 Mar 2004 01:15:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aym8V-0001qR-00 for mobopts@irtf.org; Thu, 04 Mar 2004 01:15:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aym7c-0001fU-00 for mobopts@irtf.org; Thu, 04 Mar 2004 01:14:17 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Aym6o-0001Ia-00; Thu, 04 Mar 2004 01:13:26 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i246Clt19360; Thu, 4 Mar 2004 07:12:47 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i246ClSj064381; Thu, 4 Mar 2004 07:12:47 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403040612.i246ClSj064381@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" cc: "Christian Vogt" , jari.arkko@kolumbus.fi, Erik.Nordmark@sun.com, mip6@ietf.org, mobopts@irtf.org In-reply-to: Your message of Wed, 03 Mar 2004 17:25:47 PST. <024d01c40187$a0e79200$5f6115ac@dclkempt40> Date: Thu, 04 Mar 2004 07:12:47 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mobopts] Re: Comments on Early Binding Updates Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 In your previous mail you wrote: Ingress filtering won't work if the MN is trying to bomb someone on its old link. => yes some ingress filtering mechanisms are ineffective when the attacker moves after the launch of its attack but this has nothing to do with using mobile IPv6 for the attack... The MN could send off the early BU, then move to a new subnet, leaving the victim on the old subnet subject to the attack. With standard RR, the MN could do the same trick for nodes on its link, but there the MN has some incentive not to, since the impact of a DoS attack on the MN's own traffic may be negative. => attacks from someone on the same link are a real issue and one way to solve it, SEND, gives near nothing... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Thu Mar 4 02:11:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20343 for ; Thu, 4 Mar 2004 02:11:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayn0v-0004KD-2w for mobopts-archive@odin.ietf.org; Thu, 04 Mar 2004 02:11:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i247BOgV016603 for mobopts-archive@odin.ietf.org; Thu, 4 Mar 2004 02:11:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayn0u-0004Jh-0Z for mobopts-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 02:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20302 for ; Thu, 4 Mar 2004 02:11:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayn0q-0005gn-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 02:11:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayn01-0005WK-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 02:10:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AymzZ-0005LV-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 02:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aymza-0003YJ-16; Thu, 04 Mar 2004 02:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aymyr-0003Cs-3B for mobopts@optimus.ietf.org; Thu, 04 Mar 2004 02:09:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18212 for ; Thu, 4 Mar 2004 02:09:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aymyn-0005It-00 for mobopts@irtf.org; Thu, 04 Mar 2004 02:09:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aymxt-00056n-00 for mobopts@irtf.org; Thu, 04 Mar 2004 02:08:17 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Aymx1-0004tK-00; Thu, 04 Mar 2004 02:07:24 -0500 Message-ID: <03fe01c401b7$671be1e0$5f6115ac@dclkempt40> From: "James Kempf" To: "Francis Dupont" Cc: "Christian Vogt" , , , , References: <200403040612.i246ClSj064381@givry.rennes.enst-bretagne.fr> Date: Wed, 3 Mar 2004 23:07:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mobopts] Re: Comments on Early Binding Updates Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > => attacks from someone on the same link are a real issue and > one way to solve it, SEND, gives near nothing... Sure. It wasn't intended to. It's only intended to secure the IP address/L2 address resolution, and router discovery, not third party DoS attacks. jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Thu Mar 4 03:02:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26207 for ; Thu, 4 Mar 2004 03:02:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynnv-0006oU-EQ for mobopts-archive@odin.ietf.org; Thu, 04 Mar 2004 03:02:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24823T0026190 for mobopts-archive@odin.ietf.org; Thu, 4 Mar 2004 03:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynnv-0006oG-0q for mobopts-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:02:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25991 for ; Thu, 4 Mar 2004 03:01:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aynnq-0001JP-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 03:01:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynm7-0000mS-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 03:00:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aynkf-0000Tw-05 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 02:58:41 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyndR-0000Gh-FY for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 02:51:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyndN-0004ho-NG; Thu, 04 Mar 2004 02:51:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyndE-0004gK-1C for mobopts@optimus.ietf.org; Thu, 04 Mar 2004 02:51:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24668 for ; Thu, 4 Mar 2004 02:50:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyndA-0006IX-00 for mobopts@irtf.org; Thu, 04 Mar 2004 02:50:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aync0-00061v-00 for mobopts@irtf.org; Thu, 04 Mar 2004 02:49:44 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Aynb9-0005lE-00; Thu, 04 Mar 2004 02:48:51 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i247mAt25110; Thu, 4 Mar 2004 08:48:10 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i247m7Sj064754; Thu, 4 Mar 2004 08:48:07 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403040748.i247m7Sj064754@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" cc: "Christian Vogt" , jari.arkko@kolumbus.fi, Erik.Nordmark@sun.com, mip6@ietf.org, mobopts@irtf.org In-reply-to: Your message of Wed, 03 Mar 2004 23:07:46 PST. <03fe01c401b7$671be1e0$5f6115ac@dclkempt40> Date: Thu, 04 Mar 2004 08:48:07 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mobopts] Re: Comments on Early Binding Updates Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 In your previous mail you wrote: > => attacks from someone on the same link are a real issue and > one way to solve it, SEND, gives near nothing... Sure. It wasn't intended to. It's only intended to secure the IP address/L2 address resolution, and router discovery, not third party DoS attacks. => (likely to be ou of the scope :-) The point I tried to raise is that some smart devices can detect attackers which are stealing your address but without what SEND had promised they can't know which are real owners so either are limited to detection or can be misued for DoS (e.g. when they "locked" to the first seen)... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Thu Mar 4 03:17:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27591 for ; Thu, 4 Mar 2004 03:17:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo2l-00014t-3o for mobopts-archive@odin.ietf.org; Thu, 04 Mar 2004 03:17:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248HMd9004127 for mobopts-archive@odin.ietf.org; Thu, 4 Mar 2004 03:17:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo2j-00014U-F8 for mobopts-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:17:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27577 for ; Thu, 4 Mar 2004 03:17:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo2h-0004wi-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 03:17:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayo1p-0004lz-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 03:16:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo1T-0004bP-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 03:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo1T-0000st-AW; Thu, 04 Mar 2004 03:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo0i-0000qd-Fq for mobopts@optimus.ietf.org; Thu, 04 Mar 2004 03:15:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27474 for ; Thu, 4 Mar 2004 03:15:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo0g-0004XK-00 for mobopts@irtf.org; Thu, 04 Mar 2004 03:15:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynzj-0004Jj-00 for mobopts@irtf.org; Thu, 04 Mar 2004 03:14:16 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Aynym-00046O-00 for mobopts@irtf.org; Thu, 04 Mar 2004 03:13:16 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 7AFD56A906; Thu, 4 Mar 2004 10:13:14 +0200 (EET) Message-ID: <4046E491.7070303@kolumbus.fi> Date: Thu, 04 Mar 2004 10:10:57 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: Christian Vogt , Erik.Nordmark@sun.com, kempf@docomolabs-usa.com, mip6@ietf.org, mobopts@irtf.org References: <200403040540.i245eqSj064280@givry.rennes.enst-bretagne.fr> In-Reply-To: <200403040540.i245eqSj064280@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mobopts] Re: Comments on Early Binding Updates Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Francis Dupont wrote: > => if ingress filtering is used and is effective, it can't. If ingress > filtering is not used or is not effective, you are already dead and > relaxed/delayed CoA check won't change this. Ah, I think I can see our difference now better. Thanks for the explanation. My view is that there's different levels of being "dead". What I want to prevent is an amplification attack where bad guys can cause a lot more packets to the victims than what they have to send. My current view is that even with no ingress filtering, there is no such clear attack in plain IP which would enable significant amplification. But I may have missed something. I think we can agree that if vulnerability X makes the ingress filtering-less situation much worse ("more dead") than it already is, this would be a problem. Alternatively, your opinion is that the situation is already so bad without ingress filtering that its hopeless, and some increase in vulnerabilities does not matter any more. OTOH, there seems to be a nasty issue with the victims not getting protection from their OWN ingress filter but from the attacker's ingress, if any. --Jari _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Thu Mar 4 03:55:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00987 for ; Thu, 4 Mar 2004 03:55:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyodO-0005ni-Vk for mobopts-archive@odin.ietf.org; Thu, 04 Mar 2004 03:55:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248tEPm022297 for mobopts-archive@odin.ietf.org; Thu, 4 Mar 2004 03:55:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyodO-0005nP-F9 for mobopts-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:55:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00789 for ; Thu, 4 Mar 2004 03:55:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyodM-0005rv-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 03:55:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayobz-0005V7-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 03:53:48 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyobJ-0005HB-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 03:53:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyoXO-0001jU-Mx for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 03:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoXN-0005Am-Pc; Thu, 04 Mar 2004 03:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoWP-0004x6-N6 for mobopts@optimus.ietf.org; Thu, 04 Mar 2004 03:48:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00222 for ; Thu, 4 Mar 2004 03:47:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoWM-0004Ec-00 for mobopts@irtf.org; Thu, 04 Mar 2004 03:47:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoVE-0003vz-00 for mobopts@irtf.org; Thu, 04 Mar 2004 03:46:48 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AyoU4-0003R2-00; Thu, 04 Mar 2004 03:45:36 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i248j2t31835; Thu, 4 Mar 2004 09:45:02 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i248j0Sj065101; Thu, 4 Mar 2004 09:45:00 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403040845.i248j0Sj065101@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Christian Vogt , Erik.Nordmark@sun.com, kempf@docomolabs-usa.com, mip6@ietf.org, mobopts@irtf.org In-reply-to: Your message of Thu, 04 Mar 2004 10:10:57 +0200. <4046E491.7070303@kolumbus.fi> Date: Thu, 04 Mar 2004 09:45:00 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mobopts] Re: Comments on Early Binding Updates Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 In your previous mail you wrote: > => if ingress filtering is used and is effective, it can't. If ingress > filtering is not used or is not effective, you are already dead and > relaxed/delayed CoA check won't change this. Ah, I think I can see our difference now better. Thanks for the explanation. My view is that there's different levels of being "dead". What I want to prevent is an amplification attack where bad guys can cause a lot more packets to the victims than what they have to send. => I object: what you call an amplification attack causes a number of packets of the same order. Packets are larger (MTU size in place of ACKs) but they don't come for free and are limited to a sending window per correspondent. This for the theory but unfortunately we know what happens in the real world: DDoS attackers use zombies which both give unbound amplification and hide the real origin of the attacks. They don't seem to use reflection even when reflection disperses traffic between sources and the victim. My current view is that even with no ingress filtering, there is no such clear attack in plain IP which would enable significant amplification. => do you ever read the news? so bad without ingress filtering that its hopeless, and some increase in vulnerabilities does not matter any more. => it doesn't matter: using mobile IPv6 has a very bad property for attackers: it makes them easier to track because of the HoA. OTOH, there seems to be a nasty issue with the victims not getting protection from their OWN ingress filter but from the attacker's ingress, if any. => this is a bad thing which has nothing to do with Mobile IPv6... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Thu Mar 4 10:53:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28201 for ; Thu, 4 Mar 2004 10:53:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayv9M-0008F6-An for mobopts-archive@odin.ietf.org; Thu, 04 Mar 2004 10:52:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24FqeLB031680 for mobopts-archive@odin.ietf.org; Thu, 4 Mar 2004 10:52:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayv9M-0008Et-1W for mobopts-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 10:52:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28163 for ; Thu, 4 Mar 2004 10:52:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayv9J-0004A0-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 10:52:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayv8V-0003zP-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 10:51:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayv7k-0003oJ-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 10:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayv7l-0008AI-OM; Thu, 04 Mar 2004 10:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayv7O-000890-GW for mobopts@optimus.ietf.org; Thu, 04 Mar 2004 10:50:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28043 for ; Thu, 4 Mar 2004 10:50:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayv7M-0003kt-00 for mobopts@irtf.org; Thu, 04 Mar 2004 10:50:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayv6Q-0003Y5-00 for mobopts@irtf.org; Thu, 04 Mar 2004 10:49:39 -0500 Received: from hermes.rz.fhtw-berlin.de ([141.45.5.100]) by ietf-mx with esmtp (Exim 4.12) id 1Ayv5Y-0003LO-00; Thu, 04 Mar 2004 10:48:44 -0500 Received: from fhtw-berlin.de (APointe-a-Pitre-101-2-3-22.w80-15.abo.wanadoo.fr [80.15.129.22]) (authenticated bits=0) by hermes.rz.fhtw-berlin.de (8.12.11/8.12.2) with ESMTP id i24FmUla006492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Mar 2004 16:48:33 +0100 (MET) Message-ID: <40474FCB.6020607@fhtw-berlin.de> Date: Thu, 04 Mar 2004 16:48:27 +0100 From: Thomas Schmidt User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: Rod.Walsh@nokia.com, joo.suh@samsung.com, mip6@ietf.org, mobopts@irtf.org Subject: Re: [Mobopts] Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt References: <40465FB5.6080608@fhtw-berlin.de> <01ae01c4017f$f412be80$5f6115ac@dclkempt40> In-Reply-To: <01ae01c4017f$f412be80$5f6115ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.67+CVS20040221, clamav-milter version 0.66n Content-Transfer-Encoding: 7bit Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jak, James Kempf wrote: > > Actually, we've found it the case of FMIPv4 on 802.11 that the performance > for reactive handover is perfectly adequate. There is some slight additional > delay and one loses packets during the L2 handover (if the proprietary > buffer fowarding at the AP is turned off) but other than that, it works > fine. Yes, basically the predictive handover delay / time of packet loss is (approximately) proportional to (RTT(PAR,NAR) - L2-handoff), if routers are not too close to each other. On the contrary, reactive handover delay is (approximately) proportional to (RTT(PAR,NAR)/2 + L2-handoff). (see reference to ICN04 in http://www.rz.fhtw-berlin.de/projekte/ipv6/mipv6.html) >Unfortuantely, I can't send the paper out because it is under > consideration for publication. Does the paper already carry a title (so we can whatch out?) So then you can cite our paper ;) > We haven't specifically looked at multicast, > but I can't see how it could be a problem. The multicast traffic will get > forwarded through the tunnel until the mobile node does MLD for the group > with the new router, at which point the routing change will propagate. The idea of the fmcast is to do a predictive remote subscription, which would be clearly neat, if there wasn't the issue with routing ... This routing issue becomes even more apparent if you look at multicast senders: the erection of a source tree for a moving source is heavy weight and may take up to the order of minutes. We don't want to initiate this with every (micromobile) handover or, even worse, without use. > There > is of course an issue with the route propagating, and, in that sense, HMIP > might be better if the multicast routing tree is rooted in the MAP. Maybe you want to take a look at ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-schmidt-waehlisch-mhmipv6-01.txt. cheers thomas & matthias _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Thu Mar 4 19:53:26 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24402 for ; Thu, 4 Mar 2004 19:53:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az3aD-00088A-MW for mobopts-archive@odin.ietf.org; Thu, 04 Mar 2004 19:52:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i250qviG031248 for mobopts-archive@odin.ietf.org; Thu, 4 Mar 2004 19:52:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az3aD-00087v-Hi for mobopts-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 19:52:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24388 for ; Thu, 4 Mar 2004 19:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az3aB-0006fp-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 19:52:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az3ZK-0006Vt-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 19:52:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az3YK-0006LV-00 for mobopts-web-archive@irtf.org; Thu, 04 Mar 2004 19:51:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az3YL-0007qn-G1; Thu, 04 Mar 2004 19:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az3YJ-0007qI-AE for mobopts@optimus.ietf.org; Thu, 04 Mar 2004 19:50:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24329 for ; Thu, 4 Mar 2004 19:50:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az3YH-0006L2-00 for mobopts@irtf.org; Thu, 04 Mar 2004 19:50:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az3XK-0006BE-00 for mobopts@irtf.org; Thu, 04 Mar 2004 19:49:58 -0500 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1Az3Wx-00061c-00 for mobopts@irtf.org; Thu, 04 Mar 2004 19:49:35 -0500 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-outer.mc,v 1.15 2004/01/30 18:16:28 root Exp $) with ESMTP id i250qf0K000553; Fri, 5 Mar 2004 00:52:41 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by talaria.jf.intel.com (8.12.9-20030918-01/8.12.9/d: major-inner.mc,v 1.10 2004/03/01 19:21:36 root Exp $) with SMTP id i250h6If010999; Fri, 5 Mar 2004 00:43:32 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs041.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004030416490327030 ; Thu, 04 Mar 2004 16:49:03 -0800 Received: from orsmsx403.amr.corp.intel.com ([192.168.65.209]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 4 Mar 2004 16:49:03 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Thu, 4 Mar 2004 16:49:02 -0800 Message-ID: Thread-Topic: 59th IETF: Your Presentation Thread-Index: AcQCSoTyTpFyLx2pQwKKaRSbGBiV4QAAAmaw From: "Johnston, Dj" To: "Christian Vogt" Cc: , X-OriginalArrivalTime: 05 Mar 2004 00:49:03.0244 (UTC) FILETIME=[A7B164C0:01C4024B] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Mobopts] RE: 59th IETF: Your Presentation Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.4 required=5.0 tests=OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Christian, Thankyou for your kind words. The slides were actually IEEE 802.21 submissions, since I did not want to create the impression that they were an official 802.21 liasion submission to the I[ER]TF. They are stored in at the IEEE 802 website under http://www.ieee802.org/handoff . The slides and related paper can be found by following the March 04 documents link at the top of the page. The documents are open to all. Regards, DJ -----Original Message----- From: Christian Vogt [mailto:chvogt@tm.uka.de]=20 Sent: Thursday, March 04, 2004 4:41 PM To: david.johnston@ieee.org Subject: 59th IETF: Your Presentation Hi David, you gave an excellent presentation on IEEE 802.21 at the 59th IETF's DNA WG session (as well as the MOBOPTS RG session). Do you have your slides available online? Best regards, - Christian | | Christian Vogt | Institute of Telematics, University of Karlsruhe=20 | www.tm.uka.de/~chvogt/ | ------------------------------------------------------------- This message was sent through ATIS: http://atiswww.ira.uka.de=20 _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Tue Mar 30 18:06:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24572 for ; Tue, 30 Mar 2004 18:06:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjX-0006YH-VN for mobopts-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i239Rxd6008377 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 04:27:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySfH-00025V-UX for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 04:27:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13551 for ; Wed, 3 Mar 2004 04:27:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AySed-00074K-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 04:27:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AySdR-0006nL-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 04:25:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyScZ-0006ZY-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 04:24:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyScb-0001AS-5Y; Wed, 03 Mar 2004 04:24:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRr3-0004sF-6l for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 03:35:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11035 for ; Wed, 3 Mar 2004 03:35:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRqb-00060V-00 for mobopts@irtf.org; Wed, 03 Mar 2004 03:35:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRph-0005ry-00 for mobopts@irtf.org; Wed, 03 Mar 2004 03:34:25 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AyRpI-0005iw-00 for mobopts@irtf.org; Wed, 03 Mar 2004 03:34:00 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i238XRS19955; Wed, 3 Mar 2004 09:33:27 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i238XQSj060866; Wed, 3 Mar 2004 09:33:26 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403030833.i238XQSj060866@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: chvogt@tm.uka.de, mobopts@irtf.org Subject: Re: [Mobopts] Comments on Early Binding Updates In-reply-to: Your message of Tue, 02 Mar 2004 22:04:37 PST. Date: Wed, 03 Mar 2004 09:33:26 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.2 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Is the "Early Binding Updates" document for mobopts (an IRTF WG) or for mip6 (an IETF WG)? I ask because the "credit" idea is fine for a scientific conference or meeting but *not* for an engineering forum... Why to try to defend againstsuch a complex reflection attack when it is so simple to use a large number of reflectors (e.g., there should be ~1 million Web servers which can blindly bomb you if my stupid ISP doesn't use ingress filtering)? Regards Francis.Dupont@enst-bretagne.fr PS: BTW my ISP uses ingress filtering, not because it is not stupid, but because it doesn't want to get "hidden customers" using my connection (:-). PPS: even if the IETF network is protected by ingress filtering I can easily spoof your address (we are on the same network) and even send fake TCP_ACKs (:-). _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Tue Mar 30 18:13:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26437 for ; Tue, 30 Mar 2004 18:13:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjU-0006ZK-Or for mobopts-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i239QQUM006150 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 04:26:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySdd-0001PV-0G for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 04:26:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13266 for ; Wed, 3 Mar 2004 04:25:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AySd1-0006ie-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 04:25:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AySc1-0006Xm-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 04:24:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AySbI-0006PG-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 04:23:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AySbJ-0000rR-7S; Wed, 03 Mar 2004 04:23:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRSu-0002c7-3c for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 03:11:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09733 for ; Wed, 3 Mar 2004 03:10:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRSR-0001zt-00 for mobopts@irtf.org; Wed, 03 Mar 2004 03:10:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRRi-0001qB-00 for mobopts@irtf.org; Wed, 03 Mar 2004 03:09:38 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AyRQp-0001dv-00 for mobopts@irtf.org; Wed, 03 Mar 2004 03:08:43 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 3DC2F6A902; Wed, 3 Mar 2004 10:08:42 +0200 (EET) Message-ID: <40459202.4010500@kolumbus.fi> Date: Wed, 03 Mar 2004 10:06:26 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: Erik Nordmark , chvogt@tm.uka.de, mobopts@irtf.org Subject: Re: [Mobopts] Comments on Early Binding Updates References: <4e5c01c400f5$7b8be610$3e6015ac@dclkempt40> In-Reply-To: <4e5c01c400f5$7b8be610$3e6015ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Not quite sure I follow. If the MN is responsible for sending a number/rate, > what's to prevent it from lying? The MN is not responsible for that. Even that part of the logic must reside on the CN, i.e., it would measure the rate or number. > Jari's point - that the rate be constructed based on the previous rate - > might be more doable, but there might be an issue with an MN that was on a > broadband link, since it could concievably bomb a node on a lower bandwidth > link (a point which has already been mentioned). Copying an answer for the mobile ip list... I said this: "Re: victim behind a narrow link and attacker behind a fast link. You are right that this doesn't do anything for this case. But isn't this already the case today? I mean an attacker behind a fast link can send a zillion spoofed TCP SYNs to www.cnn.com and have the responses go my GPRS link, which would be hosed. The effort required for this would be a sending a zillion packets. To do this via early binding updates, you'd need more than a zillion packets. " --Jari _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From exim@www1.ietf.org Tue Mar 30 18:29:47 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01122 for ; Tue, 30 Mar 2004 18:29:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjL-0006a4-Rk for mobopts-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2386vmr006098 for mobopts-archive@odin.ietf.org; Wed, 3 Mar 2004 03:06:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyROs-0001Vl-3D for mobopts-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 03:06:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09354 for ; Wed, 3 Mar 2004 03:06:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyROU-0001BU-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 03:06:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRNL-0000x8-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 03:05:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyRMM-0000hG-00 for mobopts-web-archive@irtf.org; Wed, 03 Mar 2004 03:04:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRMP-0000z4-Dj; Wed, 03 Mar 2004 03:04:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRL7-0000U5-Dv for mobopts@optimus.ietf.org; Wed, 03 Mar 2004 03:02:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08946 for ; Wed, 3 Mar 2004 03:02:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRKU-0000HE-00 for mobopts@irtf.org; Wed, 03 Mar 2004 03:02:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRJA-0007i1-00 for mobopts@irtf.org; Wed, 03 Mar 2004 03:00:49 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AyRHZ-0007LZ-00 for mobopts@irtf.org; Wed, 03 Mar 2004 02:59:09 -0500 Message-ID: <4e5c01c400f5$7b8be610$3e6015ac@dclkempt40> From: "James Kempf" To: "Erik Nordmark" Cc: "Erik Nordmark" , , References: Subject: Re: [Mobopts] Comments on Early Binding Updates Date: Tue, 2 Mar 2004 23:59:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mobopts-admin@ietf.org Errors-To: mobopts-admin@ietf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP Mobility Optimizations List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > How could one enforce this in a deployment/implementation where the MN's > > stack could be hacked to get around the limitation? > > Logic lives on the CN. > The MN's input to this piece of logic is only the number/rate that it sends > to the CN. It can't "fake" this since it is limited by the outgoing bandwidth > from the MN. > Not quite sure I follow. If the MN is responsible for sending a number/rate, what's to prevent it from lying? Jari's point - that the rate be constructed based on the previous rate - might be more doable, but there might be an issue with an MN that was on a broadband link, since it could concievably bomb a node on a lower bandwidth link (a point which has already been mentioned). jak _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts