From mip4-bounces@ietf.org Tue Nov 01 12:24:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWzgV-0005zC-R0; Tue, 01 Nov 2005 12:12:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWmQh-0006Js-UV; Mon, 31 Oct 2005 22:03:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05478; Mon, 31 Oct 2005 22:02:59 -0500 (EST) Received: from mailman.ufsc.br ([150.162.1.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWmer-0007np-BW; Mon, 31 Oct 2005 22:18:06 -0500 Received: from localhost (localhost [127.0.0.1]) by mailman.ufsc.br (Postfix) with ESMTP id 8EF0586034; Tue, 1 Nov 2005 01:02:33 -0200 (BRST) Received: from mailman.ufsc.br ([127.0.0.1]) by localhost (mailman.ufsc.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24546-06; Tue, 1 Nov 2005 01:02:33 -0200 (BRST) Received: from mailman.ufsc.br (mailman.ufsc.br [150.162.1.5]) by mailman.ufsc.br (Postfix) with ESMTP id 6BE3F7E5A8; Tue, 1 Nov 2005 01:01:09 -0200 (BRST) X-Original-To: researchers@mailman.ufsc.br Delivered-To: researchers@mailman.ufsc.br Received: from localhost (localhost [127.0.0.1]) by mailman.ufsc.br (Postfix) with ESMTP id EDB567E596 for ; Tue, 1 Nov 2005 01:00:37 -0200 (BRST) Received: from mailman.ufsc.br ([127.0.0.1]) by localhost (mailman.ufsc.br [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24217-07 for ; Tue, 1 Nov 2005 01:00:34 -0200 (BRST) Received: from mail.viamidia.com (mail.viamidia.net [200.215.177.134]) by mailman.ufsc.br (Postfix) with ESMTP id BDAE97E555 for ; Tue, 1 Nov 2005 01:00:27 -0200 (BRST) Received: from smtp.viamidia.com (smtp.viamidia.com [10.0.0.12]) by mail.viamidia.com (8.12.5/pre1.0-MySQL/8.12.8) with ESMTP id jA130XmK038807; Tue, 1 Nov 2005 01:00:33 -0200 (BRST) (envelope-from mirela@barddal.br) Received: from SaintMi ([201.34.131.136]) (authenticated bits=0) by smtp.viamidia.com (8.12.8p2/8.12.8) with ESMTP id jA130VBs045390; Tue, 1 Nov 2005 00:00:32 -0300 (BRT) (envelope-from mirela@barddal.br) Message-ID: <00cd01c5de90$98737ed0$b800a8c0@SaintMi> From: "Profa Mirela Sechi Moretti Annoni Notare" To: Date: Tue, 1 Nov 2005 01:01:40 -0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Viamidia-ticket: b95d90c7e5751a47c66b02e013b6e9b0c84bd12a74dc69c95254048f193c4f5d X-Virus-Scanned: by amavisd-new at mailman.ufsc.br X-BeenThere: researchers@mailman.ufsc.br X-Mailman-Version: 2.1.5 Precedence: list X-Virus-Scanned: by amavisd-new at mailman.ufsc.br X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 01 Nov 2005 12:12:30 -0500 Cc: Subject: [Mip4] [Researchers] IEEE/ACM IPDPS 2006/PMEO-PDS'06 - 5th International Workshop on Performance Modeling, Evaluation and Optimization of Parallel and Distributed Systems X-BeenThere: mip4@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org CALL FOR PAPERS 5th International Workshop on Performance Modeling, Evaluation, and Optimization of Parallel and Distributed Systems(PMEO-PDS'06) To be held in conjunction with IPDPS 2006 (sponsored by IEEE Computer Society and in co-operation with ACM SIGARCH) Rhodes Island, Greece April 25-29, 2006 http://www.dcs.gla.ac.uk/~mohamed/pmeo06.html SCOPE: The performance modeling, evaluation, and optimization of parallel, distributed, and grid systems have been an important research topic over the past years and poses challenging problems that require new tools and methods to keep up with the rapid evolution and increasing complexity of such systems. This workshop will bring together scientists, engineers, practitioners, and computer users to share and exchange their experiences, discuss challenges, and report state-of-the-art and in-progress research on all aspects of performance modeling, evaluation, and optimization of parallel, distributed, and grid systems. The topics of interest include, but are not limited to: .Predictive performance models of parallel and distributed systems .Performance measurement and monitoring tools .Tracing and trace analysis .Simulation .Analytical modeling .Software tools for system performance and evaluation .Automatic performance analysis .Performance comparison .Performance of memory and I/O interconnect .Performance of communication networks .Performance of mobile distributed systems .Performance analysis and evaluation of parallel and distributed applications .Improvement in system performance through optimization and tuning .Case studies showing the role of evaluation in the design of systems WORKSHOP CO-CHAIRS: Mohamed Ould-Khaoua Department of Computing Science University of Glasgow Glasgow, G12 8RZ, U.K. E-mail: mohamed@dcs.gla.ac.uk Geyong Min Department of Computing University of Bradford Bradford, BD7 1DP, U.K. E-mail: g.min@bradford.ac.uk Publicity Chair: Mirela Sechi Moretti Annoni Notare Barddal University Florianopolis, SC Brazil Email: mirela@barddal.br POTENTIAL PROGRAM COMMITTEE: Khalid Al-Begain, Univ. of Glamorgan (UK) A. Al-Dubai, Thames Valley University-London (UK) Marco Ajmone-Marsan, Politechnico di Torino (Italy) Hamid R. Arabnia, Univ. of Georgia (USA) Irfan Awan, Univ. of Bradford (UK) Mark Baker, Univ. of Portsmouth (UK) Pradip Bose, IBM T. J. Watson Research Center (USA) Azzedine Boukerche, Univ. of North Texas (USA) Michele Colajanni, Univ. of Modena (Italy) Erol Gelenbe, Imperial College London (UK) Pete Harrison, Imperial College London (UK) Roland Ibbett, Univ. of Edinburgh (UK) Stephen Jarvis, Univ. of Warwick (UK) Helen Karatza, Univ. of Thessaloniki (Greece) Demetres D. Kouvatsos, Univ. of Bradford (UK) Keqin Li, State Univ. of New York at New Paltz (USA) Samia Loucif, Emirates University, (UAE) Lewis M. Mackenzie, Univ. of Glasgow (UK) Yi Pan, Georgia State Univ. (USA) Dhiraj K. Pradhan, Univ. of Bristol (UK) Mirela S. M. A. Notare, Barddal University, (Brazil) Hamid Sarbazi-Azad, Sharif University & IPM (Iran) Nigel Thomas, Univ. of Newcastle (UK) Mike E. Woodward, Univ. of Bradford (UK) Jie Wu, Florida Atlantic Univ. (USA) Qing Yang, Univ. of Rhode Island (USA) Albert Zomaya, Univ. of Sydney (Australia) PAPER SUBMISIION: Authors are invited to submit manuscripts reporting original unpublished research and recent developments in the topics related to the workshop. The length of the papers should not exceed 18 DOUBLE-spaced pages including figures and references on 8.5 by 11 inch paper using at least 11 point font. Papers should be submitted electronically in PDF format (or postscript) by sending it as an e-mail attachment to mohamed@dcs.gla.ac.uk. All papers will be peer reviewed and the comments will be provided to the authors. The accepted papers will be published together with those of other IPDPS '2005 workshops by the IEEE Computer Society Press. IMPORTANT DATES: .Submission Deadline: 2 November 2005 .Author Notification: 20 December, 2005 .Final Manuscript Due: 21 January, 2005 _______________________________________________ Researchers mailing list Researchers@mailman.ufsc.br http://mailman.ufsc.br/mailman/listinfo/researchers -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 01 12:24:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWzgF-0005i4-5r; Tue, 01 Nov 2005 12:12:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWgAc-00060U-UC for mip4@megatron.ietf.org; Mon, 31 Oct 2005 15:22:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05235 for ; Mon, 31 Oct 2005 15:21:59 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWgOs-0006LC-4R for mip4@ietf.org; Mon, 31 Oct 2005 15:37:02 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 31 Oct 2005 12:22:00 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.203]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Oct 2005 12:22:00 -0800 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: Mon, 31 Oct 2005 12:21:59 -0800 Message-ID: <4A8D7C3204072A46A7DC234B2D81C1CC06BF3010@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: MobiSys 2006 Call for Papers Thread-Index: AcXeWL8BkleUvm3CSj+XQPKYbbQIHQ== From: "Alec Wolman" To: X-OriginalArrivalTime: 31 Oct 2005 20:22:00.0290 (UTC) FILETIME=[BF992420:01C5DE58] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 01 Nov 2005 12:12:14 -0500 Subject: [Mip4] MobiSys 2006 Call for Papers X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org [ We apologize in advance if you receive multiple copies of this CFP.... ] Reminder: There are just 4 weeks remaining until the Mobisys 2006 submission deadline! =20 ---------------------------------------------------------------------- MobiSys 2006 Call for Papers http://www.sigmobile.org/mobisys/2006/ The 4th International Conference on Mobile Systems, Applications, and Services June 19-22, 2006 Uppsala, Sweden Jointly sponsored by ACM SIGMOBILE and The USENIX Association, in cooperation with ACM SIGOPS MobiSys 2006 seeks to present innovative and significant research on the design, implementation, usage, and evaluation of mobile computing and wireless systems, applications, and services. The conference will be held in early summer in the historic town of Uppsala, Sweden. It builds on the success of the first three conferences held in San Francisco, Boston and Seattle. Important Dates Full papers due: Monday Nov 28 2005 (23:59 EST) (HARD DEADLINE, no extensions) Notification of paper acceptance: March 10,2005 Camera-ready final papers due: April 7, 2006 Poster and demo proposals due: March 27, 2006 Notification of poster/demo acceptance: April 21, 2006 Conference Organizers General Co-Chairs: Per Gunningberg (Uppsala University, Sweden) Lars-Ake Larzon (Uppsala University, Sweden) Steering Committee Chair: Victor Bahl, Microsoft Research Program Co-Chairs: Mahadev Satyanarayanan, Carnegie Mellon University, USA Nigel Davies, Lancaster University, UK Program Committee: Victor Bahl, Microsoft Research, USA Mary Baker, HP Labs, USA Ramon Caceres, IBM T.J. Watson Research Center, USA Mark Corner, University of Massachusetts, USA Nigel Davies, Lancaster University, UK Eyal de Lara, University of Toronto, Canada Carla Ellis, Duke University, USA Adrian Friday, Lancaster University, UK Jason Hong, Carnegie Mellon University, USA David Kotz, Dartmouth College, USA Anthony LaMarca, Intel Research Seattle, USA Antonio Kruger, University of Munster, Germany Dushyanth Narayanan, Microsoft Research, UK Brian Noble, University of Michigan, USA Mahadev Satyanarayanan, Carnegie Mellon University, USA Rahul Sukthankar, Intel Research Pittsburgh, USA Roy Want, Intel Research, USA Poster Chair:=20 Ramon Caceres, IBM T.J. Watson Research Center, USA Demo Co-Chairs:=20 Bengt Ahlgren, Swedish Institute of Computer Science, Sweden Ian Chakeres, Boeing Phantom Works, USA Publicity Chair: Alec Wolman, Microsoft Research, USA Submission guidelines We seek papers that take a broad systems perspective rather than focus narrowly on low-level components. We value results and insights obtained from working implementations more highly than those obtained solely from simulations. If you have any questions regarding relevance or other submission-related issues, please contact the program chairs at mobisys_pcchairs@acm.org. Topics of interest include, but are not limited to: - Design, implementation, and evaluation of mobile and wireless systems - Middleware and service architectures for mobile and wireless applications - Data management for mobile and wireless applications - Operating Systems for resource-constrained mobile devices - Disconnected and weakly connected operation - Proxies and data adaptation - Mobile agents - Infrastructure support for mobility - Security, privacy, authorization, and billing - System-level energy management for mobile and wireless devices - Wearable and handheld devices in the context of system design - Personal mobility - Personal-area networks and systems - Cyber foraging and resource discovery of mobile services - Systems for context sensing and location awareness - Application interfaces and services supporting the mobile user - Tools and design methodologies for building mobile and wireless systems - Mobile computing support for pervasive computing - User interfaces and usability issues for mobile and wireless applications - Experience with mobile and wireless systems Submissions should be full papers, up to 14 single-spaced 8.5" x 11" pages, including figures, tables, and references, two-column format, using 10-point type on 12-point (single-spaced) leading with reasonable margins. Submissions will be judged on originality, significance, interest, clarity, relevance, and technical correctness. Accepted papers will be shepherded by a member of the program committee. MobiSys, like most conferences and journals, requires that papers must not be submitted simultaneously to any other conference or publication, that submissions must not be previously published, and that accepted papers must not be subsequently published elsewhere. Papers accompanied by nondisclosure agreement forms are not acceptable and will be returned to the author(s) unread. As customary with the scientific peer review process, submissions will be handled as confidential material during the review. Submissions are due Monday, November 28, 2005, 23:59 EST. This is a hard deadline, and no extensions will be granted. The submission process is electronic. All submissions must be in PDF format. See the conference web page for detailed instructions. Poster and Demo Sessions Do you have interesting work you would like to share, or a great idea that is not quite ready to be published? Poster sessions are for you! The poster sessions introduce new or ongoing work. Demos of working systems and applications are also encouraged. The MobiSys audience will provide valuable discussion and feedback. We are particularly interested in presentations of student work. See the conference web page for submission details. Workshops The ACM MobiSys 2006 conference will host a day of workshops on technical areas related to mobile systems, applications and services. SIGMOBILE invites workshop proposals from interested communities. New workshops in emerging areas that can engage participants in greater interaction are welcome. See the conference web page for details. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 01 16:25:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX3dm-0005ff-LV; Tue, 01 Nov 2005 16:25:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX3dk-0005ey-9s for mip4@megatron.ietf.org; Tue, 01 Nov 2005 16:25:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16195 for ; Tue, 1 Nov 2005 16:25:35 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX3sB-0003s7-OH for mip4@ietf.org; Tue, 01 Nov 2005 16:40:53 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA1Lc0v6008125 for ; Tue, 1 Nov 2005 14:38:00 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id jA1LYjmU020359 for ; Tue, 1 Nov 2005 15:34:46 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Nov 2005 16:25:15 -0500 Message-ID: Thread-Topic: Bar-meeting on Handover keying design Thread-Index: AcXUeip0K9cwHmNUTdaeGJGn/RgZUAKsIEEA From: "Nakhjiri Madjid-MNAKHJI1" To: "Mobile IPv4 Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Subject: [Mip4] Bar-meeting on Handover keying design X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org =20 Hi, This is a solicitation for folks interested in a Bar-meeting (Bar pre-BoF or whatever the meeting ends up being) discussing handover keying (I call it HOKEY, and have created a semi-formal proposal in case we end up needing a BOF name for Dallas, who knows it does not hurt to have these things handy :) ). I have a link to an old draft from April down at the bottom of this email, but unfortunately, I did not have time to write a new version of the draft. The old draft may be enough to initiate some discussion. Please let me know if you are interested in participating. We will decide on the "happy hour" time and location :) I have not yet set up a proper mailing list, so if you are simply interested in checking things out, ***you do not need to send me an email yet*** as I am sending this email to several lists. If I manage to set of a mailing list in time for IETF, an announcement is to follow. Regards, Madjid Nakhjiri Handover Keying (HOKEY) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The recent "AAA Key Management" guidelines as well as several IEEE and WiMAX specification documents attest to the increasing popularity of approach of striving to benefit from the interaction with the authentication (AAA) servers during the network entry to provision further keying materials for support of other networking applications or handovers to other networks.=20 Recent attempts in applying these methods to access technologies with mobility support (such as WiMAX) has shown that the existing specifications may needs to be further examined or extended from the point of view of handover keying or networking application keying support. It seems to be more efficient to instead initiate a well-thought and documented design with a first-hand focus on mobility and handover keying and authorization mechanisms. The initial goal of this activity can be to examine the combination of the EAP and AAA documentations to utilize the EAP keying framework and the AAA infrastructure for handover keying and provide an appropriate key hierarchy that can handle the requirements stated in "AAA key management" and further venturing into other network applications that may need keying support. A background problem statement can be found at http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Nov 02 10:42:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXKki-0003TS-Hz; Wed, 02 Nov 2005 10:42:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXCv8-0004xK-S6 for mip4@megatron.ietf.org; Wed, 02 Nov 2005 02:20:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16960 for ; Wed, 2 Nov 2005 02:20:09 -0500 (EST) Received: from hkueee2.eee.hku.hk ([147.8.180.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXD9g-0002eR-9k for mip4@ietf.org; Wed, 02 Nov 2005 02:35:33 -0500 Received: from hkueee2 (hkueee2.eee.hku.hk [147.8.180.60]) by hkueee2.eee.hku.hk (8.13.5/8.13.5) with ESMTP id jA27KCCQ014505 for ; Wed, 2 Nov 2005 15:20:12 +0800 (HKT) Date: Wed, 2 Nov 2005 15:20:12 +0800 (HKT) From: Ka-Cheong Leung X-X-Sender: kcleung@hkueee2 To: mip4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-HKUEEE-MailScanner-Information: www.eee.hku.hk/intranet/computer/faq/mailscanner.htm X-HKUEEE-MailScanner: Found to be clean X-HKUEEE-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.518, required 5, autolearn=not spam, AWL 0.08, BAYES_00 -2.60) Subject: [mip4] Call For Participation: NASM 2005 (November 22-24, 2005) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-Mailman-Approved-At: Wed, 02 Nov 2005 10:42:16 -0500 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kcleung@ieee.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org (We apologize if you receive multiple copies of this CFP.) CALL FOR PARTICIPATION The First International Workshop on Network Architecture and Service Models NASM 2005 November 22-24, 2005 Fudan University, Shanghai, China http://www.cs.fudan.edu.cn/mobile/news/nasm2005/NASM-2005.htm Technically Co-Sponsored by: The British Computer Society (BCS) The Institution of Electrical Engineers (IEE) The Chinese Institute of Electronics (CIE) IEEE Beijing Section KEYNOTE SPEECHES * Prof. JiangXing Wu Fellow, Chinese Academy of Engineering National Digital Switching Center, China Keynote: "China's Next Generation Networks Architectures" * Prof. Victor O. K. Li, PhD MIT, FIEEE Chair Professor in Information Engineering The University of Hong Kong Keynote: "Future of 3G/4G Next Generation Networks" * Prof. Teruo Higashino, PhD, FIPSJ Professor in Computer Science University of Osaka, Japan Keynote: "Future of Mobile Computing & Ubiquitous Networks" TECHNICAL PROGRAM * 44 paper presentations - Details will be available in the conference web page soon. -------------------------------------------------------------------------------- Dr. Ka-Cheong Leung Visiting Assistant Professor Department of EEE The University of Hong Kong -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Nov 04 12:34:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5St-0001xQ-NW; Fri, 04 Nov 2005 12:34:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5Ss-0001xL-Q8 for mip4@megatron.ietf.org; Fri, 04 Nov 2005 12:34:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03316 for ; Fri, 4 Nov 2005 12:34:36 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY5ht-0005Mr-0v for mip4@ietf.org; Fri, 04 Nov 2005 12:50:31 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jA4HYf0s000879 for ; Fri, 4 Nov 2005 11:34:42 -0600 (CST) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id jA4HYe714971; Fri, 4 Nov 2005 11:34:40 -0600 (CST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Yq3YlLqdWq" Content-Transfer-Encoding: 7bit Message-ID: <17259.39855.731684.715336@gargle.gargle.HOWL> Date: Fri, 4 Nov 2005 11:34:39 -0600 From: Pete McCann To: mip4@ietf.org X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Subject: [Mip4] reg-tunnel Appendix A X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --Yq3YlLqdWq Content-Type: text/plain; charset=us-ascii Content-Description: message body text Content-Transfer-Encoding: 7bit The attached review of Appendix A of the reg-tunnel draft was done by Hesham back in September. Our apologies for not forwarding it sooner. The suggestion is made to remove the appendix. Please post opinions to the list. -Pete --Yq3YlLqdWq Content-Type: message/rfc822 Content-Description: forwarded message MIME-Version: 1.0 Content-Class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" Return-Path: Received: from 127.0.0.1 [127.0.0.1] by localhost with IMAP (fetchmail-6.2.5) for mccap@localhost (single-drop); Thu, 29 Sep 2005 10:36:57 -0500 (CDT) Received: from horh1.emsr.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j8TFPTf09223; Thu, 29 Sep 2005 10:25:29 -0500 (CDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [192.11.222.163]) by horh1.emsr.lucent.com (8.12.11/8.12.11) with ESMTP id j8TFPRnX021845 for ; Thu, 29 Sep 2005 10:25:27 -0500 (CDT) Received: from mail.flarion.com (mail.flarion.com [63.103.94.23]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j8TFPNNp022024 for ; Thu, 29 Sep 2005 10:25:24 -0500 (CDT) Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Sep 2005 11:25:14 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-mip4-reg-tunnel Thread-Index: AcW4U/mrVkMt9w+KTHSscq2F91GgigMtVhAQ X-OriginalArrivalTime: 29 Sep 2005 15:25:14.0190 (UTC) FILETIME=[FD1DE6E0:01C5C509] X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on nwsgpa X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.63 X-Spam-Level: From: "Soliman, Hesham" To: "Henrik Levkowetz" CC: "Pete McCann" Subject: RE: draft-ietf-mip4-reg-tunnel Date: Thu, 29 Sep 2005 11:25:13 -0400 Content-Transfer-Encoding: quoted-printable Hi Henrik and Pete,=20 Notes to the editor (chairs) :) : This is more of a research paper than an appendix to a draft.=20 It depends on many components that don't exist today. It would probably be less confusing to the draft if it were removed. Anyway, here is my review.=20 thx,=20 Hesham General: The appendix depends heavily on the [route optim] spec,=20 which is non-existent at this point. So I wonder if this is helpful for understanding the apendix and making it work one day. I don't think it is.=20 Also, the appendix relies on many assumptions that are not practically solveable today. For instance, there is no concrete proposal for the FA-R/G/FA security issues. This=20 is brushed over in the text.=20 Finally, the colocated CoA case is a bit vague and needs to be made sharper.=20 All this makes me see this appendix differently from other=20 appendices in other drafts. Typically, the appendix presents future extensions, further explanations or detailed processing of protocol messages. But this one doesn't fall into any of=20 the above. It is presenting an idea that can't really be done based on this spec because it needs several other=20 specs to be available before it can happen. More importantly,=20 the need for such idea is not clear.=20 I think the appendix can be removed without having any effect on the draft; removing it might have a positive effect actually. In any case, more specific comments: - Assumptions about inter FA security and distribution of keys seem vague. How can this be done today? - The reference to [route optim] might be a bit confusing given that this is no longer work in progress. Thoughts? - Should it be clearly stated that an FA cannot be connected to=20 more than one tree of FAs? I.e. there can be no overlap between the "GFA domains"? It seems to me like this is not doable because it will make it difficult to announce all CoAs in the=20 FAA.=20 End of page 33 : "It SHOULD then add, for instance, a new FA-FA Key Reply extension to the Registration Reply message, before relaying it to the next foreign agent" Remove "for instance". section 5: " If a mobile node uses a co-located care-of address, it MAY use Regional Registrations directly to the GFA (see Section 4.1 and Section 5). It MAY also use the same method to make use of multiple levels of Foreign Agents, if it can find out about the hierarchy, either from Mobility Agent Advertisements, or in some other way outside the scope of this specification. This is really vague. How can it make use of multiple levels of=20 FAs? Assume that it found out the hierarchy from the FAA, what=20 does it do ? I think this point is key. If this specification assumes that multiple levels of FAs is a good thing then it should be doable with colocated or non-colocated CoAs. But it looks like it's very difficult to do that for the colocated case.=20 Section 6: "In case of decapsulation and re-encapsulation, it should be noted that the actual decapsulation need not occur at each step of the hierarchy. Instead, the foreign agent at that level can merely change the source and destination IP addresses of the encapsulating IP header."=20 This is a bit vague as well. I guess you mean change the src=20 and dst addresses of the *outer* header?=20 Also the paragraph is worded in a way that makes it sound like = encapsulation is optional "In case of decapsulation....".=20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Tuesday, September 13, 2005 7:11 AM > To: Soliman, Hesham > Cc: Pete McCann > Subject: draft-ietf-mip4-reg-tunnel >=20 >=20 > Hi Hesham, >=20 > At the MIP4 WG meeting, you promised to review appendix A of > this draft. Margaret is now nudging the authors, and we need the > review in order to complete the editing. Do you think you could > could do this review fairly soon? >=20 > Link: > http://tools.ietf.org/id/draft-ietf-mip4-reg-tunnel-00.txt >=20 >=20 > Regards, >=20 > Henrik >=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --Yq3YlLqdWq Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --Yq3YlLqdWq-- From mip4-bounces@ietf.org Fri Nov 04 12:41:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5Z4-00037t-T6; Fri, 04 Nov 2005 12:41:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5Z2-00037H-Q8 for mip4@megatron.ietf.org; Fri, 04 Nov 2005 12:41:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03640 for ; Fri, 4 Nov 2005 12:40:58 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY5o4-0005VX-Fl for mip4@ietf.org; Fri, 04 Nov 2005 12:56:53 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id jA4Hf3ss004678; Fri, 4 Nov 2005 11:41:03 -0600 (CST) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id jA4Hf2719041; Fri, 4 Nov 2005 11:41:03 -0600 (CST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17259.40237.791684.416111@gargle.gargle.HOWL> Date: Fri, 4 Nov 2005 11:41:01 -0600 From: Pete McCann To: itijibox-mip4@yahoo.com Subject: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt In-Reply-To: <20050921073530.78072.qmail@web81910.mail.mud.yahoo.com> References: <20050921073530.78072.qmail@web81910.mail.mud.yahoo.com> X-Mailer: VM 7.17 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid X-Spam-Score: 2.0 (++) X-Scan-Signature: 08156cf414e01129f6a937203576bf20 Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org We didn't get any followup to Gabriel's review here. How does the group feel about splitting 3012bis into two documents? -Pete gabriel montenegro writes: > I reviewed this document. I feel it is not quite RFC quality, being a bit confusing > and verbose/repetitive in sections. A big issue > I have is that it is really two different things bunched together: > > - Challenge/Response extention > - Generalized Authentication Extension > > They really should be two documents, specially cuz this is a revision, the proper > opportunity to make such changes. > > I'm also wondering about the use of MD5 throughout. Given recent developments, some > folks (not unanimously, though) are already calling for the deprecation of > SHA-1, and here we are recommending MD5 for a proposed standard? If this is what's > being used today, then this could be published as a historical or informational RFC, > If the intent is to fix a few bugs in rfc 3012, perhaps the errata page is enough. > But the use of MD5 should be reviewed by the security ADs. CHAP should also be avoided, > due to its vulnerability to dictionary attacks. > For example, EAP advices against its usage (see rfc3748 section 7.6). Even more > explicitly, the EAP requirements for wireless usage call for mandatory > resistance to dictionary attacks: http://www.faqs.org/rfcs/rfc4017.html, section 2.2. > > This comment applies to 3344bis as well. > > Nit: saw "processing for" in several places. Shouldn't it be "processing of"? > > Other comments interspersed below. > > > > > > > > > Network Working Group Charles E. Perkins > > Internet-Draft Nokia Research Center > > Expires: December 19, 2005 Pat R. Calhoun > > Black Storm Networks > > Jayshree. Bharatia > > Nortel Networks > > June 17, 2005 > > Please update the author contact information now, instead of waiting for AUTH48. > > ... > > Abstract > > > ... > > > Furthermore, this document updates RFC3344 by including new > > authentication extension called the Mobile-AAA Authentication > > extension. This new extension is provided so that a mobile node can > > supply credentials for authorization using commonly available AAA > > infrastructure elements. This Authorization-enabling extension MAY > > co-exist in the same Registration Request with Authentication > > extensions defined for Mobile IP Registration by RFC3344. This > > document obsoletes RFC3012. > > This should be a separate document. > > ... > > > 1. Introduction > > > > Mobile IP defines the Mobile-Foreign Authentication extension to > > allow a mobile node to authenticate itself to a foreign agent. Such > > It can provide *mutual* authentication, right? Suggest making it explicit here > precisely because this extension differs in that it is unilateral. It does not aid the > MN in establishing legitimacy of the FA; only the opposite is true. > > > authentication mechanisms are mostly external to the principal > > operation of Mobile IP, since the foreign agent can easily route > > packets to and from a mobile node whether or not the mobile node is > > reporting a legitimately owned home address to the foreign agent. > > Unfortunately, that extension does not provide the foreign agent any > > direct guarantee that the protocol is protected from replays, and > > does not allow for the use of CHAP [RFC1994] for authenticating > > See above comments on CHAP. Shouldn't be a motivation for a new PS document. > > ... > > 2. Mobile IP Agent Advertisement Challenge Extension > > The organization of this section (describing a format), followed by the next section > on operation, followed by other sections (4 and 5) on packet formats is very > confusing. Suggest having all the packet formats bunched together, following each other. > Also suggest preceding them by some section on overview of operation (perhaps section 3 > itself. > > ... > > > > The Challenge extension, illustrated in Figure 1, is inserted in the > > Agent Advertisements by the foreign agent, in order to communicate a > > previously unused challenge value that can be used by the mobile node > > to compute an authentication for its next registration request > > message. The challenge is selected by the foreign agent to provide > > local assurance that the mobile node is not replaying any earlier > > registration request. Eastlake, et al. [RFC1750] provides more > > information on generating pseudo-random numbers suitable for use as > > values for the challenge. > > Perhaps clarify that the transport of these is unicast. > > > 2.1 Handling of Solicited Agent Advertisements > ... > > advertised Challenges. It must instead re-use the most recent of the > > CHALLENGE_WINDOW Advertisement Challenge values. > > This is the first time this is mentioned, and it is not explained. It is > mentioned several times afterwards, but is never really explained until the > appendices. Explanation or at least a reference to the proper section > should accompany the first reference. > > > 3. Operation > > > > This section describes modifications to the Mobile IP registration > > process [RFC3344] which may occur after the foreign agent issues a > > Mobile IP Agent Advertisement containing the Challenge on its local > > Given that Agent Advertisements can be multicast, I'd clarify here that > these are unicast. > > ... > > > 3.2 Foreign Agent Processing for Registration Requests > > Perhaps s/for/of/ > E.g., 3344 uses "processing of" but never "processing for" > > > > > Upon receipt of the Registration Request, if the foreign agent has > > issued a Challenge as part of its Agent Advertisements, and it does > > s/and it/and if it/ > > ... > > > unless the Registration Reply has already been > > received from the home agent. In this case the foreign agent MUST > > preserve the value of the Code field set by the home agent and MUST > > put its own rejection code only in the Status field of the FA Error > > extension (defined in [FAERR]). > > The above does not belong here, but in the next section (3.3) on handling > Registration Replies. > > s/code only in/code in/ > > ... > > with Code value FA_BAD_AAA_AUTH. If the Mobile-AAA Authentication > > Extension is present in the Registration Request, the foreign agent > > MUST NOT remove the Mobile-AAA Authentication Extension and the > > Mobile-Foreign Challenge Extension from the Registration Request. > > s/Request./Request, before forwarding to the Home Agent./ > > > Appendix C provides an example of an action that could be taken by a > > foreign agent. > > > > In the event that the Challenge extension is authenticated through > > the Mobile-Foreign Authentication extension and the Mobile-AAA > > Authentication extension is not present, the foreign agent MAY remove > > the Challenge Extension from the Registration Request without > > disturbing the authentication value computed by the mobile node for > > use by the AAA or the home agent. > > Sometimes "Challenge extension" and sometimes "Challenge Extension" > Please double-check throughout to make sure capitalization is consistent. > > "use by the AAA" is confusing as it was just said that this case has no > AAA, so perhaps clarifying text could be added: > > s/home agent./home agent, the former because it is not present, the latter > because its calculation does not include the Challenge Extension. > > Or one could reword, of course... > > ... > > > If the foreign agent does not remove the Challenge extension, then > > the foreign agent SHOULD store the Challenge value as part of the > > notice the should here. But what if it's not stored? See below. > > > pending registration request list [RFC3344]. Also, if the > > Registration Reply coming from the home agent does not include the > > Challenge Extension, the foreign agent SHOULD NOT reject the > > Registration Request message. If the Challenge Extension is present > > in the Registration Reply, it MUST be the same Challenge value that > > was included in the Registration Request. If the Challenge value > > differs in the Registration Reply received from the home agent, the > > foreign agent MUST insert an FA Error extension with Status value > > HA_WRONG_CHALLENGE in the Registration Reply sent to the mobile node > > (see Section 10). > > The above section does not belong here but in the next section on Registration > Replies. Mixing section contents like this makes things very confusing. > > Above, notice the MUST be the same Challenge value. But if the value was not > stored (as allowed by the SHOULD above), then what happens? The error recovery > and error status value above does not take that into account. > > > If the foreign agent does remove the Challenge extension and > > applicable authentication from the Registration Request message, then > > it SHOULD insert the Identification field from the Registration > > s/insert/store/ > > > Request message along with its record-keeping information about the > > s/along with/as part of/ > > > particular mobile node in order to protect against replays. > > > > 3.3 Foreign Agent Processing for Registration Replies > > s/for/of/ > > ... > > If the foreign agent receives a Registration Reply with the Code > > value HA_BAD_AAA_AUTH, it MUST be relayed to the mobile node. > > Presumably, regardless of code value, the Reg Reply must be relayed, > yes? If so, why is this here? Suggest deleting the above as it is > redundant. In general, there seems to be a lot of repetition. One > reads them carefully expecting there to be an exception to a rule, > but there is none, so it's just tiring. > > > 3.4 Home Agent Processing for the Challenge Extensions > ... > > > The home agent MAY receive a Registration Request with the Mobile-AAA > > s/MAY/may/ > > Does not seem prescriptive but merely describing an eventuality, so I don't > think we need rfc 2026 language here. > > > 3.5 Mobile Node Processing for Registration Replies > ... > > UNKNOWN_CHALLENGE: This error code is received by the mobile node in > > the case where the mobile node has moved to a new foreign agent that > > s/in the case where the mobile node/if it/ > > > MISSING_CHALLENGE: A mobile node that does not include a Challenge > > when the Mobile-Foreign Authentication extension is present may > > receive a MISSING_CHALLENGE error. In this case, the mobile node > > SHOULD send a Challenge extension containing an unused challenge in > > the next Registration Request. > > > > BAD_AUTHENTICATION: This error is sent by the foreign agent if the > > Registration Request contains a Mobile-Foreign Authentication > > extension with an incorrect authenticator that fails verification. A > > mobile node that receives a BAD_AUTHENTICATION Code value SHOULD > > include the Mobile-AAA Authentication Extension in the next > > Registration Request. This will make it possible for the Foreign > > Agent to use its AAA infrastructure in order to authenticate the > > mobile node. In this case, the mobile node MUST use a new Challenge > > value in any new registration, obtained either from an Agent > > Advertisement, or from a Challenge extension to the Registration > > Reply containing the error. > > > > FA_BAD_AAA_AUTH: This error is sent by the foreign agent if the > > Registration Request contains a Mobile-AAA Authentication extension > > with an incorrect authenticator that fails verification. A mobile > > node that receives a FA_BAD_AAA_AUTH MUST use a new Challenge value > > in any new registration, obtained either from an Agent Advertisement, > > or from a Challenge extension to the Registration Reply containing > > the error. > > > > HA_BAD_AAA_AUTH: This error is sent by the home agent if the > > Registration Request contains a Mobile-AAA Authentication extension > > with an incorrect authenticator that fails verification. A mobile > > s/incorrect// > > > node that receives a HA_BAD_AAA_AUTH MUST use a new Challenge value > > in any new registration, obtained either from an Agent Advertisement, > > or from a Challenge extension to the Registration Reply containing > > the error. > > > > STALE_CHALLENGE: If the foreign agent receives a Registration Request > > with a Challenge extension containing a Challenge value previously > > used by that mobile node, the mobile node MAY receive a Registration > > s/MAY/may/ > > > Reply to the mobile node containing the Code value STALE_CHALLENGE. > > In such instances, the mobile node MUST use a new Challenge value in > > next Registration Request, obtained either from an Agent > > Advertisement, or from a Challenge extension to the Registration > > Reply containing the error. > > > > HA_WRONG_CHALLENGE: This error is sent by the foreign agent if the > > Registration Reply from the home agent contains a different Challenge > > value from the one included in the Registration Request. > > s/the one/that/ > > Repetitiveness in the challenge rules was already taken care of by Jari's > comments, I believe. > > ... > > > 4. Mobile-Foreign Challenge Extension > > > > This section specifies a new Mobile IP Registration extension that is > > used to satisfy a Challenge in an Agent Advertisement. The Challenge > > extension to the Registration Request message is used to indicate the > > challenge that the mobile node is attempting to satisfy. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length | Challenge ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Figure 2: The Mobile-Foreign Challenge Extension > > > > Type: > > > > 132 (skippable) (see [RFC3344]) > > > > Length: > > > > Length of the Challenge value > > > > Challenge: > > > > The Challenge field is copied from the Challenge field found in > > the Agent Advertisement Challenge extension (see section 2). > > s/Agent Advertisement/received/ > Cuz Agent Advertisements are not the only way to learn a Challenge. > > > 5. Generalized Mobile IP Authentication Extension > > This really should be a separate document. > > > Several new authentication extensions have been designed for various > > control messages proposed for extensions to Mobile IP. A new > > authentication extension is required for a mobile node to present its > > credentials to any other entity other than the ones already defined; > > the only entities defined in the base Mobile IP specification > > [RFC3344] are the home agent and the foreign agent. It is the > > s/It is/The/ > > > purpose of the generalized authentication extension defined here to > > s/here to/here is to/ > > ... > > 6. Mobile-AAA Authentication subtype > > > > The Generalized Authentication extension with subtype 1 will be > > referred to as a Mobile-AAA Authentication extension. The mobile > > node MAY include a Mobile-AAA Authentication extension in any > > Registration Request. This extension MAY co-exist in the same > > Registration Request with Authentication extensions defined for > > Mobile IP Registration by [RFC3344]. If the mobile node does not > > s/by// > > > include a Mobile-Foreign Authentication [RFC3344] extension, then it > > s/[RFC3344]// > > > MUST include the Mobile-AAA Authentication extension whenever the > > Challenge extension is present. If both are present, the Mobile-AAA > > Authentication extension MUST precede the Mobile-Foreign > > Authentication extension. > > > > If the Mobile-AAA Authentication extension is present, then the > > Registration Message sent by the mobile node MUST contain the Mobile- > > Home Authentication extension [RFC3344] if it shares a security > > notice this "if" > > > association with the home agent. If both are present, the Mobile- > > and this "if" as well. > This means that MN-HA Authentication is no longer a MUST, and that it > may be absent. I believe this is a departure from rfc 3344, and if so, > it should be flagged by explicitly saying so. > > ... > > > 8. SPIs for RADIUS AAA Servers > > > > Some AAA servers only admit a single security association, and thus > > do not use the SPI numbers for Mobile IP authentication extensions > > for use when determining the security association that would be > > necessary for verifying the authentication information included with > > the Authentication extension. > > > > SPI number CHAP_SPI (see Section 9) is reserved for indicating the > > following procedure for computing authentication data (called the > > "authenticator"), which is used by many RADIUS servers [RFC2138] > > today. > > > > To compute the authenticator, apply MD5 [RFC1321] computed on the > > following data, in the order shown: > > > > High-order byte from Challenge || Key || > > > > MD5(Preceding Mobile IP data || > > > > Type, Subtype (if present), Length, SPI) || > > > > Least-order 237 bytes from Challenge > > > > where the Type, Length, SPI, and possibly Subtype, are the fields of > > the authentication extension in use. For instance, all four of these > > fields would be in use when SPI == CHAP_SPI is used with the > > Generalized Authentication extension. Since the RADIUS protocol > > cannot carry attributes of length greater than 253, the preceding > > Mobile IP data, type, subtype (if present), length and SPI are hashed > > using MD5. Finally, the least significant 237 bytes of the challenge > > are concatenated. If the challenge has fewer than 238 bytes, this > > algorithm includes the high-order byte in the computation twice, but > > ensures that the challenge is used exactly as is. Additional padding > > is never used to increase the length of the challenge; the input data > > is allowed to be shorter than 237 bytes long. > > This draft starts by trying to help the FA, not the MN. so it should at least do > no harm to the MN. > > But this is something that can end up screwing the MN. Any device within RF > coverage of both can see everything above (including the challenge), except the > password used in CHAP. Given the weakness to dictionary attacks, an exchange like > the above effectively blasts the user's password to anybody who cares to listen. > This shouldn't be recommended. Or am I missing something? > > ... > > > 9. Configurable Parameters > > > > Every Mobile IP agent supporting the extensions defined in this > > document SHOULD be able to configure each parameter in the following > > table. Each table entry contains the name of the parameter, the > > default value, and the section of the document in which the parameter > > first appears. > > > > +------------------+---------------+---------------------+ > > | Parameter Name | Default Value | Section of Document | > > +------------------+---------------+---------------------+ > > | CHALLENGE_WINDOW | 2 | 3.2 | > > This has never been explained! And the first time it's mentioned is section 2.1. > > > | | | | > > | CHAP_SPI | 2 | 8 | > > First time it's mentioned is section 3.1. > > ... > > > 10. Error Values > > > > Each entry in the following table contains the name of the Code > > [RFC3344] to be returned in a Registration Reply, the value for the > > Code, and the section in which the error is first mentioned in this > > specification. > > Why is the first time it's mentioned that important? What should be > referenced is the section in which it is properly explained (which > could be forward referenced from wherever it's mentioned for the > first time). > > > > > +--------------------+-------+--------------------------+ > > | Error Name | Value | Section of Document | > > +--------------------+-------+--------------------------+ > > | UNKNOWN_CHALLENGE | 104 | 3.2 | > > | | | | > > | BAD_AUTHENTICATION | 67 | 3.2 - also see [RFC3344] | > > | | | | > > | MISSING_CHALLENGE | 105 | 3.1, 3.2 | > > | | | | > > | STALE_CHALLENGE | 106 | 3.2 | > > | | | | > > | FA_BAD_AAA_AUTH | TBD | 3.2 | > > | | | | > > | HA_BAD_AAA_AUTH | TBD | 3.4 | > > | | | | > > | HA_WRONG_CHALLENGE | TBD | 3.2 | > > +--------------------+-------+--------------------------+ > > > > Table 2: Error Values > > > > Given the errors seen in the previous table, please double-check all the > above. > > ... > > > 12. Security Considerations > > > > In the event that a malicious mobile node attempts to replay the > > authenticator for an old Mobile-Foreign Challenge, the foreign agent > > would detect it since the agent always checks whether it has recently > > advertised the Challenge (see Section 3.2). Allowing mobile nodes > > with different IP addresses or NAIs to use the same Challenge value > > does not represent a security vulnerability, because the > > authentication data provided by the mobile node will be computed over > > data that is different (at least by the bytes of the mobile nodes' IP > > addresses). > > OLD: > at least by the bytes of the mobile nodes' IP addresses > > NEW: > at least the mobile node's IP address will vary > > > ... > > > > Section 8 (SPI For RADIUS AAA Servers) defines a method of computing > > the Generalized Mobile IP Authentication Extension's authenticator > > field using MD5 in a manner that is consistent with RADIUS [RFC2138]. > > The use of MD5 in the method described in Section 8 is less secure > > than HMAC-MD5 [RFC2104], and should be avoided whenever possible. > > s/should/MUST/ > But really, this MUST be avoided always, unless there's other (e.g., link-layer > mechanisms) that can help prevent the dictionary attacks. I guess the latter > applies throughout to the other methods as well. > > > Note that an active attacker may try to prevent successful > > registrations by sending a large number of Agent Solicitations or > > bogus Registration Requests, each of which could cause the foreign > > agent to respond with a fresh challenge, invalidating the challenge > > that the MN is currently trying to use. To prevent such attacks, the > > foreign agent MUST NOT invalidate previously unused challenges when > > responding to unauthenticated Registration Requests or Agent > > Solicitations. In addition, the foreign agent MUST NOT allocate new > > storage when responding to such messages, because this would also > > create the possibility of denial of service. > > Should say that it does not seek to provide any assurance to the MN, only > to the FA and infrastructure. > > ... > > 14. Normative References > > > > [FAERR] Perkins, C., "Foreign Agent Error Extension for Mobile > > IPv4", draft-perkins-mip4-faerr-00.txt (work in progress), > > January 2004. > > Update this reference to the latest version. > > ... > > Authors' Addresses > ... > > Pat R. Calhoun > > Black Storm Networks > > 110 Nortech Parkway > > San Jose, CA 95134 > > > > Fax: +1 720-293-7501 > > Email: pcalhoun@diameter.org > > Update this info. > > > Appendix A. Change History > > I like Jari's suggestion to detail the changes with respect to 3012. > > ... > > > Appendix B. Verification Infrastructure > ... > > In order to verify the credentials of the mobile node, we imagine > > s/imagine/assume/ > > ... > > > Appendix C. Message Flow for FA Challenge Messaging with Mobile-AAA > > Extension > ... > > 1. The foreign agent disseminates a Challenge Value in an Agent > > s/disseminates/includes/ > s/an Agent/a unicast Agent/ > > ... > > > Appendix E. Foreign Agent Algorithm for Tracking Used Challenges > > This section is normative, and is where we finally see the explanation > of how to use CHALLENGE_WINDOW. This should be in the body of the document > and must not remain in an appendix. > > The appendix should only have the pseudo-code example. > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Nov 04 12:53:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5kQ-0005Vw-ST; Fri, 04 Nov 2005 12:53:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY5kP-0005Vr-4F for mip4@megatron.ietf.org; Fri, 04 Nov 2005 12:53:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04367 for ; Fri, 4 Nov 2005 12:52:42 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY5zQ-0005px-V2 for mip4@ietf.org; Fri, 04 Nov 2005 13:08:38 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jA4HJ2k04319; Fri, 4 Nov 2005 09:19:02 -0800 X-mProtect: <200511041719> Nokia Silicon Valley Messaging Protection Received: from es-nira-16-152.europe.nokia.com (10.162.16.152, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpd1fnM1J; Fri, 04 Nov 2005 09:18:59 PST Message-ID: <436B9FC7.9060400@iprg.nokia.com> Date: Fri, 04 Nov 2005 09:52:07 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete McCann Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt References: <20050921073530.78072.qmail@web81910.mail.mud.yahoo.com> <17259.40237.791684.416111@gargle.gargle.HOWL> In-Reply-To: <17259.40237.791684.416111@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 2.0 (++) X-Scan-Signature: b4b36b0fb877eeac6f347960137fc10b Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hello folks, This document has been essentially ready to go for over a year. How much longer will it take if we start from scratch with two documents? Maybe next year someone will demand that we merge them again. Regards, Charlie P. Pete McCann wrote: >We didn't get any followup to Gabriel's review here. How does the >group feel about splitting 3012bis into two documents? > >-Pete > >gabriel montenegro writes: > > I reviewed this document. I feel it is not quite RFC quality, being a bit confusing > > and verbose/repetitive in sections. A big issue > > I have is that it is really two different things bunched together: > > > > - Challenge/Response extention > > - Generalized Authentication Extension > > > > They really should be two documents, specially cuz this is a revision, the proper > > opportunity to make such changes. > > > > I'm also wondering about the use of MD5 throughout. Given recent developments, some > > folks (not unanimously, though) are already calling for the deprecation of > > SHA-1, and here we are recommending MD5 for a proposed standard? If this is what's > > being used today, then this could be published as a historical or informational RFC, > > If the intent is to fix a few bugs in rfc 3012, perhaps the errata page is enough. > > But the use of MD5 should be reviewed by the security ADs. CHAP should also be avoided, > > due to its vulnerability to dictionary attacks. > > For example, EAP advices against its usage (see rfc3748 section 7.6). Even more > > explicitly, the EAP requirements for wireless usage call for mandatory > > resistance to dictionary attacks: http://www.faqs.org/rfcs/rfc4017.html, section 2.2. > > > > This comment applies to 3344bis as well. > > > > Nit: saw "processing for" in several places. Shouldn't it be "processing of"? > > > > Other comments interspersed below. > > > > > > > > > > > > > > Network Working Group Charles E. Perkins > > > Internet-Draft Nokia Research Center > > > Expires: December 19, 2005 Pat R. Calhoun > > > Black Storm Networks > > > Jayshree. Bharatia > > > Nortel Networks > > > June 17, 2005 > > > > Please update the author contact information now, instead of waiting for AUTH48. > > > > ... > > > Abstract > > > > > ... > > > > > Furthermore, this document updates RFC3344 by including new > > > authentication extension called the Mobile-AAA Authentication > > > extension. This new extension is provided so that a mobile node can > > > supply credentials for authorization using commonly available AAA > > > infrastructure elements. This Authorization-enabling extension MAY > > > co-exist in the same Registration Request with Authentication > > > extensions defined for Mobile IP Registration by RFC3344. This > > > document obsoletes RFC3012. > > > > This should be a separate document. > > > > ... > > > > > 1. Introduction > > > > > > Mobile IP defines the Mobile-Foreign Authentication extension to > > > allow a mobile node to authenticate itself to a foreign agent. Such > > > > It can provide *mutual* authentication, right? Suggest making it explicit here > > precisely because this extension differs in that it is unilateral. It does not aid the > > MN in establishing legitimacy of the FA; only the opposite is true. > > > > > authentication mechanisms are mostly external to the principal > > > operation of Mobile IP, since the foreign agent can easily route > > > packets to and from a mobile node whether or not the mobile node is > > > reporting a legitimately owned home address to the foreign agent. > > > Unfortunately, that extension does not provide the foreign agent any > > > direct guarantee that the protocol is protected from replays, and > > > does not allow for the use of CHAP [RFC1994] for authenticating > > > > See above comments on CHAP. Shouldn't be a motivation for a new PS document. > > > > ... > > > 2. Mobile IP Agent Advertisement Challenge Extension > > > > The organization of this section (describing a format), followed by the next section > > on operation, followed by other sections (4 and 5) on packet formats is very > > confusing. Suggest having all the packet formats bunched together, following each other. > > Also suggest preceding them by some section on overview of operation (perhaps section 3 > > itself. > > > > ... > > > > > > The Challenge extension, illustrated in Figure 1, is inserted in the > > > Agent Advertisements by the foreign agent, in order to communicate a > > > previously unused challenge value that can be used by the mobile node > > > to compute an authentication for its next registration request > > > message. The challenge is selected by the foreign agent to provide > > > local assurance that the mobile node is not replaying any earlier > > > registration request. Eastlake, et al. [RFC1750] provides more > > > information on generating pseudo-random numbers suitable for use as > > > values for the challenge. > > > > Perhaps clarify that the transport of these is unicast. > > > > > 2.1 Handling of Solicited Agent Advertisements > > ... > > > advertised Challenges. It must instead re-use the most recent of the > > > CHALLENGE_WINDOW Advertisement Challenge values. > > > > This is the first time this is mentioned, and it is not explained. It is > > mentioned several times afterwards, but is never really explained until the > > appendices. Explanation or at least a reference to the proper section > > should accompany the first reference. > > > > > 3. Operation > > > > > > This section describes modifications to the Mobile IP registration > > > process [RFC3344] which may occur after the foreign agent issues a > > > Mobile IP Agent Advertisement containing the Challenge on its local > > > > Given that Agent Advertisements can be multicast, I'd clarify here that > > these are unicast. > > > > ... > > > > > 3.2 Foreign Agent Processing for Registration Requests > > > > Perhaps s/for/of/ > > E.g., 3344 uses "processing of" but never "processing for" > > > > > > > > Upon receipt of the Registration Request, if the foreign agent has > > > issued a Challenge as part of its Agent Advertisements, and it does > > > > s/and it/and if it/ > > > > ... > > > > > unless the Registration Reply has already been > > > received from the home agent. In this case the foreign agent MUST > > > preserve the value of the Code field set by the home agent and MUST > > > put its own rejection code only in the Status field of the FA Error > > > extension (defined in [FAERR]). > > > > The above does not belong here, but in the next section (3.3) on handling > > Registration Replies. > > > > s/code only in/code in/ > > > > ... > > > with Code value FA_BAD_AAA_AUTH. If the Mobile-AAA Authentication > > > Extension is present in the Registration Request, the foreign agent > > > MUST NOT remove the Mobile-AAA Authentication Extension and the > > > Mobile-Foreign Challenge Extension from the Registration Request. > > > > s/Request./Request, before forwarding to the Home Agent./ > > > > > Appendix C provides an example of an action that could be taken by a > > > foreign agent. > > > > > > In the event that the Challenge extension is authenticated through > > > the Mobile-Foreign Authentication extension and the Mobile-AAA > > > Authentication extension is not present, the foreign agent MAY remove > > > the Challenge Extension from the Registration Request without > > > disturbing the authentication value computed by the mobile node for > > > use by the AAA or the home agent. > > > > Sometimes "Challenge extension" and sometimes "Challenge Extension" > > Please double-check throughout to make sure capitalization is consistent. > > > > "use by the AAA" is confusing as it was just said that this case has no > > AAA, so perhaps clarifying text could be added: > > > > s/home agent./home agent, the former because it is not present, the latter > > because its calculation does not include the Challenge Extension. > > > > Or one could reword, of course... > > > > ... > > > > > If the foreign agent does not remove the Challenge extension, then > > > the foreign agent SHOULD store the Challenge value as part of the > > > > notice the should here. But what if it's not stored? See below. > > > > > pending registration request list [RFC3344]. Also, if the > > > Registration Reply coming from the home agent does not include the > > > Challenge Extension, the foreign agent SHOULD NOT reject the > > > Registration Request message. If the Challenge Extension is present > > > in the Registration Reply, it MUST be the same Challenge value that > > > was included in the Registration Request. If the Challenge value > > > differs in the Registration Reply received from the home agent, the > > > foreign agent MUST insert an FA Error extension with Status value > > > HA_WRONG_CHALLENGE in the Registration Reply sent to the mobile node > > > (see Section 10). > > > > The above section does not belong here but in the next section on Registration > > Replies. Mixing section contents like this makes things very confusing. > > > > Above, notice the MUST be the same Challenge value. But if the value was not > > stored (as allowed by the SHOULD above), then what happens? The error recovery > > and error status value above does not take that into account. > > > > > If the foreign agent does remove the Challenge extension and > > > applicable authentication from the Registration Request message, then > > > it SHOULD insert the Identification field from the Registration > > > > s/insert/store/ > > > > > Request message along with its record-keeping information about the > > > > s/along with/as part of/ > > > > > particular mobile node in order to protect against replays. > > > > > > 3.3 Foreign Agent Processing for Registration Replies > > > > s/for/of/ > > > > ... > > > If the foreign agent receives a Registration Reply with the Code > > > value HA_BAD_AAA_AUTH, it MUST be relayed to the mobile node. > > > > Presumably, regardless of code value, the Reg Reply must be relayed, > > yes? If so, why is this here? Suggest deleting the above as it is > > redundant. In general, there seems to be a lot of repetition. One > > reads them carefully expecting there to be an exception to a rule, > > but there is none, so it's just tiring. > > > > > 3.4 Home Agent Processing for the Challenge Extensions > > ... > > > > > The home agent MAY receive a Registration Request with the Mobile-AAA > > > > s/MAY/may/ > > > > Does not seem prescriptive but merely describing an eventuality, so I don't > > think we need rfc 2026 language here. > > > > > 3.5 Mobile Node Processing for Registration Replies > > ... > > > UNKNOWN_CHALLENGE: This error code is received by the mobile node in > > > the case where the mobile node has moved to a new foreign agent that > > > > s/in the case where the mobile node/if it/ > > > > > MISSING_CHALLENGE: A mobile node that does not include a Challenge > > > when the Mobile-Foreign Authentication extension is present may > > > receive a MISSING_CHALLENGE error. In this case, the mobile node > > > SHOULD send a Challenge extension containing an unused challenge in > > > the next Registration Request. > > > > > > BAD_AUTHENTICATION: This error is sent by the foreign agent if the > > > Registration Request contains a Mobile-Foreign Authentication > > > extension with an incorrect authenticator that fails verification. A > > > mobile node that receives a BAD_AUTHENTICATION Code value SHOULD > > > include the Mobile-AAA Authentication Extension in the next > > > Registration Request. This will make it possible for the Foreign > > > Agent to use its AAA infrastructure in order to authenticate the > > > mobile node. In this case, the mobile node MUST use a new Challenge > > > value in any new registration, obtained either from an Agent > > > Advertisement, or from a Challenge extension to the Registration > > > Reply containing the error. > > > > > > FA_BAD_AAA_AUTH: This error is sent by the foreign agent if the > > > Registration Request contains a Mobile-AAA Authentication extension > > > with an incorrect authenticator that fails verification. A mobile > > > node that receives a FA_BAD_AAA_AUTH MUST use a new Challenge value > > > in any new registration, obtained either from an Agent Advertisement, > > > or from a Challenge extension to the Registration Reply containing > > > the error. > > > > > > HA_BAD_AAA_AUTH: This error is sent by the home agent if the > > > Registration Request contains a Mobile-AAA Authentication extension > > > with an incorrect authenticator that fails verification. A mobile > > > > s/incorrect// > > > > > node that receives a HA_BAD_AAA_AUTH MUST use a new Challenge value > > > in any new registration, obtained either from an Agent Advertisement, > > > or from a Challenge extension to the Registration Reply containing > > > the error. > > > > > > STALE_CHALLENGE: If the foreign agent receives a Registration Request > > > with a Challenge extension containing a Challenge value previously > > > used by that mobile node, the mobile node MAY receive a Registration > > > > s/MAY/may/ > > > > > Reply to the mobile node containing the Code value STALE_CHALLENGE. > > > In such instances, the mobile node MUST use a new Challenge value in > > > next Registration Request, obtained either from an Agent > > > Advertisement, or from a Challenge extension to the Registration > > > Reply containing the error. > > > > > > HA_WRONG_CHALLENGE: This error is sent by the foreign agent if the > > > Registration Reply from the home agent contains a different Challenge > > > value from the one included in the Registration Request. > > > > s/the one/that/ > > > > Repetitiveness in the challenge rules was already taken care of by Jari's > > comments, I believe. > > > > ... > > > > > 4. Mobile-Foreign Challenge Extension > > > > > > This section specifies a new Mobile IP Registration extension that is > > > used to satisfy a Challenge in an Agent Advertisement. The Challenge > > > extension to the Registration Request message is used to indicate the > > > challenge that the mobile node is attempting to satisfy. > > > > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Type | Length | Challenge ... > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > Figure 2: The Mobile-Foreign Challenge Extension > > > > > > Type: > > > > > > 132 (skippable) (see [RFC3344]) > > > > > > Length: > > > > > > Length of the Challenge value > > > > > > Challenge: > > > > > > The Challenge field is copied from the Challenge field found in > > > the Agent Advertisement Challenge extension (see section 2). > > > > s/Agent Advertisement/received/ > > Cuz Agent Advertisements are not the only way to learn a Challenge. > > > > > 5. Generalized Mobile IP Authentication Extension > > > > This really should be a separate document. > > > > > Several new authentication extensions have been designed for various > > > control messages proposed for extensions to Mobile IP. A new > > > authentication extension is required for a mobile node to present its > > > credentials to any other entity other than the ones already defined; > > > the only entities defined in the base Mobile IP specification > > > [RFC3344] are the home agent and the foreign agent. It is the > > > > s/It is/The/ > > > > > purpose of the generalized authentication extension defined here to > > > > s/here to/here is to/ > > > > ... > > > 6. Mobile-AAA Authentication subtype > > > > > > The Generalized Authentication extension with subtype 1 will be > > > referred to as a Mobile-AAA Authentication extension. The mobile > > > node MAY include a Mobile-AAA Authentication extension in any > > > Registration Request. This extension MAY co-exist in the same > > > Registration Request with Authentication extensions defined for > > > Mobile IP Registration by [RFC3344]. If the mobile node does not > > > > s/by// > > > > > include a Mobile-Foreign Authentication [RFC3344] extension, then it > > > > s/[RFC3344]// > > > > > MUST include the Mobile-AAA Authentication extension whenever the > > > Challenge extension is present. If both are present, the Mobile-AAA > > > Authentication extension MUST precede the Mobile-Foreign > > > Authentication extension. > > > > > > If the Mobile-AAA Authentication extension is present, then the > > > Registration Message sent by the mobile node MUST contain the Mobile- > > > Home Authentication extension [RFC3344] if it shares a security > > > > notice this "if" > > > > > association with the home agent. If both are present, the Mobile- > > > > and this "if" as well. > > This means that MN-HA Authentication is no longer a MUST, and that it > > may be absent. I believe this is a departure from rfc 3344, and if so, > > it should be flagged by explicitly saying so. > > > > ... > > > > > 8. SPIs for RADIUS AAA Servers > > > > > > Some AAA servers only admit a single security association, and thus > > > do not use the SPI numbers for Mobile IP authentication extensions > > > for use when determining the security association that would be > > > necessary for verifying the authentication information included with > > > the Authentication extension. > > > > > > SPI number CHAP_SPI (see Section 9) is reserved for indicating the > > > following procedure for computing authentication data (called the > > > "authenticator"), which is used by many RADIUS servers [RFC2138] > > > today. > > > > > > To compute the authenticator, apply MD5 [RFC1321] computed on the > > > following data, in the order shown: > > > > > > High-order byte from Challenge || Key || > > > > > > MD5(Preceding Mobile IP data || > > > > > > Type, Subtype (if present), Length, SPI) || > > > > > > Least-order 237 bytes from Challenge > > > > > > where the Type, Length, SPI, and possibly Subtype, are the fields of > > > the authentication extension in use. For instance, all four of these > > > fields would be in use when SPI == CHAP_SPI is used with the > > > Generalized Authentication extension. Since the RADIUS protocol > > > cannot carry attributes of length greater than 253, the preceding > > > Mobile IP data, type, subtype (if present), length and SPI are hashed > > > using MD5. Finally, the least significant 237 bytes of the challenge > > > are concatenated. If the challenge has fewer than 238 bytes, this > > > algorithm includes the high-order byte in the computation twice, but > > > ensures that the challenge is used exactly as is. Additional padding > > > is never used to increase the length of the challenge; the input data > > > is allowed to be shorter than 237 bytes long. > > > > This draft starts by trying to help the FA, not the MN. so it should at least do > > no harm to the MN. > > > > But this is something that can end up screwing the MN. Any device within RF > > coverage of both can see everything above (including the challenge), except the > > password used in CHAP. Given the weakness to dictionary attacks, an exchange like > > the above effectively blasts the user's password to anybody who cares to listen. > > This shouldn't be recommended. Or am I missing something? > > > > ... > > > > > 9. Configurable Parameters > > > > > > Every Mobile IP agent supporting the extensions defined in this > > > document SHOULD be able to configure each parameter in the following > > > table. Each table entry contains the name of the parameter, the > > > default value, and the section of the document in which the parameter > > > first appears. > > > > > > +------------------+---------------+---------------------+ > > > | Parameter Name | Default Value | Section of Document | > > > +------------------+---------------+---------------------+ > > > | CHALLENGE_WINDOW | 2 | 3.2 | > > > > This has never been explained! And the first time it's mentioned is section 2.1. > > > > > | | | | > > > | CHAP_SPI | 2 | 8 | > > > > First time it's mentioned is section 3.1. > > > > ... > > > > > 10. Error Values > > > > > > Each entry in the following table contains the name of the Code > > > [RFC3344] to be returned in a Registration Reply, the value for the > > > Code, and the section in which the error is first mentioned in this > > > specification. > > > > Why is the first time it's mentioned that important? What should be > > referenced is the section in which it is properly explained (which > > could be forward referenced from wherever it's mentioned for the > > first time). > > > > > > > > +--------------------+-------+--------------------------+ > > > | Error Name | Value | Section of Document | > > > +--------------------+-------+--------------------------+ > > > | UNKNOWN_CHALLENGE | 104 | 3.2 | > > > | | | | > > > | BAD_AUTHENTICATION | 67 | 3.2 - also see [RFC3344] | > > > | | | | > > > | MISSING_CHALLENGE | 105 | 3.1, 3.2 | > > > | | | | > > > | STALE_CHALLENGE | 106 | 3.2 | > > > | | | | > > > | FA_BAD_AAA_AUTH | TBD | 3.2 | > > > | | | | > > > | HA_BAD_AAA_AUTH | TBD | 3.4 | > > > | | | | > > > | HA_WRONG_CHALLENGE | TBD | 3.2 | > > > +--------------------+-------+--------------------------+ > > > > > > Table 2: Error Values > > > > > > > Given the errors seen in the previous table, please double-check all the > > above. > > > > ... > > > > > 12. Security Considerations > > > > > > In the event that a malicious mobile node attempts to replay the > > > authenticator for an old Mobile-Foreign Challenge, the foreign agent > > > would detect it since the agent always checks whether it has recently > > > advertised the Challenge (see Section 3.2). Allowing mobile nodes > > > with different IP addresses or NAIs to use the same Challenge value > > > does not represent a security vulnerability, because the > > > authentication data provided by the mobile node will be computed over > > > data that is different (at least by the bytes of the mobile nodes' IP > > > addresses). > > > > OLD: > > at least by the bytes of the mobile nodes' IP addresses > > > > NEW: > > at least the mobile node's IP address will vary > > > > > > ... > > > > > > > Section 8 (SPI For RADIUS AAA Servers) defines a method of computing > > > the Generalized Mobile IP Authentication Extension's authenticator > > > field using MD5 in a manner that is consistent with RADIUS [RFC2138]. > > > The use of MD5 in the method described in Section 8 is less secure > > > than HMAC-MD5 [RFC2104], and should be avoided whenever possible. > > > > s/should/MUST/ > > But really, this MUST be avoided always, unless there's other (e.g., link-layer > > mechanisms) that can help prevent the dictionary attacks. I guess the latter > > applies throughout to the other methods as well. > > > > > Note that an active attacker may try to prevent successful > > > registrations by sending a large number of Agent Solicitations or > > > bogus Registration Requests, each of which could cause the foreign > > > agent to respond with a fresh challenge, invalidating the challenge > > > that the MN is currently trying to use. To prevent such attacks, the > > > foreign agent MUST NOT invalidate previously unused challenges when > > > responding to unauthenticated Registration Requests or Agent > > > Solicitations. In addition, the foreign agent MUST NOT allocate new > > > storage when responding to such messages, because this would also > > > create the possibility of denial of service. > > > > Should say that it does not seek to provide any assurance to the MN, only > > to the FA and infrastructure. > > > > ... > > > 14. Normative References > > > > > > [FAERR] Perkins, C., "Foreign Agent Error Extension for Mobile > > > IPv4", draft-perkins-mip4-faerr-00.txt (work in progress), > > > January 2004. > > > > Update this reference to the latest version. > > > > ... > > > Authors' Addresses > > ... > > > Pat R. Calhoun > > > Black Storm Networks > > > 110 Nortech Parkway > > > San Jose, CA 95134 > > > > > > Fax: +1 720-293-7501 > > > Email: pcalhoun@diameter.org > > > > Update this info. > > > > > Appendix A. Change History > > > > I like Jari's suggestion to detail the changes with respect to 3012. > > > > ... > > > > > Appendix B. Verification Infrastructure > > ... > > > In order to verify the credentials of the mobile node, we imagine > > > > s/imagine/assume/ > > > > ... > > > > > Appendix C. Message Flow for FA Challenge Messaging with Mobile-AAA > > > Extension > > ... > > > 1. The foreign agent disseminates a Challenge Value in an Agent > > > > s/disseminates/includes/ > > s/an Agent/a unicast Agent/ > > > > ... > > > > > Appendix E. Foreign Agent Algorithm for Tracking Used Challenges > > > > This section is normative, and is where we finally see the explanation > > of how to use CHALLENGE_WINDOW. This should be in the body of the document > > and must not remain in an appendix. > > > > The appendix should only have the pseudo-code example. > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Nov 04 15:01:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY7km-0000Vp-NB; Fri, 04 Nov 2005 15:01:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY7kj-0000Ug-6N for mip4@megatron.ietf.org; Fri, 04 Nov 2005 15:01:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09885 for ; Fri, 4 Nov 2005 15:01:09 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY7zi-0000Td-41 for mip4@ietf.org; Fri, 04 Nov 2005 15:17:07 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA4KDQmJ012394 for ; Fri, 4 Nov 2005 13:13:26 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id jA4KADrQ007783 for ; Fri, 4 Nov 2005 14:10:13 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Fri, 4 Nov 2005 15:00:26 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXhZ5FQh6x6id+QRdiqQhJ12hbZ9AAEHQeQ From: "Nakhjiri Madjid-MNAKHJI1" To: "Pete McCann" , X-Spam-Score: 2.0 (++) X-Scan-Signature: 58f9ad36a39c86859dabf772b2ea7a96 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Pete, Document does have a dual personality, since it partly talks about challenge response procedures that are only used for FA-based cases, but partly also covers MN-AAA AE that is generic for MIP-AAA interaction. For RADIUS-MIP design, We have been running into some problems with the specification provided in this document, since the Authenticator field requires knowledge of the challenge Authenticator =3D MD5( High-order byte from Challenge || Key || MD5(Preceding Mobile IP data || Type, Subtype (if present), Length, SPI) || Least-order 237 bytes from Challenge) Which is not presence in a direct registration through the HA. We did talk to the authors and decided to use 0 instead of challenge for now. However, we feel that the RFC3012 needs to add this fix, not RADIUS-MIP draft. We were planning to bring this to Vancouver for attention.=20 Having said all this I don't think I am advocating for a separation. I can understand the issue with MD5, but not sure that warrants a separation either. Given that many people depend on this spec, urgency is appreciated. Regards, Madjid -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Pete McCann Sent: Friday, November 04, 2005 11:41 AM To: itijibox-mip4@yahoo.com Cc: mip4@ietf.org Subject: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt We didn't get any followup to Gabriel's review here. How does the group feel about splitting 3012bis into two documents? -Pete gabriel montenegro writes: > I reviewed this document. I feel it is not quite RFC quality, being a bit confusing > and verbose/repetitive in sections. A big issue > I have is that it is really two different things bunched together: > =09 > - Challenge/Response extention > - Generalized Authentication Extension > > They really should be two documents, specially cuz this is a revision, the proper > opportunity to make such changes. > > I'm also wondering about the use of MD5 throughout. Given recent developments, some > folks (not unanimously, though) are already calling for the deprecation of > SHA-1, and here we are recommending MD5 for a proposed standard? If this is what's > being used today, then this could be published as a historical or informational RFC, > If the intent is to fix a few bugs in rfc 3012, perhaps the errata page is enough. > But the use of MD5 should be reviewed by the security ADs. CHAP should also be avoided, > due to its vulnerability to dictionary attacks. > For example, EAP advices against its usage (see rfc3748 section 7.6). Even more > explicitly, the EAP requirements for wireless usage call for mandatory > resistance to dictionary attacks: http://www.faqs.org/rfcs/rfc4017.html, section 2.2. > > This comment applies to 3344bis as well. > > Nit: saw "processing for" in several places. Shouldn't it be "processing of"? > > Other comments interspersed below. > > > > > > >=20 > > Network Working Group Charles E. Perkins > > Internet-Draft Nokia Research Center > > Expires: December 19, 2005 Pat R. Calhoun > > Black Storm Networks > > Jayshree. Bharatia > > Nortel Networks > > June 17, 2005 > > Please update the author contact information now, instead of waiting for AUTH48. > > ... > > Abstract > > > ... >=20 > > Furthermore, this document updates RFC3344 by including new > > authentication extension called the Mobile-AAA Authentication > > extension. This new extension is provided so that a mobile node can > > supply credentials for authorization using commonly available AAA > > infrastructure elements. This Authorization-enabling extension MAY > > co-exist in the same Registration Request with Authentication > > extensions defined for Mobile IP Registration by RFC3344. This > > document obsoletes RFC3012. >=20 > This should be a separate document. =20 > > ... > > > 1. Introduction > >=20 > > Mobile IP defines the Mobile-Foreign Authentication extension to > > allow a mobile node to authenticate itself to a foreign agent. Such > > It can provide *mutual* authentication, right? Suggest making it explicit here > precisely because this extension differs in that it is unilateral. It does not aid the > MN in establishing legitimacy of the FA; only the opposite is true. >=20 > > authentication mechanisms are mostly external to the principal > > operation of Mobile IP, since the foreign agent can easily route > > packets to and from a mobile node whether or not the mobile node is > > reporting a legitimately owned home address to the foreign agent. > > Unfortunately, that extension does not provide the foreign agent any > > direct guarantee that the protocol is protected from replays, and > > does not allow for the use of CHAP [RFC1994] for authenticating > > See above comments on CHAP. Shouldn't be a motivation for a new PS document. > > ... > > 2. Mobile IP Agent Advertisement Challenge Extension > > The organization of this section (describing a format), followed by the next section > on operation, followed by other sections (4 and 5) on packet formats is very > confusing. Suggest having all the packet formats bunched together, following each other.=20 > Also suggest preceding them by some section on overview of operation (perhaps section 3 > itself. > > ... > >=20 > > The Challenge extension, illustrated in Figure 1, is inserted in the > > Agent Advertisements by the foreign agent, in order to communicate a > > previously unused challenge value that can be used by the mobile node > > to compute an authentication for its next registration request > > message. The challenge is selected by the foreign agent to provide > > local assurance that the mobile node is not replaying any earlier > > registration request. Eastlake, et al. [RFC1750] provides more > > information on generating pseudo-random numbers suitable for use as > > values for the challenge. > > Perhaps clarify that the transport of these is unicast. > > > 2.1 Handling of Solicited Agent Advertisements > ... > > advertised Challenges. It must instead re-use the most recent of the > > CHALLENGE_WINDOW Advertisement Challenge values. > > This is the first time this is mentioned, and it is not explained. It is > mentioned several times afterwards, but is never really explained until the > appendices. Explanation or at least a reference to the proper section > should accompany the first reference. > > > 3. Operation > >=20 > > This section describes modifications to the Mobile IP registration > > process [RFC3344] which may occur after the foreign agent issues a > > Mobile IP Agent Advertisement containing the Challenge on its local > > Given that Agent Advertisements can be multicast, I'd clarify here that > these are unicast. > > ... > > > 3.2 Foreign Agent Processing for Registration Requests > > Perhaps s/for/of/ > E.g., 3344 uses "processing of" but never "processing for" > > >=20 > > Upon receipt of the Registration Request, if the foreign agent has > > issued a Challenge as part of its Agent Advertisements, and it does > > s/and it/and if it/ > > ... >=20 > > unless the Registration Reply has already been > > received from the home agent. In this case the foreign agent MUST > > preserve the value of the Code field set by the home agent and MUST > > put its own rejection code only in the Status field of the FA Error > > extension (defined in [FAERR]). > > The above does not belong here, but in the next section (3.3) on handling > Registration Replies. > > s/code only in/code in/ > > ... > > with Code value FA_BAD_AAA_AUTH. If the Mobile-AAA Authentication > > Extension is present in the Registration Request, the foreign agent > > MUST NOT remove the Mobile-AAA Authentication Extension and the > > Mobile-Foreign Challenge Extension from the Registration Request. > > s/Request./Request, before forwarding to the Home Agent./ >=20 > > Appendix C provides an example of an action that could be taken by a > > foreign agent. > >=20 > > In the event that the Challenge extension is authenticated through > > the Mobile-Foreign Authentication extension and the Mobile-AAA > > Authentication extension is not present, the foreign agent MAY remove > > the Challenge Extension from the Registration Request without > > disturbing the authentication value computed by the mobile node for > > use by the AAA or the home agent. =20 > > Sometimes "Challenge extension" and sometimes "Challenge Extension" > Please double-check throughout to make sure capitalization is consistent. > > "use by the AAA" is confusing as it was just said that this case has no > AAA, so perhaps clarifying text could be added: > > s/home agent./home agent, the former because it is not present, the latter > because its calculation does not include the Challenge Extension. > > Or one could reword, of course... > > ... >=20 > > If the foreign agent does not remove the Challenge extension, then > > the foreign agent SHOULD store the Challenge value as part of the > > notice the should here. But what if it's not stored? See below. >=20 > > pending registration request list [RFC3344]. Also, if the > > Registration Reply coming from the home agent does not include the > > Challenge Extension, the foreign agent SHOULD NOT reject the > > Registration Request message. If the Challenge Extension is present > > in the Registration Reply, it MUST be the same Challenge value that > > was included in the Registration Request. If the Challenge value > > differs in the Registration Reply received from the home agent, the > > foreign agent MUST insert an FA Error extension with Status value > > HA_WRONG_CHALLENGE in the Registration Reply sent to the mobile node > > (see Section 10). > > The above section does not belong here but in the next section on Registration > Replies. Mixing section contents like this makes things very confusing. > > Above, notice the MUST be the same Challenge value. But if the value was not > stored (as allowed by the SHOULD above), then what happens? The error recovery > and error status value above does not take that into account. > =20 > > If the foreign agent does remove the Challenge extension and > > applicable authentication from the Registration Request message, then > > it SHOULD insert the Identification field from the Registration > > s/insert/store/ >=20 > > Request message along with its record-keeping information about the > > s/along with/as part of/ >=20 > > particular mobile node in order to protect against replays. > > > > 3.3 Foreign Agent Processing for Registration Replies > > s/for/of/ > > ... > > If the foreign agent receives a Registration Reply with the Code > > value HA_BAD_AAA_AUTH, it MUST be relayed to the mobile node. > > Presumably, regardless of code value, the Reg Reply must be relayed, > yes? If so, why is this here? Suggest deleting the above as it is > redundant. In general, there seems to be a lot of repetition. One > reads them carefully expecting there to be an exception to a rule, > but there is none, so it's just tiring. > > > 3.4 Home Agent Processing for the Challenge Extensions > ... >=20 > > The home agent MAY receive a Registration Request with the Mobile-AAA > > s/MAY/may/ > > Does not seem prescriptive but merely describing an eventuality, so I don't > think we need rfc 2026 language here. > > > 3.5 Mobile Node Processing for Registration Replies > ... > > UNKNOWN_CHALLENGE: This error code is received by the mobile node in > > the case where the mobile node has moved to a new foreign agent that > > s/in the case where the mobile node/if it/ >=20 > > MISSING_CHALLENGE: A mobile node that does not include a Challenge > > when the Mobile-Foreign Authentication extension is present may > > receive a MISSING_CHALLENGE error. In this case, the mobile node > > SHOULD send a Challenge extension containing an unused challenge in > > the next Registration Request. > >=20 > > BAD_AUTHENTICATION: This error is sent by the foreign agent if the > > Registration Request contains a Mobile-Foreign Authentication > > extension with an incorrect authenticator that fails verification. A > > mobile node that receives a BAD_AUTHENTICATION Code value SHOULD > > include the Mobile-AAA Authentication Extension in the next > > Registration Request. This will make it possible for the Foreign > > Agent to use its AAA infrastructure in order to authenticate the > > mobile node. In this case, the mobile node MUST use a new Challenge > > value in any new registration, obtained either from an Agent > > Advertisement, or from a Challenge extension to the Registration > > Reply containing the error. > >=20 > > FA_BAD_AAA_AUTH: This error is sent by the foreign agent if the > > Registration Request contains a Mobile-AAA Authentication extension > > with an incorrect authenticator that fails verification. A mobile > > node that receives a FA_BAD_AAA_AUTH MUST use a new Challenge value > > in any new registration, obtained either from an Agent Advertisement, > > or from a Challenge extension to the Registration Reply containing > > the error. > >=20 > > HA_BAD_AAA_AUTH: This error is sent by the home agent if the > > Registration Request contains a Mobile-AAA Authentication extension > > with an incorrect authenticator that fails verification. A mobile > > s/incorrect// >=20 > > node that receives a HA_BAD_AAA_AUTH MUST use a new Challenge value > > in any new registration, obtained either from an Agent Advertisement, > > or from a Challenge extension to the Registration Reply containing > > the error. > >=20 > > STALE_CHALLENGE: If the foreign agent receives a Registration Request > > with a Challenge extension containing a Challenge value previously > > used by that mobile node, the mobile node MAY receive a Registration > > s/MAY/may/ >=20 > > Reply to the mobile node containing the Code value STALE_CHALLENGE. > > In such instances, the mobile node MUST use a new Challenge value in > > next Registration Request, obtained either from an Agent > > Advertisement, or from a Challenge extension to the Registration > > Reply containing the error. > >=20 > > HA_WRONG_CHALLENGE: This error is sent by the foreign agent if the > > Registration Reply from the home agent contains a different Challenge > > value from the one included in the Registration Request. > > s/the one/that/ > > Repetitiveness in the challenge rules was already taken care of by Jari's > comments, I believe.=20 > > ... > > > 4. Mobile-Foreign Challenge Extension > >=20 > > This section specifies a new Mobile IP Registration extension that is > > used to satisfy a Challenge in an Agent Advertisement. The Challenge > > extension to the Registration Request message is used to indicate the > > challenge that the mobile node is attempting to satisfy. > >=20 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length | Challenge ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >=20 > > Figure 2: The Mobile-Foreign Challenge Extension > >=20 > > Type: > >=20 > > 132 (skippable) (see [RFC3344]) > >=20 > > Length: > >=20 > > Length of the Challenge value > >=20 > > Challenge: > >=20 > > The Challenge field is copied from the Challenge field found in > > the Agent Advertisement Challenge extension (see section 2). > > s/Agent Advertisement/received/ > Cuz Agent Advertisements are not the only way to learn a Challenge. > > > 5. Generalized Mobile IP Authentication Extension > > This really should be a separate document. >=20 > > Several new authentication extensions have been designed for various > > control messages proposed for extensions to Mobile IP. A new > > authentication extension is required for a mobile node to present its > > credentials to any other entity other than the ones already defined; > > the only entities defined in the base Mobile IP specification > > [RFC3344] are the home agent and the foreign agent. It is the > > s/It is/The/ >=20 > > purpose of the generalized authentication extension defined here to > > s/here to/here is to/ > > ... > > 6. Mobile-AAA Authentication subtype > >=20 > > The Generalized Authentication extension with subtype 1 will be > > referred to as a Mobile-AAA Authentication extension. The mobile > > node MAY include a Mobile-AAA Authentication extension in any > > Registration Request. This extension MAY co-exist in the same > > Registration Request with Authentication extensions defined for > > Mobile IP Registration by [RFC3344]. If the mobile node does not > > s/by// >=20 > > include a Mobile-Foreign Authentication [RFC3344] extension, then it > > s/[RFC3344]// >=20 > > MUST include the Mobile-AAA Authentication extension whenever the > > Challenge extension is present. If both are present, the Mobile-AAA > > Authentication extension MUST precede the Mobile-Foreign > > Authentication extension. > >=20 > > If the Mobile-AAA Authentication extension is present, then the > > Registration Message sent by the mobile node MUST contain the Mobile- > > Home Authentication extension [RFC3344] if it shares a security > > notice this "if" >=20 > > association with the home agent. If both are present, the Mobile- > > and this "if" as well. > This means that MN-HA Authentication is no longer a MUST, and that it > may be absent. I believe this is a departure from rfc 3344, and if so, > it should be flagged by explicitly saying so.=20 > > ... > > > 8. SPIs for RADIUS AAA Servers > >=20 > > Some AAA servers only admit a single security association, and thus > > do not use the SPI numbers for Mobile IP authentication extensions > > for use when determining the security association that would be > > necessary for verifying the authentication information included with > > the Authentication extension. > >=20 > > SPI number CHAP_SPI (see Section 9) is reserved for indicating the > > following procedure for computing authentication data (called the > > "authenticator"), which is used by many RADIUS servers [RFC2138] > > today. > >=20 > > To compute the authenticator, apply MD5 [RFC1321] computed on the > > following data, in the order shown: > >=20 > > High-order byte from Challenge || Key || > >=20 > > MD5(Preceding Mobile IP data || > >=20 > > Type, Subtype (if present), Length, SPI) || > >=20 > > Least-order 237 bytes from Challenge > >=20 > > where the Type, Length, SPI, and possibly Subtype, are the fields of > > the authentication extension in use. For instance, all four of these > > fields would be in use when SPI =3D=3D CHAP_SPI is used with the > > Generalized Authentication extension. Since the RADIUS protocol > > cannot carry attributes of length greater than 253, the preceding > > Mobile IP data, type, subtype (if present), length and SPI are hashed > > using MD5. Finally, the least significant 237 bytes of the challenge > > are concatenated. If the challenge has fewer than 238 bytes, this > > algorithm includes the high-order byte in the computation twice, but > > ensures that the challenge is used exactly as is. Additional padding > > is never used to increase the length of the challenge; the input data > > is allowed to be shorter than 237 bytes long. > > This draft starts by trying to help the FA, not the MN. so it should at least do > no harm to the MN.=20 > > But this is something that can end up screwing the MN. Any device within RF > coverage of both can see everything above (including the challenge), except the > password used in CHAP. Given the weakness to dictionary attacks, an exchange like > the above effectively blasts the user's password to anybody who cares to listen. > This shouldn't be recommended. Or am I missing something? > > ... > > > 9. Configurable Parameters > >=20 > > Every Mobile IP agent supporting the extensions defined in this > > document SHOULD be able to configure each parameter in the following > > table. Each table entry contains the name of the parameter, the > > default value, and the section of the document in which the parameter > > first appears. > >=20 > > +------------------+---------------+---------------------+ > > | Parameter Name | Default Value | Section of Document | > > +------------------+---------------+---------------------+ > > | CHALLENGE_WINDOW | 2 | 3.2 | > > This has never been explained! And the first time it's mentioned is section 2.1. >=20 > > | | | | > > | CHAP_SPI | 2 | 8 | > > First time it's mentioned is section 3.1. > > ... > > > 10. Error Values > >=20 > > Each entry in the following table contains the name of the Code > > [RFC3344] to be returned in a Registration Reply, the value for the > > Code, and the section in which the error is first mentioned in this > > specification. > > Why is the first time it's mentioned that important? What should be > referenced is the section in which it is properly explained (which > could be forward referenced from wherever it's mentioned for the > first time). > > >=20 > > +--------------------+-------+--------------------------+ > > | Error Name | Value | Section of Document | > > +--------------------+-------+--------------------------+ > > | UNKNOWN_CHALLENGE | 104 | 3.2 | > > | | | | > > | BAD_AUTHENTICATION | 67 | 3.2 - also see [RFC3344] | > > | | | | > > | MISSING_CHALLENGE | 105 | 3.1, 3.2 | > > | | | | > > | STALE_CHALLENGE | 106 | 3.2 | > > | | | | > > | FA_BAD_AAA_AUTH | TBD | 3.2 | > > | | | | > > | HA_BAD_AAA_AUTH | TBD | 3.4 | > > | | | | > > | HA_WRONG_CHALLENGE | TBD | 3.2 | > > +--------------------+-------+--------------------------+ > >=20 > > Table 2: Error Values > > > > Given the errors seen in the previous table, please double-check all the > above. > > ... > > > 12. Security Considerations > >=20 > > In the event that a malicious mobile node attempts to replay the > > authenticator for an old Mobile-Foreign Challenge, the foreign agent > > would detect it since the agent always checks whether it has recently > > advertised the Challenge (see Section 3.2). Allowing mobile nodes > > with different IP addresses or NAIs to use the same Challenge value > > does not represent a security vulnerability, because the > > authentication data provided by the mobile node will be computed over > > data that is different (at least by the bytes of the mobile nodes' IP > > addresses). > > OLD: > at least by the bytes of the mobile nodes' IP addresses > > NEW: > at least the mobile node's IP address will vary > > > ... > >=20 > > Section 8 (SPI For RADIUS AAA Servers) defines a method of computing > > the Generalized Mobile IP Authentication Extension's authenticator > > field using MD5 in a manner that is consistent with RADIUS [RFC2138]. > > The use of MD5 in the method described in Section 8 is less secure > > than HMAC-MD5 [RFC2104], and should be avoided whenever possible. > > s/should/MUST/ > But really, this MUST be avoided always, unless there's other (e.g., link-layer > mechanisms) that can help prevent the dictionary attacks. I guess the latter > applies throughout to the other methods as well. >=20 > > Note that an active attacker may try to prevent successful > > registrations by sending a large number of Agent Solicitations or > > bogus Registration Requests, each of which could cause the foreign > > agent to respond with a fresh challenge, invalidating the challenge > > that the MN is currently trying to use. To prevent such attacks, the > > foreign agent MUST NOT invalidate previously unused challenges when > > responding to unauthenticated Registration Requests or Agent > > Solicitations. In addition, the foreign agent MUST NOT allocate new > > storage when responding to such messages, because this would also > > create the possibility of denial of service. > > Should say that it does not seek to provide any assurance to the MN, only > to the FA and infrastructure. > > ... > > 14. Normative References > >=20 > > [FAERR] Perkins, C., "Foreign Agent Error Extension for Mobile > > IPv4", draft-perkins-mip4-faerr-00.txt (work in progress), > > January 2004. > > Update this reference to the latest version. > > ... > > Authors' Addresses > ... > > Pat R. Calhoun > > Black Storm Networks > > 110 Nortech Parkway > > San Jose, CA 95134 > >=20 > > Fax: +1 720-293-7501 > > Email: pcalhoun@diameter.org > > Update this info. > > > Appendix A. Change History > > I like Jari's suggestion to detail the changes with respect to 3012. > > ... > > > Appendix B. Verification Infrastructure > ... > > In order to verify the credentials of the mobile node, we imagine > > s/imagine/assume/ > > ... > > > Appendix C. Message Flow for FA Challenge Messaging with Mobile-AAA > > Extension > ... > > 1. The foreign agent disseminates a Challenge Value in an Agent > > s/disseminates/includes/ > s/an Agent/a unicast Agent/ > > ... > > > Appendix E. Foreign Agent Algorithm for Tracking Used Challenges > > This section is normative, and is where we finally see the explanation > of how to use CHALLENGE_WINDOW. This should be in the body of the document > and must not remain in an appendix. > > The appendix should only have the pseudo-code example. > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Nov 04 15:03:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY7mB-0000gk-1S; Fri, 04 Nov 2005 15:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY7m9-0000gf-In for mip4@megatron.ietf.org; Fri, 04 Nov 2005 15:03:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09963 for ; Fri, 4 Nov 2005 15:02:38 -0500 (EST) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY81C-0000Wc-9h for mip4@ietf.org; Fri, 04 Nov 2005 15:18:35 -0500 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id jA4KIR9R022680 for ; Fri, 4 Nov 2005 13:18:27 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id jA4KCYFu010795 for ; Fri, 4 Nov 2005 14:12:35 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Fri, 4 Nov 2005 15:02:05 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXhaOL5NXrW+qO4SIiBiSFVBURA7AAEZ43A From: "Nakhjiri Madjid-MNAKHJI1" To: "Charles E. Perkins" , "Pete McCann" X-Spam-Score: 2.0 (++) X-Scan-Signature: 58a894dbf8d0c4c152ea0be9e8cd3d14 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org We know that never happens in IETF :) ( :) means sarcasm)=20 -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Charles E. Perkins Sent: Friday, November 04, 2005 11:52 AM To: Pete McCann Cc: mip4@ietf.org; itijibox-mip4@yahoo.com Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Hello folks, This document has been essentially ready to go for over a year. How much longer will it take if we start from scratch with two documents? Maybe next year someone will demand that we merge them again. Regards, Charlie P. Pete McCann wrote: >We didn't get any followup to Gabriel's review here. How does the=20 >group feel about splitting 3012bis into two documents? > >-Pete > >gabriel montenegro writes: > > I reviewed this document. I feel it is not quite RFC quality, being=20 > > a bit confusing and verbose/repetitive in sections. A big issue I=20 > > have is that it is really two different things bunched together: > > =09 > > - Challenge/Response extention > > - Generalized Authentication Extension > >=20 > > They really should be two documents, specially cuz this is a=20 > > revision, the proper opportunity to make such changes. > >=20 > > I'm also wondering about the use of MD5 throughout. Given recent=20 > > developments, some folks (not unanimously, though) are already=20 > > calling for the deprecation of SHA-1, and here we are recommending=20 > > MD5 for a proposed standard? If this is what's being used today,=20 > > then this could be published as a historical or informational RFC, If the intent is to fix a few bugs in rfc 3012, perhaps the errata page is enough. > > But the use of MD5 should be reviewed by the security ADs. CHAP=20 > > should also be avoided, due to its vulnerability to dictionary attacks. > > For example, EAP advices against its usage (see rfc3748 section=20 > > 7.6). Even more explicitly, the EAP requirements for wireless usage=20 > > call for mandatory resistance to dictionary attacks: http://www.faqs.org/rfcs/rfc4017.html, section 2.2. > >=20 > > This comment applies to 3344bis as well. > >=20 > > Nit: saw "processing for" in several places. Shouldn't it be "processing of"? > >=20 > > Other comments interspersed below. > >=20 > > >=20 > > >=20 > > >=20 > > > Network Working Group Charles E. Perkins > > > Internet-Draft Nokia Research Center > > > Expires: December 19, 2005 Pat R. Calhoun > > > Black Storm Networks > > > Jayshree. Bharatia > > > Nortel Networks > > > June=20 > > > 17, 2005 > >=20 > > Please update the author contact information now, instead of waiting for AUTH48. > >=20 > > ... > > > Abstract > > >=20 > > ... > >=20 > > > Furthermore, this document updates RFC3344 by including new > > > authentication extension called the Mobile-AAA Authentication > > > extension. This new extension is provided so that a mobile node can > > > supply credentials for authorization using commonly available AAA > > > infrastructure elements. This Authorization-enabling extension MAY > > > co-exist in the same Registration Request with Authentication > > > extensions defined for Mobile IP Registration by RFC3344. This > > > document obsoletes RFC3012. > >=20 > > This should be a separate document. =20 > >=20 > > ... > >=20 > > > 1. Introduction > > >=20 > > > Mobile IP defines the Mobile-Foreign Authentication extension to > > > allow a mobile node to authenticate itself to a foreign agent. > > > Such > >=20 > > It can provide *mutual* authentication, right? Suggest making it=20 > > explicit here precisely because this extension differs in that it is > > unilateral. It does not aid the MN in establishing legitimacy of the FA; only the opposite is true. > >=20 > > > authentication mechanisms are mostly external to the principal > > > operation of Mobile IP, since the foreign agent can easily route > > > packets to and from a mobile node whether or not the mobile node is > > > reporting a legitimately owned home address to the foreign agent. > > > Unfortunately, that extension does not provide the foreign agent any > > > direct guarantee that the protocol is protected from replays, and > > > does not allow for the use of CHAP [RFC1994] for authenticating > >=20 > > See above comments on CHAP. Shouldn't be a motivation for a new PS document. > >=20 > > ... > > > 2. Mobile IP Agent Advertisement Challenge Extension > >=20 > > The organization of this section (describing a format), followed by=20 > > the next section on operation, followed by other sections (4 and 5)=20 > > on packet formats is very confusing. Suggest having all the packet formats bunched together, following each other. > > Also suggest preceding them by some section on overview of operation > > (perhaps section 3 itself. > >=20 > > ... > > >=20 > > > The Challenge extension, illustrated in Figure 1, is inserted in the > > > Agent Advertisements by the foreign agent, in order to communicate a > > > previously unused challenge value that can be used by the mobile node > > > to compute an authentication for its next registration request > > > message. The challenge is selected by the foreign agent to provide > > > local assurance that the mobile node is not replaying any earlier > > > registration request. Eastlake, et al. [RFC1750] provides more > > > information on generating pseudo-random numbers suitable for use as > > > values for the challenge. > >=20 > > Perhaps clarify that the transport of these is unicast. > >=20 > > > 2.1 Handling of Solicited Agent Advertisements > > ... > > > advertised Challenges. It must instead re-use the most recent of the > > > CHALLENGE_WINDOW Advertisement Challenge values. > >=20 > > This is the first time this is mentioned, and it is not explained.=20 > > It is mentioned several times afterwards, but is never really=20 > > explained until the appendices. Explanation or at least a reference=20 > > to the proper section should accompany the first reference. > >=20 > > > 3. Operation > > >=20 > > > This section describes modifications to the Mobile IP registration > > > process [RFC3344] which may occur after the foreign agent issues a > > > Mobile IP Agent Advertisement containing the Challenge on its=20 > > > local > >=20 > > Given that Agent Advertisements can be multicast, I'd clarify here=20 > > that these are unicast. > >=20 > > ... > > =20 > > > 3.2 Foreign Agent Processing for Registration Requests > >=20 > > Perhaps s/for/of/ > > E.g., 3344 uses "processing of" but never "processing for" > >=20 > > >=20 > > > Upon receipt of the Registration Request, if the foreign agent has > > > issued a Challenge as part of its Agent Advertisements, and it=20 > > > does > >=20 > > s/and it/and if it/ > >=20 > > ... > >=20 > > > unless the Registration Reply has already been > > > received from the home agent. In this case the foreign agent MUST > > > preserve the value of the Code field set by the home agent and MUST > > > put its own rejection code only in the Status field of the FA Error > > > extension (defined in [FAERR]). > >=20 > > The above does not belong here, but in the next section (3.3) on=20 > > handling Registration Replies. > >=20 > > s/code only in/code in/ > >=20 > > ... > > > with Code value FA_BAD_AAA_AUTH. If the Mobile-AAA Authentication > > > Extension is present in the Registration Request, the foreign agent > > > MUST NOT remove the Mobile-AAA Authentication Extension and the > > > Mobile-Foreign Challenge Extension from the Registration Request. > >=20 > > s/Request./Request, before forwarding to the Home Agent./ > >=20 > > > Appendix C provides an example of an action that could be taken by a > > > foreign agent. > > >=20 > > > In the event that the Challenge extension is authenticated through > > > the Mobile-Foreign Authentication extension and the Mobile-AAA > > > Authentication extension is not present, the foreign agent MAY remove > > > the Challenge Extension from the Registration Request without > > > disturbing the authentication value computed by the mobile node for > > > use by the AAA or the home agent. =20 > >=20 > > Sometimes "Challenge extension" and sometimes "Challenge Extension" > > Please double-check throughout to make sure capitalization is consistent. > >=20 > > "use by the AAA" is confusing as it was just said that this case has > > no AAA, so perhaps clarifying text could be added: > >=20 > > s/home agent./home agent, the former because it is not present, the=20 > > latter because its calculation does not include the Challenge Extension. > >=20 > > Or one could reword, of course... > >=20 > > ... > >=20 > > > If the foreign agent does not remove the Challenge extension, then > > > the foreign agent SHOULD store the Challenge value as part of=20 > > > the > >=20 > > notice the should here. But what if it's not stored? See below. > >=20 > > > pending registration request list [RFC3344]. Also, if the > > > Registration Reply coming from the home agent does not include the > > > Challenge Extension, the foreign agent SHOULD NOT reject the > > > Registration Request message. If the Challenge Extension is present > > > in the Registration Reply, it MUST be the same Challenge value that > > > was included in the Registration Request. If the Challenge value > > > differs in the Registration Reply received from the home agent, the > > > foreign agent MUST insert an FA Error extension with Status value > > > HA_WRONG_CHALLENGE in the Registration Reply sent to the mobile node > > > (see Section 10). > >=20 > > The above section does not belong here but in the next section on=20 > > Registration Replies. Mixing section contents like this makes things very confusing. > >=20 > > Above, notice the MUST be the same Challenge value. But if the value > > was not stored (as allowed by the SHOULD above), then what happens?=20 > > The error recovery and error status value above does not take that into account. > > =20 > > > If the foreign agent does remove the Challenge extension and > > > applicable authentication from the Registration Request message, then > > > it SHOULD insert the Identification field from the Registration > >=20 > > s/insert/store/ > >=20 > > > Request message along with its record-keeping information about > > > the > >=20 > > s/along with/as part of/ > >=20 > > > particular mobile node in order to protect against replays. > > >=20 > > > 3.3 Foreign Agent Processing for Registration Replies > >=20 > > s/for/of/ > >=20 > > ... > > > If the foreign agent receives a Registration Reply with the Code > > > value HA_BAD_AAA_AUTH, it MUST be relayed to the mobile node. > >=20 > > Presumably, regardless of code value, the Reg Reply must be relayed, > > yes? If so, why is this here? Suggest deleting the above as it is=20 > > redundant. In general, there seems to be a lot of repetition. One=20 > > reads them carefully expecting there to be an exception to a rule,=20 > > but there is none, so it's just tiring. > >=20 > > > 3.4 Home Agent Processing for the Challenge Extensions > > ... > >=20 > > > The home agent MAY receive a Registration Request with the=20 > > > Mobile-AAA > >=20 > > s/MAY/may/ > >=20 > > Does not seem prescriptive but merely describing an eventuality, so=20 > > I don't think we need rfc 2026 language here. > >=20 > > > 3.5 Mobile Node Processing for Registration Replies > > ... > > > UNKNOWN_CHALLENGE: This error code is received by the mobile node in > > > the case where the mobile node has moved to a new foreign agent > > > that > >=20 > > s/in the case where the mobile node/if it/ > >=20 > > > MISSING_CHALLENGE: A mobile node that does not include a Challenge > > > when the Mobile-Foreign Authentication extension is present may > > > receive a MISSING_CHALLENGE error. In this case, the mobile node > > > SHOULD send a Challenge extension containing an unused challenge in > > > the next Registration Request. > > >=20 > > > BAD_AUTHENTICATION: This error is sent by the foreign agent if the > > > Registration Request contains a Mobile-Foreign Authentication > > > extension with an incorrect authenticator that fails verification. A > > > mobile node that receives a BAD_AUTHENTICATION Code value SHOULD > > > include the Mobile-AAA Authentication Extension in the next > > > Registration Request. This will make it possible for the Foreign > > > Agent to use its AAA infrastructure in order to authenticate the > > > mobile node. In this case, the mobile node MUST use a new Challenge > > > value in any new registration, obtained either from an Agent > > > Advertisement, or from a Challenge extension to the Registration > > > Reply containing the error. > > >=20 > > > FA_BAD_AAA_AUTH: This error is sent by the foreign agent if the > > > Registration Request contains a Mobile-AAA Authentication extension > > > with an incorrect authenticator that fails verification. A mobile > > > node that receives a FA_BAD_AAA_AUTH MUST use a new Challenge value > > > in any new registration, obtained either from an Agent Advertisement, > > > or from a Challenge extension to the Registration Reply containing > > > the error. > > >=20 > > > HA_BAD_AAA_AUTH: This error is sent by the home agent if the > > > Registration Request contains a Mobile-AAA Authentication extension > > > with an incorrect authenticator that fails verification. A=20 > > > mobile > >=20 > > s/incorrect// > >=20 > > > node that receives a HA_BAD_AAA_AUTH MUST use a new Challenge value > > > in any new registration, obtained either from an Agent Advertisement, > > > or from a Challenge extension to the Registration Reply containing > > > the error. > > >=20 > > > STALE_CHALLENGE: If the foreign agent receives a Registration Request > > > with a Challenge extension containing a Challenge value previously > > > used by that mobile node, the mobile node MAY receive a=20 > > > Registration > >=20 > > s/MAY/may/ > >=20 > > > Reply to the mobile node containing the Code value STALE_CHALLENGE. > > > In such instances, the mobile node MUST use a new Challenge value in > > > next Registration Request, obtained either from an Agent > > > Advertisement, or from a Challenge extension to the Registration > > > Reply containing the error. > > >=20 > > > HA_WRONG_CHALLENGE: This error is sent by the foreign agent if the > > > Registration Reply from the home agent contains a different Challenge > > > value from the one included in the Registration Request. > >=20 > > s/the one/that/ > >=20 > > Repetitiveness in the challenge rules was already taken care of by=20 > > Jari's comments, I believe. > > =20 > > ... > >=20 > > > 4. Mobile-Foreign Challenge Extension > > >=20 > > > This section specifies a new Mobile IP Registration extension that is > > > used to satisfy a Challenge in an Agent Advertisement. The Challenge > > > extension to the Registration Request message is used to indicate the > > > challenge that the mobile node is attempting to satisfy. > > >=20 > > > 0 1 2 3 > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | Type | Length | Challenge ... > > > =20 > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >=20 > > > Figure 2: The Mobile-Foreign Challenge Extension > > >=20 > > > Type: > > >=20 > > > 132 (skippable) (see [RFC3344]) > > >=20 > > > Length: > > >=20 > > > Length of the Challenge value > > >=20 > > > Challenge: > > >=20 > > > The Challenge field is copied from the Challenge field found in > > > the Agent Advertisement Challenge extension (see section 2). > >=20 > > s/Agent Advertisement/received/ > > Cuz Agent Advertisements are not the only way to learn a Challenge. > >=20 > > > 5. Generalized Mobile IP Authentication Extension > >=20 > > This really should be a separate document. > >=20 > > > Several new authentication extensions have been designed for various > > > control messages proposed for extensions to Mobile IP. A new > > > authentication extension is required for a mobile node to present its > > > credentials to any other entity other than the ones already defined; > > > the only entities defined in the base Mobile IP specification > > > [RFC3344] are the home agent and the foreign agent. It is the > >=20 > > s/It is/The/ > >=20 > > > purpose of the generalized authentication extension defined=20 > > > here to > >=20 > > s/here to/here is to/ > >=20 > > ... > > > 6. Mobile-AAA Authentication subtype > > >=20 > > > The Generalized Authentication extension with subtype 1 will be > > > referred to as a Mobile-AAA Authentication extension. The mobile > > > node MAY include a Mobile-AAA Authentication extension in any > > > Registration Request. This extension MAY co-exist in the same > > > Registration Request with Authentication extensions defined for > > > Mobile IP Registration by [RFC3344]. If the mobile node does=20 > > > not > >=20 > > s/by// > >=20 > > > include a Mobile-Foreign Authentication [RFC3344] extension,=20 > > > then it > >=20 > > s/[RFC3344]// > >=20 > > > MUST include the Mobile-AAA Authentication extension whenever the > > > Challenge extension is present. If both are present, the Mobile-AAA > > > Authentication extension MUST precede the Mobile-Foreign > > > Authentication extension. > > >=20 > > > If the Mobile-AAA Authentication extension is present, then the > > > Registration Message sent by the mobile node MUST contain the Mobile- > > > Home Authentication extension [RFC3344] if it shares a security > >=20 > > notice this "if" > >=20 > > > association with the home agent. If both are present, the=20 > > > Mobile- > >=20 > > and this "if" as well. > > This means that MN-HA Authentication is no longer a MUST, and that=20 > > it may be absent. I believe this is a departure from rfc 3344, and=20 > > if so, it should be flagged by explicitly saying so. > >=20 > > ... > >=20 > > > 8. SPIs for RADIUS AAA Servers > > >=20 > > > Some AAA servers only admit a single security association, and thus > > > do not use the SPI numbers for Mobile IP authentication extensions > > > for use when determining the security association that would be > > > necessary for verifying the authentication information included with > > > the Authentication extension. > > >=20 > > > SPI number CHAP_SPI (see Section 9) is reserved for indicating the > > > following procedure for computing authentication data (called the > > > "authenticator"), which is used by many RADIUS servers [RFC2138] > > > today. > > >=20 > > > To compute the authenticator, apply MD5 [RFC1321] computed on the > > > following data, in the order shown: > > >=20 > > > High-order byte from Challenge || Key || > > >=20 > > > MD5(Preceding Mobile IP data || > > >=20 > > > Type, Subtype (if present), Length, SPI) || > > >=20 > > > Least-order 237 bytes from Challenge > > >=20 > > > where the Type, Length, SPI, and possibly Subtype, are the fields of > > > the authentication extension in use. For instance, all four of these > > > fields would be in use when SPI =3D=3D CHAP_SPI is used with = the > > > Generalized Authentication extension. Since the RADIUS protocol > > > cannot carry attributes of length greater than 253, the preceding > > > Mobile IP data, type, subtype (if present), length and SPI are hashed > > > using MD5. Finally, the least significant 237 bytes of the challenge > > > are concatenated. If the challenge has fewer than 238 bytes, this > > > algorithm includes the high-order byte in the computation twice, but > > > ensures that the challenge is used exactly as is. Additional padding > > > is never used to increase the length of the challenge; the input data > > > is allowed to be shorter than 237 bytes long. > >=20 > > This draft starts by trying to help the FA, not the MN. so it should > > at least do no harm to the MN. > >=20 > > But this is something that can end up screwing the MN. Any device=20 > > within RF coverage of both can see everything above (including the=20 > > challenge), except the password used in CHAP. Given the weakness to=20 > > dictionary attacks, an exchange like the above effectively blasts the user's password to anybody who cares to listen. > > This shouldn't be recommended. Or am I missing something? > >=20 > > ... > >=20 > > > 9. Configurable Parameters > > >=20 > > > Every Mobile IP agent supporting the extensions defined in this > > > document SHOULD be able to configure each parameter in the following > > > table. Each table entry contains the name of the parameter, the > > > default value, and the section of the document in which the parameter > > > first appears. > > >=20 > > > +------------------+---------------+---------------------+ > > > | Parameter Name | Default Value | Section of Document | > > > +------------------+---------------+---------------------+ > > > | CHALLENGE_WINDOW | 2 | 3.2 | > >=20 > > This has never been explained! And the first time it's mentioned is section 2.1. > >=20 > > > | | | | > > > | CHAP_SPI | 2 | 8 | > >=20 > > First time it's mentioned is section 3.1. > >=20 > > ... > >=20 > > > 10. Error Values > > >=20 > > > Each entry in the following table contains the name of the Code > > > [RFC3344] to be returned in a Registration Reply, the value for the > > > Code, and the section in which the error is first mentioned in this > > > specification. > >=20 > > Why is the first time it's mentioned that important? What should be=20 > > referenced is the section in which it is properly explained (which=20 > > could be forward referenced from wherever it's mentioned for the=20 > > first time). > >=20 > > >=20 > > > +--------------------+-------+--------------------------+ > > > | Error Name | Value | Section of Document | > > > +--------------------+-------+--------------------------+ > > > | UNKNOWN_CHALLENGE | 104 | 3.2 | > > > | | | | > > > | BAD_AUTHENTICATION | 67 | 3.2 - also see [RFC3344] | > > > | | | | > > > | MISSING_CHALLENGE | 105 | 3.1, 3.2 | > > > | | | | > > > | STALE_CHALLENGE | 106 | 3.2 | > > > | | | | > > > | FA_BAD_AAA_AUTH | TBD | 3.2 | > > > | | | | > > > | HA_BAD_AAA_AUTH | TBD | 3.4 | > > > | | | | > > > | HA_WRONG_CHALLENGE | TBD | 3.2 | > > > +--------------------+-------+--------------------------+ > > >=20 > > > Table 2: Error Values > > >=20 > >=20 > > Given the errors seen in the previous table, please double-check all > > the above. > >=20 > > ... > >=20 > > > 12. Security Considerations > > >=20 > > > In the event that a malicious mobile node attempts to replay the > > > authenticator for an old Mobile-Foreign Challenge, the foreign agent > > > would detect it since the agent always checks whether it has recently > > > advertised the Challenge (see Section 3.2). Allowing mobile nodes > > > with different IP addresses or NAIs to use the same Challenge value > > > does not represent a security vulnerability, because the > > > authentication data provided by the mobile node will be computed over > > > data that is different (at least by the bytes of the mobile nodes' IP > > > addresses). > >=20 > > OLD: > > at least by the bytes of the mobile nodes' IP addresses > >=20 > > NEW: > > at least the mobile node's IP address will vary > >=20 > >=20 > > ... > >=20 > >=20 > > > Section 8 (SPI For RADIUS AAA Servers) defines a method of computing > > > the Generalized Mobile IP Authentication Extension's authenticator > > > field using MD5 in a manner that is consistent with RADIUS [RFC2138]. > > > The use of MD5 in the method described in Section 8 is less secure > > > than HMAC-MD5 [RFC2104], and should be avoided whenever possible. > >=20 > > s/should/MUST/ > > But really, this MUST be avoided always, unless there's other (e.g., > > link-layer > > mechanisms) that can help prevent the dictionary attacks. I guess=20 > > the latter applies throughout to the other methods as well. > >=20 > > > Note that an active attacker may try to prevent successful > > > registrations by sending a large number of Agent Solicitations or > > > bogus Registration Requests, each of which could cause the foreign > > > agent to respond with a fresh challenge, invalidating the challenge > > > that the MN is currently trying to use. To prevent such attacks, the > > > foreign agent MUST NOT invalidate previously unused challenges when > > > responding to unauthenticated Registration Requests or Agent > > > Solicitations. In addition, the foreign agent MUST NOT allocate new > > > storage when responding to such messages, because this would also > > > create the possibility of denial of service. > >=20 > > Should say that it does not seek to provide any assurance to the MN, > > only to the FA and infrastructure. > >=20 > > ... > > > 14. Normative References > > >=20 > > > [FAERR] Perkins, C., "Foreign Agent Error Extension for Mobile > > > IPv4", draft-perkins-mip4-faerr-00.txt (work in progress), > > > January 2004. > >=20 > > Update this reference to the latest version. > >=20 > > ... > > > Authors' Addresses > > ... > > > Pat R. Calhoun > > > Black Storm Networks > > > 110 Nortech Parkway > > > San Jose, CA 95134 > > >=20 > > > Fax: +1 720-293-7501 > > > Email: pcalhoun@diameter.org > >=20 > > Update this info. > >=20 > > > Appendix A. Change History > >=20 > > I like Jari's suggestion to detail the changes with respect to 3012. > >=20 > > ... > >=20 > > > Appendix B. Verification Infrastructure > > ... > > > In order to verify the credentials of the mobile node, we=20 > > > imagine > >=20 > > s/imagine/assume/ > >=20 > > ... > >=20 > > > Appendix C. Message Flow for FA Challenge Messaging with Mobile-AAA > > > Extension > > ... > > > 1. The foreign agent disseminates a Challenge Value in an=20 > > > Agent > >=20 > > s/disseminates/includes/ > > s/an Agent/a unicast Agent/ > >=20 > > ... > >=20 > > > Appendix E. Foreign Agent Algorithm for Tracking Used Challenges > >=20 > > This section is normative, and is where we finally see the=20 > > explanation of how to use CHALLENGE_WINDOW. This should be in the=20 > > body of the document and must not remain in an appendix. > >=20 > > The appendix should only have the pseudo-code example. > >=20 > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > > =20 > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Nov 04 16:48:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY9Pz-0001Qh-Aq; Fri, 04 Nov 2005 16:48:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY9Px-0001Qc-UZ for mip4@megatron.ietf.org; Fri, 04 Nov 2005 16:48:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15917 for ; Fri, 4 Nov 2005 16:47:50 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EY9f1-0003gz-JG for mip4@ietf.org; Fri, 04 Nov 2005 17:03:48 -0500 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id jA4MBLJM020070 for ; Fri, 4 Nov 2005 15:11:21 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id jA4Lthqq029124 for ; Fri, 4 Nov 2005 15:55:44 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Nov 2005 16:47:56 -0500 Message-ID: Thread-Topic: Hokey mailing list: Bar-meeting on Handover keying design Thread-Index: AcXUeip0K9cwHmNUTdaeGJGn/RgZUAKsIEEAAJd1bHA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Nakhjiri Madjid-MNAKHJI1" , "Mobile IPv4 Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Mip4] Hokey mailing list: Bar-meeting on Handover keying design X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Folks, the mailing list for handover keying is set up.=20 Feel free to subscribe, I am expecting activity after the meeting. However, the meeting is only tentatively scheduled for Tuesday evening 9-10 PM somewhere in a IETF meeting area to be announce it on the list or on the wall somewhere.=20 The list address is hokey@motorola.com, you can send emails but you cannot see emails if you are not subscribed. To subscribe: Send a message to "command@motorola.com" with the subject "maillist-subscribe" or "maillist-unsubscribe" depending on what you wish to do. In the body of the message should be the following.=20 listname=3DHOKEY subscribers=3Dyouremailaddress Thanks, Madjid Nakhjiri -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Nakhjiri Madjid-MNAKHJI1 Sent: Tuesday, November 01, 2005 3:25 PM To: Mobile IPv4 Mailing List Subject: [Mip4] Bar-meeting on Handover keying design =20 Hi, This is a solicitation for folks interested in a Bar-meeting (Bar pre-BoF or whatever the meeting ends up being) discussing handover keying (I call it HOKEY, and have created a semi-formal proposal in case we end up needing a BOF name for Dallas, who knows it does not hurt to have these things handy :) ). I have a link to an old draft from April down at the bottom of this email, but unfortunately, I did not have time to write a new version of the draft. The old draft may be enough to initiate some discussion. Please let me know if you are interested in participating. We will decide on the "happy hour" time and location :) I have not yet set up a proper mailing list, so if you are simply interested in checking things out, ***you do not need to send me an email yet*** as I am sending this email to several lists. If I manage to set of a mailing list in time for IETF, an announcement is to follow. Regards, Madjid Nakhjiri Handover Keying (HOKEY) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The recent "AAA Key Management" guidelines as well as several IEEE and WiMAX specification documents attest to the increasing popularity of approach of striving to benefit from the interaction with the authentication (AAA) servers during the network entry to provision further keying materials for support of other networking applications or handovers to other networks.=20 Recent attempts in applying these methods to access technologies with mobility support (such as WiMAX) has shown that the existing specifications may needs to be further examined or extended from the point of view of handover keying or networking application keying support. It seems to be more efficient to instead initiate a well-thought and documented design with a first-hand focus on mobility and handover keying and authorization mechanisms. The initial goal of this activity can be to examine the combination of the EAP and AAA documentations to utilize the EAP keying framework and the AAA infrastructure for handover keying and provide an appropriate key hierarchy that can handle the requirements stated in "AAA key management" and further venturing into other network applications that may need keying support. A background problem statement can be found at http://www.ietf.org/internet-drafts/draft-nakhjiri-eap-ho-00.txt -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Nov 04 19:21:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBo6-0004rV-65; Fri, 04 Nov 2005 19:21:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYBo5-0004rN-2U for mip4@megatron.ietf.org; Fri, 04 Nov 2005 19:21:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24066 for ; Fri, 4 Nov 2005 19:20:54 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.192]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYC38-0007tl-6W for mip4@ietf.org; Fri, 04 Nov 2005 19:36:53 -0500 Received: by xproxy.gmail.com with SMTP id s9so8551wxc for ; Fri, 04 Nov 2005 16:21:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=saSm7K6TBLeAMXWfPe7jmsapHg7F+zWXZjGH5zL+kLVR8/w9V7Wm9FU4gYZ8TOY8ZM+fTn8nDjiDUHyiBRA1wn0W23Sch2Be2L2YLlJd/I5D1ACQJQjdRVQIGvJAfoJoYUNRk62+ixgyhLlVFslfhwSQ0Bi27aGTq+Dx9y3L5tQ= Received: by 10.70.65.17 with SMTP id n17mr2589135wxa; Fri, 04 Nov 2005 16:21:13 -0800 (PST) Received: by 10.70.28.18 with HTTP; Fri, 4 Nov 2005 16:21:13 -0800 (PST) Message-ID: Date: Fri, 4 Nov 2005 16:21:13 -0800 From: Vijay Devarapallli To: Pete McCann Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt In-Reply-To: <17259.40237.791684.416111@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050921073530.78072.qmail@web81910.mail.mud.yahoo.com> <17259.40237.791684.416111@gargle.gargle.HOWL> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org On 11/4/05, Pete McCann wrote: > > We didn't get any followup to Gabriel's review here. How does the > group feel about splitting 3012bis into two documents? not at this late stage. its fine as it is. however, I have one comment on the support for co-located CoA mode. the draft claims it supports it but there really isnt enough detail. IMO, it should be clarified that only FA mode is described in the draft. Vijay -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sat Nov 05 16:52:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYVxd-0001Su-Nr; Sat, 05 Nov 2005 16:52:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYVxb-0001Sj-Pt for mip4@megatron.ietf.org; Sat, 05 Nov 2005 16:52:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22144 for ; Sat, 5 Nov 2005 16:52:03 -0500 (EST) Received: from ns2.academica.fi ([217.64.177.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYWCt-0004gE-3i for mip4@ietf.org; Sat, 05 Nov 2005 17:08:15 -0500 Received: from [82.133.140.108] (ip82-133-140-108.adsl.academica.fi [82.133.140.108]) by ns2.academica.fi (Postfix) with ESMTP id 6FEF6257159; Sat, 5 Nov 2005 23:50:02 +0200 (EET) Message-ID: <436D540B.3030404@iki.fi> Date: Sun, 06 Nov 2005 02:53:31 +0200 From: Sami Vaarala User-Agent: Debian Thunderbird 1.0.6 (X11/20050802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org, espen@birdstep.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Subject: [Mip4] draft-ietf-mip4-vpn-problem-solution-02 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sami.vaarala@iki.fi List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi, I've sent out draft-ietf-mip4-vpn-problem-solution-02 to be processed, but here are a few quick links in the meantime: http://users.tkk.fi/~svaarala/mipvpn/draft-ietf-mip4-vpn-problem-solution-02.txt http://users.tkk.fi/~svaarala/mipvpn/draft-ietf-mip4-vpn-problem-solution-02-from-1.diff.html http://users.tkk.fi/~svaarala/mipvpn/draft-ietf-mip4-vpn-problem-solution-02-from-1.chbar Summary of changes from draft-ietf-mip4-vpn-problem-solution-01 to -02: o Feedback from Vijay Devarapalli incorporated. o Added references to MOBIKE WG where applicable. o Changed requirement for reverse tunneling of inner MIPv4 when MN is outside, from MUST to SHOULD. Reason: not all IPsec-based VPNs have the policy limitation; in particular, L2TP/IPsec implementations do not. o Added better explanation of why reverse tunneling to i-HA is often required when the MN is outside. o Re-added latency considerations section in a simplified form. o IPR reference from RFC 3667 updated to RFC 3978. o Removed explicit IPR section, as the general reference to on-line IPR statements suffices. o Removed unused document references. o Other minor cleanups. Best regards, -Sami -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 12:42:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZB0X-0005Rl-4S; Mon, 07 Nov 2005 12:42:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZB0U-0005OR-R1 for mip4@megatron.ietf.org; Mon, 07 Nov 2005 12:42:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24702 for ; Mon, 7 Nov 2005 12:41:44 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZBG7-0002Tr-SJ for mip4@ietf.org; Mon, 07 Nov 2005 12:58:21 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2005 09:42:00 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA7HftnT017020; Mon, 7 Nov 2005 09:41:55 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 09:41:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 7 Nov 2005 09:41:49 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52E2A16C@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXhnwx20yALBVMMQQSmHVn/apqA9ACIp7kA From: "Kent Leung \(kleung\)" To: "Vijay Devarapallli" , "Pete McCann" X-OriginalArrivalTime: 07 Nov 2005 17:41:52.0039 (UTC) FILETIME=[8986A370:01C5E3C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org On this particular topic, I don't understand what is missing in the details to support the CCoA mode? Since the draft covers MN-AAA authentication with NAS in between, I would like to see both FA (CoA) and HA (CCoA) modes supported. Where else would we be able to cover just the CCoA for MN-AAA authentication if not in this draft? Kent >=20 > not at this late stage. its fine as it is. however, I have=20 > one comment on the support for co-located CoA mode. the draft=20 > claims it supports it but there really isnt enough detail.=20 > IMO, it should be clarified that only FA mode is described in=20 > the draft. >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 12:56:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBE0-000199-8w; Mon, 07 Nov 2005 12:56:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZBDy-00017x-Sn for mip4@megatron.ietf.org; Mon, 07 Nov 2005 12:56:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25690 for ; Mon, 7 Nov 2005 12:55:41 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZBTc-0002wN-9A for mip4@ietf.org; Mon, 07 Nov 2005 13:12:17 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 07 Nov 2005 09:55:56 -0800 X-IronPort-AV: i="3.97,301,1125903600"; d="scan'208"; a="672447331:sNHT25957944" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA7HtEo3028283; Mon, 7 Nov 2005 09:55:53 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 09:55:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 7 Nov 2005 09:55:51 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52E2A198@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXhZ5q5UsmmfM4NTsm29WIDZPrCFgCXAzCA From: "Kent Leung \(kleung\)" To: "Pete McCann" , X-OriginalArrivalTime: 07 Nov 2005 17:55:52.0882 (UTC) FILETIME=[7EB51920:01C5E3C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Pete. Gabriel's assessment is correct, but I don't think document splitting will gain much technically to increase comprehension. Most people can see clearly the two functions and there is a dependency between them in FA CoA mode. Keep draft intact, IMHO. Kent=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Pete McCann > Sent: Friday, November 04, 2005 9:41 AM > To: itijibox-mip4@yahoo.com > Cc: mip4@ietf.org > Subject: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 >=20 > We didn't get any followup to Gabriel's review here. How=20 > does the group feel about splitting 3012bis into two documents? >=20 > -Pete >=20 > gabriel montenegro writes: > > I reviewed this document. I feel it is not quite RFC=20 > quality, being a bit confusing > and verbose/repetitive in=20 > sections. A big issue > I have is that it is really two=20 > different things bunched together: > > =09 > > - Challenge/Response extention > > - Generalized Authentication Extension > > They really=20 > should be two documents, specially cuz this is a revision,=20 > the proper > opportunity to make such changes. > > > > I'm also wondering about the use of MD5 throughout. Given=20 > recent developments, some > folks (not unanimously, though)=20 > are already calling for the deprecation of > SHA-1, and here=20 > we are recommending MD5 for a proposed standard? If this is=20 > what's > being used today, then this could be published as a=20 > historical or informational RFC, > If the intent is to fix a=20 > few bugs in rfc 3012, perhaps the errata page is enough. > > But the use of MD5 should be reviewed by the security ADs.=20 > CHAP should also be avoided, > due to its vulnerability to=20 > dictionary attacks. > > For example, EAP advices against its usage (see rfc3748=20 > section 7.6). Even more > explicitly, the EAP requirements=20 > for wireless usage call for mandatory > resistance to=20 > dictionary attacks: http://www.faqs.org/rfcs/rfc4017.html,=20 > section 2.2. > > > > This comment applies to 3344bis as well. > > > > Nit: saw "processing for" in several places. Shouldn't it=20 > be "processing of"? > > > > Other comments interspersed below. > > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 14:29:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCfv-00005i-69; Mon, 07 Nov 2005 14:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCft-0008VU-K3 for mip4@megatron.ietf.org; Mon, 07 Nov 2005 14:29:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02226 for ; Mon, 7 Nov 2005 14:28:35 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZCvX-0005tN-Ie for mip4@ietf.org; Mon, 07 Nov 2005 14:45:13 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jA7ItCD05846; Mon, 7 Nov 2005 10:55:12 -0800 X-mProtect: <200511071855> Nokia Silicon Valley Messaging Protection Received: from danira-pool052117.americas.nokia.com (10.241.52.117, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpd9j7NJa; Mon, 07 Nov 2005 10:55:11 PST Message-ID: <436FAAC4.3020205@iprg.nokia.com> Date: Mon, 07 Nov 2005 11:28:04 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt References: <2979E38DD6FC6544B789C8DAD7BAFC52E2A16C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC52E2A16C@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Pete McCann , mip4@ietf.org, Vijay Devarapallli , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Kent Leung (kleung) wrote: > On this particular topic, I don't understand what is missing in the > details to support the CCoA mode? Since the draft covers MN-AAA > authentication with NAS in between, I would like to see both FA (CoA) > and HA (CCoA) modes supported. Where else would we be able to cover > just the CCoA for MN-AAA authentication if not in this draft? for e.g. who generates the challenge in co-located mode? Vijay > > Kent > > > >>not at this late stage. its fine as it is. however, I have >>one comment on the support for co-located CoA mode. the draft >>claims it supports it but there really isnt enough detail. >>IMO, it should be clarified that only FA mode is described in >>the draft. >> > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 14:36:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCmr-0002FG-Q6; Mon, 07 Nov 2005 14:36:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZCmp-0002F9-S4 for mip4@megatron.ietf.org; Mon, 07 Nov 2005 14:36:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02685 for ; Mon, 7 Nov 2005 14:35:45 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZD2V-00066S-04 for mip4@ietf.org; Mon, 07 Nov 2005 14:52:23 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 07 Nov 2005 11:36:01 -0800 X-IronPort-AV: i="3.97,301,1125903600"; d="scan'208"; a="672496173:sNHT1535060846" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA7JZpnZ022651; Mon, 7 Nov 2005 11:35:58 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 11:35:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 7 Nov 2005 11:35:56 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52E2A290@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXj0YCMRx3ZIv0kROa5cc2oQ10H5QAACB9g From: "Kent Leung \(kleung\)" To: "Vijay Devarapalli" X-OriginalArrivalTime: 07 Nov 2005 19:35:57.0074 (UTC) FILETIME=[797C1720:01C5E3D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable Cc: Pete McCann , mip4@ietf.org, Vijay Devarapallli , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org OK. Since this registration exchange is between MN and HA, I expect that MN would generate some random number in Challenge value. All implementations that I'm aware of do this. "The mechanism used by the mobile node to obtain the Challenge value in this case is outside the scope of this document." But the point is mute since there won't be any Challenge value if the new scheme of zero in place of Challenge for authentication is adopted. Kent > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]=20 > Sent: Monday, November 07, 2005 11:28 AM > To: Kent Leung (kleung) > Cc: Vijay Devarapallli; Pete McCann; mip4@ietf.org;=20 > itijibox-mip4@yahoo.com > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > Kent Leung (kleung) wrote: > > On this particular topic, I don't understand what is missing in the=20 > > details to support the CCoA mode? Since the draft covers MN-AAA=20 > > authentication with NAS in between, I would like to see=20 > both FA (CoA)=20 > > and HA (CCoA) modes supported. Where else would we be able=20 > to cover=20 > > just the CCoA for MN-AAA authentication if not in this draft? >=20 > for e.g. who generates the challenge in co-located mode? >=20 > Vijay >=20 > >=20 > > Kent > >=20 > >=20 > >=20 > >>not at this late stage. its fine as it is. however, I have=20 > one comment=20 > >>on the support for co-located CoA mode. the draft claims it=20 > supports=20 > >>it but there really isnt enough detail. > >>IMO, it should be clarified that only FA mode is described in the=20 > >>draft. > >> > >=20 > >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 15:01:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZDB5-0000da-1j; Mon, 07 Nov 2005 15:01:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZDB3-0000cf-AK for mip4@megatron.ietf.org; Mon, 07 Nov 2005 15:01:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04346 for ; Mon, 7 Nov 2005 15:00:46 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZDQh-0006sG-Df for mip4@ietf.org; Mon, 07 Nov 2005 15:17:25 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 07 Nov 2005 12:00:55 -0800 X-IronPort-AV: i="3.97,301,1125903600"; d="scan'208"; a="672506403:sNHT14818887798" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA7K0Ynh009932; Mon, 7 Nov 2005 12:00:52 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 12:00:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 7 Nov 2005 12:00:48 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52E2A2C3@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXj0YCMRx3ZIv0kROa5cc2oQ10H5QAACB9gAAERMnA= From: "Kent Leung \(kleung\)" To: "Kent Leung \(kleung\)" , "Vijay Devarapalli" X-OriginalArrivalTime: 07 Nov 2005 20:00:49.0651 (UTC) FILETIME=[F3214430:01C5E3D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: Pete McCann , mip4@ietf.org, Vijay Devarapallli , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org I meant "moot", not "mute".=20 Kent=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Kent Leung (kleung) > Sent: Monday, November 07, 2005 11:36 AM > To: Vijay Devarapalli > Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli;=20 > itijibox-mip4@yahoo.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > OK. Since this registration exchange is between MN and HA, I=20 > expect that MN would generate some random number in Challenge=20 > value. All implementations that I'm aware of do this. >=20 > "The mechanism used by the mobile node to > obtain the Challenge value in this case is outside the=20 > scope of this > document." >=20 > But the point is mute since there won't be any Challenge=20 > value if the new scheme of zero in place of Challenge for=20 > authentication is adopted. >=20 > Kent >=20 >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > > Sent: Monday, November 07, 2005 11:28 AM > > To: Kent Leung (kleung) > > Cc: Vijay Devarapallli; Pete McCann; mip4@ietf.org;=20 > > itijibox-mip4@yahoo.com > > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > >=20 > > Kent Leung (kleung) wrote: > > > On this particular topic, I don't understand what is=20 > missing in the=20 > > > details to support the CCoA mode? Since the draft covers MN-AAA=20 > > > authentication with NAS in between, I would like to see > > both FA (CoA) > > > and HA (CCoA) modes supported. Where else would we be able > > to cover > > > just the CCoA for MN-AAA authentication if not in this draft? > >=20 > > for e.g. who generates the challenge in co-located mode? > >=20 > > Vijay > >=20 > > >=20 > > > Kent > > >=20 > > >=20 > > >=20 > > >>not at this late stage. its fine as it is. however, I have > > one comment > > >>on the support for co-located CoA mode. the draft claims it > > supports > > >>it but there really isnt enough detail. > > >>IMO, it should be clarified that only FA mode is described in the=20 > > >>draft. > > >> > > >=20 > > >=20 > >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 15:17:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZDQx-00043B-7l; Mon, 07 Nov 2005 15:17:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZDQv-000434-Ho for mip4@megatron.ietf.org; Mon, 07 Nov 2005 15:17:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05087 for ; Mon, 7 Nov 2005 15:17:10 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZDgb-0007GG-3R for mip4@ietf.org; Mon, 07 Nov 2005 15:33:49 -0500 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2005 12:17:26 -0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA7KGoLS025151; Tue, 8 Nov 2005 04:16:51 +0800 (CST) Received: from xmb-hkg-416.apac.cisco.com ([64.104.123.88]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Nov 2005 04:17:19 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Tue, 8 Nov 2005 04:17:17 +0800 Message-ID: <35912544FC930E49BF20EF16C3EF276586324B@xmb-hkg-416.apac.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXj0uv2NtepkstSTLC63hLMNqkEgwAAVVgg From: "Yoshi Tsuda \(yotsuda\)" To: "Vijay Devarapalli" , "Kent Leung \(kleung\)" X-OriginalArrivalTime: 07 Nov 2005 20:17:19.0498 (UTC) FILETIME=[411FEEA0:01C5E3D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: Pete McCann , mip4@ietf.org, Vijay Devarapallli , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Vijay, Even in co-located mode, you know, an FA can push challenge to an MN by setting R-bit and challenge in agent advertisements. Do you need pushing challenge from an HA to an MN, instead ? If so, Kent has already mentioned one option. If you want to push challenge from an HA to an MN really, say MS CHAPv2, we want you describe such a scenario in order to review it. At the time when we defined and did interoperability tests about rfc3012, we assumed visiting subnets need some guard by challenge. Pushing challenge really from an HA=20 to an MN is beyond our assumptions at that time. I prefer a new rfc rather than updating rfc3012, because in such a case we would probably need more functions, such as some guard against losing challenge on an MN. Thanks. -Yoshi > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Vijay Devarapalli > Sent: Monday, November 07, 2005 11:28 AM > To: Kent Leung (kleung) > Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli;=20 > itijibox-mip4@yahoo.com > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > Kent Leung (kleung) wrote: > > On this particular topic, I don't understand what is missing in the=20 > > details to support the CCoA mode? Since the draft covers MN-AAA=20 > > authentication with NAS in between, I would like to see=20 > both FA (CoA)=20 > > and HA (CCoA) modes supported. Where else would we be able=20 > to cover=20 > > just the CCoA for MN-AAA authentication if not in this draft? >=20 > for e.g. who generates the challenge in co-located mode? >=20 > Vijay >=20 > >=20 > > Kent > >=20 > >=20 > >=20 > >>not at this late stage. its fine as it is. however, I have=20 > one comment=20 > >>on the support for co-located CoA mode. the draft claims it=20 > supports=20 > >>it but there really isnt enough detail. > >>IMO, it should be clarified that only FA mode is described in the=20 > >>draft. > >> > >=20 > >=20 >=20 >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 17:04:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZF6k-0003Rw-Rh; Mon, 07 Nov 2005 17:04:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZF6j-0003Ro-Po for mip4@megatron.ietf.org; Mon, 07 Nov 2005 17:04:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10825 for ; Mon, 7 Nov 2005 17:04:28 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZFMP-0001lL-Aq for mip4@ietf.org; Mon, 07 Nov 2005 17:21:06 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jA7LV6309560; Mon, 7 Nov 2005 13:31:06 -0800 X-mProtect: <200511072131> Nokia Silicon Valley Messaging Protection Received: from danira-pool05550.americas.nokia.com (10.241.55.50, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdveWUi0; Mon, 07 Nov 2005 13:31:04 PST Message-ID: <436FCF65.9010407@iprg.nokia.com> Date: Mon, 07 Nov 2005 14:04:21 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt References: <2979E38DD6FC6544B789C8DAD7BAFC52E2A290@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC52E2A290@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Cc: Pete McCann , mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Kent Leung (kleung) wrote: > OK. Since this registration exchange is between MN and HA, I expect > that MN would generate some random number in Challenge value. All > implementations that I'm aware of do this. the MN itself generates the challenge? shouldnt the network be challenging the mobile node? > "The mechanism used by the mobile node to > obtain the Challenge value in this case is outside the scope of this > document." and this is not enough for interoperability. > But the point is mute since there won't be any Challenge value if the > new scheme of zero in place of Challenge for authentication is adopted. if you set the challenge to 0, then the whole point of challenge/response mechanism is lost, right? or am I missing something? Vijay > > Kent > > > >>-----Original Message----- >>From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >>Sent: Monday, November 07, 2005 11:28 AM >>To: Kent Leung (kleung) >>Cc: Vijay Devarapallli; Pete McCann; mip4@ietf.org; >>itijibox-mip4@yahoo.com >>Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >> >>Kent Leung (kleung) wrote: >> >>>On this particular topic, I don't understand what is missing in the >>>details to support the CCoA mode? Since the draft covers MN-AAA >>>authentication with NAS in between, I would like to see >> >>both FA (CoA) >> >>>and HA (CCoA) modes supported. Where else would we be able >> >>to cover >> >>>just the CCoA for MN-AAA authentication if not in this draft? >> >>for e.g. who generates the challenge in co-located mode? >> >>Vijay >> >> >>>Kent >>> >>> >>> >>> >>>>not at this late stage. its fine as it is. however, I have >> >>one comment >> >>>>on the support for co-located CoA mode. the draft claims it >> >>supports >> >>>>it but there really isnt enough detail. >>>>IMO, it should be clarified that only FA mode is described in the >>>>draft. >>>> >>> >>> -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 17:08:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZF9l-00041R-4r; Mon, 07 Nov 2005 17:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZF9j-00041J-EX for mip4@megatron.ietf.org; Mon, 07 Nov 2005 17:07:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11013 for ; Mon, 7 Nov 2005 17:07:34 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZFPP-0001qU-VJ for mip4@ietf.org; Mon, 07 Nov 2005 17:24:12 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jA7LYDn11324; Mon, 7 Nov 2005 13:34:13 -0800 X-mProtect: <200511072134> Nokia Silicon Valley Messaging Protection Received: from danira-pool05550.americas.nokia.com (10.241.55.50, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdBWugtz; Mon, 07 Nov 2005 13:34:11 PST Message-ID: <436FD01D.4050801@iprg.nokia.com> Date: Mon, 07 Nov 2005 14:07:25 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Yoshi Tsuda (yotsuda)" Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt References: <35912544FC930E49BF20EF16C3EF276586324B@xmb-hkg-416.apac.cisco.com> In-Reply-To: <35912544FC930E49BF20EF16C3EF276586324B@xmb-hkg-416.apac.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Pete McCann , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Yoshi Tsuda (yotsuda) wrote: > Hi Vijay, > > Even in co-located mode, you know, an FA can push > challenge to an MN by setting R-bit and challenge in > agent advertisements. in co-located mode, I am assuming there are networks with no FA. > Do you need pushing challenge from an HA to an MN, > instead ? nope. If so, Kent has already mentioned one option. I dont think the MN itself generating the challenge is a solution. > If you want to push challenge from an HA to an MN really, > say MS CHAPv2, we want you describe such a scenario > in order to review it. I wanted the draft actually to say that the challenge/response mechanism is specified only for FA mode. for co-located mode, it could be out of scope for this draft. the draft currently claims that it supports co-located mode too. I am objecting to that. > At the time when we defined and did interoperability tests > about rfc3012, we assumed visiting subnets need some > guard by challenge. Pushing challenge really from an HA > to an MN is beyond our assumptions at that time. I prefer > a new rfc rather than updating rfc3012, because in such a > case we would probably need more functions, such as some > guard against losing challenge on an MN. ok. Vijay > > Thanks. > -Yoshi > > >>-----Original Message----- >>From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On >>Behalf Of Vijay Devarapalli >>Sent: Monday, November 07, 2005 11:28 AM >>To: Kent Leung (kleung) >>Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli; >>itijibox-mip4@yahoo.com >>Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >> >>Kent Leung (kleung) wrote: >> >>>On this particular topic, I don't understand what is missing in the >>>details to support the CCoA mode? Since the draft covers MN-AAA >>>authentication with NAS in between, I would like to see >> >>both FA (CoA) >> >>>and HA (CCoA) modes supported. Where else would we be able >> >>to cover >> >>>just the CCoA for MN-AAA authentication if not in this draft? >> >>for e.g. who generates the challenge in co-located mode? >> >>Vijay >> >> >>>Kent >>> >>> >>> >>> >>>>not at this late stage. its fine as it is. however, I have >> >>one comment >> >>>>on the support for co-located CoA mode. the draft claims it >> >>supports >> >>>>it but there really isnt enough detail. >>>>IMO, it should be clarified that only FA mode is described in the >>>>draft. >>>> >>> >>> >> >> >>-- >>Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>Supplemental site: http://www.mip4.org/ >> -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 17:53:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFrO-0006xA-JJ; Mon, 07 Nov 2005 17:53:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFrN-0006vy-1x for mip4@megatron.ietf.org; Mon, 07 Nov 2005 17:53:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14475 for ; Mon, 7 Nov 2005 17:52:39 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZG73-0003Lx-St for mip4@ietf.org; Mon, 07 Nov 2005 18:09:18 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jA7MjC020237; Mon, 7 Nov 2005 17:45:13 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 7 Nov 2005 16:45:11 -0600 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXj59lK7iOOxZWpSj6CALJnEMPCIQAAOnhQ From: "Jayshree Bharatia" To: "Vijay Devarapalli" , "Yoshi Tsuda \(yotsuda\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Pete McCann , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Vijay, I agree that having co-located CoA support information in this draft is confusing. We added co-located CoA support at the later time as a result of comments (rather long debate!) we had on the mailing list. At that time, it was decided not to limit the use of this mechanism (use of the MN-AAA extension) given that challenges are generated by some other means and make them available at the MN. I am open to any suggestions which may clarify the scope better. Regards, Jayshree -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Vijay Devarapalli Sent: Monday, November 07, 2005 4:07 PM To: Yoshi Tsuda (yotsuda) Cc: Kent Leung (kleung); mip4@ietf.org; Pete McCann; itijibox-mip4@yahoo.com Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Yoshi Tsuda (yotsuda) wrote: > Hi Vijay, >=20 > Even in co-located mode, you know, an FA can push > challenge to an MN by setting R-bit and challenge in > agent advertisements. in co-located mode, I am assuming there are networks with no FA. > Do you need pushing challenge from an HA to an MN, > instead ? nope. If so, Kent has already mentioned one option. I dont think the MN itself generating the challenge is a solution. > If you want to push challenge from an HA to an MN really, say MS=20 > CHAPv2, we want you describe such a scenario in order to review it. I wanted the draft actually to say that the challenge/response mechanism is specified only for FA mode. for co-located mode, it could be out of scope for this draft. the draft currently claims that it supports co-located mode too. I am objecting to that. > At the time when we defined and did interoperability tests about=20 > rfc3012, we assumed visiting subnets need some guard by challenge. =20 > Pushing challenge really from an HA to an MN is beyond our=20 > assumptions at that time. I prefer a new rfc rather than updating=20 > rfc3012, because in such a case we would probably need more=20 > functions, such as some guard against losing challenge on an MN. ok. Vijay >=20 > Thanks. > -Yoshi >=20 >=20 >>-----Original Message----- >>From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On >>Behalf Of Vijay Devarapalli >>Sent: Monday, November 07, 2005 11:28 AM >>To: Kent Leung (kleung) >>Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli;=20 >>itijibox-mip4@yahoo.com >>Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >> >>Kent Leung (kleung) wrote: >> >>>On this particular topic, I don't understand what is missing in the >>>details to support the CCoA mode? Since the draft covers MN-AAA=20 >>>authentication with NAS in between, I would like to see=20 >> >>both FA (CoA) >> >>>and HA (CCoA) modes supported. Where else would we be able >> >>to cover >> >>>just the CCoA for MN-AAA authentication if not in this draft? >> >>for e.g. who generates the challenge in co-located mode? >> >>Vijay >> >> >>>Kent >>> >>> >>> >>> >>>>not at this late stage. its fine as it is. however, I have >> >>one comment >> >>>>on the support for co-located CoA mode. the draft claims it >> >>supports >> >>>>it but there really isnt enough detail. >>>>IMO, it should be clarified that only FA mode is described in the >>>>draft. >>>> >>> >>> >> >> >>-- >>Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>Supplemental site: http://www.mip4.org/ >> --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 19:00:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZGue-0007Hr-BK; Mon, 07 Nov 2005 19:00:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZGub-0007BO-6C for mip4@megatron.ietf.org; Mon, 07 Nov 2005 19:00:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20532 for ; Mon, 7 Nov 2005 19:00:02 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZHAI-00061i-6G for mip4@ietf.org; Mon, 07 Nov 2005 19:16:42 -0500 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2005 16:00:18 -0800 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA7Nx4Lm003139; Tue, 8 Nov 2005 07:59:43 +0800 (CST) Received: from xmb-hkg-416.apac.cisco.com ([64.104.123.88]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 8 Nov 2005 08:00:05 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Tue, 8 Nov 2005 08:00:02 +0800 Message-ID: <35912544FC930E49BF20EF16C3EF2765863289@xmb-hkg-416.apac.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXj59lK7iOOxZWpSj6CALJnEMPCIQAAOnhQAALFKyA= From: "Yoshi Tsuda \(yotsuda\)" To: "Jayshree Bharatia" , "Vijay Devarapalli" X-OriginalArrivalTime: 08 Nov 2005 00:00:05.0349 (UTC) FILETIME=[5FCAF150:01C5E3F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: quoted-printable Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Pete McCann , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Jayshree and Vijay,=20 Glad to know Jayshree has a mind to keep upgrading the draft. :) But, to support challenge mentioned by Vijay, we would definitely need some more functions than existing and having been tested functions in rfc3012, which need to be verified in a future interoperability test. So would like to know whether it is better to have a new rfc or updating rfc3012. Personally, I think, it's better to have a new rfc. Thanks. -Yoshi > -----Original Message----- > From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20 > Sent: Monday, November 07, 2005 2:45 PM > To: Vijay Devarapalli; Yoshi Tsuda (yotsuda) > Cc: Kent Leung (kleung); mip4@ietf.org; Pete McCann;=20 > itijibox-mip4@yahoo.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > Vijay, >=20 > I agree that having co-located CoA support information in=20 > this draft is confusing. We added co-located CoA support at=20 > the later time as a result of comments (rather long debate!)=20 > we had on the mailing list. At that time, it was decided not=20 > to limit the use of this mechanism (use of the MN-AAA=20 > extension) given that challenges are generated by some other=20 > means and make them available at the MN. >=20 > I am open to any suggestions which may clarify the scope better. >=20 > Regards, > Jayshree >=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Vijay Devarapalli > Sent: Monday, November 07, 2005 4:07 PM > To: Yoshi Tsuda (yotsuda) > Cc: Kent Leung (kleung); mip4@ietf.org; Pete McCann;=20 > itijibox-mip4@yahoo.com > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 >=20 > Yoshi Tsuda (yotsuda) wrote: > > Hi Vijay, > >=20 > > Even in co-located mode, you know, an FA can push =20 > challenge to an MN=20 > > by setting R-bit and challenge in agent advertisements. >=20 > in co-located mode, I am assuming there are networks with no FA. >=20 > > Do you need pushing challenge from an HA to an MN, instead ? >=20 > nope. >=20 > If so, Kent has already mentioned one option. >=20 > I dont think the MN itself generating the challenge is a solution. >=20 > > If you want to push challenge from an HA to an MN really, say MS=20 > > CHAPv2, we want you describe such a scenario in order to review it. >=20 > I wanted the draft actually to say that the=20 > challenge/response mechanism is specified only for FA mode.=20 > for co-located mode, it could be out of scope for this draft.=20 > the draft currently claims that it supports co-located mode=20 > too. I am objecting to that. >=20 > > At the time when we defined and did interoperability tests about=20 > > rfc3012, we assumed visiting subnets need some guard by challenge. > > Pushing challenge really from an HA to an MN is beyond our=20 > > assumptions at that time. I prefer a new rfc rather than updating=20 > > rfc3012, because in such a case we would probably need more=20 > > functions, such as some guard against losing challenge on an MN. >=20 > ok. >=20 > Vijay >=20 > >=20 > > Thanks. > > -Yoshi > >=20 > >=20 > >>-----Original Message----- > >>From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org]=20 > On Behalf=20 > >>Of Vijay Devarapalli > >>Sent: Monday, November 07, 2005 11:28 AM > >>To: Kent Leung (kleung) > >>Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli;=20 > >>itijibox-mip4@yahoo.com > >>Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > >> > >>Kent Leung (kleung) wrote: > >> > >>>On this particular topic, I don't understand what is=20 > missing in the=20 > >>>details to support the CCoA mode? Since the draft covers MN-AAA=20 > >>>authentication with NAS in between, I would like to see > >> > >>both FA (CoA) > >> > >>>and HA (CCoA) modes supported. Where else would we be able > >> > >>to cover > >> > >>>just the CCoA for MN-AAA authentication if not in this draft? > >> > >>for e.g. who generates the challenge in co-located mode? > >> > >>Vijay > >> > >> > >>>Kent > >>> > >>> > >>> > >>> > >>>>not at this late stage. its fine as it is. however, I have > >> > >>one comment > >> > >>>>on the support for co-located CoA mode. the draft claims it > >> > >>supports > >> > >>>>it but there really isnt enough detail. > >>>>IMO, it should be clarified that only FA mode is described in the=20 > >>>>draft. > >>>> > >>> > >>> > >> > >> > >>-- > >>Mip4 mailing list: Mip4@ietf.org > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >> Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > >>Supplemental site: http://www.mip4.org/ > >> >=20 >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 19:14:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZH82-0006N7-Fj; Mon, 07 Nov 2005 19:14:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZH6y-0005xH-Ln for mip4@megatron.ietf.org; Mon, 07 Nov 2005 19:13:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24859 for ; Mon, 7 Nov 2005 19:12:50 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZHMb-0007eQ-MC for mip4@ietf.org; Mon, 07 Nov 2005 19:29:26 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by mx2.foretec.com with esmtp (Exim 4.24) id 1EZH6Y-0000jy-Bu for mip4@ietf.org; Mon, 07 Nov 2005 19:12:50 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jA7NcWe23547; Mon, 7 Nov 2005 15:38:32 -0800 X-mProtect: <200511072338> Nokia Silicon Valley Messaging Protection Received: from danira-pool05550.americas.nokia.com (10.241.55.50, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdrqy7dh; Mon, 07 Nov 2005 15:38:29 PST Message-ID: <436FED41.3000406@iprg.nokia.com> Date: Mon, 07 Nov 2005 16:11:45 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jayshree Bharatia Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: 7bit Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, "Yoshi Tsuda \(yotsuda\)" , Pete McCann , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Jayshree Bharatia wrote: > Vijay, > > I agree that having co-located CoA support information in this draft is > confusing. We added co-located CoA support at the later time as a result > of comments (rather long debate!) we had on the mailing list. At that > time, it was decided not to limit the use of this mechanism (use of the > MN-AAA extension) given that challenges are generated by some other > means and make them available at the MN. > > I am open to any suggestions which may clarify the scope better. IMHO, this what we should do - clarify that 3012bis only addresses using the FA challenge/response extension in FA CoA mode. co-located CoA mode is not supported. - mention that the MN-AAA extension can be used in co-located CoA mode, but the actual details are out of scope for 3012bis. RFC 3957 also does a poor job of describing the co-located CoA mode. the RADIUS MIPv4 extensions draft, draft-nakhjiri-radius-mip4-02.txt, does a better job of describing how the MN-AAA extension can be used between the MN and the HA along with RFC 3957. IMO, thats the best reference today. I think draft-nakhjiri is also the wrong place for this. it should be in a separate draft. my 2 cents. Vijay > > Regards, > Jayshree > > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Monday, November 07, 2005 4:07 PM > To: Yoshi Tsuda (yotsuda) > Cc: Kent Leung (kleung); mip4@ietf.org; Pete McCann; > itijibox-mip4@yahoo.com > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > Yoshi Tsuda (yotsuda) wrote: > >>Hi Vijay, >> >> Even in co-located mode, you know, an FA can push >> challenge to an MN by setting R-bit and challenge in >> agent advertisements. > > > in co-located mode, I am assuming there are networks > with no FA. > > >> Do you need pushing challenge from an HA to an MN, >> instead ? > > > nope. > > If so, Kent has already mentioned one option. > > I dont think the MN itself generating the challenge > is a solution. > > >> If you want to push challenge from an HA to an MN really, say MS >>CHAPv2, we want you describe such a scenario in order to review it. > > > I wanted the draft actually to say that the > challenge/response mechanism is specified only for > FA mode. for co-located mode, it could be out of > scope for this draft. the draft currently claims > that it supports co-located mode too. I am objecting > to that. > > >> At the time when we defined and did interoperability tests about >>rfc3012, we assumed visiting subnets need some guard by challenge. >>Pushing challenge really from an HA to an MN is beyond our >>assumptions at that time. I prefer a new rfc rather than updating >>rfc3012, because in such a case we would probably need more >>functions, such as some guard against losing challenge on an MN. > > > ok. > > Vijay > > >>Thanks. >>-Yoshi >> >> >> >>>-----Original Message----- >>>From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On >>>Behalf Of Vijay Devarapalli >>>Sent: Monday, November 07, 2005 11:28 AM >>>To: Kent Leung (kleung) >>>Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli; >>>itijibox-mip4@yahoo.com >>>Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >>> >>>Kent Leung (kleung) wrote: >>> >>> >>>>On this particular topic, I don't understand what is missing in the >>>>details to support the CCoA mode? Since the draft covers MN-AAA >>>>authentication with NAS in between, I would like to see >>> >>>both FA (CoA) >>> >>> >>>>and HA (CCoA) modes supported. Where else would we be able >>> >>>to cover >>> >>> >>>>just the CCoA for MN-AAA authentication if not in this draft? >>> >>>for e.g. who generates the challenge in co-located mode? >>> >>>Vijay >>> >>> >>> >>>>Kent >>>> >>>> >>>> >>>> >>>> >>>>>not at this late stage. its fine as it is. however, I have >>> >>>one comment >>> >>> >>>>>on the support for co-located CoA mode. the draft claims it >>> >>>supports >>> >>> >>>>>it but there really isnt enough detail. >>>>>IMO, it should be clarified that only FA mode is described in the >>>>>draft. >>>>> >>>> >>>> >>> >>>-- >>>Mip4 mailing list: Mip4@ietf.org >>> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >>> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>>Supplemental site: http://www.mip4.org/ >>> > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 19:46:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHcu-0001yW-TM; Mon, 07 Nov 2005 19:46:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHcs-0001yM-Ei for mip4@megatron.ietf.org; Mon, 07 Nov 2005 19:46:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27125 for ; Mon, 7 Nov 2005 19:45:47 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZHsY-0000GR-Bd for mip4@ietf.org; Mon, 07 Nov 2005 20:02:28 -0500 Received: from az33exr04.mot.com ([10.64.251.234]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA80wPoZ028492 for ; Mon, 7 Nov 2005 17:58:25 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id jA80rHga003011 for ; Mon, 7 Nov 2005 18:53:18 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 7 Nov 2005 19:45:59 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXhnwx20yALBVMMQQSmHVn/apqA9ACIp7kAAA76elA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Kent Leung \(kleung\)" , "Vijay Devarapallli" , "Pete McCann" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org The fix to deal with CCoA is a very small one as I mentioned my previous email. I really don't think it warrants a huge discussion or a doc split. The fix that we suggested was agreed by Charlie as well. Madjid =20 -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Kent Leung (kleung) Sent: Monday, November 07, 2005 11:42 AM To: Vijay Devarapallli; Pete McCann Cc: mip4@ietf.org; itijibox-mip4@yahoo.com Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt On this particular topic, I don't understand what is missing in the details to support the CCoA mode? Since the draft covers MN-AAA authentication with NAS in between, I would like to see both FA (CoA) and HA (CCoA) modes supported. Where else would we be able to cover just the CCoA for MN-AAA authentication if not in this draft? Kent >=20 > not at this late stage. its fine as it is. however, I have one comment > on the support for co-located CoA mode. the draft claims it supports=20 > it but there really isnt enough detail. > IMO, it should be clarified that only FA mode is described in the=20 > draft. >=20 --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 19:47:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHdv-00021L-PR; Mon, 07 Nov 2005 19:47:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHdt-00021B-LQ for mip4@megatron.ietf.org; Mon, 07 Nov 2005 19:47:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27166 for ; Mon, 7 Nov 2005 19:46:50 -0500 (EST) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZHtV-0000I3-O8 for mip4@ietf.org; Mon, 07 Nov 2005 20:03:31 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id jA80uim0027532 for ; Mon, 7 Nov 2005 17:56:44 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id jA80t146026250 for ; Mon, 7 Nov 2005 18:55:02 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 7 Nov 2005 19:46:59 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXj0ZSVTbwPM5EFR4OjByzPaHSU8gALDztA From: "Nakhjiri Madjid-MNAKHJI1" To: "Vijay Devarapalli" , "Kent Leung \(kleung\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: Pete McCann , mip4@ietf.org, Vijay Devarapallli , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Nobody, that is why we are saying replace it with 0. You don't need additional replay protection when you are registering with HA directly. Madjid=20 -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Vijay Devarapalli Sent: Monday, November 07, 2005 1:28 PM To: Kent Leung (kleung) Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli; itijibox-mip4@yahoo.com Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Kent Leung (kleung) wrote: > On this particular topic, I don't understand what is missing in the=20 > details to support the CCoA mode? Since the draft covers MN-AAA=20 > authentication with NAS in between, I would like to see both FA (CoA)=20 > and HA (CCoA) modes supported. Where else would we be able to cover=20 > just the CCoA for MN-AAA authentication if not in this draft? for e.g. who generates the challenge in co-located mode? Vijay >=20 > Kent >=20 >=20 >=20 >>not at this late stage. its fine as it is. however, I have one comment >>on the support for co-located CoA mode. the draft claims it supports=20 >>it but there really isnt enough detail. >>IMO, it should be clarified that only FA mode is described in the=20 >>draft. >> >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 19:48:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHel-00025O-7V; Mon, 07 Nov 2005 19:48:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHej-00025J-Cq for mip4@megatron.ietf.org; Mon, 07 Nov 2005 19:48:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27206 for ; Mon, 7 Nov 2005 19:47:42 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZHuP-0000Ji-Sw for mip4@ietf.org; Mon, 07 Nov 2005 20:04:23 -0500 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA810MGR028649 for ; Mon, 7 Nov 2005 18:00:22 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id jA80wVen029158 for ; Mon, 7 Nov 2005 18:58:31 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 7 Nov 2005 19:47:57 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXj0YCMRx3ZIv0kROa5cc2oQ10H5QAACB9gAAsX7xA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Kent Leung \(kleung\)" , "Vijay Devarapalli" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Cc: Pete McCann , mip4@ietf.org, Vijay Devarapallli , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Nope, the RRQ with HA is already protected through 3344 mechanisms. No need for this.=20 -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Kent Leung (kleung) Sent: Monday, November 07, 2005 1:36 PM To: Vijay Devarapalli Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli; itijibox-mip4@yahoo.com Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt OK. Since this registration exchange is between MN and HA, I expect that MN would generate some random number in Challenge value. All implementations that I'm aware of do this. "The mechanism used by the mobile node to obtain the Challenge value in this case is outside the scope of this document." But the point is mute since there won't be any Challenge value if the new scheme of zero in place of Challenge for authentication is adopted. Kent > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Monday, November 07, 2005 11:28 AM > To: Kent Leung (kleung) > Cc: Vijay Devarapallli; Pete McCann; mip4@ietf.org;=20 > itijibox-mip4@yahoo.com > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > Kent Leung (kleung) wrote: > > On this particular topic, I don't understand what is missing in the=20 > > details to support the CCoA mode? Since the draft covers MN-AAA=20 > > authentication with NAS in between, I would like to see > both FA (CoA) > > and HA (CCoA) modes supported. Where else would we be able > to cover > > just the CCoA for MN-AAA authentication if not in this draft? >=20 > for e.g. who generates the challenge in co-located mode? >=20 > Vijay >=20 > >=20 > > Kent > >=20 > >=20 > >=20 > >>not at this late stage. its fine as it is. however, I have > one comment > >>on the support for co-located CoA mode. the draft claims it > supports > >>it but there really isnt enough detail. > >>IMO, it should be clarified that only FA mode is described in the=20 > >>draft. > >> > >=20 > >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 19:49:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHgB-0002LQ-7k; Mon, 07 Nov 2005 19:49:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHg9-0002KZ-QN for mip4@megatron.ietf.org; Mon, 07 Nov 2005 19:49:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27247 for ; Mon, 7 Nov 2005 19:49:11 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZHvq-0000LY-SI for mip4@ietf.org; Mon, 07 Nov 2005 20:05:52 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA811p0l028748 for ; Mon, 7 Nov 2005 18:01:51 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id jA80wdW1000561 for ; Mon, 7 Nov 2005 18:58:39 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 7 Nov 2005 19:49:19 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXj0uv2NtepkstSTLC63hLMNqkEgwAAVVggAAp39LA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Yoshi Tsuda \(yotsuda\)" , "Vijay Devarapalli" , "Kent Leung \(kleung\)" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: Pete McCann , mip4@ietf.org, Vijay Devarapallli , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Folks lets not get creative here. 3012 challenge was created because only HA and home network was protected but foreign network was not,.. -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Yoshi Tsuda (yotsuda) Sent: Monday, November 07, 2005 2:17 PM To: Vijay Devarapalli; Kent Leung (kleung) Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli; itijibox-mip4@yahoo.com Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Hi Vijay, Even in co-located mode, you know, an FA can push challenge to an MN by setting R-bit and challenge in agent advertisements. Do you need pushing challenge from an HA to an MN, instead ? If so, Kent has already mentioned one option. If you want to push challenge from an HA to an MN really, say MS CHAPv2, we want you describe such a scenario in order to review it. At the time when we defined and did interoperability tests about rfc3012, we assumed visiting subnets need some guard by challenge. Pushing challenge really from an HA to an MN is beyond our assumptions at that time. I prefer a new rfc rather than updating rfc3012, because in such a case we would probably need more functions, such as some guard against losing challenge on an MN. Thanks. -Yoshi > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf=20 > Of Vijay Devarapalli > Sent: Monday, November 07, 2005 11:28 AM > To: Kent Leung (kleung) > Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli;=20 > itijibox-mip4@yahoo.com > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > Kent Leung (kleung) wrote: > > On this particular topic, I don't understand what is missing in the=20 > > details to support the CCoA mode? Since the draft covers MN-AAA=20 > > authentication with NAS in between, I would like to see > both FA (CoA) > > and HA (CCoA) modes supported. Where else would we be able > to cover > > just the CCoA for MN-AAA authentication if not in this draft? >=20 > for e.g. who generates the challenge in co-located mode? >=20 > Vijay >=20 > >=20 > > Kent > >=20 > >=20 > >=20 > >>not at this late stage. its fine as it is. however, I have > one comment > >>on the support for co-located CoA mode. the draft claims it > supports > >>it but there really isnt enough detail. > >>IMO, it should be clarified that only FA mode is described in the=20 > >>draft. > >> > >=20 > >=20 >=20 >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 19:55:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHlb-0003MZ-6n; Mon, 07 Nov 2005 19:55:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHlZ-0003MU-Vs for mip4@megatron.ietf.org; Mon, 07 Nov 2005 19:55:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27516 for ; Mon, 7 Nov 2005 19:54:47 -0500 (EST) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZI19-0000TX-NV for mip4@ietf.org; Mon, 07 Nov 2005 20:11:28 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id jA81AaOP022935 for ; Mon, 7 Nov 2005 18:10:36 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id jA8126tZ007261 for ; Mon, 7 Nov 2005 19:02:07 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 7 Nov 2005 19:54:47 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXj59lK7iOOxZWpSj6CALJnEMPCIQAAOnhQAALFKyAAArA8AA== From: "Nakhjiri Madjid-MNAKHJI1" To: "Yoshi Tsuda \(yotsuda\)" , "Jayshree Bharatia" , "Vijay Devarapalli" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: quoted-printable Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, Pete McCann , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org I am not sure splitting an RFC merely because it covers two related topics warrants 2 more years of delay. BTW, I am guessing people who are suggesting a new RFC are volunteering editorship out of their own time budget for the next 2 years, is this true?? =20 -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Yoshi Tsuda (yotsuda) Sent: Monday, November 07, 2005 6:00 PM To: Jayshree Bharatia; Vijay Devarapalli Cc: Kent Leung (kleung); mip4@ietf.org; Pete McCann; itijibox-mip4@yahoo.com Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Hi Jayshree and Vijay,=20 Glad to know Jayshree has a mind to keep upgrading the draft. :) But, to support challenge mentioned by Vijay, we would definitely need some more functions than existing and having been tested functions in rfc3012, which need to be verified in a future interoperability test. So would like to know whether it is better to have a new rfc or updating rfc3012. Personally, I think, it's better to have a new rfc. Thanks. -Yoshi > -----Original Message----- > From: Jayshree Bharatia [mailto:jayshree@nortel.com] > Sent: Monday, November 07, 2005 2:45 PM > To: Vijay Devarapalli; Yoshi Tsuda (yotsuda) > Cc: Kent Leung (kleung); mip4@ietf.org; Pete McCann;=20 > itijibox-mip4@yahoo.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > Vijay, >=20 > I agree that having co-located CoA support information in this draft=20 > is confusing. We added co-located CoA support at the later time as a=20 > result of comments (rather long debate!) we had on the mailing list.=20 > At that time, it was decided not to limit the use of this mechanism=20 > (use of the MN-AAA > extension) given that challenges are generated by some other means and > make them available at the MN. >=20 > I am open to any suggestions which may clarify the scope better. >=20 > Regards, > Jayshree >=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf=20 > Of Vijay Devarapalli > Sent: Monday, November 07, 2005 4:07 PM > To: Yoshi Tsuda (yotsuda) > Cc: Kent Leung (kleung); mip4@ietf.org; Pete McCann;=20 > itijibox-mip4@yahoo.com > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 >=20 > Yoshi Tsuda (yotsuda) wrote: > > Hi Vijay, > >=20 > > Even in co-located mode, you know, an FA can push > challenge to an MN > > by setting R-bit and challenge in agent advertisements. >=20 > in co-located mode, I am assuming there are networks with no FA. >=20 > > Do you need pushing challenge from an HA to an MN, instead ? >=20 > nope. >=20 > If so, Kent has already mentioned one option. >=20 > I dont think the MN itself generating the challenge is a solution. >=20 > > If you want to push challenge from an HA to an MN really, say MS=20 > > CHAPv2, we want you describe such a scenario in order to review it. >=20 > I wanted the draft actually to say that the challenge/response=20 > mechanism is specified only for FA mode. > for co-located mode, it could be out of scope for this draft.=20 > the draft currently claims that it supports co-located mode too. I am=20 > objecting to that. >=20 > > At the time when we defined and did interoperability tests about=20 > > rfc3012, we assumed visiting subnets need some guard by challenge. > > Pushing challenge really from an HA to an MN is beyond our=20 > > assumptions at that time. I prefer a new rfc rather than updating=20 > > rfc3012, because in such a case we would probably need more=20 > > functions, such as some guard against losing challenge on an MN. >=20 > ok. >=20 > Vijay >=20 > >=20 > > Thanks. > > -Yoshi > >=20 > >=20 > >>-----Original Message----- > >>From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] > On Behalf > >>Of Vijay Devarapalli > >>Sent: Monday, November 07, 2005 11:28 AM > >>To: Kent Leung (kleung) > >>Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli;=20 > >>itijibox-mip4@yahoo.com > >>Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > >> > >>Kent Leung (kleung) wrote: > >> > >>>On this particular topic, I don't understand what is > missing in the > >>>details to support the CCoA mode? Since the draft covers MN-AAA=20 > >>>authentication with NAS in between, I would like to see > >> > >>both FA (CoA) > >> > >>>and HA (CCoA) modes supported. Where else would we be able > >> > >>to cover > >> > >>>just the CCoA for MN-AAA authentication if not in this draft? > >> > >>for e.g. who generates the challenge in co-located mode? > >> > >>Vijay > >> > >> > >>>Kent > >>> > >>> > >>> > >>> > >>>>not at this late stage. its fine as it is. however, I have > >> > >>one comment > >> > >>>>on the support for co-located CoA mode. the draft claims it > >> > >>supports > >> > >>>>it but there really isnt enough detail. > >>>>IMO, it should be clarified that only FA mode is described in the=20 > >>>>draft. > >>>> > >>> > >>> > >> > >> > >>-- > >>Mip4 mailing list: Mip4@ietf.org > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >> Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > >>Supplemental site: http://www.mip4.org/ > >> >=20 >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 20:04:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHuK-00063H-2A; Mon, 07 Nov 2005 20:04:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHuI-00063C-UX for mip4@megatron.ietf.org; Mon, 07 Nov 2005 20:04:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27910 for ; Mon, 7 Nov 2005 20:03:48 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZI9u-0000gt-Mp for mip4@ietf.org; Mon, 07 Nov 2005 20:20:29 -0500 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id jA81RaUB007945 for ; Mon, 7 Nov 2005 18:27:36 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id jA81Bt8d003462 for ; Mon, 7 Nov 2005 19:11:56 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 7 Nov 2005 20:03:53 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXj+XwsTH1zH4QJSu2M3zwvTd+NYAABZ19g From: "Nakhjiri Madjid-MNAKHJI1" To: "Vijay Devarapalli" , "Jayshree Bharatia" X-Spam-Score: 0.0 (/) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b Content-Transfer-Encoding: quoted-printable Cc: "Kent Leung \(kleung\)" , mip4@ietf.org, "Yoshi Tsuda \(yotsuda\)" , Pete McCann , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Thanks Vijay for the flattering comments on the RADIUS-MIP draft. RADIUS-MIP has a long bumpy road ahead and it really intends to explain the RADIUS sides of things, rather than the Mobile IP side. Calculation MN-AAA AE for two MIPv4 modes is really the job of MIP WGs not RADEXT. We solved the problem just because it was offered nowhere else and after we did it, we thought this is really a small fix to RFC3012bis and should go into that doc so that MIPv4 would have a clean set of specifications. I am just suggesting to do this in the interest of expediency. A lot of SDOs depend on these specs (3GPP2 and WiMAX are two examples), delaying 3012bis would do a big disservice to these SDOs. Madjid=20 -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Vijay Devarapalli Sent: Monday, November 07, 2005 6:12 PM To: Jayshree Bharatia Cc: Kent Leung (kleung); mip4@ietf.org; Yoshi Tsuda (yotsuda); Pete McCann; itijibox-mip4@yahoo.com Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Jayshree Bharatia wrote: > Vijay, >=20 > I agree that having co-located CoA support information in this draft=20 > is confusing. We added co-located CoA support at the later time as a=20 > result of comments (rather long debate!) we had on the mailing list.=20 > At that time, it was decided not to limit the use of this mechanism=20 > (use of the MN-AAA extension) given that challenges are generated by=20 > some other means and make them available at the MN. >=20 > I am open to any suggestions which may clarify the scope better. IMHO, this what we should do - clarify that 3012bis only addresses using the FA challenge/response extension in FA CoA mode. co-located CoA mode is not supported. - mention that the MN-AAA extension can be used in co-located CoA mode, but the actual details are out of scope for 3012bis. RFC 3957 also does a poor job of describing the co-located CoA mode. the RADIUS MIPv4 extensions draft, draft-nakhjiri-radius-mip4-02.txt, does a better job of describing how the MN-AAA extension can be used between the MN and the HA along with RFC 3957. IMO, thats the best reference today. I think draft-nakhjiri is also the wrong place for this. it should be in a separate draft. my 2 cents. Vijay >=20 > Regards, > Jayshree >=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf=20 > Of Vijay Devarapalli > Sent: Monday, November 07, 2005 4:07 PM > To: Yoshi Tsuda (yotsuda) > Cc: Kent Leung (kleung); mip4@ietf.org; Pete McCann;=20 > itijibox-mip4@yahoo.com > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 >=20 > Yoshi Tsuda (yotsuda) wrote: >=20 >>Hi Vijay, >> >> Even in co-located mode, you know, an FA can push challenge to an MN=20 >> by setting R-bit and challenge in agent advertisements. >=20 >=20 > in co-located mode, I am assuming there are networks with no FA. >=20 >=20 >> Do you need pushing challenge from an HA to an MN, instead ? >=20 >=20 > nope. >=20 > If so, Kent has already mentioned one option. >=20 > I dont think the MN itself generating the challenge > is a solution. >=20 >=20 >> If you want to push challenge from an HA to an MN really, say MS=20 >>CHAPv2, we want you describe such a scenario in order to review it. >=20 >=20 > I wanted the draft actually to say that the > challenge/response mechanism is specified only for > FA mode. for co-located mode, it could be out of > scope for this draft. the draft currently claims > that it supports co-located mode too. I am objecting > to that. >=20 >=20 >> At the time when we defined and did interoperability tests about=20 >>rfc3012, we assumed visiting subnets need some guard by challenge. =20 >>Pushing challenge really from an HA to an MN is beyond our=20 >>assumptions at that time. I prefer a new rfc rather than updating=20 >>rfc3012, because in such a case we would probably need more=20 >>functions, such as some guard against losing challenge on an MN. >=20 >=20 > ok. >=20 > Vijay >=20 >=20 >>Thanks. >>-Yoshi >> >> >> >>>-----Original Message----- >>>From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On >>>Behalf Of Vijay Devarapalli >>>Sent: Monday, November 07, 2005 11:28 AM >>>To: Kent Leung (kleung) >>>Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli;=20 >>>itijibox-mip4@yahoo.com >>>Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >>> >>>Kent Leung (kleung) wrote: >>> >>> >>>>On this particular topic, I don't understand what is missing in the >>>>details to support the CCoA mode? Since the draft covers MN-AAA=20 >>>>authentication with NAS in between, I would like to see=20 >>> >>>both FA (CoA) >>> >>> >>>>and HA (CCoA) modes supported. Where else would we be able >>> >>>to cover >>> >>> >>>>just the CCoA for MN-AAA authentication if not in this draft? >>> >>>for e.g. who generates the challenge in co-located mode? >>> >>>Vijay >>> >>> >>> >>>>Kent >>>> >>>> >>>> >>>> >>>> >>>>>not at this late stage. its fine as it is. however, I have >>> >>>one comment >>> >>> >>>>>on the support for co-located CoA mode. the draft claims it >>> >>>supports >>> >>> >>>>>it but there really isnt enough detail. >>>>>IMO, it should be clarified that only FA mode is described in the >>>>>draft. >>>>> >>>> >>>> >>> >>>-- >>>Mip4 mailing list: Mip4@ietf.org >>> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >>> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>>Supplemental site: http://www.mip4.org/ >>> >=20 >=20 >=20 >=20 --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 07 21:40:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJPF-0000dB-Jw; Mon, 07 Nov 2005 21:40:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJPE-0000bg-LB for mip4@megatron.ietf.org; Mon, 07 Nov 2005 21:40:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03567 for ; Mon, 7 Nov 2005 21:39:49 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZJex-0003Db-Ir for mip4@ietf.org; Mon, 07 Nov 2005 21:56:31 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2005 18:40:07 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jA82dhKO018391; Mon, 7 Nov 2005 18:40:05 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 18:40:01 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 7 Nov 2005 18:40:00 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52E2A541@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXhnwx20yALBVMMQQSmHVn/apqA9ACIp7kAAA76elAAA/UEcA== From: "Kent Leung \(kleung\)" To: "Nakhjiri Madjid-MNAKHJI1" , "Vijay Devarapallli" , "Pete McCann" X-OriginalArrivalTime: 08 Nov 2005 02:40:01.0999 (UTC) FILETIME=[B7D785F0:01C5E40D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org I agree with this sentiment. Unless there's an issue with using zero for Challenge value in the calculation for CCoA mode, this problem will be addressed in the draft. The challenge is not needed for CCoA mode since there's already Timestamp/Nonce replay protection. Kent=20 > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]=20 > Sent: Monday, November 07, 2005 4:46 PM > To: Kent Leung (kleung); Vijay Devarapallli; Pete McCann > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > The fix to deal with CCoA is a very small one as I mentioned=20 > my previous email. I really don't think it warrants a huge=20 > discussion or a doc split. The fix that we suggested was=20 > agreed by Charlie as well. >=20 > Madjid > =20 >=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Kent Leung (kleung) > Sent: Monday, November 07, 2005 11:42 AM > To: Vijay Devarapallli; Pete McCann > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > On this particular topic, I don't understand what is missing=20 > in the details to support the CCoA mode? Since the draft=20 > covers MN-AAA authentication with NAS in between, I would=20 > like to see both FA (CoA) and HA (CCoA) modes supported. =20 > Where else would we be able to cover just the CCoA for MN-AAA=20 > authentication if not in this draft? >=20 > Kent >=20 >=20 > >=20 > > not at this late stage. its fine as it is. however, I have=20 > one comment >=20 > > on the support for co-located CoA mode. the draft claims it=20 > supports=20 > > it but there really isnt enough detail. > > IMO, it should be clarified that only FA mode is described in the=20 > > draft. > >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 08 05:48:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZR1Q-0003cW-HL; Tue, 08 Nov 2005 05:48:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZR1N-0003cD-Rg for mip4@megatron.ietf.org; Tue, 08 Nov 2005 05:48:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28088 for ; Tue, 8 Nov 2005 05:47:42 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZRH9-0007p8-8R for mip4@ietf.org; Tue, 08 Nov 2005 06:04:27 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jA8AeLj29687; Tue, 8 Nov 2005 05:40:21 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Tue, 8 Nov 2005 04:40:19 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710B5A5B89@zrc2hxm2.corp.nortel.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXhnwx20yALBVMMQQSmHVn/apqA9ACIp7kAAA76elAAA/UEcAAQYO3g From: "Ahmad Muhanna" To: "Kent Leung \(kleung\)" , "Nakhjiri Madjid-MNAKHJI1" , "Vijay Devarapallli" , "Pete McCann" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org All, I was under the impression that using MN-AAA (in CCoA)is for authenticating RRQ which is needed when HA needs to authenticate MN through AAA infrastructure, same way as the FA. Although, RRQ could be protected using MN-HA Auth extension but I remember the discussion was that there could be an RRQ with one authorization enabling extension or HA does not locally maintain a security association with the MN and it uses AAA for authenticating the MN. Also, HA could get an RRQ with a MN-AAA extension only, as I remember. =20 In this case, HA needs to use the same mechanism introduced by this draft to authenticate the MN via AAA. This is has nothing to do with the replay protection which is done via the RRQ ID (time stamp/nonce). I think, there was a long debate why to leave the MN to generate its own challenge. Well, since the HA is not using this challenge for replay protection but for authenticating the MN, then there is no harm by allowing the MN to generate its own challenge. I disagree with the suggestion of allowing the MN to use a value of zero for the challenge in this case. This will generate a very weak authenticator. My 2 cents. Regards, Ahmad > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Kent Leung (kleung) > Sent: Monday, November 07, 2005 8:40 PM > To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli; Pete McCann > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 >=20 > I agree with this sentiment. Unless there's an issue with=20 > using zero for Challenge value in the calculation for CCoA=20 > mode, this problem will be addressed in the draft. The=20 > challenge is not needed for CCoA mode since there's already=20 > Timestamp/Nonce replay protection. >=20 > Kent=20 >=20 > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Monday, November 07, 2005 4:46 PM > > To: Kent Leung (kleung); Vijay Devarapallli; Pete McCann > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > >=20 > > The fix to deal with CCoA is a very small one as I mentioned > > my previous email. I really don't think it warrants a huge=20 > > discussion or a doc split. The fix that we suggested was=20 > > agreed by Charlie as well. > >=20 > > Madjid > > =20 > >=20 > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > > Behalf Of Kent Leung (kleung) > > Sent: Monday, November 07, 2005 11:42 AM > > To: Vijay Devarapallli; Pete McCann > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > >=20 > > On this particular topic, I don't understand what is missing > > in the details to support the CCoA mode? Since the draft=20 > > covers MN-AAA authentication with NAS in between, I would=20 > > like to see both FA (CoA) and HA (CCoA) modes supported. =20 > > Where else would we be able to cover just the CCoA for MN-AAA=20 > > authentication if not in this draft? > >=20 > > Kent > >=20 > >=20 > > >=20 > > > not at this late stage. its fine as it is. however, I have > > one comment > >=20 > > > on the support for co-located CoA mode. the draft claims it > > supports > > > it but there really isnt enough detail. > > > IMO, it should be clarified that only FA mode is described in the > > > draft. > > >=20 > >=20 > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-> charter.html > >=20 > Supplemental site: http://www.mip4.org/ > >=20 >=20 >=20 > --=20 > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 08 06:41:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZRql-0006Sm-Cc; Tue, 08 Nov 2005 06:41:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZRqk-0006Sh-6K for mip4@megatron.ietf.org; Tue, 08 Nov 2005 06:41:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00051 for ; Tue, 8 Nov 2005 06:40:48 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZS6W-0000TH-VO for mip4@ietf.org; Tue, 08 Nov 2005 06:57:34 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2005 03:41:04 -0800 X-IronPort-AV: i="3.97,304,1125903600"; d="scan'208"; a="228048271:sNHT44113266" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA8Bf0Nl004990; Tue, 8 Nov 2005 03:41:01 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 03:41:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Tue, 8 Nov 2005 03:40:58 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52E2A5DC@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXhnwx20yALBVMMQQSmHVn/apqA9ACIp7kAAA76elAAA/UEcAAQYO3gAAHylrA= From: "Kent Leung \(kleung\)" To: "Ahmad Muhanna" , "Nakhjiri Madjid-MNAKHJI1" , "Vijay Devarapallli" , "Pete McCann" X-OriginalArrivalTime: 08 Nov 2005 11:41:00.0585 (UTC) FILETIME=[4AAAB190:01C5E459] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Ahmad. >=20 > I was under the impression that using MN-AAA (in CCoA)is for=20 > authenticating RRQ which is needed when HA needs to=20 > authenticate MN through AAA infrastructure, same way as the=20 > FA. Although, RRQ could be protected using MN-HA Auth=20 > extension but I remember the discussion was that there could=20 > be an RRQ with one authorization enabling extension or HA=20 > does not locally maintain a security association with the MN=20 > and it uses AAA for authenticating the MN. Also, HA could get=20 > an RRQ with a MN-AAA extension only, as I remember. > =20 Right, MN-AAA Authentication Extension is used by AAA server to authenticate MN (and in effect, authenticate the RRQ). FA and HA is the NAS (i.e. AAA client). > In this case, HA needs to use the same mechanism introduced=20 > by this draft to authenticate the MN via AAA. HA needs to map fields in the RRQ to RADIUS attributes. > This is has nothing to do with the replay protection which is=20 > done via the RRQ ID (time stamp/nonce). >=20 The challenge value is used for replay protect between MN and FA because there wasn't any before RFC 3012. The ID field is for replay protection between MN and HA. > I think, there was a long debate why to leave the MN to=20 > generate its own challenge. Well, since the HA is not using=20 > this challenge for replay protection but for authenticating=20 > the MN, then there is no harm by allowing the MN to generate=20 > its own challenge. >=20 There's no harm, but also no technical value. By having adding the MN-FA Challenge Ext, it was easy for HA to map the RRQ fields/exts to RADIUS attributes and follow the authentication algorithm in RFC 3012. But I don't see this is necessary if we specify that MN does not add the MFCE in RRQ sent directly to HA, and HA sets challenge to zero when MFCE is not in RRQ. > I disagree with the suggestion of allowing the MN to use a=20 > value of zero for the challenge in this case. This will=20 > generate a very weak authenticator. >=20 How does this make a very weak authenticator? Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 08 07:03:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZSBy-0003Cp-60; Tue, 08 Nov 2005 07:03:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZSBu-0003Ch-7w for mip4@megatron.ietf.org; Tue, 08 Nov 2005 07:03:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01024 for ; Tue, 8 Nov 2005 07:02:40 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZSRi-0000v4-52 for mip4@ietf.org; Tue, 08 Nov 2005 07:19:26 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 08 Nov 2005 04:02:57 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA8C2iO1022023; Tue, 8 Nov 2005 04:02:54 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Nov 2005 04:02:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Tue, 8 Nov 2005 04:02:51 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52E2A5E2@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXj0uv2NtepkstSTLC63hLMNqkEgwAAVVggACG0lrA= From: "Kent Leung \(kleung\)" To: "Yoshi Tsuda \(yotsuda\)" , "Vijay Devarapalli" X-OriginalArrivalTime: 08 Nov 2005 12:02:53.0707 (UTC) FILETIME=[595935B0:01C5E45C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Cc: Pete McCann , mip4@ietf.org, Vijay Devarapallli , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Yoshi. You raised a good point about the R-bit. I would categorize the two types of registrations: 1) Direct registration. This is when MN sends a RRQ directly to the HA. It is only for CCoA mode. I don't think MFCE is needed to be appended in the message and authentication algorithm can have challenge value set to zero. 2) Relayed registration. FA relays RRQ from MN to the HA. This is for both FA CoA mode and CCoA mode (R-bit advertised). Since the challenge is replay protection for the leg between MN and FA of the registration, MFCE must always be included in the RRQ and authentication algorithm follows RFC 3012. Kent=20 > -----Original Message----- > From: Yoshi Tsuda (yotsuda)=20 > Sent: Monday, November 07, 2005 12:17 PM > To: Vijay Devarapalli; Kent Leung (kleung) > Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli;=20 > itijibox-mip4@yahoo.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > Hi Vijay, >=20 > Even in co-located mode, you know, an FA can push challenge=20 > to an MN by setting R-bit and challenge in agent advertisements. >=20 > Do you need pushing challenge from an HA to an MN, instead=20 > ? If so, Kent has already mentioned one option. > If you want to push challenge from an HA to an MN really, =20 > say MS CHAPv2, we want you describe such a scenario in order=20 > to review it. > At the time when we defined and did interoperability tests =20 > about rfc3012, we assumed visiting subnets need some guard=20 > by challenge. Pushing challenge really from an HA to an MN=20 > is beyond our assumptions at that time. I prefer a new rfc=20 > rather than updating rfc3012, because in such a case we=20 > would probably need more functions, such as some guard=20 > against losing challenge on an MN. >=20 > Thanks. > -Yoshi >=20 > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org]=20 > On Behalf=20 > > Of Vijay Devarapalli > > Sent: Monday, November 07, 2005 11:28 AM > > To: Kent Leung (kleung) > > Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli;=20 > > itijibox-mip4@yahoo.com > > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > >=20 > > Kent Leung (kleung) wrote: > > > On this particular topic, I don't understand what is=20 > missing in the=20 > > > details to support the CCoA mode? Since the draft covers MN-AAA=20 > > > authentication with NAS in between, I would like to see > > both FA (CoA) > > > and HA (CCoA) modes supported. Where else would we be able > > to cover > > > just the CCoA for MN-AAA authentication if not in this draft? > >=20 > > for e.g. who generates the challenge in co-located mode? > >=20 > > Vijay > >=20 > > >=20 > > > Kent > > >=20 > > >=20 > > >=20 > > >>not at this late stage. its fine as it is. however, I have > > one comment > > >>on the support for co-located CoA mode. the draft claims it > > supports > > >>it but there really isnt enough detail. > > >>IMO, it should be clarified that only FA mode is described in the=20 > > >>draft. > > >> > > >=20 > > >=20 > >=20 > >=20 > >=20 > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 08 08:30:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZTYd-0007j5-73; Tue, 08 Nov 2005 08:30:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZTYZ-0007ij-TR for mip4@megatron.ietf.org; Tue, 08 Nov 2005 08:30:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06237 for ; Tue, 8 Nov 2005 08:30:08 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZToN-00042p-4S for mip4@ietf.org; Tue, 08 Nov 2005 08:46:56 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jA8DRJf03386; Tue, 8 Nov 2005 08:27:19 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Tue, 8 Nov 2005 07:29:53 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43710B5A5BDB@zrc2hxm2.corp.nortel.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXhnwx20yALBVMMQQSmHVn/apqA9ACIp7kAAA76elAAA/UEcAAQYO3gAAHylrAABDfSUA== From: "Ahmad Muhanna" To: "Kent Leung \(kleung\)" , "Nakhjiri Madjid-MNAKHJI1" , "Vijay Devarapallli" , "Pete McCann" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Kent, Comments inline. Regards, Ahmad >=20 >=20 > Hi Ahmad. >=20 > >=20 > > I was under the impression that using MN-AAA (in CCoA)is for > > authenticating RRQ which is needed when HA needs to=20 > > authenticate MN through AAA infrastructure, same way as the=20 > > FA. Although, RRQ could be protected using MN-HA Auth=20 > > extension but I remember the discussion was that there could=20 > > be an RRQ with one authorization enabling extension or HA=20 > > does not locally maintain a security association with the MN=20 > > and it uses AAA for authenticating the MN. Also, HA could get=20 > > an RRQ with a MN-AAA extension only, as I remember. > > =20 >=20 > Right, MN-AAA Authentication Extension is used by AAA server to > authenticate MN (and in effect, authenticate the RRQ). FA=20 > and HA is the > NAS (i.e. AAA client). >=20 >=20 > > In this case, HA needs to use the same mechanism introduced=20 > > by this draft to authenticate the MN via AAA. >=20 > HA needs to map fields in the RRQ to RADIUS attributes. >=20 >=20 > > This is has nothing to do with the replay protection which is=20 > > done via the RRQ ID (time stamp/nonce). > >=20 >=20 > The challenge value is used for replay protect between MN and=20 > FA because > there wasn't any before RFC 3012. The ID field is for replay=20 > protection > between MN and HA. >=20 >=20 > > I think, there was a long debate why to leave the MN to=20 > > generate its own challenge. Well, since the HA is not using=20 > > this challenge for replay protection but for authenticating=20 > > the MN, then there is no harm by allowing the MN to generate=20 > > its own challenge. > >=20 >=20 > There's no harm, but also no technical value. By having adding the > MN-FA Challenge Ext, it was easy for HA to map the RRQ fields/exts to > RADIUS attributes and follow the authentication algorithm in RFC 3012. > But I don't see this is necessary if we specify that MN does=20 > not add the > MFCE in RRQ sent directly to HA, and HA sets challenge to=20 > zero when MFCE > is not in RRQ. [Ahmad] Makes sense. I agree to make it optional and in case not present, the assumption is 0. >=20 >=20 > > I disagree with the suggestion of allowing the MN to use a=20 > > value of zero for the challenge in this case. This will=20 > > generate a very weak authenticator. > >=20 >=20 > How does this make a very weak authenticator? [Ahmad] You are right.=20 I take it back, my mind went blank for a second and thought that the challenge is not available for an attacker.=20 >=20 > Kent >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 08 12:00:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZWpT-0004yi-13; Tue, 08 Nov 2005 12:00:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZWpJ-0004wc-5s for mip4@megatron.ietf.org; Tue, 08 Nov 2005 12:00:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17164 for ; Tue, 8 Nov 2005 11:59:38 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZX58-0000vk-CC for mip4@ietf.org; Tue, 08 Nov 2005 12:16:27 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id jA8Gr7f12396; Tue, 8 Nov 2005 11:53:07 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Tue, 8 Nov 2005 10:55:53 -0600 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXhnwx20yALBVMMQQSmHVn/apqA9ACIp7kAAA76elAAA/UEcAAdiBaA From: "Jayshree Bharatia" To: "Kent Leung \(kleung\)" , "Nakhjiri Madjid-MNAKHJI1" , "Vijay Devarapallli" , "Pete McCann" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org I am also ok with this suggestion. If it is agreed by all, I can change section 3.1 to reflect this change. Regards, Jayshree -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Kent Leung (kleung) Sent: Monday, November 07, 2005 8:40 PM To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli; Pete McCann Cc: mip4@ietf.org; itijibox-mip4@yahoo.com Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt I agree with this sentiment. Unless there's an issue with using zero for Challenge value in the calculation for CCoA mode, this problem will be addressed in the draft. The challenge is not needed for CCoA mode since there's already Timestamp/Nonce replay protection. Kent=20 > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Monday, November 07, 2005 4:46 PM > To: Kent Leung (kleung); Vijay Devarapallli; Pete McCann > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > The fix to deal with CCoA is a very small one as I mentioned > my previous email. I really don't think it warrants a huge=20 > discussion or a doc split. The fix that we suggested was=20 > agreed by Charlie as well. >=20 > Madjid > =20 >=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > Behalf Of Kent Leung (kleung) > Sent: Monday, November 07, 2005 11:42 AM > To: Vijay Devarapallli; Pete McCann > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > On this particular topic, I don't understand what is missing > in the details to support the CCoA mode? Since the draft=20 > covers MN-AAA authentication with NAS in between, I would=20 > like to see both FA (CoA) and HA (CCoA) modes supported. =20 > Where else would we be able to cover just the CCoA for MN-AAA=20 > authentication if not in this draft? >=20 > Kent >=20 >=20 > >=20 > > not at this late stage. its fine as it is. however, I have > one comment >=20 > > on the support for co-located CoA mode. the draft claims it > supports > > it but there really isnt enough detail. > > IMO, it should be clarified that only FA mode is described in the > > draft. > >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 08 12:01:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZWqx-0005I3-IW; Tue, 08 Nov 2005 12:01:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZWqu-0005Hg-3b for mip4@megatron.ietf.org; Tue, 08 Nov 2005 12:01:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17259 for ; Tue, 8 Nov 2005 12:01:17 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZX6k-0000yq-0j for mip4@ietf.org; Tue, 08 Nov 2005 12:18:06 -0500 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-3.cisco.com with ESMTP; 08 Nov 2005 09:00:48 -0800 X-IronPort-AV: i="3.97,305,1125903600"; d="scan'208"; a="362351129:sNHT1389678054" Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jA8H0CDY026420; Wed, 9 Nov 2005 01:00:13 +0800 (CST) Received: from xmb-hkg-416.apac.cisco.com ([64.104.123.88]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 9 Nov 2005 01:00:41 +0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Wed, 9 Nov 2005 01:00:37 +0800 Message-ID: <35912544FC930E49BF20EF16C3EF27658A9739@xmb-hkg-416.apac.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXj0uv2NtepkstSTLC63hLMNqkEgwAAVVggACG0lrAACkfhIA== From: "Yoshi Tsuda \(yotsuda\)" To: "Kent Leung \(kleung\)" , "Vijay Devarapalli" X-OriginalArrivalTime: 08 Nov 2005 17:00:41.0276 (UTC) FILETIME=[F33FDFC0:01C5E485] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: Pete McCann , mip4@ietf.org, Vijay Devarapallli , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Kent, Thank you for your qualification. Based on the policy of foreign subnets, some subnets can request MNs to include MFCE even in case of CCoA mode. For those subnets, they can filter away (1). They can only relay (2) to an HA in case there is MFCE. From my memory, this scinario was confirmed in the interoperability test at Sun couple years ago. Thanks. -Yoshi > -----Original Message----- > From: Kent Leung (kleung)=20 > Sent: Tuesday, November 08, 2005 4:03 AM > To: Yoshi Tsuda (yotsuda); 'Vijay Devarapalli' > Cc: 'Pete McCann'; 'mip4@ietf.org'; 'Vijay Devarapallli';=20 > 'itijibox-mip4@yahoo.com' > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > Hi Yoshi. You raised a good point about the R-bit. >=20 > I would categorize the two types of registrations: >=20 > 1) Direct registration. >=20 > This is when MN sends a RRQ directly to the HA. It is only=20 > for CCoA mode. I don't think MFCE is needed to be appended=20 > in the message and authentication algorithm can have=20 > challenge value set to zero. >=20 > 2) Relayed registration. >=20 > FA relays RRQ from MN to the HA. This is for both FA CoA=20 > mode and CCoA mode (R-bit advertised). Since the challenge=20 > is replay protection for the leg between MN and FA of the=20 > registration, MFCE must always be included in the RRQ and=20 > authentication algorithm follows RFC 3012. >=20 > Kent=20 >=20 > > -----Original Message----- > > From: Yoshi Tsuda (yotsuda) > > Sent: Monday, November 07, 2005 12:17 PM > > To: Vijay Devarapalli; Kent Leung (kleung) > > Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli;=20 > > itijibox-mip4@yahoo.com > > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > >=20 > > Hi Vijay, > >=20 > > Even in co-located mode, you know, an FA can push =20 > challenge to an MN=20 > > by setting R-bit and challenge in agent advertisements. > >=20 > > Do you need pushing challenge from an HA to an MN, =20 > instead ? If so,=20 > > Kent has already mentioned one option. > > If you want to push challenge from an HA to an MN really, say MS=20 > > CHAPv2, we want you describe such a scenario in order to review it. > > At the time when we defined and did interoperability tests about=20 > > rfc3012, we assumed visiting subnets need some guard by=20 > challenge. =20 > > Pushing challenge really from an HA to an MN is beyond our=20 > > assumptions at that time. I prefer a new rfc rather than updating=20 > > rfc3012, because in such a case we would probably need more=20 > > functions, such as some guard against losing challenge on an MN. > >=20 > > Thanks. > > -Yoshi > >=20 > > > -----Original Message----- > > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] > > On Behalf > > > Of Vijay Devarapalli > > > Sent: Monday, November 07, 2005 11:28 AM > > > To: Kent Leung (kleung) > > > Cc: Pete McCann; mip4@ietf.org; Vijay Devarapallli;=20 > > > itijibox-mip4@yahoo.com > > > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > >=20 > > > Kent Leung (kleung) wrote: > > > > On this particular topic, I don't understand what is > > missing in the > > > > details to support the CCoA mode? Since the draft=20 > covers MN-AAA=20 > > > > authentication with NAS in between, I would like to see > > > both FA (CoA) > > > > and HA (CCoA) modes supported. Where else would we be able > > > to cover > > > > just the CCoA for MN-AAA authentication if not in this draft? > > >=20 > > > for e.g. who generates the challenge in co-located mode? > > >=20 > > > Vijay > > >=20 > > > >=20 > > > > Kent > > > >=20 > > > >=20 > > > >=20 > > > >>not at this late stage. its fine as it is. however, I have > > > one comment > > > >>on the support for co-located CoA mode. the draft claims it > > > supports > > > >>it but there really isnt enough detail. > > > >>IMO, it should be clarified that only FA mode is=20 > described in the=20 > > > >>draft. > > > >> > > > >=20 > > > >=20 > > >=20 > > >=20 > > >=20 > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page:=20 > > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > >=20 > >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 08 13:29:10 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYDW-0006iC-M6; Tue, 08 Nov 2005 13:29:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZYDT-0006i3-Gu for mip4@megatron.ietf.org; Tue, 08 Nov 2005 13:29:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24224 for ; Tue, 8 Nov 2005 13:28:40 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZYTK-00043S-AX for mip4@ietf.org; Tue, 08 Nov 2005 13:45:30 -0500 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA8IfHUV013121 for ; Tue, 8 Nov 2005 11:41:17 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id jA8IdbT1018268 for ; Tue, 8 Nov 2005 12:39:37 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Tue, 8 Nov 2005 13:28:49 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXhnwx20yALBVMMQQSmHVn/apqA9ACIp7kAAA76elAAA/UEcAAQYO3gABCOg0A= From: "Nakhjiri Madjid-MNAKHJI1" To: "Ahmad Muhanna" , "Kent Leung \(kleung\)" , "Vijay Devarapallli" , "Pete McCann" X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable Cc: Nakhjiri Madjid-MNAKHJI1 , mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Lets ponder what challenge mean? And what does it mean if MN generates a challenge that was meant to challenge the MN itself?=20 Even if we allow that, what is the checking mechanism for the challenge, the MN may generate a challenge once and use it for 3 years to come.=20 We don't want to burden the AAA with checking the freshness of the challenge, because that just create too much work for AAA.=20 The current MIP specs don't have a method for checking the freshness of a challenge created by the mobile. So in the absence of a robust freshness check infrastructure, a challenge that is used 10 times adds no more value than a zero, so either fix the freshness check across the entire MIP infrastructure, or make the hash stronger, until I see a well thought and complete solutions, I am not convinced we have a better option.. -----Original Message----- From: Ahmad Muhanna [mailto:amuhanna@nortel.com]=20 Sent: Tuesday, November 08, 2005 4:40 AM To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli; Pete McCann Cc: mip4@ietf.org; itijibox-mip4@yahoo.com Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt All, I was under the impression that using MN-AAA (in CCoA)is for authenticating RRQ which is needed when HA needs to authenticate MN through AAA infrastructure, same way as the FA. Although, RRQ could be protected using MN-HA Auth extension but I remember the discussion was that there could be an RRQ with one authorization enabling extension or HA does not locally maintain a security association with the MN and it uses AAA for authenticating the MN. Also, HA could get an RRQ with a MN-AAA extension only, as I remember. =20 In this case, HA needs to use the same mechanism introduced by this draft to authenticate the MN via AAA. This is has nothing to do with the replay protection which is done via the RRQ ID (time stamp/nonce). I think, there was a long debate why to leave the MN to generate its own challenge. Well, since the HA is not using this challenge for replay protection but for authenticating the MN, then there is no harm by allowing the MN to generate its own challenge. I disagree with the suggestion of allowing the MN to use a value of zero for the challenge in this case. This will generate a very weak authenticator. My 2 cents. Regards, Ahmad > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf=20 > Of Kent Leung (kleung) > Sent: Monday, November 07, 2005 8:40 PM > To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli; Pete McCann > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 >=20 > I agree with this sentiment. Unless there's an issue with using zero=20 > for Challenge value in the calculation for CCoA mode, this problem=20 > will be addressed in the draft. The challenge is not needed for CCoA=20 > mode since there's already Timestamp/Nonce replay protection. >=20 > Kent >=20 > > -----Original Message----- > > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > > Sent: Monday, November 07, 2005 4:46 PM > > To: Kent Leung (kleung); Vijay Devarapallli; Pete McCann > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > >=20 > > The fix to deal with CCoA is a very small one as I mentioned my=20 > > previous email. I really don't think it warrants a huge discussion=20 > > or a doc split. The fix that we suggested was agreed by Charlie as=20 > > well. > >=20 > > Madjid > > =20 > >=20 > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf > > Of Kent Leung (kleung) > > Sent: Monday, November 07, 2005 11:42 AM > > To: Vijay Devarapallli; Pete McCann > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > >=20 > > On this particular topic, I don't understand what is missing in the=20 > > details to support the CCoA mode? Since the draft covers MN-AAA=20 > > authentication with NAS in between, I would like to see both FA=20 > > (CoA) and HA (CCoA) modes supported. > > Where else would we be able to cover just the CCoA for MN-AAA=20 > > authentication if not in this draft? > >=20 > > Kent > >=20 > >=20 > > >=20 > > > not at this late stage. its fine as it is. however, I have > > one comment > >=20 > > > on the support for co-located CoA mode. the draft claims it > > supports > > > it but there really isnt enough detail. > > > IMO, it should be clarified that only FA mode is described in the=20 > > > draft. > > >=20 > >=20 > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-> charter.html > >=20 > Supplemental site: http://www.mip4.org/ > >=20 >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 08 14:38:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZIm-0003lU-2U; Tue, 08 Nov 2005 14:38:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZIk-0003cR-3u for mip4@megatron.ietf.org; Tue, 08 Nov 2005 14:38:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28728 for ; Tue, 8 Nov 2005 14:38:11 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZZYb-00069M-TH for mip4@ietf.org; Tue, 08 Nov 2005 14:55:02 -0500 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jA8JogmI027263 for ; Tue, 8 Nov 2005 12:50:42 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id jA8Jmqfe028492 for ; Tue, 8 Nov 2005 13:48:52 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Tue, 8 Nov 2005 14:38:15 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXhnwx20yALBVMMQQSmHVn/apqA9ACIp7kAAA76elAAA/UEcAAdiBaAAAYRSsA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Jayshree Bharatia" , "Kent Leung \(kleung\)" , "Vijay Devarapallli" , "Pete McCann" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org I completely agree with Kent, there is no need for additional replay protection with HA, so I agree with Jayshree on moving on. Thanks, Madjid -----Original Message----- From: Jayshree Bharatia [mailto:jayshree@nortel.com]=20 Sent: Tuesday, November 08, 2005 10:56 AM To: Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli; Pete McCann Cc: mip4@ietf.org; itijibox-mip4@yahoo.com Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt I am also ok with this suggestion. If it is agreed by all, I can change section 3.1 to reflect this change. Regards, Jayshree -----Original Message----- From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of Kent Leung (kleung) Sent: Monday, November 07, 2005 8:40 PM To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli; Pete McCann Cc: mip4@ietf.org; itijibox-mip4@yahoo.com Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt I agree with this sentiment. Unless there's an issue with using zero for Challenge value in the calculation for CCoA mode, this problem will be addressed in the draft. The challenge is not needed for CCoA mode since there's already Timestamp/Nonce replay protection. Kent=20 > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Monday, November 07, 2005 4:46 PM > To: Kent Leung (kleung); Vijay Devarapallli; Pete McCann > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > The fix to deal with CCoA is a very small one as I mentioned my=20 > previous email. I really don't think it warrants a huge discussion or=20 > a doc split. The fix that we suggested was agreed by Charlie as well. >=20 > Madjid > =20 >=20 > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf=20 > Of Kent Leung (kleung) > Sent: Monday, November 07, 2005 11:42 AM > To: Vijay Devarapallli; Pete McCann > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > On this particular topic, I don't understand what is missing in the=20 > details to support the CCoA mode? Since the draft covers MN-AAA=20 > authentication with NAS in between, I would like to see both FA (CoA)=20 > and HA (CCoA) modes supported. > Where else would we be able to cover just the CCoA for MN-AAA=20 > authentication if not in this draft? >=20 > Kent >=20 >=20 > >=20 > > not at this late stage. its fine as it is. however, I have > one comment >=20 > > on the support for co-located CoA mode. the draft claims it > supports > > it but there really isnt enough detail. > > IMO, it should be clarified that only FA mode is described in the=20 > > draft. > >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 08 15:50:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZaQ0-0007BD-M3; Tue, 08 Nov 2005 15:50:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZaPq-00076A-Ox; Tue, 08 Nov 2005 15:50:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02825; Tue, 8 Nov 2005 15:49:35 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZafj-0008Aa-4x; Tue, 08 Nov 2005 16:06:27 -0500 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EZaPp-0008Tc-RX; Tue, 08 Nov 2005 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 08 Nov 2005 15:50:01 -0500 X-Spam-Score: 0.4 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-vpn-problem-solution-02.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Mobile IPv4 Traversal Across IPsec-based VPN Gateways Author(s) : S. Vaarala, E. Klovning Filename : draft-ietf-mip4-vpn-problem-solution-02.txt Pages : 43 Date : 2005-11-8 This document outlines a solution for the Mobile IPv4 and IPsec coexistence problem for enterprise users. The solution consists of an applicability statement for using Mobile IPv4 and IPsec for session mobility in corporate remote access scenarios, and a required mechanism for detecting the trusted internal network securely. The solution requires only changes to the mobile node; changes to Mobile IPv4 or IPsec protocols, the VPN gateway, or the home agent are required. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-vpn-problem-solution-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-vpn-problem-solution-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-vpn-problem-solution-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-11-8141503.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-vpn-problem-solution-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-vpn-problem-solution-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-8141503.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Sun Nov 13 07:31:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbH16-0007pL-AF; Sun, 13 Nov 2005 07:31:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbH14-0007ol-JL for mip4@megatron.ietf.org; Sun, 13 Nov 2005 07:31:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00692 for ; Sun, 13 Nov 2005 07:30:55 -0500 (EST) Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbHHq-0000K7-Kv for mip4@ietf.org; Sun, 13 Nov 2005 07:48:50 -0500 Received: from [84.60.220.159] (helo=M200) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis), id 0ML2Dk-1EbH0z1vKm-0001Cx; Sun, 13 Nov 2005 13:31:21 +0100 From: "Stefan A." To: Date: Sun, 13 Nov 2005 13:30:01 +0100 Message-ID: <000801c5e84d$fae7fac0$9d01010a@M200> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Importance: Normal X-Provags-ID: kundenserver.de abuse@kundenserver.de login:859b832e820864867306da28118b0ec9 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Mip4] looking for information X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org All, I'm new to this list and even new to the MobileIP business. I'm searching the internet for sources about MobileIP. Does anyone know about a site which lists the current implementations? My Cisco Routers and Solaris 10 seem to support MobileIP. That is good for the first steps to buils a Lab. I'm looking around for more implementations (Windows/Mac/Linux). Thank you for any advices. Regards Stefan -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 14 10:35:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgMM-0007RM-1c; Mon, 14 Nov 2005 10:35:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZqed-0008QW-6P for mip4@megatron.ietf.org; Wed, 09 Nov 2005 09:10:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11543 for ; Wed, 9 Nov 2005 09:09:55 -0500 (EST) Received: from hkueee2.eee.hku.hk ([147.8.180.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZque-0005Vi-CO for mip4@ietf.org; Wed, 09 Nov 2005 09:26:57 -0500 Received: from hkueee2 (hkueee2.eee.hku.hk [147.8.180.60]) by hkueee2.eee.hku.hk (8.13.5/8.13.5) with ESMTP id jA9EA69T020261 for ; Wed, 9 Nov 2005 22:10:06 +0800 (HKT) Date: Wed, 9 Nov 2005 22:10:06 +0800 (HKT) From: Ka-Cheong Leung X-X-Sender: kcleung@hkueee2 To: mip4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-HKUEEE-MailScanner-Information: www.eee.hku.hk/intranet/computer/faq/mailscanner.htm X-HKUEEE-MailScanner: Found to be clean X-HKUEEE-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.459, required 5, autolearn=not spam, AWL 0.14, BAYES_00 -2.60) Subject: [mip4] Call For Participation: NASM 2005 (Nov. 22-24, 2005) X-Spam-Score: 1.1 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 X-Mailman-Approved-At: Mon, 14 Nov 2005 10:35:04 -0500 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kcleung@ieee.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org ******************************************************************************* CALL FOR PARTICIPATION The First International Workshop on Network Architecture and Service Models NASM 2005 November 22-24, 2005 Fudan University, Shanghai, China http://www.cs.fudan.edu.cn/mobile/news/nasm2005/NASM-2005.htm Technically Co-Sponsored by: The British Computer Society (BCS) The Institution of Electrical Engineers (IEE) The Chinese Institute of Electronics (CIE) IEEE Beijing Section ******************************************************************************* You are cordially invited to participate in the upcoming first International Workshop on network Architecture and Service Models (NASM 2005). This is a selective single-track forum for the presentation of research results on new approaches and technologies in the field of next generation networks (NGN), ad hoc mobile networks, wireless sensor networks, and P2P networks. Technical Program ----------------- The technical program at NASM 2005 consists of 36 high quality papers covering the architecture and service models of the next generation wired networks, and wireless and mobile networks. Complete details of the program can be found at: http://www.cs.fudan.edu.cn/mobile/news/nasm2005/NASM-2005.htm Keynote Speakers ---------------- Three renowned speakers will provide keynote talks. 1. Prof. JiangXing Wu from the National Digital Switching Center will give a talk on "China's Next Generation Networks Architectures". 2. Prof. Victor O. K. Li from the University of Hong Kong will present his keynote on "Future of 3G/4G Next Generation Networks". 3. Prof. Teruo Higashino from the university of Osaka will deliver his speech on "Future of Mobile Computing & Ubiquitous Networks". Registration ------------ You can download a registration form from: http://www.cs.fudan.edu.cn/mobile/news/nasm2005/registration.htm A completed registration form should be faxed to +86-21-65642824. You can either call +86-21-55664617 or e-mail to nasm2005@fudan.edu.cn if you have any questions about registration. Accommodation ------------- NASM 2005 will take place in Shanghai, the largest industrial city in China. The conference will be hosted at Fudan University. A number of hotels are located nearby. For booking details, please refer to: http://www.software.fudan.edu.cn/wfss/laborary/dmcl/nasm2005/NASM-hotel-Web.mht We look forward to seeing you in Shanghai for NASM 2005! -------------------------------------------------------------------------------- Dr. Ka-Cheong Leung Visiting Assistant Professor Department of EEE The University of Hong Kong -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 14 10:35:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgMc-0007Zf-M4; Mon, 14 Nov 2005 10:35:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea05i-00015d-Hn; Wed, 09 Nov 2005 19:14:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20854; Wed, 9 Nov 2005 19:14:31 -0500 (EST) Received: from mr4.cc.ic.ac.uk ([155.198.5.114]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea0Ln-0007C2-T5; Wed, 09 Nov 2005 19:31:37 -0500 Received: from icexp4.cc.ic.ac.uk ([155.198.3.44] helo=icex.imperial.ac.uk) by mr4.cc.ic.ac.uk with smtp (Exim 4.51) id 1Ea05L-0001PZ-KO; Thu, 10 Nov 2005 00:14:35 +0000 Received: from icex3.ic.ac.uk ([155.198.3.3]) by icex.imperial.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 10 Nov 2005 00:13:39 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 10 Nov 2005 00:13:31 -0000 Message-ID: <7DF6E965086F4B40A66BFB1CABB12AE6F7BC04@icex3.ic.ac.uk> Thread-Topic: Call for Workshop Proposals for MobiQuitous 2006 Thread-Index: AcXli5T060z8cOW0R8OwNGy9YnAxGA== From: "Leung, Kin K" To: , , , , , , , , , , , , , X-OriginalArrivalTime: 10 Nov 2005 00:13:39.0112 (UTC) FILETIME=[99A8D280:01C5E58B] X-Spam-Score: 0.5 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac X-Mailman-Approved-At: Mon, 14 Nov 2005 10:35:21 -0500 Cc: "Leung, Kin K" , tlp@cse.psu.edu Subject: [Mip4] Call for Workshop Proposals for MobiQuitous 2006 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1465643284==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1465643284== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E58B.99386B9E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E58B.99386B9E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Apologies for duplicated copies of this message. =20 =20 Call for Workshop Proposals for MobiQuitous 2006 =20 Building on the success of the last two years, the 3rd Annual = International Conference on Mobile and Ubiquitous Systems (MobiQuitous = 2006) will be held on July 17 - 21, 2006 in San Jose, California. This = is an exciting forum for researchers and practitioners working in the = areas of mobile and ubiquitous systems, services, and applications. = Areas addressed by the conference include applications, service-oriented = computing, middleware, mobile computing and networking, agents, = knowledge management and databases. In conjunction with the main = conference, four one-day workshops will be held on July 17 and 21. = Please visit www.mobiquitous.org for details. =20 WHAT TO SUBMIT: We solicit proposals for the one-day workshops on new = and emerging topics in mobile and ubiquitous computing and systems, = infrastructure, and services. An ideal proposal would focus on a = specific theme, be of current interest, and be able to attract a number = of high quality submissions. The workshop proposal should be a maximum = of 2 pages long and should clearly identify the theme, the scope, and = specific topic areas of interest. The proposal should also suggest = potential program chairs and program committee members.=20 =20 SUBMISSION GUIDELINE: Please send workshop proposals by December 16, = 2005 to both the General Co-Chair, Tom LaPorta (tlp@cse.psu.edu) and the = Workshop Chair, Kin Leung (kin.leung@imperial.ac.uk). We look forward to = your workshop proposals.=20 ------_=_NextPart_001_01C5E58B.99386B9E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=0A=
=0A=

Apologies =0A= for duplicated copies of this message.

=0A=

 

=0A=

 

=0A=

Call for =0A= Workshop Proposals for MobiQuitous 2006

=0A=

 

=0A=

Building on =0A= the success of the last two years, the 3rd Annual International = Conference on =0A= Mobile and Ubiquitous Systems = (MobiQuitous =0A= 2006) will be held on July =0A= 17 – 21, 2006 in =0A= San = Jose, California. This is an exciting forum = for =0A= researchers and practitioners working in the areas of mobile and = ubiquitous =0A= systems, services, and applications. Areas addressed by the conference = include =0A= applications, service-oriented computing, middleware, mobile computing = and =0A= networking, agents, knowledge management and databases. In conjunction = with the =0A= main conference, four one-day workshops will be held on July 17 and 21. = Please =0A= visit www.mobiquitous.org for details.

=0A=

 

=0A=

WHAT TO =0A= SUBMIT: We solicit proposals for the one-day workshops on new and = emerging =0A= topics in mobile and ubiquitous computing and systems, infrastructure, = and =0A= services. An ideal proposal would focus on a specific theme, be of = current =0A= interest, and be able to attract a number of high quality submissions. = The =0A= workshop proposal should be a maximum of 2 pages long and should clearly =0A= identify the theme, the scope, and specific topic areas of interest. The =0A= proposal should also suggest potential program chairs and program = committee =0A= members.

=0A=

 

=0A=

SUBMISSION =0A= GUIDELINE: Please send workshop proposals by December 16, 2005 to both the General Co-Chair, = Tom =0A= LaPorta (tlp@cse.psu.edu) and =0A= the Workshop Chair, Kin Leung (kin.leung@imperial.ac.uk). We look forward to your = workshop =0A= proposals.

------_=_NextPart_001_01C5E58B.99386B9E-- --===============1465643284== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1465643284==-- From mip4-bounces@ietf.org Mon Nov 14 10:37:34 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgOk-0008Do-7S; Mon, 14 Nov 2005 10:37:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZtd1-0005CE-9F; Wed, 09 Nov 2005 12:20:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23459; Wed, 9 Nov 2005 12:20:26 -0500 (EST) Received: from mantis.cs.colorado.edu ([128.138.206.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZtsw-0002ja-Q2; Wed, 09 Nov 2005 12:37:30 -0500 Received: from mantis.cs.colorado.edu (localhost [127.0.0.1]) by mantis.cs.colorado.edu (Postfix) with ESMTP id 0E457179B49; Wed, 9 Nov 2005 10:20:14 -0700 (MST) X-Original-To: securecomm-cfp@mantis.cs.colorado.edu Delivered-To: securecomm-cfp@mantis.cs.colorado.edu Received: from mroe.cs.colorado.edu (mroe-fs.cs.colorado.edu [128.138.242.197]) by mantis.cs.colorado.edu (Postfix) with ESMTP id 890E617AA21 for ; Wed, 9 Nov 2005 02:50:42 -0700 (MST) Received: from mailgateway1.uni-freiburg.de (mailgateway1.uni-freiburg.de [132.230.2.211]) by mroe.cs.colorado.edu (Postfix) with ESMTP id B05D26465 for ; Wed, 9 Nov 2005 02:50:29 -0700 (MST) Received: from iig.uni-freiburg.de ([132.230.2.44] helo=uni-freiburg.de) port 40304 by mailgateway1.uni-freiburg.de with esmtp (Exim 4.50 #1 built 18-Feb-2005 14:34:25 running on Gentoo) id 1EZmbD-0001nZ-AW for securecomm-cfp@mantis.cs.colorado.edu; Wed, 09 Nov 2005 10:50:35 +0100 Received: from [132.230.16.199] (account moritz.strasser@iig.uni-freiburg.de HELO tpc167) by uni-freiburg.de (CommuniGate Pro SMTP 4.3.8) with ESMTPA id 63788139 for securecomm-cfp@mantis.cs.colorado.edu; Wed, 09 Nov 2005 10:50:32 +0100 From: "Moritz Strasser" To: Date: Wed, 9 Nov 2005 10:52:06 +0100 Message-ID: <000b01c5e513$3e817ce0$c710e684@tpc167> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Mailman-Approved-At: Wed, 09 Nov 2005 10:20:11 -0700 X-BeenThere: securecomm-cfp@mantis.cs.colorado.edu X-Mailman-Version: 2.1.6 Precedence: list List-Archive: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 14 Nov 2005 10:37:32 -0500 Cc: Subject: [Mip4] [Securecomm-cfp] CALL FOR PAPERS - Workshop "Security and Privacy in Future Business Services" at ETRICS'06 X-BeenThere: mip4@ietf.org Reply-To: moritz.strasser@iig.uni-freiburg.de List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org CALL FOR PAPERS Submission Deadline February 15, 2006 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Workshop =93Security and Privacy in Future Business Services=94 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D International Conference on Emerging Trends in Information and Communication Security /\ ||__^_ /\ ETRICS 2006 _/\_| \_||______________________________________________________________ June 6-9, 2006, FREIBURG, GERMANY http://www.etrics.org/workshops Individualization of business services is one of the most promising business development prospects for future markets. Customized products and services, individual price differentiation, personalized promotions, and location/time-sensitive addressing of customers are raising marketers=92 attention. Particularly ubiquitous com=ACputing technologies, with their mobile and wireless interfaces, are laying the grounds for these developments: information about purchase behavior and location, proximity, presence, after-sales usage patterns, and even personal emotional states will potentially be combined and analyzed. = Technical progress, however, not only improves the available data pool but also results in new challenges for security and privacy. Handling the trade-off between high-quality individualized services and maintaining pri=ACvacy and security seems to be a key factor for business success. With= out suitable mechanisms for enforcing the correct handling of data collection and processing, new service ideas may not receive marketplace acceptance. This workshop therefore focuses on technical and economic mechanisms addressing the trade-off between privacy and individualization. It aims to bring together privacy experts on an international level to discuss recent advances in trust-promoting mechanisms. To this end, the workshop seeks submissions from academia and industry presenting novel research on theoretical and practical aspects of security and privacy technologies as well as economic models that may enforce a correct handling of sensitive data. Theoretical work, prototypes and experimental studies are equally welcome. = Selected contributions will be invited to submit a full paper to a special issue of the Wirtschaftsinformatik journal. Topics of interest include but are not limited to: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Valuation of personal data/private information = * Private data markets and market mechanisms * Trust management from a business process perspective * Trust management from a technical perspective * Political dimensions of privacy and security * Drivers of technology acceptance: what is the role of privacy and security in a Technology Acceptance Model? = * Empirical studies on privacy and/or security perception and behavior = * Technical mechanisms to promote trust, privacy and security, especially - Reputation mechanisms - Architectures and models for identity management - Pseudonymity management - Anonymity - Authentication * Privacy and security for RFID and location-based technologies = * Privacy-enhancing technologies for enterprises Important Dates: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = February 15, 2006: Submission of position paper (send 2 pages to sackmann@iig.uni-freiburg.de), = March 10, 2006: Notification of acceptance for the workshop, = March 10, 2006: Invitation to submit a full paper to the journal Wirtschaftsinformatik Workshop Chairs: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = Stefan Sackmann, University of Freiburg, Germany Sarah Spiekermann, University of Berlin, Germany Program Committee: = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = Alessandro Acquisti, Carnegie Mellon University, Pittsburgh, USA Jens Grossklags, UC Berkeley, USA = Marit Hansen, Independent Centre for Privacy Protection Schleswig-Holstein, Germany = Marc Langheinrich, ETH Zurich, Switzerland = Ursula Sury, Hochschulen f=FCr Wirtschaft und Technik und Architektur Luzer= n, Switzerland = _______________________________________________ Securecomm-cfp mailing list Securecomm-cfp@mantis.cs.colorado.edu http://mantis.cs.colorado.edu/mailman/listinfo/securecomm-cfp -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 14 10:38:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgPl-0008QY-GW; Mon, 14 Nov 2005 10:38:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EafHm-0003Ur-Mb for mip4@megatron.ietf.org; Fri, 11 Nov 2005 15:14:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02192 for ; Fri, 11 Nov 2005 15:13:18 -0500 (EST) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EafXr-00044D-77 for mip4@ietf.org; Fri, 11 Nov 2005 15:30:47 -0500 Received: from MINDLAP2 (mindlap2.cs.umd.edu [172.16.0.37]) (authenticated bits=0) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id jABKDSQh026992 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 11 Nov 2005 15:13:35 -0500 (EST) Message-Id: <200511112013.jABKDSQh026992@carrierpigeon.cs.umd.edu> From: "Moustafa Youssef" To: Date: Fri, 11 Nov 2005 15:13:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 14 Nov 2005 10:38:35 -0500 Subject: [Mip4] Extended Deadline: IEEE Workshop on Dependability and Security in Sensor Networks and Systems X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org (Our apologies if you receive multiple copies of this CFP) ------------------------------------------------------------- Call for Papers Second IEEE Workshop on Dependability and Security in Sensor Networks and Systems (DSSNS'2006) http://www.dssns.org In conjunction with 2nd NASA/IEEE Systems and Software Week 30th NASA/IEEE Software Engineering Workshop (SEW'2006) Columbia, Maryland, USA ~ April 24-28, 2006 Recently, there has been a growing interest in the potential use of networked sensors in applications such as smart environments,=20 disaster management, combat field reconnaissance, and security=20 surveillance. While the initial view of the community was that=20 networked sensors will play a complementary role that enhances=20 the quality of these applications, recent research results have=20 encouraged practitioners to envision an increased reliance on sensor=20 networks and systems (SN&S) in such critical and sensitive=20 applications. Therefore to realize their potential, necessary=20 dependability and security (D&S) measures have to be=20 incorporated in the design and during the operation of SN&S.=20 Dependability is usually specified using attributes like reliability,=20 survivability, safety, maintainability, and availability in presence=20 of failure, while security is specified by attributes like integrity,=20 authenticity, confidentiality, and availability in presence of=20 attacks. D&S services accomplish tasks for attack and failure prevention, detection and response. The scope of D&S=20 services may span the deployed sensors to command nodes=20 and likely beyond. It also involves D&S support at, and=20 cross-cutting, the protocol stack layers from physical to=20 application. Achieving dependability and security in SN&S will require=20 non-conventional mechanisms due to many factors including:=20 (1) sensors are significantly constrained in the amount of=20 available resources such as energy, storage and computation;=20 (2) sensors are expected to be deployed in very large numbers=20 in normal as well as harsh/hostile environments; (3) sensor=20 networks suffer from structural weakness and limited physical protection, and (4) localization of impact is complicated due=20 to the un-tethered nature of SN&S and of the potential=20 attackers. In addition, D&S requirements may vary according to mission defined over a multi-dimensional context, such=20 as field of deployment (e.g., hostile versus friendly), type of=20 application (e.g., monitoring, tracking, data collection), mode=20 of operation (e.g., normal, exception, post-event recovery),=20 and time. This workshop will foster a forum for discussing and presenting=20 recent research results on dependability and security in SN&S.=20 Topics of interest include, although not limited to, the following: - Fault and intrusion-tolerant architectures, middleware and operational models=20 - Robust routing, storage, and processing of sensed data - D&S architectures, protocols and tools - Vulnerabilities, attacks and countermeasures - Monitoring and evaluation techniques - Robust clustering techniques - Self-awareness and context-awareness=20 - Resilient virtual infrastructures - Autonomic and adaptive D&S support. - Formal representation and verification of D&S properties - Network inference support for D&S - Quality of service provisioning - Models, metrics, and measurements for D&S - Privacy-aware D&S services - Testbeds, simulation and visualization=20 - Agent-based D&S management=20 - SN&S support for D&S in larger information grids - SN&S application development environments Submission Guidelines --------------------- Papers should contain original material and not be previously published, or currently submitted for consideration elsewhere.=20 The manuscript should not exceed 20 single-column=20 double-space pages in PDF format, font size 11 or larger.=20 The first page should include title, authors' contact information,=20 abstract and five keywords.=20 Please e-mail (subject: DSSNS 2006) the paper as an attachment in PDF format to:=20 submission@dssns.org The e-mail should include title, authors, and the corresponding author's contact information. Important Dates ---------------- Submission deadline: November 15, 2005 Decision notification: December 20, 2005 Final manuscript due: January 20, 2006 The accepted papers will appear in a proceedings published by IEEE. The best paper will be recognized and selected papers will be invited to a Special Issue of the Journal of Ad Hoc and Sensor Wireless Networks.=20 Workshop Co-Chairs ------------------- Mohamed Eltoweissy Virginia Tech, USA E-mail: toweissy@vt.edu=20 Mohamed Younis University of Maryland Baltimore County, USA E-mail: younis@csee.umbc.edu=20 Publicity Co-Chairs -------------------- Denis Gracanin Virginia Tech, USA E-mail: gracanin@vt.edu Moustafa Youssef University of Maryland at College Park, USA E-mail: moustafa@cs.umd.edu=20 Program Committee ------------------ Farooq Anjum, Telcordia & U. of Penn, USA David Carman, Johns Hopkins U.=96 Applied Physics Lab, USA Ing-Ray Chen, Virginia Tech, USA M. Nazih Elderini, Alexandria U., Egypt Deborah Frincke, Pacific Northwest National Lab and U. of Idaho, USA Ahmed Helmy, University of Southern California, USA Sushil Jajodia, George Mason U., USA Shivakant Mishra, U. of Colorado, USA Peng Ning, North Carolina State U., USA Cristina Nita-Rotaru, Purdue U., USA Stephan Olariu, Old Dominion U., USA David Simplot-Ryl, U. Lille, INRIA Futurs, France Mani B. Srivastava, U. of California =96 Los Angeles, USA John A. Stankovic, U. of Virginia, USA Ivan Stojmenovic, U. of Ottawa, Canada Gene Tsudik, U. of California-Irvine, USA Cliff Wang, Army Research Office, USA Stephen D. Wolthusen, Fraunhofer-IGD, Germany Albert Zomaya, U. of Sydney, Australia -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 14 10:40:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgRQ-0000Hg-4F; Mon, 14 Nov 2005 10:40:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYybl-0007Y6-H9; Sun, 06 Nov 2005 23:27:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12452; Sun, 6 Nov 2005 23:27:24 -0500 (EST) Received: from mail.cse.ohio-state.edu ([164.107.123.5] helo=cse.ohio-state.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYyrI-0006uI-9t; Sun, 06 Nov 2005 23:43:52 -0500 Received: from pcdl699 (pc-dl699.cse.ohio-state.edu [164.107.120.81]) by cse.ohio-state.edu (8.12.11/8.12.11) with SMTP id jA74JPOV008238; Sun, 6 Nov 2005 23:19:25 -0500 (EST) Message-ID: <003901c5e352$740698e0$51786ba4@cse.ohiostate.edu> From: "Prasun Sinha" To: Date: Sun, 6 Nov 2005 23:19:25 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 X-Mailman-Approved-At: Mon, 14 Nov 2005 10:40:17 -0500 Cc: Subject: [Mip4] CFP: MobiQuitous 2006 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1812716066==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1812716066== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0036_01C5E328.872F53F0" This is a multi-part message in MIME format. ------=_NextPart_000_0036_01C5E328.872F53F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please accept my sincere apologies, if you are receiving multiple copies = of this CFPPrasun Sinha = -------------------------------------------------------------------------= -------=20 MobiQuitous 2006 The Third Annual International Conference on Mobile and Ubiquitous Systems: Computing, Networking and = Services http://www.mobiquitous.org July 17 -- 21, 2006 San Jose, California, USA (ACM/IEEE sponsorship pending) The combination of mobile and ubiquitous computing is emerging as a = promising new paradigm with the goal to provide computing and communication = services all the time, everywhere, transparently and invisibly to the user, using = devices embedded in the surrounding physical environment. In this context, the communication devices, the objects with which they interact, or both may = be mobile. The implementation of such a paradigm requires advances in = wireless network technologies and devices, development of infrastructures = supporting cognitive environments, and discovery and identification of ubiquitous = computing applications and services. The Third Annual International Conference on = Mobile and Ubiquitous Systems: networking and services (Mobiquitous-06) will = cover all these aspects, providing a forum where practitioners and researchers = coming from the many areas involved in ubiquitous solutions design and = deployment will be able to interact exchanging the cross-layer experiences needed to = build the overall ubiquitous systems. Areas addressed by the conference include = applications, service-oriented computing, middleware, networking, agents, data = management and services, all with special focus on mobility and ubiquitous computing. PAPERS: Technical papers describing original, previously unpublished = research, not currently under review by another conference or journal, are = solicited. The conference is interested in contributions addressing all the areas associated with mobile and ubiquitous architectures, infrastructure, = data and services. Technical papers clearly identifying how the specific = contributions fit to an overall working solution are particularly of interest. Topics = include, but are not limited to, the following feature topics: * Ubiquitous architectures and systems * Wearable computing and personal area networks * Wireless technologies for mobile and ubiquitous (Bluetooth, ZigBee, = 802.15.x, WiFi) * Wireless Internet access in ubiquitous systems * Reconfigurability and personalization of wireless networks * Service discovery mechanisms, knowledge discovery, matching and = composition mechanisms * Wireless/mobile service management and delivery * Security, privacy and social issues of mobile and ubiquitous systems * Peer-to-peer computing and networking * Emerging industrial/business/scientific scenarios * Multimodal interfaces (speech, video kinetic, tactile) * Adaptive and customizable user interfaces * Smart spaces * Ad hoc and sensor networks * Location-based services and tracking * Context and location aware application * Multimedia encoding and transcoding * Middleware services * Agent technologies in ubiquitous, wearable, and mobile systems * Hardware and software platforms for ubiquitous systems, and testbeds * Context modeling, services and frameworks * Toolkits, development environments, and languages for ubiquitous = computing * Rapid prototyping of ubiquitous applications * Ontologies for mobile and ubiquitous computing * Mobile and ubiquitous data management SUBMISSION INSTRUCTIONS: All paper submissions will be handled = electronically (see the conference web page for details). Authors should prepare an Adobe = Acrobat PDF version of their full paper. Papers must not exceed 8 pages double = column (US Letter size, 8.5 x 11 inches) including text, figures and references. = The font size must be at least 10 points. The deadline for registering the title and = the abstract of the paper with our electronic submission system is February 13, 2006. = The deadline for submitting the actual paper is February 20, 2006. All deadlines are = 11:59PM PST. PUBLICATION: All submitted papers will be rigorously reviewed by the = international technical program committee. Accepted papers will be published in the = conference proceedings. Papers of particular merit will be proposed for publication = in the ACM/Kluwer Mobile Networks and Applications (MONET) journal. WORKSHOPS: Proposals for one-day workshops to be held in conjunction = with the conference are solicited. A maximum of 2 pages should be submitted which include = the workshop name, its scope and a list of topic of interests. Proposals should be = submitted to both the Workshop Chair by December 16, 2005. DEMOS: Proposals for research and industrial demos are solicited. A = maximum of 3 pages should be submitted which include a description of the demo and = needed equipment. Proposals should be submitted to the Demo Chair by March 1, 2006. IMPORTANT DATES: Paper registration and submission: February 13 and 20, 2006 Notification of acceptance: April 21, 2006 General Co-Chairs Hamid Ahmadi, IBM, hahmadi@us.ibm.com Tom La Porta, Penn State, tlp@cse.psu.edu Program Co-Chairs Ravi Jain, Google, ravi.jain@acm.org Asim Smailagic, CMU, asim@cs.cmu.edu Arkady Zaslavsky, Monash University, arkady.zaslavsky@csse.monash.edu.au Workshop Chair Kin Leung, Imperial College, kin.leung@imperial.ac.uk Finance Chair Karen Decker, ICST, karen@icst.org Local Arrangements Chair Ulas Kozat, DoCoMo Labs, kozat@docomolabs-usa.com Web Chair Patrick Traynor, Penn State, traynor@cse.psu.edu Steering Committee Chair Imrich Chlamtac, Create-Net, imrich.chlamtac@create-net.it Publicity Chair Prasun Sinha, Ohio State University, prasun@cse.ohio-state.edu = -------------------------------------------------------------------------= ------- ------=_NextPart_000_0036_01C5E328.872F53F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 
Please accept my =
sincere apologies, if you are receiving multiple copies of this =
CFP
Prasun Sinha

  
 
 


                                  MobiQuitous 2006
                         The Third Annual International Conference on
            Mobile and Ubiquitous Systems: Computing, Networking and =
Services
                               http://www.mobiquitous.org
                                  July 17 -- 21, 2006
                               San Jose, California, USA
                             (ACM/IEEE sponsorship pending)

The combination of mobile and ubiquitous computing is emerging as a =
promising
new paradigm with the goal to provide computing and communication =
services all
the time, everywhere, transparently and invisibly to the user, using =
devices
embedded in the surrounding physical environment. In this context, the
communication devices, the objects with which they interact, or both may =
be
mobile. The implementation of such a paradigm requires advances in =
wireless
network technologies and devices, development of infrastructures =
supporting
cognitive environments, and discovery and identification of ubiquitous =
computing
applications and services. The Third Annual International Conference on =
Mobile
and Ubiquitous Systems: networking and services (Mobiquitous-06) will =
cover
all these aspects, providing a forum where practitioners and researchers =
coming
from the many areas involved in ubiquitous solutions design and =
deployment will
be able to interact exchanging the cross-layer experiences needed to =
build the
overall ubiquitous systems. Areas addressed by the conference include =
applications,
service-oriented computing, middleware, networking, agents, data =
management and
services, all with special focus on mobility and ubiquitous computing.

PAPERS:  Technical papers describing original, previously unpublished =
research,
not currently under review by another conference or journal, are =
solicited.
The conference is interested in contributions addressing all the areas
associated with mobile and ubiquitous architectures, infrastructure, =
data
and services. Technical papers clearly identifying how the specific =
contributions
fit to an overall working solution are particularly of interest. Topics =
include,
but are not limited to, the following feature topics:


*	Ubiquitous architectures and systems
*	Wearable computing and personal area  networks
*	Wireless technologies for mobile and ubiquitous (Bluetooth, ZigBee, =
802.15.x, WiFi)
*	Wireless Internet access in ubiquitous systems
*	Reconfigurability and personalization of wireless networks
*	Service discovery mechanisms, knowledge discovery, matching and =
composition mechanisms
*	Wireless/mobile service management and delivery
*	Security, privacy and social issues of mobile and ubiquitous systems
*	Peer-to-peer computing and networking
*	Emerging industrial/business/scientific scenarios
*	Multimodal interfaces (speech, video kinetic, tactile)
*	Adaptive and customizable user interfaces
*	Smart spaces
*	Ad hoc and sensor networks
*	Location-based services and tracking
*	Context and location aware application
*	Multimedia encoding and transcoding
*	Middleware services
*	Agent technologies in ubiquitous, wearable, and    mobile systems
*	Hardware and software platforms for ubiquitous systems, and testbeds
*	Context modeling, services and frameworks
*	Toolkits, development environments, and languages for ubiquitous =
computing
*	Rapid prototyping of ubiquitous applications
*	Ontologies for mobile and ubiquitous computing
*	Mobile and ubiquitous data management


SUBMISSION INSTRUCTIONS:  All paper submissions will be handled =
electronically (see
the conference web page for details). Authors should prepare an Adobe =
Acrobat PDF
version of their full paper.  Papers must not exceed 8 pages double =
column (US
Letter size, 8.5 x 11 inches) including text, figures and references. =
The font size
must be at least 10 points. The deadline for registering the title and =
the abstract
of the paper with our electronic submission system is February 13, 2006. =
The deadline
for submitting the actual paper is February 20, 2006. All deadlines are =
11:59PM PST.

PUBLICATION: All submitted papers will be rigorously reviewed by the =
international
technical program committee.  Accepted papers will be published in the =
conference
proceedings. Papers of particular merit will be proposed for publication =
in the
ACM/Kluwer Mobile Networks and Applications (MONET) journal.

WORKSHOPS:  Proposals for one-day workshops to be held in conjunction =
with the conference
are solicited.  A maximum of 2 pages should be submitted which include =
the workshop
name, its scope and a list of topic of interests.  Proposals should be =
submitted to
both the Workshop Chair by December 16, 2005.

DEMOS:  Proposals for research and industrial demos are solicited.  A =
maximum of 3
pages should be submitted which include a description of the demo and =
needed equipment.
Proposals should be submitted to the Demo Chair by March 1, 2006.

IMPORTANT DATES:
Paper registration and submission: February 13 and 20, 2006
Notification of acceptance: April 21, 2006


General Co-Chairs
Hamid Ahmadi, IBM, hahmadi@us.ibm.com
Tom La Porta, Penn State, tlp@cse.psu.edu

Program Co-Chairs
Ravi Jain, Google, ravi.jain@acm.org
Asim Smailagic, CMU, asim@cs.cmu.edu
Arkady Zaslavsky, Monash University, arkady.zaslavsky@csse=
.monash.edu.au

Workshop Chair
Kin Leung, Imperial College, kin.leung@imperial.ac.uk

Finance Chair
Karen Decker, ICST, karen@icst.org

Local Arrangements Chair
Ulas Kozat, DoCoMo Labs, kozat@docomolabs-usa.com

Web Chair
Patrick Traynor, Penn State, traynor@cse.psu.edu

Steering Committee Chair
Imrich Chlamtac, Create-Net, imrich.chlamtac@create-net.=
it

Publicity Chair
Prasun Sinha, Ohio State University, prasun@cse.ohio-state.edu

  
 
 =
------=_NextPart_000_0036_01C5E328.872F53F0-- --===============1812716066== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1812716066==-- From mip4-bounces@ietf.org Mon Nov 14 10:40:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgRm-0000K2-9Q; Mon, 14 Nov 2005 10:40:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZgSL-00054P-Av; Tue, 08 Nov 2005 22:17:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07784; Tue, 8 Nov 2005 22:16:33 -0500 (EST) Received: from ms-smtp-02.nyroc.rr.com ([24.24.2.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZgiH-0005nq-0t; Tue, 08 Nov 2005 22:33:29 -0500 Received: from hpn307pc2 (cpe-69-204-120-221.rochester.res.rr.com [69.204.120.221]) by ms-smtp-02.nyroc.rr.com (8.12.10/8.12.10) with SMTP id jA93GtDK027406; Tue, 8 Nov 2005 22:16:55 -0500 (EST) Message-ID: <00c101c5e4dc$0aaff950$6701a8c0@hpn307pc2> From: "Wendi Heinzelman" To: , Date: Tue, 8 Nov 2005 22:16:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.1 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 14 Nov 2005 10:40:41 -0500 Cc: Wendi Heinzelman Subject: [Mip4] SECON 2006 Call for Papers X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org ======================================================= CALL FOR PAPERS IEEE SECON 2006 Third Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks Reston, VA, USA September 25-29, 2006 Paper submissions due (via EDAS): April 1, 2006 (Abstract/title registration) April 7, 2006 (Full paper) http://www.ieee-secon.org/2006/index.html ======================================================= The third annual IEEE SECON conference will provide a unique forum to exchange ideas, techniques, and applications, discuss best practices, raise awareness, and share experiences among researchers, practitioners, standard developers and policy makers in the field of sensor, ad hoc, and mesh networks and systems. IEEE SECON grew out of IEEE INFOCOM (http://www.ieee-infocom.org) in 2004, in order to create an event that focused on the important and exciting topics of Sensor, Mesh and Ad Hoc Communications and Networks. The conference will be organized to provide for collegiality and continuity in the discussions of the various topics among participants from the industrial, governmental and academic sectors. Original technical papers that address the communications, networking, applications, systems and algorithmic aspects of mesh and sensor networks, as well as those that describe practical deployment and implementation experiences are solicited for presentation at the conference and publication in the conference proceedings. Papers presenting novel contributions in such disciplines as communications, networking protocols and architectures, algorithms, embedded systems, middleware and information management, and novel applications are solicited. PAPERS: Full papers - describing original, previously unpublished research work, experimental efforts, practical experiences, and industrial and commercial developments in sensor, ad hoc, and mesh communications and networks - are solicited. Papers with a deep focus on a specific discipline or stimulated by the synergistic interaction of diverse disciplines are encouraged. Papers describing practical application of technology to real-world problems are similarly encouraged. Papers submitted should not be concurrently under review at another conference, journal or similar venue. Particular topics of interest include, but are not limited to: * New architectures and protocols to support communication, localization, time synchronization, routing, data dissemination, and other distributed services in heterogeneous, large-scale distributed, mesh networks and sensor networks * Novel algorithms and theories for management, supervisory control, and monitoring of distributed ad hoc networks, and techniques for the interpretation and use of sensor data in decision-making processes * Modeling and performance evaluation of large-scale distributed ad hoc and sensor networks, practical implementations and deployments, and real-world experiences * Theories and models on fundamental information and communication aspects of wireless mesh and sensor networks * Mechanisms for authenticated, secure communication and data dissemination in sensor and mesh networks * Algorithms and protocols to support quality of service in mesh and sensor networks, including admission control, resource allocation and fairness, and capacity planning * Integration of sensors into engineered systems, including novel techniques for on-sensor renewable power sources, mechanisms for on-sensor self-calibration and self-testing, and efficient schemes to maximize accuracy and minimize false alarms * Hardware platforms incorporating multiple sensors, computation, actuation, and wireless interfaces * Software platforms, middleware, and tools for mesh and sensor network applications development, deployment, and management TUTORIALS AND PANELS: Proposals for tutorials and panels on current topics in the field of ad hoc and sensor networking and applications are solicited. Panels related to the commercial application and development of sensors and mesh networks are especially encouraged. DEMOS AND EXPO: Demonstrations that showcase practical implementations, industrial and commercial developments, and new applications for mesh and sensor networks are solicited. SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically through the EDAS system. Details regarding the paper format and the submission process will be announced shortly at http://www.ieee-secon.org/2006/index.html. Accepted papers will be published in the conference proceedings and will appear on IEEE Xplore. IEEE Communications Society policy states that all accepted SECON 2006 papers must have at least one registration at the regular rate. For authors co-authoring multiple papers, one regular registration is valid for up to three papers. IMPORTANT DATES: Paper registration: April 1, 2006, by 5pm EDT Full Paper Submission: April 7, 2006, by 5pm EDT Decision Notification: June 15, 2006, by 5pm EDT Camera-ready paper due: July 7, 2006, by 5pm EDT Demo proposals due: June 1, 2006, by 5pm EDT Poster proposals due: June 30, 2006, by 5pm EDT Tutorial/Panel proposals due: May 1, 2006, by 5pm EDT CONFERENCE ORGANIZING COMMITEE GENERAL CHAIR: Krishna Sivalingam, University of Maryland Baltimore County, krishna@umbc.edu TECHNICAL PROGRAM CO-CHAIRS: Mark Yarvis, Intel Corporation, mark.d.yarvis@intel.com Michele Zorzi, Universita' degli Studi di Padova, zorzi@dei.unipd.it POSTERS/DEMOS CO-CHAIRS: Stefano Basagni, Northeastern University, basagni@ece.neu.edu Cedric Westphal, Nokia, Cedric.Westphal@nokia.com PANELS CO-CHAIRS: TBA TUTORIALS CHAIR: Tom Hou, Virginia Tech, thou@vt.edu PUBLICITY CHAIR: Wendi Heinzelman, University of Rochester, wheinzel@ece.rochester.edu EXHIBITS/SPONSORSHIPS CHAIR: Vishal Anand, SUNY Brockport, vanand@brockport.edu LOCAL ARRANGEMENTS CHAIR: Mohamed Eltoweissy, Virgina Tech, toweissy@vt.edu STANDING COMMITTEE: Fred Bauer (fred@fredbauer.com), PacketHop (CHAIR) Harvey Freeman, Booz Allen Hamilton Sung-Ju Lee, HP Labs Prasant Mohapatra, University of California, Davis TECHNICAL PROGRAM COMMITTEE TBA ========================================================================== -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Nov 16 15:00:14 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTS2-0007Wx-RB; Wed, 16 Nov 2005 15:00:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbsIs-0001lB-IW for mip4@megatron.ietf.org; Mon, 14 Nov 2005 23:20:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27541 for ; Mon, 14 Nov 2005 23:19:45 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebsa2-0004pS-EM for mip4@ietf.org; Mon, 14 Nov 2005 23:38:02 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 14 Nov 2005 20:20:08 -0800 Received: from RED-MSG-43.redmond.corp.microsoft.com ([157.54.12.204]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 20:20:08 -0800 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: Mon, 14 Nov 2005 20:20:07 -0800 Message-ID: <4A8D7C3204072A46A7DC234B2D81C1CC06EA883A@RED-MSG-43.redmond.corp.microsoft.com> Thread-Topic: Final reminder: Mobisys 2006 cfp Thread-Index: AcXpm9yIu0hLFNx6Qo+FcCJFWAR7kA== From: "Alec Wolman" To: X-OriginalArrivalTime: 15 Nov 2005 04:20:08.0243 (UTC) FILETIME=[DCBBE030:01C5E99B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 16 Nov 2005 15:00:13 -0500 Subject: [Mip4] Final reminder: Mobisys 2006 cfp X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org [ We apologize in advance if you receive multiple copies of this CFP.... ] There are only 2 weeks remaining until the Mobisys 2006 submission deadline! ------------------------------------------------------------------------ ----- MobiSys 2006 Call for Papers http://www.sigmobile.org/mobisys/2006/ The 4th International Conference on Mobile Systems, Applications, and Services June 19-22, 2006 Uppsala, Sweden Jointly sponsored by ACM SIGMOBILE and The USENIX Association, in cooperation with ACM SIGOPS Corporate supporters: Intel, Ericsson, and Microsoft. MobiSys 2006 seeks to present innovative and significant research on the design, implementation, usage, and evaluation of mobile computing and wireless systems, applications, and services. The conference will be held in early summer in the historic town of Uppsala, Sweden. It builds on the success of the first three conferences held in San Francisco, Boston and Seattle. Important Dates Full papers due: Monday Nov 28 2005 (23:59 EST) (HARD DEADLINE, no extensions) Notification of paper acceptance: March 10,2005 Camera-ready final papers due: April 7, 2006 Poster and demo proposals due: March 27, 2006 Notification of poster/demo acceptance: April 21, 2006 Conference Organizers General Co-Chairs: Per Gunningberg (Uppsala University, Sweden) Lars-Ake Larzon (Uppsala University, Sweden) Steering Committee Chair: Victor Bahl, Microsoft Research Program Co-Chairs: Mahadev Satyanarayanan, Carnegie Mellon University, USA Nigel Davies, Lancaster University, UK Program Committee: Victor Bahl, Microsoft Research, USA Mary Baker, HP Labs, USA Ramon Caceres, IBM T.J. Watson Research Center, USA Mark Corner, University of Massachusetts, USA Nigel Davies, Lancaster University, UK Eyal de Lara, University of Toronto, Canada Carla Ellis, Duke University, USA Adrian Friday, Lancaster University, UK Jason Hong, Carnegie Mellon University, USA David Kotz, Dartmouth College, USA Anthony LaMarca, Intel Research Seattle, USA Antonio Kruger, University of Munster, Germany Dushyanth Narayanan, Microsoft Research, UK Brian Noble, University of Michigan, USA Mahadev Satyanarayanan, Carnegie Mellon University, USA Rahul Sukthankar, Intel Research Pittsburgh, USA Roy Want, Intel Research, USA Poster Chair:=20 Ramon Caceres, IBM T.J. Watson Research Center, USA Demo Co-Chairs:=20 Bengt Ahlgren, Swedish Institute of Computer Science, Sweden Ian Chakeres, Boeing Phantom Works, USA Publicity Chair: Alec Wolman, Microsoft Research, USA Submission guidelines We seek papers that take a broad systems perspective rather than focus narrowly on low-level components. We value results and insights obtained from working implementations more highly than those obtained solely from simulations. If you have any questions regarding relevance or other submission-related issues, please contact the program chairs at mobisys_pcchairs@acm.org. Topics of interest include, but are not limited to: - Design, implementation, and evaluation of mobile and wireless systems - Middleware and service architectures for mobile and wireless applications - Data management for mobile and wireless applications - Operating Systems for resource-constrained mobile devices - Disconnected and weakly connected operation - Proxies and data adaptation - Mobile agents - Infrastructure support for mobility - Security, privacy, authorization, and billing - System-level energy management for mobile and wireless devices - Wearable and handheld devices in the context of system design - Personal mobility - Personal-area networks and systems - Cyber foraging and resource discovery of mobile services - Systems for context sensing and location awareness - Application interfaces and services supporting the mobile user - Tools and design methodologies for building mobile and wireless systems - Mobile computing support for pervasive computing - User interfaces and usability issues for mobile and wireless applications - Experience with mobile and wireless systems Submissions should be full papers, up to 14 single-spaced 8.5" x 11" pages, including figures, tables, and references, two-column format, using 10-point type on 12-point (single-spaced) leading with reasonable margins. Submissions will be judged on originality, significance, interest, clarity, relevance, and technical correctness. Accepted papers will be shepherded by a member of the program committee. MobiSys, like most conferences and journals, requires that papers must not be submitted simultaneously to any other conference or publication, that submissions must not be previously published, and that accepted papers must not be subsequently published elsewhere. Papers accompanied by nondisclosure agreement forms are not acceptable and will be returned to the author(s) unread. As customary with the scientific peer review process, submissions will be handled as confidential material during the review. Submissions are due Monday, November 28, 2005, 23:59 EST. This is a hard deadline, and no extensions will be granted. The submission process is electronic. All submissions must be in PDF format. See the conference web page for detailed instructions. Poster and Demo Sessions Do you have interesting work you would like to share, or a great idea that is not quite ready to be published? Poster sessions are for you! The poster sessions introduce new or ongoing work. Demos of working systems and applications are also encouraged. The MobiSys audience will provide valuable discussion and feedback. We are particularly interested in presentations of student work. See the conference web page for submission details. Workshops The ACM MobiSys 2006 conference will host a day of workshops on technical areas related to mobile systems, applications and services. SIGMOBILE invites workshop proposals from interested communities. New workshops in emerging areas that can engage participants in greater interaction are welcome. See the conference web page for details. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Nov 16 15:00:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTS3-0007XM-5K; Wed, 16 Nov 2005 15:00:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcSsu-0007BU-F8 for mip4@megatron.ietf.org; Wed, 16 Nov 2005 14:23:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18764 for ; Wed, 16 Nov 2005 14:23:22 -0500 (EST) Received: from letters.cs.ucsb.edu ([128.111.41.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcTAO-0005SW-17 for mip4@ietf.org; Wed, 16 Nov 2005 14:42:01 -0500 Received: from jackson.cs.ucsb.edu (jackson.cs.ucsb.edu [128.111.52.10]) by letters.cs.ucsb.edu (8.13.1/8.13.1) with ESMTP id jAGJNrGg027078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 16 Nov 2005 11:23:53 -0800 Received: from jackson.cs.ucsb.edu (localhost [127.0.0.1]) by jackson.cs.ucsb.edu (8.12.8/8.12.8) with ESMTP id jAGJNrxb012678 for ; Wed, 16 Nov 2005 11:23:53 -0800 Received: from localhost (almeroth@localhost) by jackson.cs.ucsb.edu (8.12.8/8.12.8/Submit) with ESMTP id jAGJNr7a012674 for ; Wed, 16 Nov 2005 11:23:53 -0800 X-Authentication-Warning: jackson.cs.ucsb.edu: almeroth owned process doing -bs Date: Wed, 16 Nov 2005 11:23:53 -0800 (PST) From: "Kevin C. Almeroth" To: mip4@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on localhost X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on letters.cs.ucsb.edu X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-Mailman-Approved-At: Wed, 16 Nov 2005 15:00:13 -0500 Subject: [Mip4] WinMee CFP (Papers due Dec 4th) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org The Second International Workshop on Wireless Network Measurement (WiNMee) (co-located with WiOpt) April 3, 2006 Boston, Massachusetts, USA http://www.winmee.org/ WiNMee 2006 will be the second international workshop on Wireless Network Measurement. The first workshop, WiNMee 2005, was held in Lago di Gardi, Italy, and was highly successful with 32 submissions and 13 accepted papers. This year we hope to build on the success of last year by bringing researchers together to discuss the next generation of wireless network measurement research. Wireless networking has attracted much recent interest. Nonetheless, performance evaluation of wireless protocols, networks, and applications are still largely based on simulations. Only recently have researchers turned their attention to measuring real-world networks; building models based on real-world data, and using testbeds to more realistically evaluate their proposed ideas. Accurate network measurements have proven to be a different and a greater challenge than in wired networks. Accurate data models that reflect the unique characteristics of wireless networks have also proven to be more of a challenge. Wireless network testbeds have proven to be yet another difficult environments in which to work due to the many unique properties of the wireless medium. For example, results in wireless testbeds are often difficult to reproduce due to performance variations caused by location, weather, time of day, and other uncontrollable external variables. Testbeds are also challenging because implementing novel solutions often requires significant changes to the network as well as careful observation and measurement. The committee for WiNMee 2006 is soliciting 6 page papers that report on experiences obtained from operational wireless experiments, either in testbeds or in the field. Topics include: * Operational experience on the performance of wireless networks * Challenges with wireless measurements * Experimental (in)validation of assumptions in a wireless environments * Metrics for wireless network for performance evaluation * Wireless network troubleshooting techniques and recommendations * Experience with building/designing wireless networks * Description of tools for building and/or managing wireless testbeds * Techniques for testbed scaling * Techniques for improving experiment repeatability * Techniques for validating results obtained from wireless testbeds * Methods for simplifying experiment setup and reconfiguration * Mobility pattern implementation Important Dates Submission deadline: December 4, 2005 Notification deadline: January 26, 2006 Camera-ready due: February 26, 2006 Workshop: April 3, 2006 Submission Instructions Submitted papers should not exceed 6 pages in length and should be formatted in two columns with a point size greater or equal to 10. Workshop Chairs Kevin Almeroth (University California, Santa Barbara) Kave Salamatian (LIP6-University Pierre et Marie Curie) Technical Program Committee Kevin Almeroth, UC-Santa Barbara, USA Anish Arora, Ohio State, USA Chadi Barakat, INRIA , France Elizabeth M. Belding-Royer, UC-Santa Barbara, USA Andrew Campbell, Dartmouth , USA Ahmed Helmy, USC, USA Tristan Henderson, Dartmouth, USA Ed Knightly, Rice University , USA Josep Mangues, CTTC, Spain Konstantina Papagiannaki, Intel Research, UK Ashu Sabharwal, Rice University, USA Kave Salamatian, LIP6 , France Suresh Singh, Portland State University, USA Aruna Seneviratne, National ICT, Australia Thierry Turletti, INRIA, France Thomas Ziegler, FTW , Austria -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Nov 17 15:54:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecqlk-00089j-Lv; Thu, 17 Nov 2005 15:54:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecqlj-00089D-Ab for mip4@megatron.ietf.org; Thu, 17 Nov 2005 15:54:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20372 for ; Thu, 17 Nov 2005 15:53:31 -0500 (EST) Received: from av6-2-sn3.vrr.skanova.net ([81.228.9.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecr3P-0000SR-UY for mip4@ietf.org; Thu, 17 Nov 2005 16:12:25 -0500 Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502) id A6F6F38311; Thu, 17 Nov 2005 21:53:43 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 8322237FBB; Thu, 17 Nov 2005 21:53:43 +0100 (CET) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 3DCDE37E46; Thu, 17 Nov 2005 21:53:42 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.54) id 1EcqlK-0007ke-Mh; Thu, 17 Nov 2005 21:53:42 +0100 Message-ID: <437CEDD5.7070500@levkowetz.com> Date: Thu, 17 Nov 2005 21:53:41 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles E. Perkins" , Mobile IPv4 Mailing List , Pete McCann X-Enigmail-Version: 0.93.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Subject: [Mip4] Additional 3344bis error codes X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1871545395==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1871545395== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig710E527F3956DB9A9B780FC3" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig710E527F3956DB9A9B780FC3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I've had some feedback from the people at ipUnplugged, who have run into some new error cases in deployments of MIPv4 where dynamic home address allocation has been used. After some iterations and experience with code discovering and reporting on the error cases, it seems the following 4 HA error codes would be appropriate: * home address already in use (as care-of address) * care-of address already in use (as home address) * home address is not unicast * care-of address is not unicast Could we consider adding these to the "Registration denied by the home agent" error codes in Section 3.4? ( Oh, and incidentally - 3344bis refers to RFC 1700, as reference [21], but RFC 1700 has been replaced by IANA's online database, according to RFC 3232, so reference [21] should probably point to the IANA web-site and specifically to http://www.iana.org/assignments/mobileip-numbers .) Henrik --------------enig710E527F3956DB9A9B780FC3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDfO3WeVhrtTJkXCMRAoztAJkBx5HrL4+qruYdu2NTLlPiSCyZrQCgyQZI eof72AoXTc62OcLG7Un57MQ= =UXqO -----END PGP SIGNATURE----- --------------enig710E527F3956DB9A9B780FC3-- --===============1871545395== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1871545395==-- From mip4-bounces@ietf.org Thu Nov 17 17:03:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcrqU-0005Fh-9V; Thu, 17 Nov 2005 17:03:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcrqS-0005FZ-Nq for mip4@megatron.ietf.org; Thu, 17 Nov 2005 17:03:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28979 for ; Thu, 17 Nov 2005 17:02:30 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecs87-0004RK-CD for mip4@ietf.org; Thu, 17 Nov 2005 17:21:23 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 17 Nov 2005 14:02:51 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAHM24f6017578; Thu, 17 Nov 2005 14:02:47 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 14:02:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Additional 3344bis error codes Date: Thu, 17 Nov 2005 14:02:45 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52F46B39@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] Additional 3344bis error codes Thread-Index: AcXruzxgrPWJOdD4TrW7LXK0ign/ugABJBew From: "Kent Leung \(kleung\)" To: "Henrik Levkowetz" , "Charles E. Perkins" , "Mobile IPv4 Mailing List" , "Pete McCann" X-OriginalArrivalTime: 17 Nov 2005 22:02:47.0071 (UTC) FILETIME=[A4C872F0:01C5EBC2] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Henrik.=20 I agree in general that explicit error codes would be nice since we are clumping them under "Reason unspecified (128)" or "Admin prohibited (129)". I'll gather some of our error codes that should be assigned. Comments below. > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > Behalf Of Henrik Levkowetz > Sent: Thursday, November 17, 2005 12:54 PM > To: Charles E. Perkins; Mobile IPv4 Mailing List; Pete McCann > Subject: [Mip4] Additional 3344bis error codes >=20 > Hi, >=20 > I've had some feedback from the people at ipUnplugged,=20 > who have run into some new error cases in deployments of=20 > MIPv4 where dynamic home address allocation has been used.=20 If these are directly related to dynamic HoA assignment based on RFC 2794, wondering if we should deal with them in 2794bis instead of 3344bis? Any error codes not related to dynamic HoA assignment should definitely be in 3344bis. =20 > After some iterations and experience with code discovering=20 > and reporting on the error cases, it seems the following 4 HA=20 > error codes would be appropriate: >=20 >=20 > * home address already in use (as care-of address) Isn't this an ambiguity issue with RFC 2794 when RRQ has NAI and HoA that is set? HA can either assign a new HoA in the RRP or reject with error code. The draft, draft-paulkandasamy-mobileip-nai-based-home-address-00.txt, covers this case by sending ADDR_ALLOC_FAILED error code. > * care-of address already in use (as home address) The CoA can be HoA when deregistering. What is the condition for registration? The CoA and HoA should not be in the same subnet prefix since technically MN is home? > * home address is not unicast Same as #1 in terms that should be covered in 2794bis. If the HoA is assigned by HA, this should never happen. If MN registers with an HoA that is used or invalid, then possibly we could use the same error code as #1. That's why it's best to debate the various error codes in the scope of that draft. > * care-of address is not unicast >=20 This may be related to #2 bullet in terms of having the same error code. I'm not sure how CoA can be checked for unicast or not without knowing the subnet prefix? This info is not known in the RRQ. Kent > Could we consider adding these to the "Registration denied by=20 > the home agent" error codes in Section 3.4? >=20 >=20 > ( Oh, and incidentally - 3344bis refers to RFC 1700, as=20 > reference [21], but RFC 1700 has been replaced by IANA's=20 > online database, according to RFC 3232, so reference [21]=20 > should probably point to the IANA web-site and specifically=20 > to http://www.iana.org/assignments/mobileip-numbers .) >=20 >=20 > Henrik >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Nov 17 17:36:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcsMQ-0003K2-M1; Thu, 17 Nov 2005 17:36:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcsMP-0003IW-8T for mip4@megatron.ietf.org; Thu, 17 Nov 2005 17:36:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01126 for ; Thu, 17 Nov 2005 17:35:31 -0500 (EST) Received: from av10-1-sn2.hy.skanova.net ([81.228.8.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecse7-0005df-TC for mip4@ietf.org; Thu, 17 Nov 2005 17:54:24 -0500 Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id 774EF3843E; Thu, 17 Nov 2005 23:35:54 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP id 4E52B37F11; Thu, 17 Nov 2005 23:35:54 +0100 (CET) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id E24E737E46; Thu, 17 Nov 2005 23:35:53 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.54) id 1EcsMD-0000Ru-DA; Thu, 17 Nov 2005 23:35:53 +0100 Message-ID: <437D05C8.1080502@levkowetz.com> Date: Thu, 17 Nov 2005 23:35:52 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] Additional 3344bis error codes References: <2979E38DD6FC6544B789C8DAD7BAFC52F46B39@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC52F46B39@xmb-sjc-235.amer.cisco.com> X-Enigmail-Version: 0.93.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Mobile IPv4 Mailing List , Olavi Kumpulainen X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1444880552==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1444880552== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig971A4530755459B7CCDCCE01" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig971A4530755459B7CCDCCE01 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Kent, on 2005-11-17 23:02 Kent Leung (kleung) said the following: > Hi Henrik. > > I agree in general that explicit error codes would be nice since we are > clumping them under "Reason unspecified (128)" or "Admin prohibited > (129)". I'll gather some of our error codes that should be assigned. Sounds good. > Comments below. > >> -----Original Message----- >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On >> Behalf Of Henrik Levkowetz >> Sent: Thursday, November 17, 2005 12:54 PM >> To: Charles E. Perkins; Mobile IPv4 Mailing List; Pete McCann >> Subject: [Mip4] Additional 3344bis error codes >> >> Hi, >> >> I've had some feedback from the people at ipUnplugged, >> who have run into some new error cases in deployments of >> MIPv4 where dynamic home address allocation has been used. > > If these are directly related to dynamic HoA assignment based on RFC > 2794, wondering if we should deal with them in 2794bis instead of > 3344bis? Any error codes not related to dynamic HoA assignment should > definitely be in 3344bis. Yess.. Although I don't see any harm in placing these in 3344 as well, seeing as we're revising it now. >> After some iterations and experience with code discovering >> and reporting on the error cases, it seems the following 4 HA >> error codes would be appropriate: >> >> >> * home address already in use (as care-of address) > > Isn't this an ambiguity issue with RFC 2794 when RRQ has NAI and HoA > that is set? HA can either assign a new HoA in the RRP or reject with > error code. The draft, > draft-paulkandasamy-mobileip-nai-based-home-address-00.txt, covers this > case by sending ADDR_ALLOC_FAILED error code. I maybe should have been clearer - these cases occur in mis-configured networks or MNs, and isn't directly associated with a bad address assignment at the HA, so can't be handled by this error code. Olavi, could you provide some details? (This goes for the remaining points below, too...) >> * care-of address already in use (as home address) > > The CoA can be HoA when deregistering. What is the condition for > registration? The CoA and HoA should not be in the same subnet prefix > since technically MN is home? Ah, but this is (remember this is a bad error case) the home address of *another* MN... >> * home address is not unicast > > Same as #1 in terms that should be covered in 2794bis. If the HoA is > assigned by HA, this should never happen. If MN registers with an HoA > that is used or invalid, then possibly we could use the same error code > as #1. That's why it's best to debate the various error codes in the > scope of that draft. > >> * care-of address is not unicast >> > > This may be related to #2 bullet in terms of having the same error code. > I'm not sure how CoA can be checked for unicast or not without knowing > the subnet prefix? This info is not known in the RRQ. Correct - only if you know the subnet prefix can you give this error message. Seems like a slim chance - basically it's only true for the home network, I think. Looks like we could skip this. Olavi? Henrik --------------enig971A4530755459B7CCDCCE01 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDfQXJeVhrtTJkXCMRAqbpAKCyEjhgCqFME60YN4CYdwUQ9Mp2JwCgwKXt nXTgmhQ/2rP8tA808oGgRLE= =5dD5 -----END PGP SIGNATURE----- --------------enig971A4530755459B7CCDCCE01-- --===============1444880552== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1444880552==-- From mip4-bounces@ietf.org Thu Nov 17 17:59:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecsil-0004vf-VS; Thu, 17 Nov 2005 17:59:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecsil-0004va-6E for mip4@megatron.ietf.org; Thu, 17 Nov 2005 17:59:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02626 for ; Thu, 17 Nov 2005 17:58:36 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ect0U-0006Qj-5B for mip4@ietf.org; Thu, 17 Nov 2005 18:17:30 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2005 14:59:00 -0800 X-IronPort-AV: i="3.97,344,1125903600"; d="scan'208"; a="231836464:sNHT30504464" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jAHMwveU012799; Thu, 17 Nov 2005 14:58:59 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 14:58:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Additional 3344bis error codes Date: Thu, 17 Nov 2005 14:58:56 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52F46BA3@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] Additional 3344bis error codes Thread-Index: AcXrx0g/r9nJfNj2RpuRp1RO/hBvdQAApjsA From: "Kent Leung \(kleung\)" To: "Henrik Levkowetz" X-OriginalArrivalTime: 17 Nov 2005 22:58:57.0130 (UTC) FILETIME=[7D7EA4A0:01C5EBCA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: Mobile IPv4 Mailing List , Olavi Kumpulainen X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org OK, now I see that you are talking about misconfiguration cases. The HA needs to detect them and avoid self-destruction in processing the RRQ. We have the same checks too. :) I'll dig out some more sanity checks and error conditions. Kent > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Thursday, November 17, 2005 2:36 PM > To: Kent Leung (kleung) > Cc: Mobile IPv4 Mailing List; Olavi Kumpulainen > Subject: Re: [Mip4] Additional 3344bis error codes >=20 > Hi Kent, >=20 > on 2005-11-17 23:02 Kent Leung (kleung) said the following: > > Hi Henrik.=20 > >=20 > > I agree in general that explicit error codes would be nice since we=20 > > are clumping them under "Reason unspecified (128)" or "Admin=20 > > prohibited (129)". I'll gather some of our error codes=20 > that should be assigned. >=20 > Sounds good. >=20 > > Comments below. > >=20 > >> -----Original Message----- > >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org]=20 > On Behalf=20 > >> Of Henrik Levkowetz > >> Sent: Thursday, November 17, 2005 12:54 PM > >> To: Charles E. Perkins; Mobile IPv4 Mailing List; Pete McCann > >> Subject: [Mip4] Additional 3344bis error codes > >>=20 > >> Hi, > >>=20 > >> I've had some feedback from the people at ipUnplugged,=20 > who have=20 > >> run into some new error cases in deployments of > >> MIPv4 where dynamic home address allocation has been used.=20 > >=20 > > If these are directly related to dynamic HoA assignment=20 > based on RFC=20 > > 2794, wondering if we should deal with them in 2794bis instead of=20 > > 3344bis? Any error codes not related to dynamic HoA=20 > assignment should=20 > > definitely be in 3344bis. >=20 > Yess.. Although I don't see any harm in placing these in 3344=20 > as well, seeing as we're revising it now. >=20 > >> After some iterations and experience with code discovering and=20 > >> reporting on the error cases, it seems the following 4 HA=20 > error codes=20 > >> would be appropriate: > >>=20 > >>=20 > >> * home address already in use (as care-of address) > >=20 > > Isn't this an ambiguity issue with RFC 2794 when RRQ has=20 > NAI and HoA=20 > > that is set? HA can either assign a new HoA in the RRP or=20 > reject with=20 > > error code. The draft,=20 > > draft-paulkandasamy-mobileip-nai-based-home-address-00.txt, covers=20 > > this case by sending ADDR_ALLOC_FAILED error code. >=20 > I maybe should have been clearer - these cases occur in=20 > mis-configured networks or MNs, and isn't directly associated=20 > with a bad address assignment at the HA, so can't be handled=20 > by this error code. >=20 > Olavi, could you provide some details? (This goes for the=20 > remaining points below, too...) >=20 > >> * care-of address already in use (as home address) > >=20 > > The CoA can be HoA when deregistering. What is the condition for=20 > > registration? The CoA and HoA should not be in the same=20 > subnet prefix=20 > > since technically MN is home? >=20 > Ah, but this is (remember this is a bad error case) the home=20 > address of > *another* MN... >=20 >=20 > >> * home address is not unicast > >=20 > > Same as #1 in terms that should be covered in 2794bis. If=20 > the HoA is=20 > > assigned by HA, this should never happen. If MN registers=20 > with an HoA=20 > > that is used or invalid, then possibly we could use the same error=20 > > code as #1. That's why it's best to debate the various=20 > error codes in=20 > > the scope of that draft. > >=20 > >> * care-of address is not unicast > >>=20 > >=20 > > This may be related to #2 bullet in terms of having the=20 > same error code. > > I'm not sure how CoA can be checked for unicast or not=20 > without knowing=20 > > the subnet prefix? This info is not known in the RRQ. >=20 > Correct - only if you know the subnet prefix can you give=20 > this error message. Seems like a slim chance - basically=20 > it's only true for the home network, I think. Looks like we=20 > could skip this. >=20 > Olavi? >=20 >=20 > Henrik >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Nov 18 05:42:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3hP-00060o-GK; Fri, 18 Nov 2005 05:42:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed3hN-0005z9-Op for mip4@megatron.ietf.org; Fri, 18 Nov 2005 05:42:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08111 for ; Fri, 18 Nov 2005 05:41:55 -0500 (EST) Received: from smtp13.clb.oleane.net ([213.56.31.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed3zC-0002eM-Cp for mip4@ietf.org; Fri, 18 Nov 2005 06:00:55 -0500 Received: from Pavillonquatre ([194.3.133.88]) (authenticated) by smtp13.clb.oleane.net with ESMTP id jAIAgAIf009276 for ; Fri, 18 Nov 2005 11:42:11 +0100 Message-Id: <200511181042.jAIAgAIf009276@smtp13.clb.oleane.net> From: "Chantal Ladouce" To: Date: Fri, 18 Nov 2005 11:41:47 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcXsLKvKkID+wqvdSCuD1qDryh92sA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Subject: [Mip4] IMS at the International SIP 2006 - Paris - France X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1939334872==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1939334872== Content-Type: multipart/alternative; boundary="----=_NextPart_000_005F_01C5EC35.0EC9DFA0" This is a multi-part message in MIME format. ------=_NextPart_000_005F_01C5EC35.0EC9DFA0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Carriers Experience on SIP based IMS Real Size Experiments . Extending SIP IMS Architecture from Wireless to Wireline Networks . Challenges in IMS Testing Everything you need to know on IMS and SIP will be delivered at the International SIP conference to be held in Paris next 21-24 February 2006. Get all details at: http://www.upperside.fr/sip2006/sip2006program.htm#day2 ------=_NextPart_000_005F_01C5EC35.0EC9DFA0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Carriers = Experience on SIP based IMS Real Size = Experiments

=

. Extending = SIP IMS Architecture from Wireless to Wireline Networks

=

. Challenges in = IMS Testing

=

 

Everything you = need to know on IMS and SIP will be delivered at the International SIP = conference to be held in Paris next 21-24 February 2006.

=

 

Get all details = at:

=

 

http://w= ww.upperside.fr/sip2006/sip2006program.htm#day2

 

 

------=_NextPart_000_005F_01C5EC35.0EC9DFA0-- --===============1939334872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1939334872==-- From mip4-bounces@ietf.org Fri Nov 18 16:25:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdDja-0006i2-4q; Fri, 18 Nov 2005 16:25:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdDjY-0006fx-Lz for mip4@megatron.ietf.org; Fri, 18 Nov 2005 16:25:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11807 for ; Fri, 18 Nov 2005 16:24:48 -0500 (EST) Received: from web30801.mail.mud.yahoo.com ([68.142.200.144]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EdE1Q-0004PC-8f for mip4@ietf.org; Fri, 18 Nov 2005 16:43:55 -0500 Received: (qmail 20776 invoked by uid 60001); 18 Nov 2005 21:25:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=hhy4MqJOttp6/Gx8FBkjt44F4UbTWsVHFQ+a2x7Ps9pYVnWiqdKtnK4xreOoilU2586L8i8SdYAQhYPfg4MJTfTSBbryynzbII2w59UuzI1bo6eB1P+aUXj/v7KczRL09H8hMys2TUJVQi2CemUOMC2Q9V/EgKO67paRo9wbiGk= ; Message-ID: <20051118212511.20774.qmail@web30801.mail.mud.yahoo.com> Received: from [216.37.120.50] by web30801.mail.mud.yahoo.com via HTTP; Fri, 18 Nov 2005 13:25:11 PST Date: Fri, 18 Nov 2005 13:25:11 -0800 (PST) From: Mike Borella To: mip4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 4.2 (++++) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 8bit Subject: [Mip4] HA error codes X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Speaking of missing error codes, here's one that I really wish we had. When the MN sends a MIP de-registration for a call that does not exist on the HA, it would be nice to send a distinct error code rather than acking it with 0 or naking it with 128. Mike __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sun Nov 20 11:25:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eds0h-00025L-Bv; Sun, 20 Nov 2005 11:25:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EdgWO-0008TG-Vq; Sat, 19 Nov 2005 23:09:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29163; Sat, 19 Nov 2005 23:09:07 -0500 (EST) Received: from mail.cse.ohio-state.edu ([164.107.123.5] helo=cse.ohio-state.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EdgoZ-0002K3-9u; Sat, 19 Nov 2005 23:28:31 -0500 Received: from pcdl699 (pc-dl699.cse.ohio-state.edu [164.107.120.81]) by cse.ohio-state.edu (8.12.11/8.12.11) with SMTP id jAK41Rln014322; Sat, 19 Nov 2005 23:01:28 -0500 (EST) Message-ID: <001201c5ed87$17ca9f10$51786ba4@cse.ohiostate.edu> From: "Prasun Sinha" To: Date: Sat, 19 Nov 2005 23:01:27 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb X-Mailman-Approved-At: Sun, 20 Nov 2005 11:25:46 -0500 Cc: Subject: [Mip4] CFP: MobiQuitous 2006 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0406893639==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0406893639== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C5ED5D.2C2BB310" This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C5ED5D.2C2BB310 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My apologies if you are receiving multiple copies of this CFP. - Prasun Sinha =20 = -------------------------------------------------------------------------= -------=20 MobiQuitous 2006 The Third Annual International Conference on Mobile and Ubiquitous Systems: Computing, Networking and = Services http://www.mobiquitous.org July 17 -- 21, 2006 San Jose, California, USA (ACM/IEEE sponsorship pending) The combination of mobile and ubiquitous computing is emerging as a = promising new paradigm with the goal to provide computing and communication = services all the time, everywhere, transparently and invisibly to the user, using = devices embedded in the surrounding physical environment. In this context, the communication devices, the objects with which they interact, or both may = be mobile. The implementation of such a paradigm requires advances in = wireless network technologies and devices, development of infrastructures = supporting cognitive environments, and discovery and identification of ubiquitous = computing applications and services. The Third Annual International Conference on = Mobile and Ubiquitous Systems: networking and services (Mobiquitous-06) will = cover all these aspects, providing a forum where practitioners and researchers = coming from the many areas involved in ubiquitous solutions design and = deployment will be able to interact exchanging the cross-layer experiences needed to = build the overall ubiquitous systems. Areas addressed by the conference include = applications, service-oriented computing, middleware, networking, agents, data = management and services, all with special focus on mobility and ubiquitous computing. PAPERS: Technical papers describing original, previously unpublished = research, not currently under review by another conference or journal, are = solicited. The conference is interested in contributions addressing all the areas associated with mobile and ubiquitous architectures, infrastructure, = data and services. Technical papers clearly identifying how the specific = contributions fit to an overall working solution are particularly of interest. Topics = include, but are not limited to, the following feature topics: * Ubiquitous architectures and systems * Wearable computing and personal area networks * Wireless technologies for mobile and ubiquitous (Bluetooth, ZigBee, = 802.15.x, WiFi) * Wireless Internet access in ubiquitous systems * Reconfigurability and personalization of wireless networks * Service discovery mechanisms, knowledge discovery, matching and = composition mechanisms * Wireless/mobile service management and delivery * Security, privacy and social issues of mobile and ubiquitous systems * Peer-to-peer computing and networking * Emerging industrial/business/scientific scenarios * Multimodal interfaces (speech, video kinetic, tactile) * Adaptive and customizable user interfaces * Smart spaces * Ad hoc and sensor networks * Location-based services and tracking * Context and location aware application * Multimedia encoding and transcoding * Middleware services * Agent technologies in ubiquitous, wearable, and mobile systems * Hardware and software platforms for ubiquitous systems, and testbeds * Context modeling, services and frameworks * Toolkits, development environments, and languages for ubiquitous = computing * Rapid prototyping of ubiquitous applications * Ontologies for mobile and ubiquitous computing * Mobile and ubiquitous data management SUBMISSION INSTRUCTIONS: All paper submissions will be handled = electronically (see the conference web page for details). Authors should prepare an Adobe = Acrobat PDF version of their full paper. Papers must not exceed 8 pages double = column (US Letter size, 8.5 x 11 inches) including text, figures and references. = The font size must be at least 10 points. The deadline for registering the title and = the abstract of the paper with our electronic submission system is February 13, 2006. = The deadline for submitting the actual paper is February 20, 2006. All deadlines are = 11:59PM PST. PUBLICATION: All submitted papers will be rigorously reviewed by the = international technical program committee. Accepted papers will be published in the = conference proceedings. Papers of particular merit will be proposed for publication = in the ACM/Kluwer Mobile Networks and Applications (MONET) journal. WORKSHOPS: Proposals for one-day workshops to be held in conjunction = with the conference are solicited. A maximum of 2 pages should be submitted which include = the workshop name, its scope and a list of topic of interests. Proposals should be = submitted to both the Workshop Chair by December 16, 2005. DEMOS: Proposals for research and industrial demos are solicited. A = maximum of 3 pages should be submitted which include a description of the demo and = needed equipment. Proposals should be submitted to the Demo Chair by March 1, 2006. IMPORTANT DATES: Paper registration and submission: February 13 and 20, 2006 Notification of acceptance: April 21, 2006 General Co-Chairs Hamid Ahmadi, IBM, hahmadi@us.ibm.com Tom La Porta, Penn State, tlp@cse.psu.edu Program Co-Chairs Ravi Jain, Google, ravi.jain@acm.org Asim Smailagic, CMU, asim@cs.cmu.edu Arkady Zaslavsky, Monash University, arkady.zaslavsky@csse.monash.edu.au Workshop Chair Kin Leung, Imperial College, kin.leung@imperial.ac.uk Finance Chair Karen Decker, ICST, karen@icst.org Local Arrangements Chair Ulas Kozat, DoCoMo Labs, kozat@docomolabs-usa.com Web Chair Patrick Traynor, Penn State, traynor@cse.psu.edu Steering Committee Chair Imrich Chlamtac, Create-Net, imrich.chlamtac@create-net.it Publicity Chair Prasun Sinha, Ohio State University, prasun@cse.ohio-state.edu = -------------------------------------------------------------------------= ------- ------=_NextPart_000_000F_01C5ED5D.2C2BB310 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
My apologies if you are receiving = multiple copies=20 of this CFP.
 
- Prasun Sinha

 
 


                                  MobiQuitous 2006
                         The Third Annual International Conference on
            Mobile and Ubiquitous Systems: Computing, Networking and =
Services
                               http://www.mobiquitous.org
                                  July 17 -- 21, 2006
                               San Jose, California, USA
                             (ACM/IEEE sponsorship pending)

The combination of mobile and ubiquitous computing is emerging as a =
promising
new paradigm with the goal to provide computing and communication =
services all
the time, everywhere, transparently and invisibly to the user, using =
devices
embedded in the surrounding physical environment. In this context, the
communication devices, the objects with which they interact, or both may =
be
mobile. The implementation of such a paradigm requires advances in =
wireless
network technologies and devices, development of infrastructures =
supporting
cognitive environments, and discovery and identification of ubiquitous =
computing
applications and services. The Third Annual International Conference on =
Mobile
and Ubiquitous Systems: networking and services (Mobiquitous-06) will =
cover
all these aspects, providing a forum where practitioners and researchers =
coming
from the many areas involved in ubiquitous solutions design and =
deployment will
be able to interact exchanging the cross-layer experiences needed to =
build the
overall ubiquitous systems. Areas addressed by the conference include =
applications,
service-oriented computing, middleware, networking, agents, data =
management and
services, all with special focus on mobility and ubiquitous computing.

PAPERS:  Technical papers describing original, previously unpublished =
research,
not currently under review by another conference or journal, are =
solicited.
The conference is interested in contributions addressing all the areas
associated with mobile and ubiquitous architectures, infrastructure, =
data
and services. Technical papers clearly identifying how the specific =
contributions
fit to an overall working solution are particularly of interest. Topics =
include,
but are not limited to, the following feature topics:


*	Ubiquitous architectures and systems
*	Wearable computing and personal area  networks
*	Wireless technologies for mobile and ubiquitous (Bluetooth, ZigBee, =
802.15.x, WiFi)
*	Wireless Internet access in ubiquitous systems
*	Reconfigurability and personalization of wireless networks
*	Service discovery mechanisms, knowledge discovery, matching and =
composition mechanisms
*	Wireless/mobile service management and delivery
*	Security, privacy and social issues of mobile and ubiquitous systems
*	Peer-to-peer computing and networking
*	Emerging industrial/business/scientific scenarios
*	Multimodal interfaces (speech, video kinetic, tactile)
*	Adaptive and customizable user interfaces
*	Smart spaces
*	Ad hoc and sensor networks
*	Location-based services and tracking
*	Context and location aware application
*	Multimedia encoding and transcoding
*	Middleware services
*	Agent technologies in ubiquitous, wearable, and    mobile systems
*	Hardware and software platforms for ubiquitous systems, and testbeds
*	Context modeling, services and frameworks
*	Toolkits, development environments, and languages for ubiquitous =
computing
*	Rapid prototyping of ubiquitous applications
*	Ontologies for mobile and ubiquitous computing
*	Mobile and ubiquitous data management


SUBMISSION INSTRUCTIONS:  All paper submissions will be handled =
electronically (see
the conference web page for details). Authors should prepare an Adobe =
Acrobat PDF
version of their full paper.  Papers must not exceed 8 pages double =
column (US
Letter size, 8.5 x 11 inches) including text, figures and references. =
The font size
must be at least 10 points. The deadline for registering the title and =
the abstract
of the paper with our electronic submission system is February 13, 2006. =
The deadline
for submitting the actual paper is February 20, 2006. All deadlines are =
11:59PM PST.

PUBLICATION: All submitted papers will be rigorously reviewed by the =
international
technical program committee.  Accepted papers will be published in the =
conference
proceedings. Papers of particular merit will be proposed for publication =
in the
ACM/Kluwer Mobile Networks and Applications (MONET) journal.

WORKSHOPS:  Proposals for one-day workshops to be held in conjunction =
with the conference
are solicited.  A maximum of 2 pages should be submitted which include =
the workshop
name, its scope and a list of topic of interests.  Proposals should be =
submitted to
both the Workshop Chair by December 16, 2005.

DEMOS:  Proposals for research and industrial demos are solicited.  A =
maximum of 3
pages should be submitted which include a description of the demo and =
needed equipment.
Proposals should be submitted to the Demo Chair by March 1, 2006.

IMPORTANT DATES:
Paper registration and submission: February 13 and 20, 2006
Notification of acceptance: April 21, 2006


General Co-Chairs
Hamid Ahmadi, IBM, hahmadi@us.ibm.com
Tom La Porta, Penn State, tlp@cse.psu.edu

Program Co-Chairs
Ravi Jain, Google, ravi.jain@acm.org
Asim Smailagic, CMU, asim@cs.cmu.edu
Arkady Zaslavsky, Monash University, arkady.zaslavsky@csse=
.monash.edu.au

Workshop Chair
Kin Leung, Imperial College, kin.leung@imperial.ac.uk

Finance Chair
Karen Decker, ICST, karen@icst.org

Local Arrangements Chair
Ulas Kozat, DoCoMo Labs, kozat@docomolabs-usa.com

Web Chair
Patrick Traynor, Penn State, traynor@cse.psu.edu

Steering Committee Chair
Imrich Chlamtac, Create-Net, imrich.chlamtac@create-net.=
it

Publicity Chair
Prasun Sinha, Ohio State University, prasun@cse.ohio-state.edu

  
 
 =
------=_NextPart_000_000F_01C5ED5D.2C2BB310-- --===============0406893639== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0406893639==-- From mip4-bounces@ietf.org Tue Nov 22 14:08:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EedVX-00069O-O4; Tue, 22 Nov 2005 14:08:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EedVT-00067K-W3 for mip4@megatron.ietf.org; Tue, 22 Nov 2005 14:08:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26754 for ; Tue, 22 Nov 2005 14:08:03 -0500 (EST) Received: from av8-2-sn3.vrr.skanova.net ([81.228.9.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EedfK-00051w-E7 for mip4@ietf.org; Tue, 22 Nov 2005 14:18:54 -0500 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 983DD37EF0; Tue, 22 Nov 2005 19:59:15 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 7FEE937EA7; Tue, 22 Nov 2005 19:59:15 +0100 (CET) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id D38E137E46; Tue, 22 Nov 2005 19:59:14 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.54) id 1EedMI-00016v-Ii; Tue, 22 Nov 2005 19:59:14 +0100 Message-ID: <43836A81.3020309@levkowetz.com> Date: Tue, 22 Nov 2005 19:59:13 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jayshree Bharatia Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: Nakhjiri Madjid-MNAKHJI1 , Pete McCann , mip4@ietf.org, Vijay Devarapallli , "Kent Leung \(kleung\)" , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Jayshree, I believe we've reached consensus on this. The AD is waiting for an updated document, so please make the change and submit a new version. Regards, Henrik on 2005-11-08 17:55 Jayshree Bharatia said the following: > I am also ok with this suggestion. If it is agreed by all, I can change > section 3.1 to reflect this change. > > Regards, > Jayshree > > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of > Kent Leung (kleung) > Sent: Monday, November 07, 2005 8:40 PM > To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli; Pete McCann > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > I agree with this sentiment. Unless there's an issue with using zero > for Challenge value in the calculation for CCoA mode, this problem will > be addressed in the draft. The challenge is not needed for CCoA mode > since there's already Timestamp/Nonce replay protection. > > Kent > >> -----Original Message----- >> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] >> Sent: Monday, November 07, 2005 4:46 PM >> To: Kent Leung (kleung); Vijay Devarapallli; Pete McCann >> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com >> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >> >> The fix to deal with CCoA is a very small one as I mentioned >> my previous email. I really don't think it warrants a huge >> discussion or a doc split. The fix that we suggested was >> agreed by Charlie as well. >> >> Madjid >> >> >> -----Original Message----- >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On >> Behalf Of Kent Leung (kleung) >> Sent: Monday, November 07, 2005 11:42 AM >> To: Vijay Devarapallli; Pete McCann >> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com >> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >> >> On this particular topic, I don't understand what is missing >> in the details to support the CCoA mode? Since the draft >> covers MN-AAA authentication with NAS in between, I would >> like to see both FA (CoA) and HA (CCoA) modes supported. >> Where else would we be able to cover just the CCoA for MN-AAA >> authentication if not in this draft? >> >> Kent >> >> >> > >> > not at this late stage. its fine as it is. however, I have >> one comment >> >> > on the support for co-located CoA mode. the draft claims it >> supports >> > it but there really isnt enough detail. >> > IMO, it should be clarified that only FA mode is described in the >> > draft. >> > >> >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >> Supplemental site: http://www.mip4.org/ >> > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 22 21:41:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EekZk-0003hl-CA; Tue, 22 Nov 2005 21:41:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EekZi-0003g8-DG for mip4@megatron.ietf.org; Tue, 22 Nov 2005 21:41:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25999 for ; Tue, 22 Nov 2005 21:40:54 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeksU-0000Ft-F1 for mip4@ietf.org; Tue, 22 Nov 2005 22:00:58 -0500 Received: by xproxy.gmail.com with SMTP id t12so1192357wxc for ; Tue, 22 Nov 2005 18:41:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=foiLRhZp15QGndxaOfFq0SccJli/DOC7Fv087Wux19hzw5CsL0d74oRdGeXmitwV2oU1WK2gil7gq8pKm7IvuhPFbJLb+WvEE51B7qqkkmKPR6gKPZyNe8xdWIO5r32m7bx+zk4eIjmgo8k1yD+m+wKMHWSuitmjr8to1b6HqF0= Received: by 10.70.47.7 with SMTP id u7mr4235484wxu; Tue, 22 Nov 2005 18:41:33 -0800 (PST) Received: by 10.70.83.12 with HTTP; Tue, 22 Nov 2005 18:41:33 -0800 (PST) Message-ID: Date: Tue, 22 Nov 2005 18:41:33 -0800 From: Vijay Devarapallli To: Henrik Levkowetz Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt In-Reply-To: <43836A81.3020309@levkowetz.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43836A81.3020309@levkowetz.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: Nakhjiri Madjid-MNAKHJI1 , Pete McCann , Jayshree Bharatia , mip4@ietf.org, "Kent Leung \(kleung\)" , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org On 11/22/05, Henrik Levkowetz wrote: > Hi Jayshree, > > I believe we've reached consensus on this. The AD is waiting for an > updated document, so please make the change and submit a new version. just to make sure I understand what the consensus is. when Kent and I discussed this, we agreed that the MN leaves out the challenge extension in the registration request when using co-located CoA mode rather than include a null challenge. is this the consensus? I think we also need some text which explains that replay protection is provided by the use of timestamp in the registration request instead of a challenge when the mobile node is using co-located CoA mode. Vijay > > Regards, > > Henrik > > on 2005-11-08 17:55 Jayshree Bharatia said the following: > > I am also ok with this suggestion. If it is agreed by all, I can change > > section 3.1 to reflect this change. > > > > Regards, > > Jayshree > > > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of > > Kent Leung (kleung) > > Sent: Monday, November 07, 2005 8:40 PM > > To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli; Pete McCann > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > > > > I agree with this sentiment. Unless there's an issue with using zero > > for Challenge value in the calculation for CCoA mode, this problem will > > be addressed in the draft. The challenge is not needed for CCoA mode > > since there's already Timestamp/Nonce replay protection. > > > > Kent > > > >> -----Original Message----- > >> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > >> Sent: Monday, November 07, 2005 4:46 PM > >> To: Kent Leung (kleung); Vijay Devarapallli; Pete McCann > >> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > >> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > >> > >> The fix to deal with CCoA is a very small one as I mentioned > >> my previous email. I really don't think it warrants a huge > >> discussion or a doc split. The fix that we suggested was > >> agreed by Charlie as well. > >> > >> Madjid > >> > >> > >> -----Original Message----- > >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > >> Behalf Of Kent Leung (kleung) > >> Sent: Monday, November 07, 2005 11:42 AM > >> To: Vijay Devarapallli; Pete McCann > >> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > >> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > >> > >> On this particular topic, I don't understand what is missing > >> in the details to support the CCoA mode? Since the draft > >> covers MN-AAA authentication with NAS in between, I would > >> like to see both FA (CoA) and HA (CCoA) modes supported. > >> Where else would we be able to cover just the CCoA for MN-AAA > >> authentication if not in this draft? > >> > >> Kent > >> > >> > >> > > >> > not at this late stage. its fine as it is. however, I have > >> one comment > >> > >> > on the support for co-located CoA mode. the draft claims it > >> supports > >> > it but there really isnt enough detail. > >> > IMO, it should be clarified that only FA mode is described in the > >> > draft. > >> > > >> > >> -- > >> Mip4 mailing list: Mip4@ietf.org > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html > >> Supplemental site: http://www.mip4.org/ > >> > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Nov 23 09:52:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eevyw-00079k-Ib; Wed, 23 Nov 2005 09:52:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eevys-00077e-LN for mip4@megatron.ietf.org; Wed, 23 Nov 2005 09:52:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10872 for ; Wed, 23 Nov 2005 09:51:38 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EewHk-00067A-2V for mip4@ietf.org; Wed, 23 Nov 2005 10:11:49 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id jANEhtt20957; Wed, 23 Nov 2005 09:43:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Wed, 23 Nov 2005 08:43:49 -0600 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXv122fMA8ZEutGTbeNjiip4GvjNwAYI6yw From: "Jayshree Bharatia" To: "Vijay Devarapallli" , "Henrik Levkowetz" X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: quoted-printable Cc: Nakhjiri Madjid-MNAKHJI1 , "Kent Leung \(kleung\)" , mip4@ietf.org, Pete McCann , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Vijay, My understanding of the proposal is that challenge value 0 will be used for the calculation for co-located CoA mode. Hence, there won't be challenge extension included in the registration request. I haven't included your suggestion on using timestamp for replay protection. Please propose new text for this change and I will include it in the document.=20 Regards, Jayshree -----Original Message----- From: Vijay Devarapallli [mailto:dvijay@gmail.com]=20 Sent: Tuesday, November 22, 2005 8:42 PM To: Henrik Levkowetz Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1; Pete McCann; mip4@ietf.org; itijibox-mip4@yahoo.com Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt On 11/22/05, Henrik Levkowetz wrote: > Hi Jayshree, > > I believe we've reached consensus on this. The AD is waiting for an=20 > updated document, so please make the change and submit a new version. just to make sure I understand what the consensus is. when Kent and I discussed this, we agreed that the MN leaves out the challenge extension in the registration request when using co-located CoA mode rather than include a null challenge. is this the consensus? I think we also need some text which explains that replay protection is provided by the use of timestamp in the registration request instead of a challenge when the mobile node is using co-located CoA mode. Vijay > > Regards, > > Henrik > > on 2005-11-08 17:55 Jayshree Bharatia said the following: > > I am also ok with this suggestion. If it is agreed by all, I can=20 > > change section 3.1 to reflect this change. > > > > Regards, > > Jayshree > > > > -----Original Message----- > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf > > Of Kent Leung (kleung) > > Sent: Monday, November 07, 2005 8:40 PM > > To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli; Pete McCann > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > > > > I agree with this sentiment. Unless there's an issue with using=20 > > zero for Challenge value in the calculation for CCoA mode, this=20 > > problem will be addressed in the draft. The challenge is not needed > > for CCoA mode since there's already Timestamp/Nonce replay=20 > > protection. > > > > Kent > > > >> -----Original Message----- > >> From: Nakhjiri Madjid-MNAKHJI1=20 > >> [mailto:Madjid.Nakhjiri@motorola.com] > >> Sent: Monday, November 07, 2005 4:46 PM > >> To: Kent Leung (kleung); Vijay Devarapallli; Pete McCann > >> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > >> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > >> > >> The fix to deal with CCoA is a very small one as I mentioned my=20 > >> previous email. I really don't think it warrants a huge discussion=20 > >> or a doc split. The fix that we suggested was agreed by Charlie as=20 > >> well. > >> > >> Madjid > >> > >> > >> -----Original Message----- > >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > >> Behalf Of Kent Leung (kleung) > >> Sent: Monday, November 07, 2005 11:42 AM > >> To: Vijay Devarapallli; Pete McCann > >> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > >> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > >> > >> On this particular topic, I don't understand what is missing in the > >> details to support the CCoA mode? Since the draft covers MN-AAA=20 > >> authentication with NAS in between, I would like to see both FA=20 > >> (CoA) and HA (CCoA) modes supported. Where else would we be able to > >> cover just the CCoA for MN-AAA authentication if not in this draft? > >> > >> Kent > >> > >> > >> > > >> > not at this late stage. its fine as it is. however, I have > >> one comment > >> > >> > on the support for co-located CoA mode. the draft claims it > >> supports > >> > it but there really isnt enough detail. > >> > IMO, it should be clarified that only FA mode is described in the > >> > draft. > >> > > >> > >> -- > >> Mip4 mailing list: Mip4@ietf.org > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >> Charter page:=20 > >> http://www.ietf.org/html.charters/mip4-charter.html > >> Supplemental site: http://www.mip4.org/ > >> > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Nov 23 17:29:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef37a-0005F1-QL; Wed, 23 Nov 2005 17:29:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ef37Y-0005Em-Gz for mip4@megatron.ietf.org; Wed, 23 Nov 2005 17:29:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08714 for ; Wed, 23 Nov 2005 17:29:03 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ef3QT-0000Go-Py for mip4@ietf.org; Wed, 23 Nov 2005 17:49:19 -0500 Received: by xproxy.gmail.com with SMTP id t12so15597wxc for ; Wed, 23 Nov 2005 14:29:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MOK8LyV+Jw4V8MKuKQlYKcGzFrPNgTJGqnmyEZ1TRnre/ZIxj0ci+y5vdO9A7TmtcOrzz1r6jvYwiEw8rujl3cgBj4ZMAC7ZxQR4a7VJOW3TCkgKDS0Va3uOZ0415XvrDp8RdN731tKnTf4ojHN2b5xfi0oYlaCMgIKWyq4Xks4= Received: by 10.70.47.7 with SMTP id u7mr5398841wxu; Wed, 23 Nov 2005 14:29:39 -0800 (PST) Received: by 10.70.83.12 with HTTP; Wed, 23 Nov 2005 14:29:39 -0800 (PST) Message-ID: Date: Wed, 23 Nov 2005 14:29:39 -0800 From: Vijay Devarapallli To: Jayshree Bharatia Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 2.2 (++) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Content-Transfer-Encoding: quoted-printable Cc: Nakhjiri Madjid-MNAKHJI1 , Pete McCann , mip4@ietf.org, "Kent Leung \(kleung\)" , Henrik Levkowetz , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org On 11/23/05, Jayshree Bharatia wrote: > Vijay, > > My understanding of the proposal is that challenge value 0 will be used > for the calculation for co-located CoA mode. Hence, there won't be > challenge extension included in the registration request. agree. > I haven't > included your suggestion on using timestamp for replay protection. it wasnt mine. Kent? Vijay > Please propose new text for this change and I will include it in the > document. > > Regards, > Jayshree > -----Original Message----- > From: Vijay Devarapallli [mailto:dvijay@gmail.com] > Sent: Tuesday, November 22, 2005 8:42 PM > To: Henrik Levkowetz > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; Kent Leung (kleung); Nakhjiri > Madjid-MNAKHJI1; Pete McCann; mip4@ietf.org; itijibox-mip4@yahoo.com > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > On 11/22/05, Henrik Levkowetz wrote: > > Hi Jayshree, > > > > I believe we've reached consensus on this. The AD is waiting for an > > updated document, so please make the change and submit a new version. > > just to make sure I understand what the consensus is. > > when Kent and I discussed this, we agreed that the MN leaves out the > challenge extension in the registration request when using co-located > CoA mode rather than include a null challenge. > > is this the consensus? > > I think we also need some text which explains that replay protection is > provided by the use of timestamp in the registration request instead of > a challenge when the mobile node is using co-located CoA mode. > > Vijay > > > > > Regards, > > > > Henrik > > > > on 2005-11-08 17:55 Jayshree Bharatia said the following: > > > I am also ok with this suggestion. If it is agreed by all, I can > > > change section 3.1 to reflect this change. > > > > > > Regards, > > > Jayshree > > > > > > -----Original Message----- > > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf > > > > Of Kent Leung (kleung) > > > Sent: Monday, November 07, 2005 8:40 PM > > > To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli; Pete McCann > > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > > > > > > > I agree with this sentiment. Unless there's an issue with using > > > zero for Challenge value in the calculation for CCoA mode, this > > > problem will be addressed in the draft. The challenge is not needed > > > > for CCoA mode since there's already Timestamp/Nonce replay > > > protection. > > > > > > Kent > > > > > >> -----Original Message----- > > >> From: Nakhjiri Madjid-MNAKHJI1 > > >> [mailto:Madjid.Nakhjiri@motorola.com] > > >> Sent: Monday, November 07, 2005 4:46 PM > > >> To: Kent Leung (kleung); Vijay Devarapallli; Pete McCann > > >> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > >> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > >> > > >> The fix to deal with CCoA is a very small one as I mentioned my > > >> previous email. I really don't think it warrants a huge discussion > > >> or a doc split. The fix that we suggested was agreed by Charlie as > > >> well. > > >> > > >> Madjid > > >> > > >> > > >> -----Original Message----- > > >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On > > >> Behalf Of Kent Leung (kleung) > > >> Sent: Monday, November 07, 2005 11:42 AM > > >> To: Vijay Devarapallli; Pete McCann > > >> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > >> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > >> > > >> On this particular topic, I don't understand what is missing in the > > > >> details to support the CCoA mode? Since the draft covers MN-AAA > > >> authentication with NAS in between, I would like to see both FA > > >> (CoA) and HA (CCoA) modes supported. Where else would we be able to > > > >> cover just the CCoA for MN-AAA authentication if not in this draft? > > >> > > >> Kent > > >> > > >> > > >> > > > >> > not at this late stage. its fine as it is. however, I have > > >> one comment > > >> > > >> > on the support for co-located CoA mode. the draft claims it > > >> supports > > >> > it but there really isnt enough detail. > > >> > IMO, it should be clarified that only FA mode is described in the > > > >> > draft. > > >> > > > >> > > >> -- > > >> Mip4 mailing list: Mip4@ietf.org > > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> Charter page: > > >> http://www.ietf.org/html.charters/mip4-charter.html > > >> Supplemental site: http://www.mip4.org/ > > >> > > > > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Nov 24 05:10:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfE3Q-0003Y2-Ep; Thu, 24 Nov 2005 05:10:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfE3P-0003Xq-2I for mip4@megatron.ietf.org; Thu, 24 Nov 2005 05:10:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10599 for ; Thu, 24 Nov 2005 05:09:30 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfEMD-0006BR-NW for mip4@ietf.org; Thu, 24 Nov 2005 05:29:51 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IQG003C3F509E@szxga02-in.huawei.com> for mip4@ietf.org; Thu, 24 Nov 2005 18:15:01 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IQG00I5FF50AC@szxga02-in.huawei.com> for mip4@ietf.org; Thu, 24 Nov 2005 18:15:00 +0800 (CST) Received: from manjuis ([10.18.4.120]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IQG00JO3F4RLC@szxml02-in.huawei.com> for mip4@ietf.org; Thu, 24 Nov 2005 18:14:52 +0800 (CST) Date: Thu, 24 Nov 2005 15:35:01 +0530 From: manju_shivaji To: mip4@ietf.org Message-id: <000001c5f0de$8909e460$7804120a@china.huawei.com> Organization: htipl MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.3 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Cc: 'Karthik' Subject: [Mip4] Regarding MN-AAA extension X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: manju_shivaji@huawei.com List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1454427608==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1454427608== Content-type: multipart/alternative; boundary="Boundary_(ID_GO+bx7p+ApvsWx7q2ZxFMA)" This is a multi-part message in MIME format. --Boundary_(ID_GO+bx7p+ApvsWx7q2ZxFMA) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi all, I have a doubt regarding MN-AAA extension. Please help me to solve this. When the mobile node has sent a request with MN-AAA extension, what are the parameters to be filled in each field of the Radius request? The draft draft-ietf-mobileip-radius-challenge-00 says: The CHAP-ID octet of the RADIUS CHAP-password attribute will contain the last byte of the Challenge value from MIP FA Challenge extension[6]. The authenticator from the MN-AAA Authentication extension MUST be used as the CHAP-Password attribute. The User-Name attribute MUST be populated with the user-name attribute from the AMR message. The following data stream, as described earlier, MUST be included in the CHAP- Challenge attribute: Preceding Mobile IP data || Type, Length, SPI. We made CHAP-ID as the last byte of the challenge value from MIP FA Challenge extension, Password as the authenticator from MN-AAA extension, and username attribute is also correct. In CHAP-Challenge field, currently we are filling the MD5 checksum of the preceding mobile ip data || Type, Length, SPI. Is this correct? How can we fill the preceding mobile IP data as it is since size of the data can vary each time? Now the radius server is rejecting the request every time. What are the correct parameters to be filled? Please do reply. Thanks & Regards Manju This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! --Boundary_(ID_GO+bx7p+ApvsWx7q2ZxFMA) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

 

Hi all,

 

I have a doubt regarding MN-AAA extension. Please help me to solve this.

 

When the mobile node has sent a request with MN-AAA extension, what are the parameters to be filled in each field of the Radius request?

 

The draft draft-ietf-mobileip-radius-challenge-00 says:

 

The CHAP-ID octet of the RADIUS CHAP-password attribute will contain the last byte of the Challenge value from MIP FA Challenge extension[6].  The authenticator from the MN-AAA Authentication extension MUST be used as the CHAP-Password attribute. The User-Name attribute MUST be populated with the user-name attribute from the AMR message. The following data stream, as described earlier, MUST be included in the CHAP- Challenge attribute:

 

Preceding Mobile IP data || Type, Length, SPI.

 

We made CHAP-ID as the last byte of the challenge value from MIP FA Challenge extension, Password as the authenticator from MN-AAA extension, and username attribute is also correct. In CHAP-Challenge field, currently we are filling the MD5 checksum of the preceding mobile ip data || Type, Length, SPI. Is this correct? How can we fill the preceding mobile IP data as it is since size of the data can vary each time?

 

Now the radius server is rejecting the request every time. What are the correct parameters to be filled?

 

Please do reply.

Thanks & Regards

Manju

 

 

This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

 

--Boundary_(ID_GO+bx7p+ApvsWx7q2ZxFMA)-- --===============1454427608== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1454427608==-- From mip4-bounces@ietf.org Fri Nov 25 14:16:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efj41-00054g-Nv; Fri, 25 Nov 2005 14:16:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efj40-00051p-0C for mip4@megatron.ietf.org; Fri, 25 Nov 2005 14:16:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05406 for ; Fri, 25 Nov 2005 14:16:09 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfjNH-0002LY-En for mip4@ietf.org; Fri, 25 Nov 2005 14:36:50 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 25 Nov 2005 11:16:40 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAPJGcCN013024; Fri, 25 Nov 2005 11:16:39 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Nov 2005 11:16:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Fri, 25 Nov 2005 11:16:38 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52FAC524@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXwfW7b5mTmP0CYQouEI3PF8wC+6ABdviQQ From: "Kent Leung \(kleung\)" To: "Vijay Devarapallli" , "Jayshree Bharatia" X-OriginalArrivalTime: 25 Nov 2005 19:16:39.0507 (UTC) FILETIME=[C2F4E230:01C5F1F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: quoted-printable Cc: Nakhjiri Madjid-MNAKHJI1 , Pete McCann , mip4@ietf.org, Henrik Levkowetz , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org I don't think it's necessary to say replay protection of messages between MN and HA is provided by timestamp or nonce as specified in RFC 3344. This function is already explicitly stated in the base protocol. Kent =20 > -----Original Message----- > From: Vijay Devarapallli [mailto:dvijay@gmail.com]=20 > Sent: Wednesday, November 23, 2005 2:30 PM > To: Jayshree Bharatia > Cc: Henrik Levkowetz; Kent Leung (kleung); Nakhjiri=20 > Madjid-MNAKHJI1; Pete McCann; mip4@ietf.org; itijibox-mip4@yahoo.com > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > On 11/23/05, Jayshree Bharatia wrote: > > Vijay, > > > > My understanding of the proposal is that challenge value 0 will be=20 > > used for the calculation for co-located CoA mode. Hence,=20 > there won't=20 > > be challenge extension included in the registration request. >=20 > agree. >=20 > > I haven't > > included your suggestion on using timestamp for replay protection. >=20 > it wasnt mine. Kent? >=20 > Vijay >=20 > > Please propose new text for this change and I will include=20 > it in the=20 > > document. >=20 >=20 >=20 > > > > Regards, > > Jayshree > > -----Original Message----- > > From: Vijay Devarapallli [mailto:dvijay@gmail.com] > > Sent: Tuesday, November 22, 2005 8:42 PM > > To: Henrik Levkowetz > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; Kent Leung (kleung);=20 > > Nakhjiri Madjid-MNAKHJI1; Pete McCann; mip4@ietf.org;=20 > > itijibox-mip4@yahoo.com > > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > > > > On 11/22/05, Henrik Levkowetz wrote: > > > Hi Jayshree, > > > > > > I believe we've reached consensus on this. The AD is=20 > waiting for an=20 > > > updated document, so please make the change and submit a=20 > new version. > > > > just to make sure I understand what the consensus is. > > > > when Kent and I discussed this, we agreed that the MN=20 > leaves out the=20 > > challenge extension in the registration request when using=20 > co-located=20 > > CoA mode rather than include a null challenge. > > > > is this the consensus? > > > > I think we also need some text which explains that replay=20 > protection=20 > > is provided by the use of timestamp in the registration request=20 > > instead of a challenge when the mobile node is using=20 > co-located CoA mode. > > > > Vijay > > > > > > > > Regards, > > > > > > Henrik > > > > > > on 2005-11-08 17:55 Jayshree Bharatia said the following: > > > > I am also ok with this suggestion. If it is agreed by=20 > all, I can=20 > > > > change section 3.1 to reflect this change. > > > > > > > > Regards, > > > > Jayshree > > > > > > > > -----Original Message----- > > > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > > > > Behalf > > > > > > Of Kent Leung (kleung) > > > > Sent: Monday, November 07, 2005 8:40 PM > > > > To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli; Pete McCann > > > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > > > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > > > > > > > > > > I agree with this sentiment. Unless there's an issue=20 > with using=20 > > > > zero for Challenge value in the calculation for CCoA mode, this=20 > > > > problem will be addressed in the draft. The challenge is not=20 > > > > needed > > > > > > for CCoA mode since there's already Timestamp/Nonce replay=20 > > > > protection. > > > > > > > > Kent > > > > > > > >> -----Original Message----- > > > >> From: Nakhjiri Madjid-MNAKHJI1 > > > >> [mailto:Madjid.Nakhjiri@motorola.com] > > > >> Sent: Monday, November 07, 2005 4:46 PM > > > >> To: Kent Leung (kleung); Vijay Devarapallli; Pete McCann > > > >> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > > >> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > >> > > > >> The fix to deal with CCoA is a very small one as I=20 > mentioned my=20 > > > >> previous email. I really don't think it warrants a huge=20 > > > >> discussion or a doc split. The fix that we suggested=20 > was agreed=20 > > > >> by Charlie as well. > > > >> > > > >> Madjid > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > > > >> Behalf Of Kent Leung (kleung) > > > >> Sent: Monday, November 07, 2005 11:42 AM > > > >> To: Vijay Devarapallli; Pete McCann > > > >> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > > >> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > >> > > > >> On this particular topic, I don't understand what is=20 > missing in=20 > > > >> the > > > > > >> details to support the CCoA mode? Since the draft=20 > covers MN-AAA=20 > > > >> authentication with NAS in between, I would like to see both FA > > > >> (CoA) and HA (CCoA) modes supported. Where else would=20 > we be able=20 > > > >> to > > > > > >> cover just the CCoA for MN-AAA authentication if not=20 > in this draft? > > > >> > > > >> Kent > > > >> > > > >> > > > >> > > > > >> > not at this late stage. its fine as it is. however, I have > > > >> one comment > > > >> > > > >> > on the support for co-located CoA mode. the draft claims it > > > >> supports > > > >> > it but there really isnt enough detail. > > > >> > IMO, it should be clarified that only FA mode is=20 > described in=20 > > > >> > the > > > > > >> > draft. > > > >> > > > > >> > > > >> -- > > > >> Mip4 mailing list: Mip4@ietf.org > > > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > >> Charter page: > > > >> http://www.ietf.org/html.charters/mip4-charter.html > > > >> Supplemental site: http://www.mip4.org/ > > > >> > > > > > > > > > > > >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sat Nov 26 08:38:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg0Fy-0005X6-82; Sat, 26 Nov 2005 08:38:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfykN-0006TH-Qp for mip4@megatron.ietf.org; Sat, 26 Nov 2005 07:01:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01387 for ; Sat, 26 Nov 2005 07:00:57 -0500 (EST) From: invitation@iaria.org Received: from nucleon.liquidweb.com ([64.91.224.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Efz3p-0006rS-Lc for mip4@ietf.org; Sat, 26 Nov 2005 07:21:46 -0500 Received: from c-69-181-8-85.hsd1.ca.comcast.net ([69.181.8.85]:1792 helo=Oana2) by nucleon.liquidweb.com with esmtpa (Exim 4.52) id 1Efyk6-00038j-L3 for mip4@ietf.org; Sat, 26 Nov 2005 07:01:22 -0500 Message-ID: <4040784.1133006486796.JavaMail.Onitza@Oana2> Date: Sat, 26 Nov 2005 04:01:26 -0800 (PST) To: mip4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ClamAntiVirus-Scanner: This mail is clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - nucleon.liquidweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - iaria.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 26 Nov 2005 08:38:20 -0500 Subject: [Mip4] ICNS 2006 || ICAS 2006 || WSTC 2006 || Call for Submissions, Silicon Valley, July 16-23, 2006 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Apologies if you receive multiple copies. INVITATION Call for Submissions We are pleased to announce a group of 3 outstanding scientific events scheduled in Silicon Valley, mid-July 2006 Submissions could cover any of the tracks listed along with each conference. We stress out the third event which is an open context on the topics listed on the web site. Substantial prizes will be offered. Submisisons to the contest are separate from submissions to the collocated conferences. ICNS'06, International Conference on Networking and Services July 16-18, 2006, Silicon Valley, USA http://www.iaria.org/conferences/ICNS06.html ENCOT 2006: Emerging Network Communications and Technologies COMAN 2006: Network Control and Management SERVI 2006: Multi-technology service deployment and assurance NGNUS 2006: Next Generation Networks and Ubiquitous Services MPQSI 2006: Multi Provider QoS/SLA Internetworking GRID 2006: Grid Networks and Services EDNA 2006: Emergency Services and Disaster Recovery of Networks and Applications ICAS'06, International Conference on Autonomic and Autonomous Systems July 19-21, 2006, Silicon Valley, USA http://www.iaria.org/conferences/ICSA06.html SYSAT 2006: Advances in system automation AUTSY 2006: Theory and practice of autonomous systems AWARE 2006: Design and deployment of context-awareness networks, services and applications AUTONOMIC 2006: Autonomic computing: design and management of self-behavioural networks and services MCMAC 2006: Monitoring, control, and management of autonomous Self-aware CASES 2006: Automation in specialized mobile environments ALCOC 2006: Algorithms and theory for control and computation MODEL 2006: Modeling, virtualization, any-on-demand, MDA, SOA Summer Contest: WCTS'06, World Class Technology Summit July 16-23, 2006, Silicon Valley, USA http://www.iaria.org/conferences/SummerContest06.html Looking forward for your contribution, On behalf of the organizers Publicity Board: Dumitru Roman, Joel Rodriques, Damien Magoni Details: petre@iaria.org, lorenz@ieee.org -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Nov 28 07:52:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgiUK-0000Uj-Je; Mon, 28 Nov 2005 07:52:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgiUI-0000UC-VS for mip4@megatron.ietf.org; Mon, 28 Nov 2005 07:52:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29169 for ; Mon, 28 Nov 2005 07:51:23 -0500 (EST) Received: from smtp12.clb.oleane.net ([213.56.31.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egio8-0004CN-3H for mip4@ietf.org; Mon, 28 Nov 2005 08:12:39 -0500 Received: from Pavillonquatre ([194.3.133.88]) (authenticated) by smtp12.clb.oleane.net with ESMTP id jASCpbxq019028 for ; Mon, 28 Nov 2005 13:51:38 +0100 Message-Id: <200511281251.jASCpbxq019028@smtp12.clb.oleane.net> From: "Chantal Ladouce" To: Date: Mon, 28 Nov 2005 13:51:07 +0100 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcX0GmYGBCAAmw9iTWSDdC6r2pOMiA== X-Spam-Score: 0.2 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [Mip4] WiMAX Summit 06 - Paris - France X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2087322334==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============2087322334== Content-Type: multipart/alternative; boundary="----=_NextPart_000_031F_01C5F422.C876A010" This is a multi-part message in MIME format. ------=_NextPart_000_031F_01C5F422.C876A010 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit WiMAX Summit 06: Incumbent and New Entrant Operators Architectures The WiMAX Summit 2006 will be held on February 21 to 24 at the Sofitel Bercy hotel in Paris. Capitalizing on the 2005 edition success, the organizer, Upper Side plans to welcome more than 200 participants and more than 20 exhibitors, making WiMAX Summit the most important event in Europe. The conference will largely be devoted to case studies presented by both incumbent and new entrant operators who have set up WiMAX infrastructures. Get all details on the following link: http://www.upperside.fr/wimax2006/wimax2006intro.htm ------=_NextPart_000_031F_01C5F422.C876A010 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

WiMAX = Summit 06: Incumbent and New Entrant Operators = Architectures

 

The WiMAX Summit 2006 will be held on = February 21 to = 24 at the Sofitel Bercy hotel in Paris.
Capitalizing on the 2005 edition success, the organizer, Upper Side = plans to welcome more than 200 participants and more than 20 exhibitors, making = WiMAX Summit the most important event in Europe.

 

The conference will largely be devoted to case = studies presented by both incumbent and new entrant operators who have set up = WiMAX infrastructures.  

Get all details on the following = link:

 

http://www.upperside.fr/wimax2006/wimax2006intro.htm<= /a>

 

------=_NextPart_000_031F_01C5F422.C876A010-- --===============2087322334== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============2087322334==-- From mip4-bounces@ietf.org Mon Nov 28 11:15:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglfR-000290-Mv; Mon, 28 Nov 2005 11:15:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EglfP-00028s-BU for mip4@megatron.ietf.org; Mon, 28 Nov 2005 11:15:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25454 for ; Mon, 28 Nov 2005 11:14:55 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eglz9-00038v-FC for mip4@ietf.org; Mon, 28 Nov 2005 11:36:15 -0500 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id jASGSHBU000736 for ; Mon, 28 Nov 2005 09:28:17 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by il06exr01.mot.com (8.13.1/8.13.0) with ESMTP id jASGQfxF005171 for ; Mon, 28 Nov 2005 10:26:42 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Date: Mon, 28 Nov 2005 11:15:16 -0500 Message-ID: Thread-Topic: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt Thread-Index: AcXwfW7b5mTmP0CYQouEI3PF8wC+6ABdviQQAJCbn3A= From: "Nakhjiri Madjid-MNAKHJI1" To: "Kent Leung \(kleung\)" , "Vijay Devarapallli" , "Jayshree Bharatia" X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: quoted-printable Cc: Pete McCann , mip4@ietf.org, Henrik Levkowetz , itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org I agree. I don't remember anybody discussing the need for this type of addition.=20 -----Original Message----- From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 Sent: Friday, November 25, 2005 1:17 PM To: Vijay Devarapallli; Jayshree Bharatia Cc: Henrik Levkowetz; Nakhjiri Madjid-MNAKHJI1; Pete McCann; mip4@ietf.org; itijibox-mip4@yahoo.com Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt I don't think it's necessary to say replay protection of messages between MN and HA is provided by timestamp or nonce as specified in RFC 3344. This function is already explicitly stated in the base protocol. Kent =20 > -----Original Message----- > From: Vijay Devarapallli [mailto:dvijay@gmail.com] > Sent: Wednesday, November 23, 2005 2:30 PM > To: Jayshree Bharatia > Cc: Henrik Levkowetz; Kent Leung (kleung); Nakhjiri Madjid-MNAKHJI1;=20 > Pete McCann; mip4@ietf.org; itijibox-mip4@yahoo.com > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt >=20 > On 11/23/05, Jayshree Bharatia wrote: > > Vijay, > > > > My understanding of the proposal is that challenge value 0 will be=20 > > used for the calculation for co-located CoA mode. Hence, > there won't > > be challenge extension included in the registration request. >=20 > agree. >=20 > > I haven't > > included your suggestion on using timestamp for replay protection. >=20 > it wasnt mine. Kent? >=20 > Vijay >=20 > > Please propose new text for this change and I will include > it in the > > document. >=20 >=20 >=20 > > > > Regards, > > Jayshree > > -----Original Message----- > > From: Vijay Devarapallli [mailto:dvijay@gmail.com] > > Sent: Tuesday, November 22, 2005 8:42 PM > > To: Henrik Levkowetz > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; Kent Leung (kleung);=20 > > Nakhjiri Madjid-MNAKHJI1; Pete McCann; mip4@ietf.org;=20 > > itijibox-mip4@yahoo.com > > Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > > > > On 11/22/05, Henrik Levkowetz wrote: > > > Hi Jayshree, > > > > > > I believe we've reached consensus on this. The AD is > waiting for an > > > updated document, so please make the change and submit a > new version. > > > > just to make sure I understand what the consensus is. > > > > when Kent and I discussed this, we agreed that the MN > leaves out the > > challenge extension in the registration request when using > co-located > > CoA mode rather than include a null challenge. > > > > is this the consensus? > > > > I think we also need some text which explains that replay > protection > > is provided by the use of timestamp in the registration request=20 > > instead of a challenge when the mobile node is using > co-located CoA mode. > > > > Vijay > > > > > > > > Regards, > > > > > > Henrik > > > > > > on 2005-11-08 17:55 Jayshree Bharatia said the following: > > > > I am also ok with this suggestion. If it is agreed by > all, I can > > > > change section 3.1 to reflect this change. > > > > > > > > Regards, > > > > Jayshree > > > > > > > > -----Original Message----- > > > > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > > > > Behalf > > > > > > Of Kent Leung (kleung) > > > > Sent: Monday, November 07, 2005 8:40 PM > > > > To: Nakhjiri Madjid-MNAKHJI1; Vijay Devarapallli; Pete McCann > > > > Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > > > Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > > > > > > > > > > I agree with this sentiment. Unless there's an issue > with using > > > > zero for Challenge value in the calculation for CCoA mode, this=20 > > > > problem will be addressed in the draft. The challenge is not=20 > > > > needed > > > > > > for CCoA mode since there's already Timestamp/Nonce replay=20 > > > > protection. > > > > > > > > Kent > > > > > > > >> -----Original Message----- > > > >> From: Nakhjiri Madjid-MNAKHJI1 > > > >> [mailto:Madjid.Nakhjiri@motorola.com] > > > >> Sent: Monday, November 07, 2005 4:46 PM > > > >> To: Kent Leung (kleung); Vijay Devarapallli; Pete McCann > > > >> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > > >> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > >> > > > >> The fix to deal with CCoA is a very small one as I > mentioned my > > > >> previous email. I really don't think it warrants a huge=20 > > > >> discussion or a doc split. The fix that we suggested > was agreed > > > >> by Charlie as well. > > > >> > > > >> Madjid > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On=20 > > > >> Behalf Of Kent Leung (kleung) > > > >> Sent: Monday, November 07, 2005 11:42 AM > > > >> To: Vijay Devarapallli; Pete McCann > > > >> Cc: mip4@ietf.org; itijibox-mip4@yahoo.com > > > >> Subject: RE: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt > > > >> > > > >> On this particular topic, I don't understand what is > missing in > > > >> the > > > > > >> details to support the CCoA mode? Since the draft > covers MN-AAA > > > >> authentication with NAS in between, I would like to see both FA > > > >> (CoA) and HA (CCoA) modes supported. Where else would > we be able > > > >> to > > > > > >> cover just the CCoA for MN-AAA authentication if not > in this draft? > > > >> > > > >> Kent > > > >> > > > >> > > > >> > > > > >> > not at this late stage. its fine as it is. however, I have > > > >> one comment > > > >> > > > >> > on the support for co-located CoA mode. the draft claims it > > > >> supports > > > >> > it but there really isnt enough detail. > > > >> > IMO, it should be clarified that only FA mode is > described in > > > >> > the > > > > > >> > draft. > > > >> > > > > >> > > > >> -- > > > >> Mip4 mailing list: Mip4@ietf.org > > > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > >> Charter page: > > > >> http://www.ietf.org/html.charters/mip4-charter.html > > > >> Supplemental site: http://www.mip4.org/ > > > >> > > > > > > > > > > > >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 29 11:35:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8Rl-0006fe-1z; Tue, 29 Nov 2005 11:35:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh8Rj-0006fZ-MK for mip4@megatron.ietf.org; Tue, 29 Nov 2005 11:35:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29815 for ; Tue, 29 Nov 2005 11:34:26 -0500 (EST) Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh8lp-00020W-HB for mip4@ietf.org; Tue, 29 Nov 2005 11:55:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 3884690002; Tue, 29 Nov 2005 11:34:54 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29277-09; Tue, 29 Nov 2005 11:34:50 -0500 (EST) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP; Tue, 29 Nov 2005 11:34:50 -0500 (EST) X-MessageTextProcessor: DisclaimIt (2.50.252) [Starent Networks Corp.] X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Content-Class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Additional 3344bis error codes Date: Tue, 29 Nov 2005 11:34:49 -0500 Message-ID: <8A16DAD84432534FBFC19FD92B50512F05B97782@ames.starentnetworks.com> Thread-Topic: [Mip4] Additional 3344bis error codes thread-index: AcXruzciCyLsfUXyR9CHZb6ZyWnmFwJRE71g From: "Chowdhury, Kuntal" To: "Henrik Levkowetz" , "Charles E. Perkins" , "Mobile IPv4 Mailing List" , "Pete McCann" X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: "Navali, Jay" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Henrik, How about the following error codes: - MN-HA Auth failure - MN-AAA Auth failure - MN-AAA Authentication timed out with AAA (Note: currently "MN Auth failure" is sent as a generic error code for all the above) - Dynamic Home address is not available (IP Pool exhausted) - Static home address not available=20 - Require reverse-tunnel for private home address - Improper ordering of extensions (Note: currently "poorly formed request" is overloaded for this) -Kuntal > -----Original Message----- > From: mip4-bounces@ietf.org [mailto:mip4-bounces@ietf.org] On Behalf Of > Henrik Levkowetz > Sent: Thursday, November 17, 2005 2:54 PM > To: Charles E. Perkins; Mobile IPv4 Mailing List; Pete McCann > Subject: [Mip4] Additional 3344bis error codes >=20 > Hi, >=20 > I've had some feedback from the people at ipUnplugged, who have > run into some new error cases in deployments of MIPv4 where dynamic > home address allocation has been used. After some iterations and > experience with code discovering and reporting on the error cases, > it seems the following 4 HA error codes would be appropriate: >=20 >=20 > * home address already in use (as care-of address) > * care-of address already in use (as home address) > * home address is not unicast > * care-of address is not unicast >=20 > Could we consider adding these to the "Registration denied by the > home agent" error codes in Section 3.4? >=20 >=20 > ( Oh, and incidentally - 3344bis refers to RFC 1700, as reference [21], > but RFC 1700 has been replaced by IANA's online database, according to > RFC 3232, so reference [21] should probably point to the IANA web-site > and specifically to http://www.iana.org/assignments/mobileip-numbers .) >=20 >=20 > Henrik "This email message and any attachments are confidential information of = Starent Networks, Corp. The information transmitted may not be used to = create or change any contractual obligations of Starent Networks, Corp. = Any review, retransmission, dissemination or other use of, or taking of = any action in reliance upon this e-mail and its attachments by persons = or entities other than the intended recipient is prohibited. If you are = not the intended recipient, please notify the sender immediately -- by = replying to this message or by sending an email to = postmaster@starentnetworks.com -- and destroy all copies of this message = and any attachments without reading or disclosing their contents. Thank = you." -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Nov 29 16:24:28 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCxg-0001Jg-N4; Tue, 29 Nov 2005 16:24:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCxe-0001Gh-Ls for mip4@megatron.ietf.org; Tue, 29 Nov 2005 16:24:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10589 for ; Tue, 29 Nov 2005 16:23:41 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhDHm-0005YM-5N for mip4@ietf.org; Tue, 29 Nov 2005 16:45:16 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jATKnaF15199; Tue, 29 Nov 2005 12:49:36 -0800 X-mProtect: <200511292049> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14168.americas.nokia.com (172.18.141.68, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdolhcGa; Tue, 29 Nov 2005 12:49:34 PST Message-ID: <438CC6E6.1070206@iprg.nokia.com> Date: Tue, 29 Nov 2005 13:23:50 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: Jayshree Bharatia , mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hi Jayshree, > On 11/23/05, Jayshree Bharatia wrote: > >>Vijay, >> >>My understanding of the proposal is that challenge value 0 will be used >>for the calculation for co-located CoA mode. Hence, there won't be >>challenge extension included in the registration request. >>I haven't >>included your suggestion on using timestamp for replay protection. >>Please propose new text for this change and I will include it in the >>document. here are a few suggested changes to make sure 3012bis describes clearly how the co-located CoA mode works. please excuse me if some of the suggested changes look clumsy or if I overlooked something. I was not involved in 3012 standardization. :) section 3.1, replace > A mobile node MAY include the Mobile-AAA Authentication extension in > the Registration Request when the mobile node registers directly with > its home agent (using a co-located care-of address). In this case, > if the mobile node uses an SPI value of CHAP_SPI (Section 8) in the > MN-AAA Authentication extension, the mobile node MUST include the > Mobile-Foreign Challenge extension prior to the Mobile-AAA > Authentication extension. The mechanism used by the mobile node to > obtain the Challenge value in this case is outside the scope of this > document. with A mobile node MAY include the Mobile-AAA Authentication extension in the Registration Request when the mobile node registers directly with its home agent (using a co-located care-of address). In this case, the mobile node uses an SPI value of CHAP_SPI (Section 8) in the MN-AAA Authentication extension and MUST NOT include the Mobile-Foreign Challenge extension. in section 3.5, at the end of section add the following In the co-located CoA mode, the mobile node will receive a Registration Reply without the Challenge Extension and processes the Registration Reply as specified in [RFC3344]. add a new section before "Generalized Mobile IP Authentication Extension" 5. Co-located Care-of Address mode When a foreign agent is not present, the mobile node uses co-located CoA mode to send a Registration Request to the home agent. Since there is no foreign agent, there is no mobile IP specific entity in the visited network to generate a challenge. Therefore the mobile node sends a Registration Request without the Challenge extension. Replay protection for the Registration Request is provided by the Identification field [RFC3344]. in the Security Considerations sections, include the following at the end. The challenge extension specified in this document cannot be used when there is no foreign agent present in the foreign link. Replay protection is provided only by the Identification field in the Registration Request message. Vijay -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Nov 30 18:32:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhbRH-0007Ix-QR; Wed, 30 Nov 2005 18:32:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhbRE-0007Gs-Hv for mip4@megatron.ietf.org; Wed, 30 Nov 2005 18:32:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15619 for ; Wed, 30 Nov 2005 18:31:47 -0500 (EST) Received: from av11-1-sn2.hy.skanova.net ([81.228.8.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhbfI-00034X-Kt for mip4@ietf.org; Wed, 30 Nov 2005 18:47:11 -0500 Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id 720CC381A2; Thu, 1 Dec 2005 00:25:55 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id 560153815A; Thu, 1 Dec 2005 00:25:55 +0100 (CET) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 8C51537E43; Thu, 1 Dec 2005 00:25:54 +0100 (CET) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.54) id 1EhbKg-0008IZ-5v; Thu, 01 Dec 2005 00:25:50 +0100 Message-ID: <438E34FD.1010206@levkowetz.com> Date: Thu, 01 Dec 2005 00:25:49 +0100 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mobile IPv4 Mailing List X-Enigmail-Version: 0.93.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: Ted Hardie , Pete McCann , Alpesh Patel , Kent Leung , Milind Kulkarni , Henrik Levkowetz Subject: [Mip4] [Fwd: RE: DISCUSS: draft-ietf-mip4-dynamic-assignment-06.txt] X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0283515052==" Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0283515052== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF9E2EC57B8DE6B8A27878905" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF9E2EC57B8DE6B8A27878905 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, We have received a DISCUSS comment from the IESG related to the dynamic HA assignment draft, draft-ietf-mip4-dynamic-assignment-06.txt. During the responses from the authors and the WG chairs to the comment and question from Ted Hardie, it became clear that some corrections and / or clarifications of the draft text is needed. Text will be proposed to the list to handle this. Meanwhile, here is the comments leading up to this understanding. Below I first quote Ted's summary of the discussion, and then an excerpt of the thread of messages resulting from Ted's initial DISCUSS comment, in chronological order from first to last: On Wed, 30 Nov 2005 14:25:21 -0800, Ted Hardie wrote: [snip] > 1) There is a risk of misconfiguration creating a loop if there are > multiple redirects. > > 2) Given this design, the appropriate entity to detect that loop is the > client. > > 3) If detected, a client will not be able to affect the loop, but > would be able to conserve resources (network and battery, primarily) > by ceasing to traverse it. If there is an operator, the client would > also be able to inform the operator that out-of-band resolution of the > problem is needed. > > 4) At least some folks believe it would be valuable to add language to > the text describing the loop possibility and client's role in detection, > This might be augmented by advice on how many HA redirections the > client should be able to track in order to detect a loop. This is an excerpt of the thread leading up to this: [Ted] > In section 4.2, bullet 5, the document says: > > If the error code is set to REDIRECT-HA-REQ, MN obtains the HA > address from Redirected HA Extension. The MN then sends a > Registration Request to Redirected HA, unless it has already > received a redirection response from this HA while processing this > Registration Request. The MN may choose to add Requested HA > extension in this new Registration Request. > > I'm not sure if the statement "unless it has already received a redirection response > from this HA while processing this Registration Request" is meant to be > a form of loop detection. If it is, this seems like something that needs to > be called out more explicitly; if it is not, then some clarifying text on what > this means may be needed. [Kent] > Hi Ted. We couldn't figure out the intent of the identified statement. > Looks like it may be some residual of some previous versions. There is > no loop condition since the HA receiving the request always respond to > the MN, which needs to send request to new HA when Redirected HA > Extension is in the response. > > We will take out the "unless..." part of the sentence unless anyone > objects. Thanks. > [Henrik] > Umm... How is this case to be handled, then: > > MN sends a request to HA1 as requested HA. HA1 rejects registration, > but supplies HA2 as redirected HA. MN then sends a request to HA2, but > HA2 also rejects, with HA3 as redirected HA. MN continues to HA3, but > HA3 unfortunately sends a reject with HA1 (!) as redirected HA... > > A misconfiguration of the HAs, sure, and how they choose the redirected > HA is outside the scope of the specification, but how should the MN > handle this? > > If the MN started out with a plain ZERO addr, and HA1 was assigned by > an FA, the MN will not be able to detect the loop until it gets HA2 > back from HA1 the second time, but at that point it should again react. > > I agree with Ted, this would benefit from better description; including > how many HAs is an MN required to remember, for loop detection purposes? > I'd say 3 is too few, and 101 too many. Pick a favourite prime number? > (No, there's no special reason why I say prime ,;-) [Kent] > Hi Henrik. If there is a logic error in the dynamic HA assignment > algorithm/methodology, what can MN do to recover? In your example, > should MN stop registration if it detects this type of loop? And then > how does MN recover without user intervention? > > My thought is that MN follows the instructions of the network (i.e. HA) > and sends registration request to the redirected HA obediently. If > there is some misconfiguration/assignment error that ping pongs the MN > between 2 or more HAs, then MN will never be able to register > successfully. Which is the same result as if MN stopped registration > after detection. However, if a service call is made to the mobile > operator support, then the network can fix the misconfiguration/error > and the MN would automatically recover with the next registration > request. > [Henrik] > I assume that on a received redirect, the MN tries the next > HA without delay. If you just let the MN cycle, it will be > sending continuously, and if this is e.g. a cell-phone, it > will swiftly run down its batteries. > > It makes more sense to me to break the loop, wait for a while > (X seconds or minutes) and try again from the very beginning. > This has the added advantage of presenting the service > technician with a complete set of events, rather than him > being able to observe only the looping. [Pete] > As I recall, we decided on an end-to-end version of dynamic assignment > (where the MN is responsible for re-sending the RRQ) mainly so that > things like loop detection could be performed in the MN. I personally > think that if the MN detects such a loop it should give up and report > the error to the user as a way to prevent further wasting of air > interface resources. > [Alpesh] >Henrik: > >I hear your argument. I think picking a number like 8 or 10 and then >Giving up (asking for operator intervention) may be good. > >Why 8 or 10 - this is too high anyway - this many round trips and >redirections will frustrate the user (delay). > >I am fine with anything between 5-7 too. Note that this now puts >The onus on the client to detect loops or bailing out when the number >Of redirection attempts exceed. --30-- --------------enigF9E2EC57B8DE6B8A27878905 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDjjT9eVhrtTJkXCMRAjhZAJ0Wc8FadlH6BRnMfXJ/5Xj6woKnAgCgi1Lm XRc98MFsV319njflRxK0Hrs= =8ib1 -----END PGP SIGNATURE----- --------------enigF9E2EC57B8DE6B8A27878905-- --===============0283515052== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0283515052==-- From mip4-bounces@ietf.org Wed Nov 30 20:05:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhctR-0008W3-EY; Wed, 30 Nov 2005 20:05:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhctP-0008VD-NM for mip4@megatron.ietf.org; Wed, 30 Nov 2005 20:05:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27105 for ; Wed, 30 Nov 2005 20:05:01 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhdDm-0007cW-Ky for mip4@ietf.org; Wed, 30 Nov 2005 20:26:52 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id jB10V7q21186; Wed, 30 Nov 2005 16:31:07 -0800 X-mProtect: <200512010031> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14194.americas.nokia.com (172.18.141.94, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpd0yCDDh; Wed, 30 Nov 2005 16:31:05 PST Message-ID: <438E4C53.5040603@iprg.nokia.com> Date: Wed, 30 Nov 2005 17:05:23 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] review: draft-ietf-mip4-rfc3012bis-04.txt References: <2979E38DD6FC6544B789C8DAD7BAFC52E2A16C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC52E2A16C@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: mip4@ietf.org, itijibox-mip4@yahoo.com X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Hello folks, I do not believe the document should support co-located CoA mode. The point is to enable some mechanism for use by the foreign agent. There is no need for a mobile node to use the challenge. No additional replay protection is afforded. I would prefer for the use of the extension to be prohibited whenever the 'D' bit is set. Even when a foreign agent is sending 'R' bit advertisements, there isn't any significant functionality gained. Perhaps it's technically feasible to have the challenge in such situations, but (i) it is wasteful and (ii) I would not like to see it become considered a mandatory part of any mobile node implementation where co-located care-of addresses are used, for whatever reason. Regards, Charlie P. PS. Please excuse if I have overlooked some e-mail about this. Kent Leung (kleung) wrote: >On this particular topic, I don't understand what is missing in the >details to support the CCoA mode? Since the draft covers MN-AAA >authentication with NAS in between, I would like to see both FA (CoA) >and HA (CCoA) modes supported. Where else would we be able to cover >just the CCoA for MN-AAA authentication if not in this draft? > >Kent > > > > >>not at this late stage. its fine as it is. however, I have >>one comment on the support for co-located CoA mode. the draft >>claims it supports it but there really isnt enough detail. >>IMO, it should be clarified that only FA mode is described in >>the draft. >> >> >> > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Nov 30 22:28:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehf7J-0001Du-I2; Wed, 30 Nov 2005 22:28:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ehf7H-0001Dp-U5 for mip4@megatron.ietf.org; Wed, 30 Nov 2005 22:28:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11361 for ; Wed, 30 Nov 2005 22:27:30 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhfRg-0003j2-R0 for mip4@ietf.org; Wed, 30 Nov 2005 22:49:21 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 30 Nov 2005 19:28:07 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jB13RlP3014702; Wed, 30 Nov 2005 19:28:03 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Nov 2005 19:28:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2005 19:28:00 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC520101473F@xmb-sjc-235.amer.cisco.com> Thread-Topic: [Fwd: RE: DISCUSS: draft-ietf-mip4-dynamic-assignment-06.txt] Thread-Index: AcX2BXJrvQ1RhqUyT162Mlw6e2YnIgAASpPQ From: "Kent Leung \(kleung\)" To: "Henrik Levkowetz" , "Mobile IPv4 Mailing List" X-OriginalArrivalTime: 01 Dec 2005 03:28:02.0139 (UTC) FILETIME=[3C0A42B0:01C5F627] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: quoted-printable Cc: Ted Hardie , Pete McCann , "Milind Kulkarni \(mkulkarn\)" , "Alpesh Patel \(alpesh\)" Subject: [Mip4] RE: [Fwd: RE: DISCUSS: draft-ietf-mip4-dynamic-assignment-06.txt] X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip4-bounces@ietf.org Errors-To: mip4-bounces@ietf.org Here's a suggestion for new text: 5. If the error code is set to REDIRECT-HA-REQ, MN obtains the HA=20 address from Redirected HA Extension. The MN then sends a=20 Registration Request to Redirected HA. The MN may choose to add Requested HA=20 extension in this new Registration Request. If a registration loop occurs, the case when the Redirected HA is an HA that had already directed the MN to register elsewhere, then the MN stops sending any further Registration Request and provide an indication that the loop event was detected. The number of=20 consecutive Redirected HAs remembered by MN for loop detection is an=20 implementation parameter. =20 Kent=20 =20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Wednesday, November 30, 2005 3:26 PM > To: Mobile IPv4 Mailing List > Cc: Alpesh Patel (alpesh); Henrik Levkowetz; Kent Leung=20 > (kleung); Pete McCann; Milind Kulkarni (mkulkarn); Ted Hardie > Subject: [Fwd: RE: DISCUSS: draft-ietf-mip4-dynamic-assignment-06.txt] >=20 > Hi, >=20 > We have received a DISCUSS comment from the IESG related to=20 > the dynamic HA assignment draft,=20 > draft-ietf-mip4-dynamic-assignment-06.txt. >=20 > During the responses from the authors and the WG chairs to=20 > the comment and question from Ted Hardie, it became clear=20 > that some corrections and / or clarifications of the draft=20 > text is needed. >=20 > Text will be proposed to the list to handle this. Meanwhile,=20 > here is the comments leading up to this understanding. >=20 > Below I first quote Ted's summary of the discussion, and then=20 > an excerpt of the thread of messages resulting from Ted's=20 > initial DISCUSS comment, in chronological order from first to last: >=20 >=20 > On Wed, 30 Nov 2005 14:25:21 -0800, Ted Hardie wrote: >=20 > [snip] >=20 > > 1) There is a risk of misconfiguration creating a loop if there are=20 > > multiple redirects. > >=20 > > 2) Given this design, the appropriate entity to detect that loop is=20 > > the client. > >=20 > > 3) If detected, a client will not be able to affect the loop, but=20 > > would be able to conserve resources (network and battery,=20 > primarily)=20 > > by ceasing to traverse it. If there is an operator, the=20 > client would=20 > > also be able to inform the operator that out-of-band=20 > resolution of the=20 > > problem is needed. > >=20 > > 4) At least some folks believe it would be valuable to add=20 > language to=20 > > the text describing the loop possibility and client's role in=20 > > detection, This might be augmented by advice on how many HA=20 > > redirections the client should be able to track in order to=20 > detect a loop. >=20 >=20 >=20 > This is an excerpt of the thread leading up to this: >=20 > [Ted] > > In section 4.2, bullet 5, the document says: > >=20 > > If the error code is set to REDIRECT-HA-REQ, MN obtains the HA=20 > > address from Redirected HA Extension. The MN then sends a=20 > > Registration Request to Redirected HA, unless it has already=20 > > received a redirection response from this HA while=20 > processing this=20 > > Registration Request. The MN may choose to add Requested HA=20 > > extension in this new Registration Request.=20 > >=20 > > I'm not sure if the statement "unless it has already received a=20 > > redirection response from this HA while processing this=20 > Registration=20 > > Request" is meant to be a form of loop detection. If it is, this=20 > > seems like something that needs to be called out more=20 > explicitly; if=20 > > it is not, then some clarifying text on what this means may=20 > be needed. >=20 > [Kent] > > Hi Ted. We couldn't figure out the intent of the=20 > identified statement. > > Looks like it may be some residual of some previous=20 > versions. There=20 > > is no loop condition since the HA receiving the request=20 > always respond=20 > > to the MN, which needs to send request to new HA when Redirected HA=20 > > Extension is in the response. > >=20 > > We will take out the "unless..." part of the sentence unless anyone=20 > > objects. Thanks. > >=20 >=20 > [Henrik] > > Umm... How is this case to be handled, then: > >=20 > > MN sends a request to HA1 as requested HA. HA1 rejects=20 > registration,=20 > > but supplies HA2 as redirected HA. MN then sends a request to HA2,=20 > > but > > HA2 also rejects, with HA3 as redirected HA. MN continues=20 > to HA3, but > > HA3 unfortunately sends a reject with HA1 (!) as redirected HA... > >=20 > > A misconfiguration of the HAs, sure, and how they choose the=20 > > redirected HA is outside the scope of the specification, but how=20 > > should the MN handle this? > >=20 > > If the MN started out with a plain ZERO addr, and HA1 was=20 > assigned by=20 > > an FA, the MN will not be able to detect the loop until it gets HA2=20 > > back from HA1 the second time, but at that point it should=20 > again react. > >=20 > > I agree with Ted, this would benefit from better description;=20 > > including how many HAs is an MN required to remember, for=20 > loop detection purposes? > > I'd say 3 is too few, and 101 too many. Pick a favourite=20 > prime number? > > (No, there's no special reason why I say prime ,;-) >=20 >=20 > [Kent] > > Hi Henrik. If there is a logic error in the dynamic HA assignment=20 > > algorithm/methodology, what can MN do to recover? In your example,=20 > > should MN stop registration if it detects this type of=20 > loop? And then=20 > > how does MN recover without user intervention? > >=20 > > My thought is that MN follows the instructions of the network (i.e.=20 > > HA) and sends registration request to the redirected HA=20 > obediently. =20 > > If there is some misconfiguration/assignment error that=20 > ping pongs the=20 > > MN between 2 or more HAs, then MN will never be able to register=20 > > successfully. Which is the same result as if MN stopped=20 > registration=20 > > after detection. However, if a service call is made to the mobile=20 > > operator support, then the network can fix the=20 > misconfiguration/error=20 > > and the MN would automatically recover with the next registration=20 > > request. > >=20 >=20 >=20 > [Henrik] > > I assume that on a received redirect, the MN tries the next=20 > HA without=20 > > delay. If you just let the MN cycle, it will be sending=20 > continuously,=20 > > and if this is e.g. a cell-phone, it will swiftly run down its=20 > > batteries. > > > > It makes more sense to me to break the loop, wait for a while (X=20 > > seconds or minutes) and try again from the very beginning. > > This has the added advantage of presenting the service technician=20 > > with a complete set of events, rather than him being able=20 > to observe=20 > > only the looping. >=20 >=20 > [Pete] > > As I recall, we decided on an end-to-end version of dynamic=20 > assignment=20 > > (where the MN is responsible for re-sending the RRQ) mainly so that=20 > > things like loop detection could be performed in the MN. I=20 > personally=20 > > think that if the MN detects such a loop it should give up=20 > and report=20 > > the error to the user as a way to prevent further wasting of air=20 > > interface resources. > >=20 >=20 >=20 > [Alpesh] > >Henrik: > > > >I hear your argument. I think picking a number like 8 or 10 and then=20 > >Giving up (asking for operator intervention) may be good. > > > >Why 8 or 10 - this is too high anyway - this many round trips and=20 > >redirections will frustrate the user (delay). > > > >I am fine with anything between 5-7 too. Note that this now=20 > puts The=20 > >onus on the client to detect loops or bailing out when the number Of=20 > >redirection attempts exceed. >=20 >=20 >=20 > --30-- >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/