From mobopts-bounces@irtf.org Mon Dec 03 14:12:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGir-0005kv-3g; Mon, 03 Dec 2007 14:12:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGip-0005bg-KW for mobopts@irtf.org; Mon, 03 Dec 2007 14:12:51 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzGip-00049V-Eb for mobopts@irtf.org; Mon, 03 Dec 2007 14:12:51 -0500 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lB3JCKsj058599; Mon, 3 Dec 2007 14:12:20 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1IzGiJ-00011T-0N; Mon, 03 Dec 2007 14:12:19 -0500 Date: Mon, 3 Dec 2007 14:12:18 -0500 To: mobopts@irtf.org Message-ID: <20071203191218.GH2478@steelhead.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: -1.4 (-) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Mobopts] Multimob and security X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Shouldn't multimob work also consider security aspect for securing IGMP/MLD where MN does not have a pre-established security association with the visited network? Yoshihiro Ohba _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Dec 03 16:38:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJ09-0004uu-8q; Mon, 03 Dec 2007 16:38:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJ07-0004og-HN for mobopts@irtf.org; Mon, 03 Dec 2007 16:38:51 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzJ07-000608-7g for mobopts@irtf.org; Mon, 03 Dec 2007 16:38:51 -0500 Received: from steelhead.localdomain (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id lB3LcNPl059168; Mon, 3 Dec 2007 16:38:23 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Received: from ohba by steelhead.localdomain with local (Exim 4.67) (envelope-from ) id 1IzIze-00019i-Cu; Mon, 03 Dec 2007 16:38:22 -0500 Date: Mon, 3 Dec 2007 16:38:22 -0500 To: Rajeev Koodli Subject: Re: [Mobopts] Multimob and security Message-ID: <20071203213822.GK2478@steelhead.localdomain> References: <20071203191218.GH2478@steelhead.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Spam-Score: -1.4 (-) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org On Mon, Dec 03, 2007 at 01:23:27PM -0800, Rajeev Koodli wrote: > > Hi Yoshi, > > > On 12/3/07 11:12 AM, "ext Yoshihiro Ohba" wrote: > > > Shouldn't multimob work also consider security aspect for securing > > IGMP/MLD where MN does not have a pre-established security association > > with the visited network? > > > > Okay, but could you state why we should do this? Is this specific to > mobility? Sooner or later any mobility-related signaling without security will become an issue. At least I would like to see some discussion as to whether multimob work can just rely on L2 security or should have its own security mechanism. Regards, Yoshihiro Ohba > > Regards, > > -Rajeev > -- > http://people.nokia.net/~rajeev > > > > > Yoshihiro Ohba > > > > _______________________________________________ > > Mobopts mailing list > > Mobopts@irtf.org > > https://www1.ietf.org/mailman/listinfo/mobopts > > > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Dec 03 16:42:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJ3r-0005bg-8p; Mon, 03 Dec 2007 16:42:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzImL-0006ez-Qr for mobopts@irtf.org; Mon, 03 Dec 2007 16:24:37 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzImJ-0005Xj-DV for mobopts@irtf.org; Mon, 03 Dec 2007 16:24:37 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB3LO2xt019142; Mon, 3 Dec 2007 23:24:15 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 23:23:45 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 15:23:25 -0600 Received: from 10.241.59.18 ([10.241.59.18]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Mon, 3 Dec 2007 21:23:24 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Mon, 03 Dec 2007 13:23:27 -0800 Subject: Re: [Mobopts] Multimob and security From: Rajeev Koodli To: ext Yoshihiro Ohba , Message-ID: Thread-Topic: [Mobopts] Multimob and security Thread-Index: Acg18r47/Je5TKHlEdyKDQAWy5YJpw== In-Reply-To: <20071203191218.GH2478@steelhead.localdomain> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Dec 2007 21:23:25.0136 (UTC) FILETIME=[BD1F4500:01C835F2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Mon, 03 Dec 2007 16:42:41 -0500 Cc: X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hi Yoshi, On 12/3/07 11:12 AM, "ext Yoshihiro Ohba" wrote: > Shouldn't multimob work also consider security aspect for securing > IGMP/MLD where MN does not have a pre-established security association > with the visited network? > Okay, but could you state why we should do this? Is this specific to mobility? Regards, -Rajeev -- http://people.nokia.net/~rajeev > Yoshihiro Ohba > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Dec 03 16:44:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJ56-0001Zz-Hy; Mon, 03 Dec 2007 16:44:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJ55-0001Yk-B2 for mobopts@irtf.org; Mon, 03 Dec 2007 16:43:59 -0500 Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzJ54-0006BR-UX for mobopts@irtf.org; Mon, 03 Dec 2007 16:43:59 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id 49EA01986CC; Mon, 3 Dec 2007 23:43:58 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 625BC198671; Mon, 3 Dec 2007 23:43:57 +0200 (EET) Message-ID: <47547893.9000903@piuha.net> Date: Mon, 03 Dec 2007 13:43:47 -0800 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: [Mobopts] Multimob and security References: <20071203191218.GH2478@steelhead.localdomain> In-Reply-To: <20071203191218.GH2478@steelhead.localdomain> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -1.4 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org IMO, this is a different problem that should be addressed by a separate effort, "IGMP/MLD security". Jari Yoshihiro Ohba kirjoitti: > Shouldn't multimob work also consider security aspect for securing > IGMP/MLD where MN does not have a pre-established security association > with the visited network? > > Yoshihiro Ohba > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > > > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Dec 05 18:54:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J044B-0006c1-Uf; Wed, 05 Dec 2007 18:54:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J03tv-0006Rf-Fh for mobopts@irtf.org; Wed, 05 Dec 2007 18:43:35 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J03tu-0002TA-Uc for mobopts@irtf.org; Wed, 05 Dec 2007 18:43:35 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB5NhFOX019866 for ; Thu, 6 Dec 2007 01:43:31 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 01:43:13 +0200 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 17:43:06 -0600 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Dec 2007 17:43:02 -0600 Message-ID: <3C33B44F3E969F4D8DE8D578078410C8014F4044@daebe103.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Presentations Thread-Index: Acg3mJNfyuDN7cj5Smy7Yqsr5Zvp0A== From: To: X-OriginalArrivalTime: 05 Dec 2007 23:43:07.0060 (UTC) FILETIME=[95F6DF40:01C83798] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Wed, 05 Dec 2007 18:54:10 -0500 Subject: [Mobopts] Presentations X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello folks, I have uploaded them to the IETF Meeting Materials site. Regards, -Rajeev -- http://people.nokia.net/~rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Dec 05 21:07:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J069Z-0000Zq-Lb; Wed, 05 Dec 2007 21:07:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J069Y-0000ZY-BL for mobopts@irtf.org; Wed, 05 Dec 2007 21:07:52 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J069Y-00067W-1p for mobopts@irtf.org; Wed, 05 Dec 2007 21:07:52 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1196906871!24980373!1 X-StarScan-Version: 5.5.12.14.2; banners=.,-,- X-Originating-IP: [144.189.100.103] Received: (qmail 23366 invoked from network); 6 Dec 2007 02:07:51 -0000 Received: from motgate3.mot.com (HELO motgate3.mot.com) (144.189.100.103) by server-8.tower-119.messagelabs.com with SMTP; 6 Dec 2007 02:07:51 -0000 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motorola) with ESMTP id lB627gMH002496; Wed, 5 Dec 2007 19:07:46 -0700 (MST) Received: from az10vts04.mot.com (az10vts04.mot.com [10.64.251.245]) by az33exr04.mot.com (8.13.1/Vontu) with SMTP id lB627fO8014934; Wed, 5 Dec 2007 20:07:41 -0600 (CST) Received: from [127.0.0.1] (mvp-10-19-249-241.corp.mot.com [10.19.249.241]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id lB627arl014898; Wed, 5 Dec 2007 20:07:40 -0600 (CST) Message-ID: <47575967.7090008@gmail.com> Date: Wed, 05 Dec 2007 18:07:35 -0800 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [Mobopts] Multimob and security References: <20071203191218.GH2478@steelhead.localdomain> <47547893.9000903@piuha.net> In-Reply-To: <47547893.9000903@piuha.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 071205-2, 05/12/2007), Outbound message X-Antivirus-Status: Clean X-CFilter-Loop: Reflected X-Spam-Score: -4.0 (----) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Jari Arkko wrote: > IMO, this is a different problem that should be addressed by a separate > effort, "IGMP/MLD security". If there were some *-cast to secure for mobility, I think it could also be anycast such that Mobile IPv6 DHAAD operation is secure (DHAAD Request message is sent to a anycast address and sometimes IPsec may probably not like it; happily though DHAAD Reply is unicast to unicast.) Just a thought, Alex > > Jari > > Yoshihiro Ohba kirjoitti: >> Shouldn't multimob work also consider security aspect for securing >> IGMP/MLD where MN does not have a pre-established security association >> with the visited network? >> >> Yoshihiro Ohba >> >> _______________________________________________ >> 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 > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Thu Dec 13 16:36:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2vir-0002tA-Fm; Thu, 13 Dec 2007 16:36:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2viq-0002t5-Go for mobopts@irtf.org; Thu, 13 Dec 2007 16:36:00 -0500 Received: from p130.piuha.net ([2001:14b8:400::130] helo=smtp.piuha.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2vip-0002dR-VG for mobopts@irtf.org; Thu, 13 Dec 2007 16:36:00 -0500 Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id AC9181986CC; Thu, 13 Dec 2007 23:35:58 +0200 (EET) Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 34DD719863E; Thu, 13 Dec 2007 23:35:58 +0200 (EET) Message-ID: <4761A5BE.8050509@piuha.net> Date: Thu, 13 Dec 2007 23:35:58 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.14pre (X11/20071022) MIME-Version: 1.0 To: Rajeev Koodli , draft-irtf-mobopts-l2-abstractions@tools.ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -0.6 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "mobopts@irtf.org" Subject: [Mobopts] draft-irtf-mobopts-l2-abstractions-04.txt comments X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org FYI -- this document was on the IESG telechat a few weeks ago for the does-not-conflict-with-WG-efforts check. The IESG had no problem in publishing it. However, I also read the document for its technical content and wanted post a personal opinion, as well as copy you on the some comments that we received from other ADs during the review. Basically, I believe the specification of the interface is not detailed enough to be implemented in the general case. Not that this is a requirement for research work, but I hope no one thinks the work is now done. For example, even after re-reading the document and its appendix, it is unclear to me how the document proposes dealing with the intricacies related to what it means to be associated with a wireless end point. In 802.11 having an association, having completed EAP/RSN, and having a working IP interface are all different things. Presumably one would prefer getting an indication when authentication and all required link layer tasks complete, but the document does not say this. Link layer fast handoff designs, web authentication, firewalls, etc complicate this further. Another example is the use of the link quality indicators. They appear simple, but their use is far from trivial. Would you move from FAIR 802.11n to EXCELLENT 802.11b? What about BAD 802.11 to GOOD GPRS? To be usable the interfaces would have to have many of these details worked out. For instance, RFC 4957 focused on one event for one purpose, and it turned out that the interactions are far from trivial. In addition, Tim Polk was not convinced that the points raised in IAB link indications document were adequately addressed. For example, iab-link-indications notes for spoofing attacks: "However, even where the link layer incorporates security, attacks may still be possible if the security model is not consistent." Yet this document addresses spoofing with a single sentence: " "Our proposal is nor more insecure than a particular link layer on which it is implemented". These statements appear to be a contradiction. Tim believed that the treatment of spoofing and denial of service should be expanded in the security considerations section to clearly demonstrate the issues raised in iab-link-indications have been fully addressed. Also, Dan Romascanu had questions about the usage or some link layer specific terms. For example he was not sure whether the LinkUp and LinkDown terms are aligned with the RFC 2863 terminology. Finally, some editorial issues: The document would probably benefit from a reference to RFC 4957. Draft-iab-link-indications has been published as RFC 4907. Author's name in [7] should be "Aboba", not "Adoba". Jari _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Dec 14 23:43:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3OsF-0006kH-O9; Fri, 14 Dec 2007 23:43:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3OsE-0006kC-My for mobopts@irtf.org; Fri, 14 Dec 2007 23:43:38 -0500 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J3OsE-0003VP-5Y for mobopts@irtf.org; Fri, 14 Dec 2007 23:43:38 -0500 Received: by py-out-1112.google.com with SMTP id u77so2723881pyb.15 for ; Fri, 14 Dec 2007 20:43:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=0tFaYVSp4abmxSQ41c98fZ9i+Xth8icv7pSNG6pTYyA=; b=DMDo3HqujDU1piWv4LhTM24fGfjfkUPFB8MMGm6JyMPD0Xha9qszZw9zeH83beWLFK2uLV+Jdam5hZz5CCcl0e6+aE8cMy615k0d5Z5YUs2TmYr3WITaXOWceQa55gTfOvcorQkVl5Tb+gEwiVnEizeyOXP8Bi6j5uaWcyCoC7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OvK7zxWzEf98UXRNk1Usa+kOXhF/KzS1s7uuMVERjLbrJRLKa4mO9idSBcmnlSwQaoLmD4wq9ioHkHJkrIlRTVv5zl1f3JJxjPHCfe7uxEEZpcxKduEdIxY0lInSxiRFcxWMPV9y4vEDH/2k+r3/k1BO7m01MJTLAObzsjWu7ws= Received: by 10.142.242.8 with SMTP id p8mr2019594wfh.142.1197693815925; Fri, 14 Dec 2007 20:43:35 -0800 (PST) Received: by 10.142.47.18 with HTTP; Fri, 14 Dec 2007 20:43:35 -0800 (PST) Message-ID: <3d57679a0712142043x3ba99d2epde76d00b002e5921@mail.gmail.com> Date: Fri, 14 Dec 2007 20:43:35 -0800 From: "Rajeev Koodli" To: tera@ics.keio.ac.jp Subject: Re: [Mobopts] draft-irtf-mobopts-l2-abstractions-04.txt comments In-Reply-To: <4761A5BE.8050509@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4761A5BE.8050509@piuha.net> X-Spam-Score: 0.8 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Dear Authors, please address Jari's comments. I see at least two directions: 1. provide clarifications and add some descriptions about the interface Jari is referring to. I know you have built a working system. So, it should be relatively straightforward to provide some additional description. 2. Identify what needs further work or could be improved. Perhaps you can do both 1) and 2). Jari: I hope we can do this during the AUTH48 stage. Anything else that requires further work is perhaps another ID I guess. Regards, -Rajeev On 12/13/07, Jari Arkko wrote: > > FYI -- this document was on the IESG telechat a few weeks ago for the > does-not-conflict-with-WG-efforts check. The IESG had no problem in > publishing it. > > However, I also read the document for its technical content and wanted > post a personal opinion, as well as copy you on the some comments that > we received from other ADs during the review. > > Basically, I believe the specification of the interface is not detailed > enough to be implemented in the general case. Not that this is a > requirement for research work, but I hope no one thinks the work is now > done. > > For example, even after re-reading the document and its appendix, it is > unclear to me how the document proposes dealing with the intricacies > related to what it means to be associated with a wireless end point. In > 802.11 having an association, having completed EAP/RSN, and having a > working IP interface are all different things. Presumably one would > prefer getting an indication when authentication and all required link > layer tasks complete, but the document does not say this. Link layer > fast handoff designs, web authentication, firewalls, etc complicate this > further. > > Another example is the use of the link quality indicators. They appear > simple, but their use is far from trivial. Would you move from FAIR > 802.11n to EXCELLENT 802.11b? What about BAD 802.11 to GOOD GPRS? > > To be usable the interfaces would have to have many of these details > worked out. For instance, RFC 4957 focused on one event for one purpose, > and it turned out that the interactions are far from trivial. > > In addition, Tim Polk was not convinced that the points raised in IAB > link indications document were adequately addressed. For example, > iab-link-indications notes for spoofing attacks: "However, even where > the link layer incorporates security, attacks may still be possible if > the security model is not consistent." Yet this document addresses > spoofing with a single sentence: " "Our proposal is nor more insecure > than a particular link layer on which it is implemented". These > statements appear to be a contradiction. Tim believed that the > treatment of spoofing > and denial of service should be expanded in the security considerations > section to clearly demonstrate the issues raised in iab-link-indications > have been fully addressed. > > Also, Dan Romascanu had questions about the usage or some link layer > specific terms. For example he was not sure whether the LinkUp and > LinkDown terms are aligned with the RFC 2863 terminology. > > Finally, some editorial issues: > > The document would probably benefit from a reference to RFC 4957. > > Draft-iab-link-indications has been published as RFC 4907. > > Author's name in [7] should be "Aboba", not "Adoba". > > Jari > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Mon Dec 17 16:54:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4Nub-00013t-7k; Mon, 17 Dec 2007 16:54:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4HPk-0000l4-TV for mobopts@irtf.org; Mon, 17 Dec 2007 09:57:52 -0500 Received: from maro.tera.ics.keio.ac.jp ([131.113.71.3] helo=smtp.tera.ics.keio.ac.jp) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J4HPi-0004zS-Ep for mobopts@irtf.org; Mon, 17 Dec 2007 09:57:52 -0500 Received: (qmail 7980 invoked from network); 17 Dec 2007 23:57:44 +0900 X-Authentication: tera was authenticated by 0 at 17 Dec 2007 23:57:44 +0900 Received: from unknown (HELO hotaka.ics.keio.ac.jp) (2001:200::6800::3) by 0 with SMTP; 17 Dec 2007 23:57:44 +0900 Message-Id: <6.2.3.4.2.20071217234955.0ae8a090@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2J rev4.2 Date: Mon, 17 Dec 2007 23:57:48 +0900 To: "Rajeev Koodli" From: Fumio Teraoka Subject: Re: [Mobopts] draft-irtf-mobopts-l2-abstractions-04.txt comments In-Reply-To: <3d57679a0712142043x3ba99d2epde76d00b002e5921@mail.gmail.co m> References: <4761A5BE.8050509@piuha.net> <3d57679a0712142043x3ba99d2epde76d00b002e5921@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.8 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 X-Mailman-Approved-At: Mon, 17 Dec 2007 16:54:07 -0500 Cc: mobopts@irtf.org X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Dear Rajeev Koodli and Jari Arkko, We will revise the document at Rajeev's suggestion. Since we don't have enough time now, please wait for 1 or 2 weeks. Regards, Fumio Teraoka At 07/12/14 20:43 -0800, Rajeev Koodli wrote: >Dear Authors, > >please address Jari's comments. I see at least two directions: > >1. provide clarifications and add some descriptions about the >interface Jari is referring to. I know you have built a working >system. So, it should be relatively straightforward to provide some >additional description. > >2. Identify what needs further work or could be improved. > >Perhaps you can do both 1) and 2). > >Jari: I hope we can do this during the AUTH48 stage. Anything else >that requires further work is perhaps another ID I guess. > >Regards, > >-Rajeev > > >On 12/13/07, Jari Arkko wrote: >> >> FYI -- this document was on the IESG telechat a few weeks ago for the >> does-not-conflict-with-WG-efforts check. The IESG had no problem in >> publishing it. >> >> However, I also read the document for its technical content and wanted >> post a personal opinion, as well as copy you on the some comments that >> we received from other ADs during the review. >> >> Basically, I believe the specification of the interface is not detailed >> enough to be implemented in the general case. Not that this is a >> requirement for research work, but I hope no one thinks the work is now >> done. >> >> For example, even after re-reading the document and its appendix, it is >> unclear to me how the document proposes dealing with the intricacies >> related to what it means to be associated with a wireless end point. In >> 802.11 having an association, having completed EAP/RSN, and having a >> working IP interface are all different things. Presumably one would >> prefer getting an indication when authentication and all required link >> layer tasks complete, but the document does not say this. Link layer >> fast handoff designs, web authentication, firewalls, etc complicate this >> further. >> >> Another example is the use of the link quality indicators. They appear >> simple, but their use is far from trivial. Would you move from FAIR >> 802.11n to EXCELLENT 802.11b? What about BAD 802.11 to GOOD GPRS? >> >> To be usable the interfaces would have to have many of these details >> worked out. For instance, RFC 4957 focused on one event for one purpose, >> and it turned out that the interactions are far from trivial. >> >> In addition, Tim Polk was not convinced that the points raised in IAB >> link indications document were adequately addressed. For example, >> iab-link-indications notes for spoofing attacks: "However, even where >> the link layer incorporates security, attacks may still be possible if >> the security model is not consistent." Yet this document addresses >> spoofing with a single sentence: " "Our proposal is nor more insecure >> than a particular link layer on which it is implemented". These >> statements appear to be a contradiction. Tim believed that the >> treatment of spoofing >> and denial of service should be expanded in the security considerations >> section to clearly demonstrate the issues raised in iab-link-indications >> have been fully addressed. >> >> Also, Dan Romascanu had questions about the usage or some link layer >> specific terms. For example he was not sure whether the LinkUp and >> LinkDown terms are aligned with the RFC 2863 terminology. >> >> Finally, some editorial issues: >> >> The document would probably benefit from a reference to RFC 4957. >> >> Draft-iab-link-indications has been published as RFC 4907. >> >> Author's name in [7] should be "Aboba", not "Adoba". >> >> Jari >> >> >> _______________________________________________ >> Mobopts mailing list >> Mobopts@irtf.org >> https://www1.ietf.org/mailman/listinfo/mobopts >> _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Wed Dec 19 05:22:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4w4m-0008Hc-2f; Wed, 19 Dec 2007 05:22:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4w4k-0008GD-LQ for mobopts@irtf.org; Wed, 19 Dec 2007 05:22:54 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J4w4i-0000RC-Qa for mobopts@irtf.org; Wed, 19 Dec 2007 05:22:54 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBJAM2m6013411 for ; Wed, 19 Dec 2007 12:22:51 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 12:22:18 +0200 Received: from esdhcp03973.research.nokia.com ([172.21.39.73]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Dec 2007 12:22:18 +0200 Message-Id: <24EA9435-586C-4C29-B659-D2720FA7FB9B@nokia.com> From: Lars Eggert To: mobopts@irtf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v915) Date: Wed, 19 Dec 2007 12:22:17 +0200 X-Mailer: Apple Mail (2.915) X-OriginalArrivalTime: 19 Dec 2007 10:22:18.0247 (UTC) FILETIME=[086C5970:01C84229] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Subject: [Mobopts] CFP: MobiArch'08 - ACM SIGCOMM workshop X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org -= ------------------------------------------------------------------------ CALL FOR PAPERS ACM MobiArch 2008 An ACM SIGCOMM 2008 Workshop *** PAPER REGISTRATION DEADLINE: MARCH 17, 2008 *** = ------------------------------------------------------------------------- ACM MobiArch 2008 The 3rd ACM International Workshop on Mobility in the Evolving Internet Architecture An ACM SIGCOMM 2008 Workshop Seattle, WA, USA, August 22, 2008 http://www.sigcomm.org/sigcomm2008/workshops/mobiarch/ Recent developments in wireless access technologies and mobile devices are beginning to make widespread user, terminal and network mobility a reality in the commercial Internet. At the same time, the Internet architecture struggles to incorporate the functionality that will =20 sustain this increasingly more mobile and more dynamic Internet use. Efficient mobility management and mobility optimizations, locator-identifier splits, multihoming, security and related network operation and management functions are still in the early stages of development. It =20= is, however, already clear that supporting widespread mobility poses to significantly impact the original end-to-end design of the Internet. At the same time, critical momentum is building to significantly revise or even replace the current Internet architecture. Several substantial Future Internet initiatives have started in Europe, the US and Asia, and the topic is also actively being discussed in the vendor and network operator communities. These Future Internet efforts offer the exciting opportunity to design radically different approaches to supporting host and network mobility and multihoming, and may eventually lead to an internetwork architecture with significantly more advanced mobility features than those that the piecemeal extensions of the current =20 Internet protocols result in. MobiArch'08 welcomes submissions from both researchers and practitioners that explore recent advances in architectures, protocols and emerging technologies to enable mobility and multihoming in the Internet, as well as concepts and designs to support widespread mobility and multihoming =20= in future internetworks. Early results, position papers, systems and measurement papers are particularly welcome. TOPICS MobiArch'08 covers all aspects related to mobility in the current and future Internet, including, but not limited to: * Architectures and protocols for mobility support at all layers of the Internet protocol stack, as well as cross-layer approaches * Novel concepts to support widespread mobility and multihoming in a Future Internet * Routing and addressing issues (including locator/identifier splits) and their impact on the Internet architecture * Multihoming, including flow distribution and load-sharing for wireless and mobility * Performance evaluation, experimentation and modeling of Internet mobility * Models for mobility patterns and their experimental validation * New wireless technologies and services and their impact on the Internet architecture * Location management, positioning and data management for wireless and mobility * Accounting, access control, security and privacy issues and their impact on the Internet architecture * Social, economic, scalability and deployment issues SUBMISSION GUIDELINES Submissions must be no longer than six pages, including all figures and references, must be in PDF format, and must follow the ACM formatting guidelines (http://www.acm.org/sigs/publications/proceedings-templates). Submissions that do not adhere to these requirements will be rejected without further review. Peer review is single-blind; the authors names and affiliations are to =20= be included on the submission. Submissions cannot be previously published =20= or be under concurrent review elsewhere. The submission of position papers is encouraged; please clearly identify position papers as such when submitting. Papers may be submitted at http://edas.info/newPaper.php?c=3D6140 TECHNICAL PROGRAM COMMITTEE Lars Eggert (co-chair, Nokia Research Center, FI) Linda Doyle (co-chair, Trinity College, IE) Bengt Ahlgren (Swedish Institute of Computer Science, SE) Jari Arkko (Ericsson, FI) Marcelo Bagnulo (University Carlos III of Madrid, ES) Olivier Bonaventure (Universit=E9 Catholique de Louvain, BE) Wesley Eddy (NASA/Verizon (US) Joseph Evans (University of Kansas, US) Ted Faber (USC Information Sciences Institute, US) Stephen Hailes (University College London, UK) Roger Karrer (T-Labs, DE) Rajeev Koodli (Nokia Research Center, US) Donal O'Mahony (Trinity College, IE) J=F6rg Ott (Helsinki University of Technology, FI) Dipankar Raychaudhuri (Rutgers University, US) Dave Thaler (Microsoft Research, US) Ryuji Wakikawa (Keio University, JP) Klaus Wehrle (RWTH Aachen University, DE) Lixia Zhang (UCLA, US) _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts